Názory k článku SQLite-vec: vektorové rozšíření databáze SQLite

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.

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.

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.

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í db

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