Fórum Root.cz
Hlavní témata => Server => Téma založeno: Paja 20. 10. 2016, 20:58:27
-
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.
-
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?
-
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.
-
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.
-
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
-
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
...
Č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
-
Č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é.
-
Č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
-
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.
-
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.
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ť.
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.
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.
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?
-
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.
-
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
-
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.