HOVD 2016 - Kedvenc adatbázis-kezelő

az megvan, hogy a nosql azt jelenti, hogy nem sql? :-)
Es az megvan, hogy a no-sql meg nem azt jelenti hogy nincs sema? Csak annyit, hogy a lekerdezes nem SQL-el tortenik. Egeszen pontosan "Not Only SQL."
Bar ertem en, hogy felrevezeto annak aki csak SQL-t latott eddig mint "adatbazist", es most itt egy "uj" dolog. Lets call it nosql! :) Biztos "csipobol tuzelt" a nevadoja. Kb annyi ertelme van mint az "organikus" termek elnevezesnek az itteni boltokban.
A nosql kicsit szerencsetlen nev, feltehetoen olyan valakitol, aki azt hitte hogy a sema miatt van SQL. :) Valoszinu valami "ujsagirotol", aki nem csak a hackert keveri ossze a cracker-el, hanem meg sok egyeb mast is.
SQL kepes lehet kezelni dinamikus semat, semmi nem tarja vissza tole. Vagy nem tabla alapu szerkezetet is lehet SQL-el lekerdezni, csak az implementacion mulik.

Es bizony a MongoDB DB-nek is van semaja, csak dinamikus. Minden dokumentun lehet teljesen kulonbozo. Igaz, akkor az egesznek nem sok ertelme van (ugrott a sharding (no shard key), az indexeknek semmi ertelme, stb.) Ha megnezed, szerintem minden Mongo "adatbazis" "tablanak" van valamilyen alap semaja, amelyhez extra "mezok" tartoznak egyes dokumentumoknal. Talan egy jo pelda a session adatok tarolasa, ahol az elobbi eset nyilvanvalo. Es talan, ez az egyetlen ertelmes felhasznalasi esete a MongoDB-nek. (szemely szerint, akkor is mast valasztanek). Es persze a MongoDB is rendelkezhetne SQL felulettel, de a JSON cool-abb volt, feltehetoen. Es akkor nem lehetne nosql-nek hivi tiszta szivvel.

Adatbazis nem csak "SQL" letezik, sot az SQL (Structured Query Language = strukturalt lekerdezesi nyelv) nem adatbazis, csak egy adat lekerdezesi lehetoseg. Van adatbazis, amely tobb fele lekerdezesi feluletet is bistosit (pl: PROGRESS kettot is 4GL es SQL, vagy az altalam emlitett Cassandra is tamogatott kettot egy idoben, talan meg most is vissza kapcsolhato a regi).
Semaja nem "SQL" adatbasisoknak is van / lehet. Az SQL csak segit, hogy ne szivj mindenfele CRC (stb.) hibaval csak azert, mert modositottal valamit (lasd kezdeti PROGRESS 4GL es egyeb "legacy" cucc). En meg emlekszem a banki szoftver ujraforditasara object code-bol, mert az egyik tablan csinaltunk egy uj indexet (vagy valami hasonlo ostoba ok miatt).

Egyebkent meg B.U.E.K. Otthon mar Uj Ev van. :)

Vagy még gyakrabban Not-Only-SQL, tehát ahhoz képet SQL-szerű nyelveket is támogat, nem csak szigorúan vett SQL-t. :)

Az előzményeket nem tudom pontosan, mivel már csak akkor sikítottak, mikor már ötletük sem volt a problémára. Utólag nézve a dolgokat olyasmi lehetett, hogy valaki szerint túl sok CPU-t evett túl sokáig a Cassandra és kill -9 `pidof java`. Ez nyilván korrupciót okozó tevékenység :), de volt rá példa, hogy egy sima reboot után is teker-teker-teker majd összeomlik. A logokban adatfájl korrupcióra panaszkodik. Volt memória foglalásos hibánk is Cassandra-val, ami az adatfájlok felolvasásakor keletkezett (izgi, mert bőven elég memória van a gépben).

Az adott példány adatfájljai közt lett egy korrupt, szóval a többiekre ez nem volt hatással. Az viszont kínos, hogy várunk az elindulásra 10-30 percet, majd valahol félúton összecsuklik az adatfájlok felolvasása közben. A megoldás végül az lett az idő szorítása miatt, hogy minden adatfájlt töröltünk, majd lefutott a replikáció a (még) jól működő node-okról. Utáltam a "megoldást", tiszta gányolás az egész..

A mentés + visszaállítás toolra hatalmas +1, nincs egy normális eszköz. Szerintem ez a probléma a Netflix-nél is előjött, ha csináltak rá jó tool-t, akkor közzétehetnék. :D