Ahoj,
chtěl bych nahradit PostgreSQL nějakou in-memory databází. V aplikacích, se kterými se setkávám, nepřesahují databáze desítky GB. Což je dnes možné nakoupit v RAM.
Chtěl bych, aby to mělo data v RAM. Ale na SSD disky s NVRAM řadičem to zapisovalo - aby to prostě bylo i na disku. Nechci aby to fungovalo jen jako cache bloků. Příjde mi, že projít index půlením intervalu u lineárního seznamu v RAM je několikrát rychlejší než mít to v RAM po blocích jako na disku.
Pak bych chtěl aby to mělo dobré SQL. Umělo to i XML sloupec v tabulce (xpath). Referenční integritu. Transakce. View. Nějaký rozumný jazyk pro uložené procedury. Triggery. Ideálně i materializované view.
A aby se to dalo pořídit za cenu úměrnou výsledné aplikaci. Zrychlit se dá i ve firmě s malým obratem.
Nemáte někdo přehled o stávajících řešeních ? Nebo o slibných vyvíjejících se projektech ?
Díky
SQLite? https://www.sqlite.org/inmemorydb.html
Záleží na tom, co se od toho chce. Samozřejmě mě prvně napadlo použití SQLite v RAM, ale podle popisu požadavků chceš také nějakou perzistenci. Pokud ne, tak bys mohl v objektovém jazyce používat kolekce a bylo by vymalováno.
Další možností je databáze Redis. Nemá sice SQL, ale zato umí přímo pracovat s kolekcemi.
Citace od: Ivan Nový kdy 20. 10. 2016, 21:07:09
SQLite? https://www.sqlite.org/inmemorydb.html
po přečtení toho odkazu si nejsem jistý, jestli to in memory neznamená, že se to neukládá na disk a že to není v RAM organizováno po blocích stejně jako na disku. Připadá mi to jako návod jak to spustit v RAMdisku. Pletu se?
Citace od: Kit kdy 20. 10. 2016, 21:22:43
Další možností je databáze Redis. Nemá sice SQL, ale zato umí přímo pracovat s kolekcemi.
SQL je potřeba, když přijde zákazník a chce specifický report. Přijde mi, že přes SQL se to dá jednodušeji a rychleji programovat a testovat než to zpracovávat programem. Navíc SQL se dá napojit třeba na excel a dělat kontingenční tabulky. Takže za chvíli mám view které si jen zákazník načítá do excelu a sám si dělá pohledy na ty data přes kontingenčky.
Souzní mi to v halvě jako regulární výrazy - ty mají specifický jedinečný výrazový prostředek jak to elegantně udělat. Ale je fakt, že se to málo programátorů naučí používat.
SQL je potřeba. Vidím spousty aplikací, které neumí udělat join a řeší to na úrovni programu.
Citace od: Kit kdy 20. 10. 2016, 21:22:43
Záleží na tom, co se od toho chce. Samozřejmě mě prvně napadlo použití SQLite v RAM, ale podle popisu požadavků chceš také nějakou perzistenci. Pokud ne, tak bys mohl v objektovém jazyce používat kolekce a bylo by vymalováno.
Další možností je databáze Redis. Nemá sice SQL, ale zato umí přímo pracovat s kolekcemi.
Přece si ji musíš i napsat. Používat už hotové řešení není přece cool.
Citace od: Paja kdy 20. 10. 2016, 21:33:56
SQL je potřeba. Vidím spousty aplikací, které neumí udělat join a řeší to na úrovni programu.
V tom případě vidím jako nejjednodušší řešení zůstat u PostgreSQL a ten databázový stroj trochu vytunit.
SAP HANA
https://en.wikipedia.org/wiki/SAP_HANA
Citace od: Kit kdy 20. 10. 2016, 21:47:07
Citace od: Paja kdy 20. 10. 2016, 21:33:56
SQL je potřeba. Vidím spousty aplikací, které neumí udělat join a řeší to na úrovni programu.
V tom případě vidím jako nejjednodušší řešení zůstat u PostgreSQL a ten databázový stroj trochu vytunit.
+1
Citace od: Paja...
Čo vlastne potrebuješ zrýchliť? Čítanie, alebo zápisy? Ak zápisy, tak mnohonásobné zrýchlenie postgresu sa dá dosiahnuť vypnutím fsync. Prídeš tým o dáta v prípade havárie, ale keď hovoríme o in-memory databázach, tak to sa asi rozumie samo sebou. Čítanie sa zase obvykle dá ľahko zrýchliť dostatkom RAM, správnymi indexami, či optimalizáciou SQL dotazov.
Co použít nějakou databázi s master-slave replikací, kde master bude in memory a slave on-disk? Záleží jak hodně konkurenčních přístupů tam bude a jaký bude podíl čtení/zápisy.
Třeba se podívat na http://www.h2database.com/html/features.html In-memory má, procedury má, replikaci taky... ale zda se pro tento účel a objem dat skutečně hodí, to nevím. Na druhou stranu někde se začít musí a je tam i porovnání s dalšími databázemi :-)
In-memory technologii obsahuje SQL Server 2016, i předchozí verze 2014. Ale podle všeho jen v edicích Enterprise, Developer a Evaluation. Podotýkám že MS SQL Server i dříve uváděná DB SAP HANA jsou placené, a není to úplně levné. Výhodou je vysoký výkon a plný ACID, s důrazem na D jako Durability.
https://www.youtube.com/watch?v=l5l5eophmK4
Citace od: Trupik kdy 20. 10. 2016, 22:11:58
Čo vlastne potrebuješ zrýchliť? Čítanie, alebo zápisy? Ak zápisy, tak mnohonásobné zrýchlenie postgresu sa dá dosiahnuť vypnutím fsync. Prídeš tým o dáta v prípade havárie, ale keď hovoríme o in-memory databázach, tak to sa asi rozumie samo sebou. Čítanie sa zase obvykle dá ľahko zrýchliť dostatkom RAM, správnymi indexami, či optimalizáciou SQL dotazov.
Nejde mi o řešení nějaké aktulní situace. S posgresem žiju už 10 let a tuním ho, optimalizuju ... Trochu opruz je simulovat v něm materializované view.
Ale žiju v představě (možná mi ji někdo vyvrátíte), že postges používá nějakou komplikovanou strategii pro vlastní cache a co nemá u sebe je v cache souborů v RAM linuxu. A příjde mi, že pokud by se celé tabulky a indexy načetli do RAM v lineárním adresování, snížila by se režie přístupu k datům v RAM. Nemuselo by se to přepočítávat na bloky atd. Možná by to mohlo umět používat i SIMD nebo podobné moderní instrukce CPU, mohlo by to být lépe optimalizované pro víceprocesorové zpracování a kdoví co dál.
Prostě by stejný dotaz mohl trvat třeba jen polovinu doby. A zrychlit odezvy má smysl vždy.
Jde mi o to včas přejít na nové technologie. Ale na to jak dlouho se in-memory databáze používají, jsem nenašel náhradu za postgresql.
Oracle, HANA, MS SQL ... jsou poněkud drahé.
Citace od: Paja kdy 21. 10. 2016, 10:08:37
Citace od: Trupik kdy 20. 10. 2016, 22:11:58
Čo vlastne potrebuješ zrýchliť? Čítanie, alebo zápisy? Ak zápisy, tak mnohonásobné zrýchlenie postgresu sa dá dosiahnuť vypnutím fsync. Prídeš tým o dáta v prípade havárie, ale keď hovoríme o in-memory databázach, tak to sa asi rozumie samo sebou. Čítanie sa zase obvykle dá ľahko zrýchliť dostatkom RAM, správnymi indexami, či optimalizáciou SQL dotazov.
Nejde mi o řešení nějaké aktulní situace. S posgresem žiju už 10 let a tuním ho, optimalizuju ... Trochu opruz je simulovat v něm materializované view.
Ale žiju v představě (možná mi ji někdo vyvrátíte), že postges používá nějakou komplikovanou strategii pro vlastní cache a co nemá u sebe je v cache souborů v RAM linuxu. A příjde mi, že pokud by se celé tabulky a indexy načetli do RAM v lineárním adresování, snížila by se režie přístupu k datům v RAM. Nemuselo by se to přepočítávat na bloky atd. Možná by to mohlo umět používat i SIMD nebo podobné moderní instrukce CPU, mohlo by to být lépe optimalizované pro víceprocesorové zpracování a kdoví co dál.
Prostě by stejný dotaz mohl trvat třeba jen polovinu doby. A zrychlit odezvy má smysl vždy.
Jde mi o to včas přejít na nové technologie. Ale na to jak dlouho se in-memory databáze používají, jsem nenašel náhradu za postgresql.
Oracle, HANA, MS SQL ... jsou poněkud drahé.
A co GPUdb? Viz https://en.wikipedia.org/wiki/Kinetica_(software)
A nebo toto? https://github.com/antonmks/Alenka
Citace od: Ivan Nový kdy 21. 10. 2016, 10:49:53
A nebo toto? https://github.com/antonmks/Alenka
Má to i JDBC viz zde http://technica-corporation.github.io/Alenka-JDBC/
A co zkusit do Postgresu strčit modul redis_fdw a napojit ho na Redis?
Pak mám data v Redisu v RAM a přistupuji k tomu přes SQL skrz Postgres.
Ale zda se tím dá dosáhnout požadovaného nevím.
Já to řeším na aplikční úrovni, že co mé se kešuje v Redisu a co má být persitentní, to strká do PgSQL.
Citace od: Paja kdy 21. 10. 2016, 10:08:37
Nejde mi o řešení nějaké aktulní situace. S posgresem žiju už 10 let a tuním ho, optimalizuju ... Trochu opruz je simulovat v něm materializované view.
Ale žiju v představě (možná mi ji někdo vyvrátíte), že postges používá nějakou komplikovanou strategii pro vlastní cache a co nemá u sebe je v cache souborů v RAM linuxu.
Myslím, že toto zodpovedá realite.
Citace od: Paja kdy 21. 10. 2016, 10:08:37
A příjde mi, že pokud by se celé tabulky a indexy načetli do RAM v lineárním adresování, snížila by se režie přístupu k datům v RAM. Nemuselo by se to přepočítávat na bloky atd.
Ono by to bolo lineárne len do prvého UPDATE/INSERT/DELETE. Potom by sa tie dáta museli opäť všetky zoradiť, alebo by sa museli aj tak organizovať do stromových štruktúr, teda indexovať.
Citace od: Paja kdy 21. 10. 2016, 10:08:37
Možná by to mohlo umět používat i SIMD nebo podobné moderní instrukce CPU, mohlo by to být lépe optimalizované pro víceprocesorové zpracování a kdoví co dál.
Neviem ako SIMD, ale viacprocesorové spracovanie jednotlivej query (parallel execution) je vo verzii 9.6, ktorá vyšla pred mesiacom.
Citace od: Paja kdy 21. 10. 2016, 10:08:37
Prostě by stejný dotaz mohl trvat třeba jen polovinu doby. A zrychlit odezvy má smysl vždy.
Veľké zrýchlenie odozvy sa dá dosiahnuť použitím cache (napríklad memcached). Bohužiaľ to vyžaduje zásahy do aplikácie.
Citace od: Paja kdy 21. 10. 2016, 10:08:37
Jde mi o to včas přejít na nové technologie. Ale na to jak dlouho se in-memory databáze používají, jsem nenašel náhradu za postgresql.
To je chvályhodný cieľ, držím palce.
nema nahodou postgres pri dostatocne velkej pamati v podstate vsetko v RAM?
Citace od: andrej kdy 21. 10. 2016, 12:20:05
nema nahodou postgres pri dostatocne velkej pamati v podstate vsetko v RAM?
V podstatě ano.
Tazatel se však ptá, zda v takovém případě používá i algoritmy, které jsou vhodnější pro RAM než pro disk, tedy binární vyhledávání místo B-stromu. Ovšem rozdíly budou podle mne spíše marginální.
Pokud tedy PostgreSQL v některých případech výkonově nestačí, je nutné se spíš zaměřit na prováděcí plány dotazů, strukturu triggerů a případně i vnořených procedur. Pokud bude pravidelně selektovat agregáty velkých tabulek, tak ani přesunutí do RAM problém nevyřeší.
Mozem odporucit mnesia (erlang). Je to by default in memory a vie sa to sem tam odlozit i na disk. Je to high performance, len to nema moc sql pristup. Co sa tyka toho, tak imho ci uz clovek pise sql, alebo pouzije priamo vhodny programovaci jazyk (funkcionalny ;) je jedno. Dokonca to sql je v mnohych pripadoch len "write once, do not read" stav. Pokial clovek nevyuziva CTE, tak normalizovane tabulky nutia casto k sialenym (neprehladnym) selektom.
MemSQL
Máte to blbě
správně je to
In memory of SQL
Extrémně rychlá paměťová SQL databáze je monetdb https://www.monetdb.org/Home
Dneska je celá kategorie databází označovaná jako NewSQL - která už pracuje s daty úplně jinak než Postgres - Postgres má data ve formátu, který vyhovuje uložení na disk - nové databáze už si data drží primárně v RAMce a na disk udělají občas backup a na disku si drží transakční log. Když máte štěstí, tak tyto databáze mohou být o řád až dva rychlejší než klasická db (data ale musí být 100% v RAM). Na druhou stranu vzhledem k mládí a k výrazně nižšímu počtu uživatelů musí člověk počítat s větší pravděpodobností výskytu chyb a provozních problémů. Klasické databáze jsou ověřené časem a počtem uživatelů. To u nových db samozřejmě neplatí. Hodně záleží na zátěži, typu a objemu dat - někdy bude benefit větší, někdy menší.
MonetDB ale není klasická in RAM DB, ne (při porovnání s memcached/Redis/...)? Jen s trocou štestí mám data v RAM a jede rychle, ale pořád aktivně jede přes disk.
Když má data v RAM, tak je asi rychlejší jak PotgreSQL s podobně obsazenou a využitou RAM.
Citace od: M. kdy 28. 10. 2016, 12:16:58
MonetDB ale není klasická in RAM DB, ne (při porovnání s memcached/Redis/...)? Jen s trocou štestí mám data v RAM a jede rychle, ale pořád aktivně jede přes disk.
Když má data v RAM, tak je asi rychlejší jak PotgreSQL s podobně obsazenou a využitou RAM.
Memcached/Redis to jsou více/méně sofistikované cache key/value dat - jedná se o jednoduché jednoúčelové databáze. Oprati tomu je Monet obecnější - s velkou většinou funkcí typických pro paměťové databáze - sloupcové uložení dat, efektivní komprimace, optimalizace CPU, diskové operace jsou nahrazeny virtuální pamětí. Paměťové databáze jsou relativní novinkou, těžko se dá označit nějaká technologie jako klasická. V každém případku je MonetDB jednou z nejstarších databází, které rovnou byly navrhovány jako paměťové - cca 20 a více let. O memchaced pravděpodobně nikdo z jejich tvůrců neuvažoval jako o databázi - byl to jednoduchý jednoúčelový nástroj, který umožňoval sdílený přístup do paměti.
A co tkahle použít v postgresu TABLESPACES které umožní umístit určité tabulky na jiný disk nebo RAM disk . Podotýkám, že u jednotlivé tablespace lze nastavit optimalizace jné než v centrálním clusteru
Citace od: ntpt kdy 29. 10. 2016, 19:07:53
A co tkahle použít v postgresu TABLESPACES které umožní umístit určité tabulky na jiný disk nebo RAM disk . Podotýkám, že u jednotlivé tablespace lze nastavit optimalizace jné než v centrálním clusteru
Pokud se bavíme o Postgresu, tak to je nesmyl - je úplně jedno jestli jsou data ve file system cachi nebo v Pg cache nebo v ramdisku - pokaždé mají stejný formát.