Názory k článku SQLite-vec: vektorové rozšíření databáze SQLite
-
Pavel TišnovskýZlatý podporovatelDo SQLite si ukládá RAG třeba Llama Stack, ale myslím, že to potom stejně načítají do paměti. Zkusím zjistit, ale myslím, že to tam mají uloženo normálně jako text a uvnitř je JSONní vektor :/
-
-
Michal ŠmucrBronzový podporovatelJestli se nepletu, tak s SQLite je trochu potíž v tom, že byť je open-source, tak je poměrně složité tam přispět jakýmkoliv dalším kódem nebo změnou. Řekněme, že je to relativně velmi konzervativní, což někomu může naopak vyhovovat, jiný by si pak zas představoval rychlejší začleňování funkcionality a zapojení dalších lidí.
Tihle autoři databáze Turso už proto předtím provozovali svůj fork SQLite, což zřejmě částečně vyřešilo jejich tehdejší potřeby, ale stejně to nepřilákalo moc dalších lidí (ať už k používání nebo přispívání).
Takže to v nějaké fázi přehodnotili a rozhodli se pro kompletně nový engine, který bude ale kvůli hromadě existujících aplikací a uživatelů cílit na kompatiblitu s SQLite (jak API, tak on-disk formát).
S tím, že se pak chtějí koncentrovat např. na širší použití asynchonních I/O operací, paralelizaci pro lepší využití moderního HW, aut. testování s použitím DST (mají partnerství s Antithesis), víceméně od začátku je plná podpora překladu do WASM atp. Zároveň samozřejmě i to, že to bude zajímat uživatele a další poteniconální přispivatele.
A s těmihle cíli, zamýšlenou změnou některých vnitřních věcí a pravděpodobně i expertízou u svých vývojářů si zvolili Rust.Sám jsem to ještě nezkoušel, ale určitě se k tomu chystám včetně nějakého provnání. Tím, jak masivně se embeddované databáze všude používají, tak drop-in alternativa a konkurenční projekt k SQLite mi nepřijde na škodu.
-
Pavel TišnovskýZlatý podporovatel
jj určitě to stojí za vyzkoušení. Paralelizace (nebo aspoň souběžnost) by se hodila. Jako není to asi typický use case pro SQLlite, ale mám tady projekty, kde by NEzamykání celé DB bylo fajn.
-
Michal ŠmucrBronzový podporovatel
Ano, oni přesně zmiňují největší benefit u vícevláknových aplikací, kde třeba vlákna něco nezávisle počítají, výstup je do db, a přestože SQLite sama může být velice rychlá na inserty, tak zamykání logicky sundá výkon a propustnost celé aplikace (a případné další bufferování ten problém jen posune a zvýší nároky celé aplikace).
Přidali tedy celé MVCC, které umožní přístup pro zápis z více vláken a optimistické zamykání. Tzn. jako u "plnotučných" databází, s tím, že případné kolize se řeší v commit fázi na konci transakce.
V poslední verzi (vyšla před pár dny) povolili zapínání MVCC režimu přes pragmu, byť samozřejmě pak ten soubor přestane být kompatibilní s SQLite.
Ale uvidíme, u každého MVCC je pak naprosto kritická implementace čištění starých verzí (ať už se tomu říká vacuum, sweep, compacting..). Ať už kvůli tomu, kdy se to provádí, jak rychlé to je, tak i tomu v jakém stavu pak zůstane soubor na disku.
Byť u těch embedded aplikací je to z provozního hlediska trochu lepší v tom, že má autor aplikace plně pod kontrolou patterny a časy zápisu a může to čistění přímo spouštět v nějaké vhodné chvíli atp.
Jinak ty další asynchronní I/O operace, co jsem zmiňoval vychází i z toho, že to na Linuxu může používat io_uring. -
Michal ŠmucrBronzový podporovatel
Ještě jsou tam další experimentální věci, které by mohly být potencionálně velmi zajímavé pro některá použití.
Inkrementální aktualizace materialized view (které samotné v SQLite nebyly).
https://turso.tech/blog/introducing-real-time-data-with-materialized-views-in-turso
Což by z toho činilo jeden z prvních enginů s přímou podporou pro tyhle inkrementální aktualizace s použitím DBSP.
https://muratbuffalo.blogspot.com/2024/11/dbsp-automatic-incremental-view.html -
> Což by z toho činilo jeden z prvních enginů s přímou podporou pro tyhle inkrementální aktualizace s použitím DBSP.
Nejde tohle s každou databází, co má nějakou replikaci?
Tímhle se na druhé straně ztrácí jedna z výhod SQLite - jednoduchost a malá velikost. A AFAIK incremental computation jak popisují v tom článku funguje v praxi dobře jen na omezené případy - aspoň takovou mám zkušenost z projektů jako Incremental, Adapton nebo Salsa - snadno se stane, že výpočet od 0 je o řády rychlejší a to ani nemluvím o paměťové náročnosti nebo kolik chyb tam vnese ta inkrementalizace.
-
Michal ŠmucrBronzový podporovatel
Nejde tohle s každou databází, co má nějakou replikaci?
Jj, tohle bude víceméně nejčastější použití v nějakých větších projektech.
Autoři DBSP paperu z toho mají hotový produkt Feldera. Který běží samostatně jako služba s API, má různé vstupní a výstupní konektory.
Tipoval bych něco jako:
zdrojová db (nebo několik) -> Debezium (interpretuje replikační logy nebo CDC přímo z databáze, odstraňuje duplikáty) -> Kafka -> Feldera -> výstupní dbJinak souhlas, určitě to není univerzální řešení na všechno. Nicméně rozlišoval bych mezi inkrementálními výpočty obecně a pak např. agregací v kontextu relačních databází. Tam kde to podle mě může nejvíc pomáhat, jsou velké tabulky (výrazně větší než velikost paměti) s častými změnami a nějakými agregacemi nad tím (součty, podíly atp.). Tam pak to úzké hrdlo zdaleka není počítání samotné, ale I/O operace - čtení z tabulek a indexů, při každé aktualizaci toho view (přehled, statistika).
Samozřejmě v menším si můžete tohle zkusit optimalizovat ručně i standardními prostředky (pomocné tabulky s posledními hodnotami, triggery), podobně jako můžete fejkovat materialized view s normálními tabulkami atp. Akorát od určité komplexity je to docela úsilí neudělat chybu :), udržovat to konzistentní, když se třeba maže, ošetřit si stavy, kdy se to musí projít celé, abyste měl nějaký výchozí bod atp. Nehledě na to, když se k tomu po nějaké době vrátíte, mění se schéma nebo nějaké vazby, tak to může být celkem peklo.
Takže pokud tohle bude asi jeden z prvních db enginu, co tohle bude mít nějak schopně integrované a půjde to tím optimalizovat (pořeší to relace, filtrování), může to být pro zmíněné scénáře opravdu pomoc.Ad. SQLite - jednoduchost a malá velikost. Jasně, ale to jsou dost relativní pojmy. Otázka je, jak moc to případně nabobtná a zkomplikuje se to. Zatím všechny změny funkcionality, co provedli, nevypadají vynucené, pořád se to dá používat víceméně stejně jako SQLite. A přesně to, aby mohli přidávat další funkcionalitu a případně se i odchylovat od původní architektury bylo jedním z důvodů pro vznik dalšího samostatného projektu psaného od začátku. Nakonec bych ještě připomněl, že ta SQLite má prakticky dneska široké spektrum použití. Od nějakých malých db s pár tabulkami a záznamy u desktopových aplikací (např. cookies v browseru) až po db, co můžou mít klidně vyšší desítky, možná stovky GB, pokud tomu sedne workload (nějaké systémy s lokální db třeba pro ukládání logů, telemetrie atp.), takže v kontextu použití mě třeba nárůst velikost engine nemusí až tak trápit.
ČLÁNKY DO MAILU