Itt egy kérdés, amit sokszor hallunk: SQL vagy NoSQL adatbázisokat használjak? Ezt a kérdést legtöbbször azért teszik fel, mert mögötte egy másik kérdés áll: mi a rossz az SQL adatbázisokban, amit a NoSQL adatbázisokban kijavítottak? Erre már sokkal könnyebb válaszolni. Semmi sem rossz, csupán másképp közelítik meg az adatbázisok létrehozását: ugyanúgy, ahogy egy assembler, és egy magasabb szintű nyelvvel is másképp lehet alkalmazásokat létrehozni.

Gondoljunk csak a magas szintű nyelvekre! Elvonatkoztatja a gépi kód összes – így az ütemezéssel, memóriakezeléssel, megszakításokkal, processzorvermekkel és a pufferekkel kapcsolatos jellemzőjét egy intellektuális keretrendszerbe, ami maga a nyelv. Megírjuk a programot a nyelvben, majd belép egy fordító- vagy értelmezőprogram, és olyan feldolgozható nagyságú gépi kóddá (más néven köztes kóddá) alakítja, ami futtatható valós hardveren. Ezzel azonban már nem is kell törődünk, csak az fontos, hogy a kód minden gép esetén alkalmazható legyen. 

Hasonlóképpen tekinthetünk az SQL-re: amikor megírunk egy magas szintű lekérdezést, amely általában átvihető a különböző SQL adatbázisok között, akkor azt az adatbázis belső fordító- vagy értelmezőprogramja végrehajtható műveletekké alakítja, ami így futtatható lesz. Az adatbázisban lévő lekérdezőmotor pedig megkeresi az optimális módot arra, hogy az SQL lekérdezést optimális műveletsorrá alakítsa. Általában csak akkor törődünk azzal ami történik, amikor a lekérdezés nem a remélt gyorsasággal megy végbe. Ugyanígy, csak akkor foglalkozunk a fordítóprogrammal, amikor az alkalmazás számára az lassú kódot generál.

Most pedig gondoljunk az assemblerre! Egy assembler csak arra a processzorcsaládra jellemző, amelyen fut. Ezek a legkisebb műveletek amivel a processzor programozható, és olyan gyorsan futtathatók, amilyen sebességre a processzor képes. Pontosan azt teszik, amire hivatottak, és semmi többet. A magas szintű nyelvek fordítóprogramjai (végső soron) átalakítják a programokat egy assemblerré, hogy futtathatóvá váljanak, azonban a pusztán assemblerben történő programírás még hatékonyabb lehet, ha számításba vesszük a processzor összes belső „mozgó alkatrészét”. Ennek az a hátránya, hogy az assemblerkódot nem lehet áthelyezni másik processzorcsaládra.

És most gondoljunk ugyanígy a NoSQL-re! A lekérdezőmotor és az adatbázis – egy API által hozzáférhetővé tett – alacsony szintű műveletei révén még jobban irányíthatók. Az adatbázisok esetén ez olyan, mint megtalálni egy bejegyzést, frissíteni kulccsal, vagy operandusok sorából lekérdezést készíteni. Az alkalmazások képesek kombinálni ezeket a kicsi művelteket, és ezáltal erőteljes műveleteket hoznak létre. 

Az SQL világában nem azért jelent meg a NoSQL, hogy a helyébe lépjen, hanem azért, hogy lehetővé tegye a kísérletezést az adatbázisokkal kapcsolatos új gondolkodásmódokkal, és azokat egyéni feladatokra optimalizálják. Ugyanez az assemblerrel kapcsolatos szituáció érvényes a NoSQL-re is: közvetlenül irányható vele az alapjául szolgáló rendszer, így nekünk kell törődnünk a rendszer kezelésével –  az  indexek kiválasztásával, megbízható, egymással nem ütköző műveletek létrehozásával, egyéb műveletek kizárásával. Ezek olyan dolgok, amelyekről valamikor a munka során minden szinten gondoskodnunk kell. A jó hír az, hogy a NoSQL adatbázisok sokat fejlődtek, így az alapul szolgáló mechanizmusok sokkal rugalmasabbak és megbízhatóbbak ez ügyben. A NoSQL adatbázisok emellett fókuszálnak arra is, hogy speciális adattípusok és adatszerkezetek esetén - JSON-dokumentumokra, oszlopos tárolásra, gráfokra -, illetve eltérő architektúrákban - in-memory, shardolt, elosztott, replikált - különösen jó hatásfokkal működjenek.

Az SQL általános felhasználási célú nyelv. Relációs, táblázatközpontú struktúrát alkalmaz, és a szándékaink értelmezésével, az adatbázisra támaszkodva hozhatunk optimális döntéseket, továbbá a legjobb módszert javasolják az eredmények elérése érdekében. Az SQL arra is hatással volt, hogy az idők folyamán hogyan működtek és fejlődtek az alapjául szolgáló adatbázisok.

Hogy egy másik analógiát alkalmazzunk, a NoSQL olyan, mint amilyenek a RISC processzorok voltak a CISC processzorokkal szemben a ’80-as, ’90-es években. A RISC processzorok teljesen új megközelítést tettek lehetővé a chiptervezők számára, hogy kezeljék a skálázódás problémáit, és az optimalizált utasítás-szettek feladatát átadták a fordítóprogramnak, amit arra használtak, hogy előállítsa a kódot a RISC chipeknek. Egyesek addig jutottak, hogy a CISC utasításokat menet közben RISC utasításokká alakították. A két megközelítés sokszor teljesítménybeli harcot vívott egymással. Hol tartunk most? A RISC processzorokból tanultakat alkalmazták a CISC processzorok tervezése esetén, mindemellett milliárdnyi energiafelhasználásra optimalizált eszközben található meg a RISC chipek új, még összetettebb osztálya – kitöltve a valaha volt legnagyobb piaci rést.

Itt jön a dolog menő része. E milliárdnyi eszköz együttműködik az összes CISC és a többi RISC eszközzel az internet és a felhő milliónyi szervere segítségével. Ez nem egy vagy-vagy választás. Ez a „legjobbat-a-feladathoz” választás. Amikor valaki 2016-ban elmegy számítógépet venni, akkor a felhasználási módnak megfelelően választ és nem az alapján, hogy a CPU ja RISC vagy CISC tervezési filozófia alapján készült-e. Hasonlóan, amikor adatbázist vagy adatbázisokat választunk egy feladathoz, az annak való megfelelés alapján választunk.

Ez ismét felveti az assembler/magasabb szintű nyelv analógiáját ebben a kontextusban. Ez az analógia egy egyszerű megközelítést ad arról, miként hat az SQL és a NoSQL a megfelelőséggel kapcsolatos döntésre. Egy NoSQL adatbázis általában egy adott problémacsoportra lesz optimalizálva, és fontos tudatában lenni annak, melyek ezek a problémák. Az SQL – legalábbis elméletileg – alkalmazható egy NoSQL adatbázis műveleteiben, és léteznek olyan eszközök, amelyek segítségével ez elvégezhető. Ezek rendszerint az üzleti intelligenciai és üzleti analitikai termékek között keresendők. Néhány NoSQL adatbázis ugyanezeket az ötleteket használja fel, és SQL részegységeket is kínál, és ezzel a NoSQL assemblere közelebb kerül a magas szintű nyelvek képességeihez.

Válaszd a NoSQL-t, és megkapod a kulcsot az adatbázishoz, akárcsak a komponensek speciális összeállított csoportját, illetve a tetszés szerinti összeállítás szabadságát! Válaszd az SQL-t, és kapsz – úgymond – egy jól felszerelt félig-önvezető autót, amelyik minden nap hatékonyan elvisz A-ból B-be! Fejlesztőként sosem mondjuk, hogy „csak assemblert fogok használni az összes alkalmazásomhoz” vagy „csak ezt a magas szintű nyelvet fogom használni”, hanem nyitva hagyunk minden lehetőséget.

Mi a legjobb megoldás? Válaszd, ami a legmegfelelőbb az elvégzendő feladat számára; ne csak egyet, hanem annyit, amennyire csak szükséged van! Ha az alkalmazás stack-nek szüksége van egy in-memory adatbázisra vagy egy messaging buszra, ami egy, az ügyfélkezelési alkalmazásokhoz használt dokumentum adatbázis segítségével összekapcsolja az alkalmazásokat, egy back-end analízishez használt adatbázisra és egy JSON dokumentum keresési adatbázisra, akkor ezt az architektúrát javasoljuk.

(Forrás)

 ***
Ha Te is kreatív, kihívásokkal teli mérnök állást keresel minőségi munkáltatónál, jó helyen jársz, mert a Schönherz Bázis épp azért jött létre, hogy Neked segítsen!

Gyere, nézz szét aktuális állásaink között!