[Videó] Spanner: SQL adatbázis a Gmail és a YouTube alatt

HUP

Tőzsér Tamás (Doctusoft/Aliz)

Hatalmas fejlődés tapasztalható az elmúlt években a backend területen is - az egyik komoly innováció a területen a Google-féle Spanner adatbázis, amely (elvben) lehetetlent állít magáról. A CAP tétel ugyanis kimondja, hogy az elosztott rendszereknek választaniuk kell a rendelkezésre állás és konzisztencia között. Google Cloud Spannerre ennek ellenére korlátlanul skálázható konzisztens adatbázisnak írja le magát, ami egyesíti az SQL és NoSQL világ előnyeit. Hogyan lehetséges ez a gyakorlatban? A Doctusoftnál nap mint nap találkozunk olyan kihívásokkal, amiket meg lehetne oldani Spannerrel. AODocs - egy sok TB-os felhő alapú alkalmazás - esettanulmányként használható, hogy milyen problémák járnak együtt a NoSQL adatbázisokkal és hogy Spanner hogyan tudja megoldani ezeket.

(Az előadás a 2017-es HWSW mobile! termékfejlesztési konferencián hangzott el.)

( joco01 v | 2021. 03. 15., h – 14:04 )

A Spanner király, és főleg érdekes egy külsőstől hallani róla :)

( turul16 v | 2021. 03. 18., cs – 08:59 )

Szerkesztve: 2021. 03. 18., cs – 12:23

Szoval ez egy CP rendszer nemi plusz high avilibility megoldassal, CA -nak reklamozva.
Reletive magas valasz idokkel ~5ms , amit tartani kepes nagyobb konkurincia esteben is,
mas megoldasok nem annyira.

A video olyen estben ajanlja amikor par node -ba nem praktikus annyi adatot hordozot bele tenni
amire szukseg lenne. Kis (<256GB) kozisztes DB-ket valoszinuleg nem erdemes erre tenni.

A video szaz ezres write intent transakcio szamot emleget, amire nem talaltam publikalt teszt eredmenyt.
Szazres valoban konzisztes  tranzakciok eleresehez valoszinuleg RDMA szukseges es local halozat .
(Nahany speciallies esetben lehet tobb, de .. )

BTW, mi legjobb elosztott consistens RDMA -t hasznalni kepes adatbazis ?
<1ms valasz idok, 100 000 kozeli tranzikcio szammal ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.