Dotaz: SQLite zpomaluje během INSERT OR IGNORE

[Aleš Nehyba]

ahoj,

Při vkládání velkého množství záznamů do SQLite pomocí příkazu INSERT OR IGNORE pozoruji výrazné zpomalení. Data vkládám přes python z csv souborů. Mám desítky souborů o velikosti cca 300 MB a každý obsahuje statisíce až milion záznamů - textové popisky definující význam a k nim přiřazená číselné hodnoty. Python vytváří několik číselníků, do kterých se ukládají ty popisky, aby se šetřilo místo, protože ty jsou hodně duplicitní.

Zpracování prvních takových souborů trvá pár desítek vteřin/několik minut na každý soubor. Postupně se čas zpracování souboru prodlužuje a dosahuje i desítek minut/pár hodin. Nějak významně nepomohlo ani vypnutí indexování během vkládání. Transakce používám.

K datům bude přistupovat pouze jeden program běžící lokálně. Proto jsem volil sqlite. To zpomalování při vkládání mě ale nutí zeptat se, jestli by na tom jiné databáze nebyly lépe?

---

---

Odpovědi

[debian+]

Urcite lepsie.

Mas na vyber SQL alebo NoSQL databazy. SQLite pri ukladany zmeny potrebuje ulozit databazu ako SQL dotaz (RAW -> SQL), co pri tom mnozstve chce cas a blokuje pracu s DB.

[EtDirloth]

Ako vzdy, aj tu plati, ze DB engine treba vyberat podla potrieb aplikacie. Takze tazko povedat, ako by na tom boli ine databazy.

Nevieme, ako vyzeraju data. Mohol by tu pomoct bulk load CSV do docasnej tabulky v sqlite a nasledny podmieneny INSERT INTO trvale SELECT FROM docasne WHERE NOT IN/NOT EXISTS (trvale). Toto sa potom da urobit aj z CLI, resp. v bashi cez sqlite3 klienta.

Nepozname tvoju aplikaciu - a v akej forme robis dotazy. Python je dost pomaly a ten bottleneck mozes mat v nejakom tvojom foreach. Skus si spravit profiling, nech vidis, kde ten program travi cas.

Nevieme, ci potrebujes mat data perzistentne. Subor so Sqlite databazou je mozne nacitat aj do RAM a pouzit ju ako in-memory DB. Spatne ulozenie do suboru vsak bolo par rokov dozadu trochu zlozitejsie, ale islo aj to. Ak potrebujes len key-value, potom by mozno taky Redis bol pre teba vhodnejsi.

[Aleš Nehyba]

Díky za tip. Zkusím tu dočasnou tabulku.

Data převádím do databáze pro trvalé uložení. Vyhledávání v původních csv souborech celkem trvá. Dotaz do SQL je mnohonásobně rychlejší. Těch dotazů může být v dávce několik tisíc, výsledkem každého je několik desítek řádků pro další zpracování. Zpočátku to vypadalo, že databáze je řešení. Ale s prodlužujícím se časem zpracování insertů už to tak růžové není. Už je skoro jedno, jestli čekat hodiny na přípravu dat pro sql dotazy, nebo hodiny na zpracování dotazů do csv.

Velikost databáze je dnes cca 12 GB. Za rok naroste cca o 1 GB, to je asi 6 mio záznamů.

[Aleš Nehyba]

Tak ta úprava INSERT pomohla. Díky.

[Kit]

Bez znalostí požadavků na systém (typy dotazů) se dá těžko odpovědět. Plnění SQLite skutečně trvá déle a možná bude stát za to vydržet i několikadenní plnění, protože čtení bývá rychlé.

Ovšem pokud to má být KVS, tak se dá najít pár vhodnějších databází. Je možné i využití NoSQL.

[Kit]

Na tohle by se dala využít DB4, která je pro podobné účely fakt rychlá. Zkoušel jsem i Tokyo Cabinet, který také podával zajímavé výkony.

[OldFrog {Ondra Nemecek}]

Bulk insert se tu řeší v diskuzích pravidelně (pro různé databáze). Každá databáze se chová jinak a řada databází umí nacpat csv do tabulky přímým importem - je to mnohonásobně rychlejší než normální insert (i multi-insert, kdy se vkládá více záznamů jediným dotazem). Některé databáze umí mít jako storage i csv, takže by pak stálo za to zkusit načíst csv takto a pak selectem překopírovat do cílové tabulky. Zkusit jak je na tom databáze s výkonem v režimu in-memory. Při importu koukat na obsazení RAM, vytížení CPU a vytížení IO. Pokud jde o data ze sensorů existují specializované time-series databáze, které řeší některá specifika efektivněji.

Nakonec stojí za zvážení změna workflow, zda by nešlo vkládat záznamy do databáze bez csv mezikroku.

Pokud to chcete řešit podrobněji, chce to vidět ten python script a vzorek dat.

[OldFrog {Ondra Nemecek}]

PS: Ruční tvorbě číselníků by se šlo asi vyhnout, například by šlo popisky uložit do jiné 1:1 tabulky a na tu tabulku nastavit vhodný typ úložiště (s kompresí) nebo prostě jen nastavit jiný vhodnější typ sloupce (trigramy). To by odvedlo stejnou práci - a oproti skriptu by to bylo určitě efektivnější. Jsem celkově přesvědčen, že vhodné řešení může přinést řádové urychlení.

[Tom K]

sqlite3 má jako vlastnost, že při určitém počtu záznamů začne výrazně zpomalovat insert. Ten počet je někde okolo milionu řádků. Souvisí to s implicitním indexem a UNIQUE sloupci, které se chovají jako indexy. Na jednom projektu, kde jsem potřeboval řádově desítky milionů řádků jsem to řešil rozdělením do samostatných databází, které jsem následně spojil (bylo jich 512).
Při spojování je důležité klíčové slovo WITHOUT ROWID.
Zajímavý odkaz je tady: https://stackoverflow.com/questions/15778716/sqlite-insert-speed-slows-as-number-of-records-increases-due-to-an-index/15809806

[Aleš Nehyba]

Díky. Ve dvou největších tabulkách mám 25 mio a 60 mio řádků. Zkusím ta data rozdělit podle let.

[Kit]

Však už to máš rozděleno. Z každého vstupního souboru uděláš jednu databázi a následně je spojíš do jedné.