Dotaz: jak nahrát stovky souborů do databáze

[urputnik]

Mám mnoho textových souborů, které budu potřebovat často prohledávat na základě zadaného regulárního výrazu. Rozhodl jsem se použít databázi. Slibuji si od toho, že prohledávání bude rychlejší než při použití ripgrepu. Zatím netuším jak efektivně nahrát stovky textových souborů do MySQL databáze z příkazového řádku nebo v shellu. Poradíte?

Odpovědi

[debian+]

To som nedavno riesil :D ... Mal som 1 priecinok a v nom takmer 2 milion priecinkov s asi 1 suborom v kazdom priecinku.

Len generovanie SQL dotazu trvalo 24-48 hodin (povodne malo 2-3 tyzdne v cistom).

Ako na to.

Musis manualne nahodit data. Zo suborov vytvor jeden dotaz (alebo n dotazov, kde v kazdom dotaze vkladas 10000 insertov - aspon tak u mna to bolo). A tie potom hodis do databazy. Ak sa zmesti cele do ram, ukladaj do /dev/shm a vystup si skopiruj (kukni df pre /dev/shm). Alebo ukladaj na disk, ale generuj docastne do /dev/shm a po 100 napr. vkladani, z /dev/shm to uloz do na disk.

Tabulku si vytvor v phpmyadmin (instalacnu verziu pouzi zo stranky - v debian testing my bola blba). Vloz 2 insert, aby si videl syntax pre insert viac-vkladanim naraz.

A logiku si naprogramuj v php (ma funkciu mysqli_real_escape_string() na spravne konvertovanie na vkladanie). Php je ma aj prebrate syntax z bash.

Ak zaplatis, do 0.5 - 1 hodiny to mas. Ak mozes poslat tie data, dak Ti mozem rovno vytvorit jeden sql prikaz, ktory Ti rovno nahodi databazu. A poslat aj s programom, ktory pri tom vytvorim (ak do buducna ak by si potrebol si pridat).

[debian+]

Ak sa zmestia do RAM, pouzi ramFS. /dev/shm je nim.

[lazywriter]

Jelikož se zmiňuje SQL, tak se nejspíš předpokládá _relační_ databáze. A ta má takový název proto, že dobře řeší vztahy (cizím slovem relace) mezi záznamy. Takže není dobrý nápad ji znasilňovat na něco jiného. Když už nestačí doporučené hledání na disku, tak by mohly připadat do úvahy nějaké databáze, ale rozhodně ne relační. Napadá mě třeba nějaká dokumentová nosql databáze, např. Elasticsearch apod.

[lazywriter]

pardon, ukliknutí. Odpověď měla jít přímo na původní otázku.

[Kit]

Relace je ten jeden záznam (n-tice) v tabulce.

[lazywriter]

Použít třeba Google přece není tak složité. Druhý odkaz na dotaz "relace databáze": https://office.lasakovi.com/access/tabulky/relace-vazby-v-databazich-teorie/

Záznam se v relační teorii jmenuje entita. Proto se také schématu databáze někdy říká ER diagram od slov entita-relace (česky: záznam a jeho vztah k ostatním).

[Aleš Kapica]

A nebylo by lepší místo takové opičárny vyzkoušet sift?

[debian+]

Ako to testovali/merali, lebo HDD a ani SD disk neda 30GB za 0.5s.

Vid "Web log files search"

[Aleš Kapica]

Nevím jak to testovali oni, ale pokud bych chtěl obejít IO omezení HDD, tak bych ty data hodil do ramdisku.

Jinak tazatel chce prohledávat stovky textových souborů. To je úplná sranda proti prohledávání milionů malých souborů. Neuvedl taky co s tím pak chce dělat. Já si většinou takový soubor chci přečíst, proto je pro mne optimální klasická kombinace grep + less. A pokud bych chtěl něco svižnějšího, tak bych nejspíš vyzkoušel ten sift. Pořád mi to přijde lepší než se drbat s nějakou databází. Bez rozumné indexace to stejně nedává smysl.

[Aleš Kapica]

Tak jsem to jen tak z legrace zkusil na svůj home. Obsahuje aktuálně 1044971 souborů (208GB). Co se mi líbilo, tj. že sift zvýrazňoval barevně cestu k souboru a nalezený vzorek. Sift také na rozdíl od grepu jel vícevláknově.

Co jsem neošetřil, to bylo nastavení parametru aby nepřeskakoval příliš dlouhé řádky, takže 3130 souborů sift právě kvůli tomu přeskočil.

sift
real    17m12,227s
user    2m28,896s
sys     4m6,882s

grep
real    23m28,636s
user    3m38,805s
sys     3m57,037s

[urputnik]

Tedy by mě zajímalo porovnání s prohledáváním v DB, ale to asi vyzkoušet nemůžete.

[dustin]

Nahrání do DB a indexace pro nějaký fulltext (který nezafunguje na regexp) je dost náročná operace. Samozřejmě pokud budeš hledat častěji (a bude možné použít nějaký index), přínos to mít může. Jinak bude varianta s mezikrokem do DB logicky delší, když dělá to samé a ještě mnoho navíc.

[lertimir]

Ano, souhlas. Podstatné je, že fultext index je sice mnohonásobně rychlejší, ale v podstatě je uvnitř jenom něco jako ekvivalent substringu. rozhodně to není regexp.

[Kit]

Pokud ta data v souborech nejsou strukturována, tak ti konverze do databáze moc fungovat nebude a ztratíš pohodlí přímé editace. Jak dlouho tomu ripgrepu trvá, než nalezne výskyty vzorku?

[urputnik]

Strukturovana jsou, ale to bych v te db uz nejak vyresil. Treba tak, ze bych si cestu do adresare (strukturu) ukladal do tabulky vedle toho textu.

Rychle to s tim ripgrepem je zatim dost, ale mam tech souboru jenom asi stovku. Brzy jich budou tisice.

[debian+]

Strukturovana jsou, ale to bych v te db uz nejak vyresil. Treba tak, ze bych si cestu do adresare (strukturu) ukladal do tabulky vedle toho textu.

To v ziadnom pripade!!!! ... Zvlast tabulka na nazvy a zvlast na data. A prepajas indexami.

[Kit]

Je u všech souborů zachována stejná struktura sloupců nebo to má každý soubor jinak? Máš ty soubory v CSV nebo v jiném podobném formátu?

[urputnik]

Je to jen text, žádný formát to nemá.

[Kit]

V tom případě nedává moc smysl takové nestrukturované údaje ukládat do databáze. Jak velké jsou ty soubory a co od toho databázového řešení očekáváš?

[Käyttäjä 11133]

On ElasticSearch je taky databáze, víme?

[urputnik]

V podstatě jde o to, jestli webový backend bude pracovat se strukturou souborů nebo s databází, ze které by se posléze vybraný text kopíroval do souboru, se kterým by se pracovalo -- překlad textového formátu do PDF a jiných formátů. Dneska už je běžné mít všechno v DB, je to rychlé a pohodlné a dobře rozšiřitelné. Na základě toho mě právě napadlo hrnout už to všechno přes DB, protože ta tam bude stejně, zejména pokud by to vyhledávání v DB mělo být rychlejší.

[dustin]

Nepřijde mi, že je dnes běžné mít všechno v DB. Je to vždy o konkrétních potřebách.

Pokud potřebuješ fulltext (ne regexpy, které zmiňuješ), pak to nahraj do elasticsearche, jak tady již bylo řečeno. Nevím o DB indexu, který by uměl urychlit obecný regexp.

Mysql žádný pořádný fulltext nemá, navíc s podporou různých jazyků.

Nebo použij Postgresql https://postgres.cz/wiki/Instalace_PostgreSQL#Instalace_Fulltextu

[Josef Kufner]

To, co chceš, je hlavně index. Pro obecné regexpy se indexovat nedá, ale pokud máš předem dané dotazy a přepíšeš je do jednoduchého hledání klíčových slov, tak už to půjde fulltextem.

Na fulltext můžeš zkusit třeba Sphinx Search nebo již zmiňovaný Elastic Search. Fulltext v MySQL je dosti omezený.

Import do databáze uděláš tak, že si napíšeš skript, který přečte soubor, sestaví SQL dotaz a pošle to do databáze. Je to na pár řádků. Doporučuju sáhnout po rozumném skriptovacím jazyce, např. Python nebo PHP. V shellu se z toho zblázníš.