Odpověď na názor

Odpovídáte na názor k článku SQLite-vec: vektorové rozšíření databáze SQLite. Názory mohou přidávat pouze registrovaní uživatelé. Nově přidané názory se na webu objeví až po schválení redakcí.

  • 15. 1. 2026 0:37

    Michal Šmucr
    Bronzový 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í 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.