Comments on: Import velkých dat do MySQL http://blog.novoj.net/2009/10/06/import-velkych-dat-do-mysql/ Dává je jen zřídka, obvykle jim není moc rozumět a často vám ani k ničemu nejsou. Wed, 21 Jul 2010 16:31:34 +0000 hourly 1 http://wordpress.org/?v=3.0 By: MJJ http://blog.novoj.net/2009/10/06/import-velkych-dat-do-mysql/comment-page-1/#comment-13666 MJJ Tue, 27 Oct 2009 21:07:46 +0000 http://blog.novoj.net/?p=614#comment-13666 Zdravím. Technická pozn.: MS Excel 2007 už umí milion řádků. Zdravím.
Technická pozn.: MS Excel 2007 už umí milion řádků.

]]> By: Otec Fura http://blog.novoj.net/2009/10/06/import-velkych-dat-do-mysql/comment-page-1/#comment-13310 Otec Fura Thu, 22 Oct 2009 04:21:08 +0000 http://blog.novoj.net/?p=614#comment-13310 Ponechme slovíčkaření stranou. Typický usecase, který řešíme zas a znovu je ruční import dat z externí uživatelské DB, kterou má zákazník vyexportovanou ve formě CSV nebo Excelu. On demand import, který si zákazník dělá sám, typicky neobsahuje milióny záznamů (ještě jsem to ve své praxi neviděl), ale řádově desetitisíce nebo stotisíce záznamů (jen formát XLS množství výrazně omezuje s omezením 65 tis. záznamů na jeden list). Tím že je to on demand, musí bý v aplikaci rutina, která import provádí a tu píšeme pomocí insertů přes JDBC. Máš pravdu, že pokud bych měl import o 10 mil. záznamech, tak bych to řešil specifickým importem ze strany dodavatele přímo nástroji, které se k DB dodávají. Tenhle problém tu ale neřeším. Btw. kupodivu jsem nezaznamenal výraznou úsporu času vypnutím constraint. Ponechme slovíčkaření stranou. Typický usecase, který řešíme zas a znovu je ruční import dat z externí uživatelské DB, kterou má zákazník vyexportovanou ve formě CSV nebo Excelu. On demand import, který si zákazník dělá sám, typicky neobsahuje milióny záznamů (ještě jsem to ve své praxi neviděl), ale řádově desetitisíce nebo stotisíce záznamů (jen formát XLS množství výrazně omezuje s omezením 65 tis. záznamů na jeden list). Tím že je to on demand, musí bý v aplikaci rutina, která import provádí a tu píšeme pomocí insertů přes JDBC.

Máš pravdu, že pokud bych měl import o 10 mil. záznamech, tak bych to řešil specifickým importem ze strany dodavatele přímo nástroji, které se k DB dodávají. Tenhle problém tu ale neřeším.

Btw. kupodivu jsem nezaznamenal výraznou úsporu času vypnutím constraint.

]]> By: deii http://blog.novoj.net/2009/10/06/import-velkych-dat-do-mysql/comment-page-1/#comment-13296 deii Wed, 21 Oct 2009 14:07:30 +0000 http://blog.novoj.net/?p=614#comment-13296 Par pripominek: Import velkych dat neni o stotisicich ale milionech. Clanek neni o rychlosti importu, ale rychlosti insertu. Import dat pres inserty je sebevrazda. ;) Kdyz uz importuju pres inserty, tak si zavislosti behem operace vypinam. Pokud se chci dozvedet o nekonzistenci dat - tak je to dobre vyresit mimo import - pred nebo potom. Par pripominek:
Import velkych dat neni o stotisicich ale milionech.
Clanek neni o rychlosti importu, ale rychlosti insertu.
Import dat pres inserty je sebevrazda. ;)
Kdyz uz importuju pres inserty, tak si zavislosti behem operace vypinam. Pokud se chci dozvedet o nekonzistenci dat – tak je to dobre vyresit mimo import – pred nebo potom.

]]> By: Otec Fura http://blog.novoj.net/2009/10/06/import-velkych-dat-do-mysql/comment-page-1/#comment-13132 Otec Fura Wed, 14 Oct 2009 08:52:26 +0000 http://blog.novoj.net/?p=614#comment-13132 Zdá se, že tvrzení, že MyISAM je rychlejší než InnoDB je hodně zastaralá chiméra: http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/ Někde jsem zaspal dobu. Zdá se, že tvrzení, že MyISAM je rychlejší než InnoDB je hodně zastaralá chiméra:

http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/

Někde jsem zaspal dobu.

]]> By: Otec Fura http://blog.novoj.net/2009/10/06/import-velkych-dat-do-mysql/comment-page-1/#comment-13020 Otec Fura Fri, 09 Oct 2009 08:11:35 +0000 http://blog.novoj.net/?p=614#comment-13020 Upravil jsem text článku podle toho, na co jsi Maaartine upozorňoval - skutečně ta MyISAM nevychází o moc líp než InnoDB. Já jsem původně porovnával časy na všechny testy ve třídě, jenže tam se hrozně projevila neefektivita InnoDB v autocommit režimu, z čehož jsem vyvodil špatný závěr. Dík za upozornění - kupodivu tedy MyISAM není výrazně rychlejší a to zmiňované doporučení jsem odstranil. Prostě víc očí víc vidí. Upravil jsem text článku podle toho, na co jsi Maaartine upozorňoval – skutečně ta MyISAM nevychází o moc líp než InnoDB. Já jsem původně porovnával časy na všechny testy ve třídě, jenže tam se hrozně projevila neefektivita InnoDB v autocommit režimu, z čehož jsem vyvodil špatný závěr. Dík za upozornění – kupodivu tedy MyISAM není výrazně rychlejší a to zmiňované doporučení jsem odstranil. Prostě víc očí víc vidí.

]]> By: Otec Fura http://blog.novoj.net/2009/10/06/import-velkych-dat-do-mysql/comment-page-1/#comment-13019 Otec Fura Fri, 09 Oct 2009 07:31:32 +0000 http://blog.novoj.net/?p=614#comment-13019 Pravda je, že InnoDB v transakci dosahuje podobných výsledků jako MyISAM - taky jsem do těch výsledků čučel pozdě v noci. Tj. možná to s tou MyISAM není zase až o tolik výhodnější jak s InnoDB. Data tam cpu z Javy přes Springovou podporu executeBatch - tj. asi nejrychlejší způsob, který jsem dokázal vymyslet. Pouze pro otestování LOAD DATA INFILE jsem si vytvořil externí TXT file, který jsem potom funkci předhodil (tam to snad ani nijak jinak nejde). Nejlíp když se koukneš rovnou do testovacího kódu. Pravda je, že InnoDB v transakci dosahuje podobných výsledků jako MyISAM – taky jsem do těch výsledků čučel pozdě v noci. Tj. možná to s tou MyISAM není zase až o tolik výhodnější jak s InnoDB.

Data tam cpu z Javy přes Springovou podporu executeBatch – tj. asi nejrychlejší způsob, který jsem dokázal vymyslet. Pouze pro otestování LOAD DATA INFILE jsem si vytvořil externí TXT file, který jsem potom funkci předhodil (tam to snad ani nijak jinak nejde). Nejlíp když se koukneš rovnou do testovacího kódu.

]]> By: Maaartin http://blog.novoj.net/2009/10/06/import-velkych-dat-do-mysql/comment-page-1/#comment-13009 Maaartin Thu, 08 Oct 2009 23:15:08 +0000 http://blog.novoj.net/?p=614#comment-13009 Naxem jsem nepochopil jesti tam cpes data z Javy nebo z SQL-souboru. Pokud ze souboru, taxe divim ze se ti ho chtelo vytvaret (mnohem vic prace nez pro LOAD DATA INFILE), pokud z Javy taxe divim ze nepises o pouziti PreparedStatement-s ci o executeBatch. Super, zes udelal takovyhle prehled, ale s necim moc nesouhlasim: "preferujte MyISAM před InnoDB" - MyISAM je stary netransakcni srot. Sice rychly, ale kdyz se rozsype, tak je vymalovano. Kdyz zjistis ze transakce ci jiny ficurky vznikly po roce nula prece jen potrebujes, pak muzes nejen pracne presypavat data, ale mas zadelano na hafo problemu. Rekl bych to naopak: Kdyz potrebujes rychlost, jen rychlost a to extemne moc, pak MyISAM. Me navic Tvoje vysledky pro InnoDB prijdou zhruba stejny jako pro MyISAM: Kdyz se to dela dobre, pak oboje je pod 20s; mozna ale spatne vidim, uz je dost pozde. Naxem jsem nepochopil jesti tam cpes data z Javy nebo z SQL-souboru. Pokud ze souboru, taxe divim ze se ti ho chtelo vytvaret (mnohem vic prace nez pro LOAD DATA INFILE), pokud z Javy taxe divim ze nepises o pouziti PreparedStatement-s ci o executeBatch.

Super, zes udelal takovyhle prehled, ale s necim moc nesouhlasim:

“preferujte MyISAM před InnoDB” – MyISAM je stary netransakcni srot. Sice rychly, ale kdyz se rozsype, tak je vymalovano. Kdyz zjistis ze transakce ci jiny ficurky vznikly po roce nula prece jen potrebujes, pak muzes nejen pracne presypavat data, ale mas zadelano na hafo problemu. Rekl bych to naopak: Kdyz potrebujes rychlost, jen rychlost a to extemne moc, pak MyISAM.

Me navic Tvoje vysledky pro InnoDB prijdou zhruba stejny jako pro MyISAM: Kdyz se to dela dobre, pak oboje je pod 20s; mozna ale spatne vidim, uz je dost pozde.

]]> By: Otec Fura http://blog.novoj.net/2009/10/06/import-velkych-dat-do-mysql/comment-page-1/#comment-13004 Otec Fura Thu, 08 Oct 2009 18:20:13 +0000 http://blog.novoj.net/?p=614#comment-13004 Faktem je, že když jsem si cvičně implementoval metodu, která LOAD DATA INFILE využívá, tak si dokážu docela dobře představit i produkční využití. Ono to zase tak pracné není, jak jsem si původně myslel. Faktem je, že když jsem si cvičně implementoval metodu, která LOAD DATA INFILE využívá, tak si dokážu docela dobře představit i produkční využití. Ono to zase tak pracné není, jak jsem si původně myslel.

]]> By: LesTR http://blog.novoj.net/2009/10/06/import-velkych-dat-do-mysql/comment-page-1/#comment-13002 LesTR Thu, 08 Oct 2009 15:03:01 +0000 http://blog.novoj.net/?p=614#comment-13002 On je to vždy kompromis : ) Osobně jsem LOAD DATA IN FILE používal pouze při importech do jedné tabulky, nebo když těch dat bylo opravdu hodně, pak už se vynaložené úsilí při přípravě dat vyplatí. On je to vždy kompromis : )
Osobně jsem LOAD DATA IN FILE používal pouze při importech do jedné tabulky, nebo když těch dat bylo opravdu hodně, pak už se vynaložené úsilí při přípravě dat vyplatí.

]]> By: Otec Fura http://blog.novoj.net/2009/10/06/import-velkych-dat-do-mysql/comment-page-1/#comment-12987 Otec Fura Wed, 07 Oct 2009 12:22:47 +0000 http://blog.novoj.net/?p=614#comment-12987 Tak jsem dopsal poslední test - skutečně funkce Load data infile vychází ve výkonnostních statistikách nejlépe. Když jsem nad tím přemýšlel, asi by bylo možné tu naši logiku implementovat v předstihu a do souboru ukládat už vypočtená data. Provázání klíčů by se dalo řešit dodatečnými selecty, ve kterých by se dotáhly přidělené primární klíče pro importované záznamy (do tabulky totiž mohou v našem případě konkurentně přistupovat i další uživatelé, takže fixní hodnoty primárních klíčů nepřipadají v úvahu). Rozhodně by to asi za tu námahu stálo, kdybychom tahle čísla věděli už na začátku. Každopádně jsme teď chytřejší. Lukáši, díky za komentář. Tak jsem dopsal poslední test – skutečně funkce Load data infile vychází ve výkonnostních statistikách nejlépe. Když jsem nad tím přemýšlel, asi by bylo možné tu naši logiku implementovat v předstihu a do souboru ukládat už vypočtená data. Provázání klíčů by se dalo řešit dodatečnými selecty, ve kterých by se dotáhly přidělené primární klíče pro importované záznamy (do tabulky totiž mohou v našem případě konkurentně přistupovat i další uživatelé, takže fixní hodnoty primárních klíčů nepřipadají v úvahu). Rozhodně by to asi za tu námahu stálo, kdybychom tahle čísla věděli už na začátku. Každopádně jsme teď chytřejší.

Lukáši, díky za komentář.

]]>