Distribuovaná key-value databáze

[petersveter]

Potrebujem nejaku distribuovanu databazu alebo cache(idealne s moznostou ulozit data na disk kvoli restartu a prevencii studeneho startu) ktora bude medzi N servermi(bavme sa o dvojcifernom cisle) synchronizovat svoj stav. Kazdy server ma vlastny namespace, cize povedzme ze [ip adresa]/[kluc] = [hodnota] s tym ze ja prakticky ani hodnotu nepotrebujem. V principe mi ide len o to vediet ktory server ma aky kluc. Viete o niecom jednoduchom? Nieco comu len mozem posunut zoznam ip adries, a ten zoznam menit podla toho ako servery pribudnu a ubudnu, a ono si to proste zosynchronizuje stav tak, ze vsade je totozny.

Pozeral som rqlite, dqlite co su len sqlite obalene raftom, etcd co je bolt tiez obaleny raftom, ale nepride mi to uplne idealne. Navyse pre raft sa odporuca max 7 serverov a teda to v principe je na iny ucel nez chcem ja. Pretoze ja nehladam distribuovanu db ale skor chcem mat lokalnu db pre kazdy server ktora reflektuje globalny stav, nie distribuovanu db ktoru mozem dopytovat cez siet.

Viem si to napisat aj sam ale moc sa mi nechce...

PS: kazdy server bude mat len par tisic klucov, nejde o nejake masivne data.

[Reklama]

[alex6bbc]

tak kdyz nepotrebujes "value" tak to udelej klic=ip/hodnota=jakoze_klic.

co chces dosahnout, nejaky loadbalancing?
to by slo udelat i pomoci jinych systemu nez key/value db, treba pomoci txt zaznamu v dns, pomoci pingovani serveru apod.

[petersveter]

tak kdyz nepotrebujes "value" tak to udelej klic=ip/hodnota=jakoze_klic.

co chces dosahnout, nejaky loadbalancing?
to by slo udelat i pomoci jinych systemu nez key/value db, treba pomoci txt zaznamu v dns, pomoci pingovani serveru apod.

Je to pre CDN siet. Robim refactoring logiky a prakticky potrebujem aby nody medzi sebou vedeli kto ma aky subor. Aktualne sa dopytuju svojich peerov ale chcem to prerobit, kvoli rastu poctu serverov do buducna,  aby proste kazdy cdn node vedel od koho si ma subor pytat. Rozmyslam implementovat centraly zdroj informacii ako taky metadatovy server kam kazdy cdn node posle info ze ma subor alebo ze ho zmazal, takze nan sa budu cdn nody dopytovat, ale je tam problem ze ked tento metadatovy server pojde dolu(udrzba a podobne), tak nody by museli bud skusat kazdeho peera(ako to je teraz), vratit 500vku, alebo si subor stiahnut z originu, co moze sposobit ze viacero nodov stiahne totozny subor a spravia mi tak zbytocny traffic na externej object storage sluzbe, comu sa chcem za kazdu cenu vyhnut.

Mozem pouzit externu sluzbu namiesto vlastneho md serveru, ako je turso, ale v principe je to totozne ako vlastny md server akurat je to "cloudove" riesenie a teda neziskam nic moc oproti svojmu serveru.

Takze sa priklanam prave k tomu aby existoval globalny zoznam kde kazdy server ma svoj namespace kde ma zoznam suborov ktore ma a kde kazdy node moze zistit kto vsetko ma subor a postupne sa dopytovat peerov a ist teda na istotu(ak peer samozrejme nie je offline).

Kazdy node robi mutaciu iba svojmu namespace ([ip adresa]/*) takze nehrozi ziadna kolizia operacii. Kazdy node si periodicky aktualizuje zoznam ip adries peerov takze vie kam sa ma napojit ale zase nema zmysel sa napajat na kazdy node a streamovat z neho jeho zoznam aby si vytvoril vlastny globalny zoznam. Preto chcem aby to bolo riesene uz nejakym toolom ktory bezi lokalne na kazdom cdn node a len mu davam zoznam ip adrries s ktorymi ma komunikovat a lokalne len don robim get/set zapis ktore nasledne sychronizuje sam a nemusim to riesit ja.

[petersveter]

Este ma napadlo ze vlastne by som to mohol skombinovat tak ze bude teda ten metadatovy server kam nody budu posielat "mam subor" a "nemam subor" ked ho zmazu lebo nebol dlho servirovany. A zaroven budu z tohto metadatoveho serveru streamovat globalny stav. Takze je to centralizovane stale a ked ten md server bude offline tak maju stale posledny aktualny stav s ktorym mozu pracovat a ked sa znovu pripoija na ten md server tak len odoslu lokalne zmeny od posledneho odoslanie, pripadne cely lokalny stav ak je to len ramke a je to. To by mohlo stacit.

[CPU]

Máš jádro "redakčního systému", které pro obrázek pomeranč.jpg může vrátit:
server_[1..2]_pomeranč.jpg (Tj. řídí to jádro tvého redakčního systému.)

Ale pro banán.jpg ti vrátí jen server_1, protože není v XY instancí.

Takže:
* redakční systém může uživateli doporučovat CDN podle jeho GEO-umístění, to se hodí jednak na optimalizaci přenosu a jednak na obsah CDN, možná některá data nejsou pro některé GEO-umístění tolik důleitá
* redakční systém ví, kolik požadavků je na který CDN směrováno (stačí in memory table)
* redakční systém může sám zkontrolovat, jestli soubor na CDN skutečně je a případně se léčit
* redačkní systém může používat i jednoduchý round-robin
* redakční systém může řídit spouštění dalších CDN serverů
* CDN server nepotřebuje žádnou zvláštní logiku, prostě jen podává soubory přes HTTPS
* celé se to ladí o trochu snáz
...

A pak jsou samozřejmě i určité nevýhody, ale tohle je z hlediska implementace poměrně jednoduché a nemusíš složitě řešit distribuci databáze.

Příklad, rozhodneš se porovnávat všechny soubory server_[1..2]_pomeranč.jpg, to klidně můžeš offloadovat na jiný server, který soubory stahuje a kontroluje jejich konzistenci (jestli nějaký není uříznutý). Takový "makáč" ti pak může řešit i samotný přenos dat na další CDN servery, protože je nebude tahat z jádra systému, ale jako zdroj použije CDN servery a jen to, co na CDN serverech není.

Makáč někde mimo jádro může:
- monitorovat odezvu každého CDN serveru
- pokud detekuje poškozený soubor, provede jeho vyřazení, kopii a znovu publikování daného obsahu a to bez zatěžování linky k hlavnímu serveru
....

[Reklama]

[Filip Jirsák]

Database of Databases

[František Ryšánek]

Nedávno jsem zaslechl, že některé z požadovaných vlastností má Apache Cassandra = distribuovaný KV store.

Nebo si dovedu představit, že by se asi dalo něco stlouct na bázi "CEPH + něco nad tím v souborech" - ale u takové vlastní tvorby může být obtížné, ošetřit konkurenci při přístupu k souborům.

[M_D]

Poslední dny bylo celkem haló kolem Redisu a asi by uměl, co ochceš. Respektive kombinace Redis+Sentinel. Jeden uzel je master, tam zapisuji změny, na ten se ti navěsí ty uzly a k sobě replikují stav toho masteru. Takže máš lokální Redis db s infem o souborech pro čtení, změny zapisuješ do jednoho mastera. Sentinel slouží k tomu, když ti ten master chcípne, aby se zvolil nový master, který bude pro zápisy (a Redis uzly se překonfigurují dle Sentinelu na nový master). Sentinel bych pustil jen na několika z těch uzlů, asi 5 plně stačí.
Jméno souboru by byl klíč, datový typ sorted set. Score je čas poslední aktualizace a hodnota odkaz na server. Můžeš použít TTL, když data o daném seouboru dost dlouho nikdo neobčerství, samo se to v DB smaže.
https://redis.io/docs/management/sentinel/
Ale dá se vymyslet/použít řada jiného. :-)

[petersveter]

Na koniec som sa rozhodol ze budem mat md server ale nebude sa streamovat stejt nikam ale proste ked node nema subor tak sa spyta md serveru kto ho ma, cize vlastne obycajna vzdialena db.