In memory SQL

[Paja]

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

[Reklama]

[Ivan Nový]

SQLite? https://www.sqlite.org/inmemorydb.html

[Kit]

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.

[Paja]

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?

[Paja]

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.

[Reklama]

[javaman ((]

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.

[Kit]

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.

[Ivan]

SAP HANA
https://en.wikipedia.org/wiki/SAP_HANA

[Trupik]

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.

[Ondrej Nemecek]

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 :-)

[Lael.Ophir]

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

[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.

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é.

[Ivan Nový]

Č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)

[Ivan Nový]

A nebo toto? https://github.com/antonmks/Alenka

[Ivan Nový]

A nebo toto? https://github.com/antonmks/Alenka

Má to i JDBC viz zde http://technica-corporation.github.io/Alenka-JDBC/