Aku db pre rychle citanie?

18. 8. 2015 11:17:22

Ahojte.

Mam par Drupal instalacii a kazda z nich ma konfiguraicu ulozenu v subore.

Chcem vsak mat lepsiu kontrolu a preto chcem mat konfiguraciu v centralizovanej DB odkial si ju budu stranky tahat.

Tento konfiguracny subor je volany pri kazdom requeste a nacitanie momentalne trva tusim 0.0002 sekundy, ak si dobre pametam.

Tym ze konfiguracia bude v DB tak potrebujem zabezpecit to, aby sa ta konfiguracia nacitala odbobne rychlo. Tzn. 0.02 oproti 0.0002 je neprijatelne.

Preto by ma zaujimalo ktora DB je extremne rychla v citani dat? Zapisovat sa bude iba zriedka, preto mi ide cisto o citanie. Je mi jedno ak sa vsetky data nakesuju pre jednu velku query alebo samostatne. Skratka jedine o co mi ide je rychlost citania.

Ktora DB by bola podla vas vhodna? Redis, Mongo, Cassandra...?

Data su pole(array) a je mi jedno ci budu ulozene ako dokument alebo ako serializovany string.

Taktiez db bude na jednej lokalnej sieti.

18. 8. 2015 11:17:22

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134169

Jamira40

(4 hodnocení)

18. 8. 2015 11:22:13

Redis bude vhodné riešenie aj preto že umožnuje "trvalé" uloženie dát po reštarte.

Aj keď na druhej strane Redis nemá nejakú extra vrstvu zabezpečenia takže treba aj na toto myslieť. Je tam len jednouchá auth ktorá sa málokedy používa.

18. 8. 2015 11:22:13

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134168

Petr Soukup

(5 hodnocení)

18. 8. 2015 11:58:00

Vzal bych to za jiný konec. Konfiguraci mít pořád v souboru (bude jí držet v paměti opcache) a do konfiguraci si uložit její verzi (třeba čas změny). To pak porovnat s hodnotou v databázi (mysql nebo klidně redis) a pokud se liší, tak aktualizovat lokální soubor s konfigurací.

Tímto způsobem se nebudou přenášet pořád ty samé informace. V případě mysql je to navíc tak jednoduchý dotaz, že vždycky bude pod 1ms. Navíc to bude fungovat i v případě webů na různých serverech (třeba v cloudu).

18. 8. 2015 11:58:00

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134167

node

(5 hodnocení)

18. 8. 2015 13:42:46

Druhy postup co ma napadol je na vyziadanie alebo v intervaloch vyexportovat udaje z db to jednotlivych konfiguracnych suborov cim by sa nestratila ziadna rychlost a zachovala by sa centralna sparava konfiguracie, avsak skript/worker by musel mat pristup ku vsetkym instalackam co nemusi byt vzdy mozne. Pripadne by kazda stranka mala skript ktory by volal DB a natiahol data z nej na zavolane z cronu a pod.

Souki - planujem to v cloude takze je mozne ze mat to iba v db moze byt celkom rychle.

18. 8. 2015 13:42:46

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134166

Václav Hodek

(9 hodnocení)

18. 8. 2015 14:32:18

A co mít nějakou lokální in-memory databázi (H2, apod.), ve které bude konfigurace dostupná velmi rychle lokálně a pomocí třeba cronu nebo stále běžícího skriptu ji synchronizovat s centrální DB. Můžeš to dělat klidně 10krát za vteřinu a jen kontrolovat časovou známku a při změně známky stáhnout konfiguraci (případně stahovat změny inkrementálně tím, že máš čas změny u každého pole). Tak máš jistou a predikovatelnou zátěž na centrální server = 10x počet klientů.

Výhodou je to, že lokální DB je rychlá, ale současně má i transakce, apod. takže je to bezpečnější než přepisovat lokální soubor, můžeš nad ní provádět více operací včetně právě třeba inkrementálních změn, plnohodnotných SQL dotazů, apod. pokud by to bylo třeba do budoucna potřeba (například při různých konfiguracích dle různých parametrů).

18. 8. 2015 14:32:18

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134165

Petr Soukup

(5 hodnocení)

18. 8. 2015 14:32:23

U nás to totiž řešíme přesně jak jsem psal - v Elasticache (Memcache/redis) se ověří číslo verze a buď se použije lokální nebo se stáhne aktuální z Elasticache.

18. 8. 2015 14:32:23

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134164

Petr Soukup

(5 hodnocení)

18. 8. 2015 14:33:14

Napsal vaclav.hodek;1218684
A co mít nějakou lokální in-memory databázi (H2, apod.), ve které bude konfigurace dostupná velmi rychle lokálně a pomocí třeba cronu nebo stále běžícího skriptu ji synchronizovat s centrální DB. Můžeš to dělat klidně 10krát za vteřinu a jen kontrolovat časovou známku a při změně známky stáhnout konfiguraci (případně stahovat změny inkrementálně tím, že máš čas změny u každého pole). Tak máš jistou a predikovatelnou zátěž na centrální server = 10x počet klientů.
Výhodou je to, že lokální DB je rychlá, ale současně má i transakce, apod. takže je to bezpečnější než přepisovat lokální soubor, můžeš nad ní provádět více operací včetně právě třeba inkrementálních změn, plnohodnotných SQL dotazů, apod. pokud by to bylo třeba do budoucna potřeba (například při různých konfiguracích dle různých parametrů).

Tohle bude fungovat možná pro tři velké servery, ale určitě ne pro malé cloudové instance. Navíc tam bude vždycky vznikat moment, kdy bude mít neaktuální config.

18. 8. 2015 14:33:14

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134163

azka

(2 hodnocení)

18. 8. 2015 14:38:00

mongo je zpopularizovana sracka, ktera nema vlastnosti ani sql ani nosql;

cassandra je lidr v nosql a taktez nejrychlejsi hrac na trhu co se read/write a skalovatelnosti tyce, velmi rychly setup, dotazujes se nad tim pomoci sql - viz netflix, spotify (ukladaj asi 100TB hudby), apple (10PB), ebay (250TB);

redis nevim, nikdy jsem na to nenasel vyuziti, ikdyz na toto se muze hodit (cassandra muze byt overkill);

co takhle si to nechat v mysql a cachovat pomoci memcache? a kde jsi zjistil ten rozdil - jak jsi to meril? jsi si jisty, ze to je ten problem? jak velky jsou ty data? nastavoval jsi mysql spravne? a uz ani nevim, k cemu potrebujes takovy rychlosti :)

18. 8. 2015 14:38:00

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134162

Václav Hodek

(9 hodnocení)

18. 8. 2015 14:38:36

Napsal Souki;1218686
Tohle bude fungovat možná pro tři velké servery, ale určitě ne pro malé cloudové instance. Navíc tam bude vždycky vznikat moment, kdy bude mít neaktuální config.

No vycházel jsem z toho, že podle předchozího příspěvku zvažoval použít cron = možná není synchronizace v řádu vteřin / minut / desítek minut klíčovou záležitostí.

---------- Příspěvek doplněn 18.08.2015 v 14:40 ----------

Napsal azka;1218687
mongo je zpopularizovana sracka, ktera nema vlastnosti ani sql ani nosql; cassandra je lidr v nosql a taktez nejrychlejsi hrac na trhu co se read/write a skalovatelnosti tyce, velmi rychly setup, dotazujes se nad tim pomoci sql - viz netflix, spotify (ukladaj asi 100TB hudby), apple (10PB), ebay (250TB); redis nevim, nikdy jsem na to nenasel vyuziti, nicmene co takhle si nechat v mysql a cachovat pomoci memcache? a kde jsi zjistil ten rozdil? jsi si jisty, ze to je ten problem?

Cassandru jsme testovali a je rychlá, pokud k tomu nastavíš podmínky. Na jednom obyčejném serveru bez specifické konfigurace nevyužiješ její potenciál naplno. To už je lepší ta MySQL (snažší na instalaci, konfiguraci, použití).

18. 8. 2015 14:38:36

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134161

azka

(2 hodnocení)

18. 8. 2015 14:52:47

Napsal vaclav.hodek;1218688
Cassandru jsme testovali a je rychlá, pokud k tomu nastavíš podmínky. Na jednom obyčejném serveru bez specifické konfigurace nevyužiješ její potenciál naplno. To už je lepší ta MySQL (snažší na instalaci, konfiguraci, použití).

mate pravdu, nechtel jsem se rozepisovat, cassandra tezi z velkeho poctu nodes a tudiz je pro velky projekty, jen jsem nahodil overview (vypadalo to, ze op o tom moc nevi), necekam, ze pouzije neco podobnyho, kdyz je u toho mnoho moznosti, co predtim zkusit, spravne nastavena a vyuzita single instance mysql nejspis bude o dost rychlejsi, a nejspis budou i patrny rozdily mezi samotnymi mysql distribucemi

nejrealnejsi verze je pro me cachovat sql dotaz (result) pomoci php memcache (budes mit key/value a nemusis nahazovat napr. redis), ale asi budes potrebovat knihovnu :)

18. 8. 2015 14:52:47

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134160

node

(5 hodnocení)

18. 8. 2015 15:48:23

Ono tych zaznamov/konfiguracii bude smiesny pocet a menit sa to bude raz za sto rokov a ak by sa konfiguracia stahovala pre mna za mna aj niekolko sekund raz za cas ked sa aktualizuje tak to absolutne nie je ziaden problem. Ide mi len o to mat to centralizovane a nechcem novym riesenim vniest akekolvek spomalenie do aktualneho stavu.

mongo je zpopularizovana sracka, ktera nema vlastnosti ani sql ani nosql;

Ked som s nou robil tak mi vyhovovala a urcite to nie je ziadna sracka, len sa to musi spravne vyuzit.

Ako tak teraz nad tym rozmyslam je blbost to tahat z db pri kazdom pristupe. Asi si to necham "niekde" a spravim si nejaky Python skript ktory to bude raz za cas aktualizovat do lokalneho suboru a je to.

18. 8. 2015 15:48:23

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134159

Petr Soukup

(5 hodnocení)

18. 8. 2015 16:43:23

Pokud to má být v cloudu, tak bych ještě zvážil na to využít rovnou nějaké CI. Například v AWS na to je CodeDeploy. Změní se konfigurace v gitu, zmáčkne se tlačítko a CodeDeploy se postará o distribuci.

Jde tím pak hezky řešit i vracení se k předchozí verzi apod.

18. 8. 2015 16:43:23

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134158

node

(5 hodnocení)

18. 8. 2015 16:56:09

Toto praveze v kode nebude, o tom je ta databaza.

18. 8. 2015 16:56:09

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134157

Roman

(15 hodnocení)

18. 8. 2015 20:58:52

Nečetl jsem diskusi, takže pokud je příspěvek mimo, prosím ignorovat. Dotaz zněl na rychlejší databázi, vím, že velmi oblíbená je MariaDB, víc najdete na netu.

18. 8. 2015 20:58:52

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134156

Gav

18. 8. 2015 21:13:05

Sorry, ale to je dotaz jako stehno....neco jako chci rychli auto, ale musi jezdit fakt rychle! (a asi bejt levny); specifikujte pozadavky, specifikujte cenovou predstavu.

Nebo to nereste a kupte si Exadatu, to by melo stacit

http://www.oracle.com/technetwork/database/exadata/exadata-x5-2-ds-2406241.pdf

18. 8. 2015 21:13:05

https://webtrh.cz/diskuse/aku-db-pre-rychle-citanie/#reply1134155