.net aplikace proti mysql databazi

Dostal jsem se k možnosti vytvořit jednoduchou aplikaci, která se bude starat o import dat do mysql databáze. Říkal jsem si, že by to neměl být velký problém, podobných můstků jsem již několik vytvořil a tak jsem se do toho pustil.

Jelikož jsem měl již dřívější zkušenosti s mysql tak mi bylo jasné, že cesta přes ODBC určitě nepovede, protože je ve verzi 3.51 stále ještě chyba při ukládání datových typů (a možná to není jediná chyba) a vyšší verzi jsem nenašel.

Na stránkách mysql je k dispozici connector pro připojení k mysql databázi a tak jsem jej hodlal vyzkoušet. Aplikace pro import byla napsána poměrně rychle, a tak nastal čas testování.

Připojení a dotazy do mysql

A právě fáze testování přinesla, pro účely aplikace, nelichotivé výsledky. Aktualizace probíhala pomocí volání metody ExecuteNonQuery() na vytvořené instanci třídy MySqlCommand s naplněnými parametry. Čas potřebný k vykonání jednoho dotazu, sestávajícího pouze z volání dané metody, byl v rozmezí 60-80ms. Což představovalo v podání profileru nějakých 98% celkového času práce aplikace. Po vynásobení množstvím záznamů jsem se dostal k neúnosným číslům.

Alternativy v připojení nebo změna aplikace?

Začal jsem tedy hledat alternativy v připojení k mysql databázi. Vyzkoušel jsem ještě jeden provider, který měl však velice podobné časové nároky a tak nezbývalo, než zkusit změnit chování samotné aplikace. První varianta, která mě napadla je, celé to přesunout do samostatných vláken, což jsem ale záhy zamítl. Nechtěl jsem začít spravovat jednotlivá vlákna a ani ThreadPool jsem v tomto scénáři nechtěl použít - spíše šlo o jistou intuici a třeba jsem to měl zkusit.

Obdobně dopadl, tentokát již vyzkoušený pokus s voláním asynchronních metod, které jsou ve verzi ADO.NET 2.0 podporovány. I tak však vykonání několika stovek až tisíců příkazů bylo časově neúnosné. A tak jsem zkusil poslední možnost, která mě napadla.

Naplnil jsem vstupnímy daty DataTable a tu jsem pomocí vytvořeného DataAdapteru naimportoval do databáze. Výkon sice nebyl oslňující, ale přeci jen citelně lepší než v předchozích dvou případech. Navíc se v tomto scénáři dalo velice dobře využít výhod ThreadPoolu a to pro každou importovanou DataTable.

Víte o něčem lepším?

Je klidně možné, že existuje ještě lepší řešení, nebo i rychlejší connector pro přístup k mysql databázi. Pokud se chcete podělit, vaše rady určitě přivítám.

3 Comments

  • optik said

    Pouzit C++ nebo C++/CLI a ceckove knihovny pro mysql, ale to jste asi nechtel slyset :-)

  • Michal Blaha said

    Jardo, a overil jsi si pres poslani prikazu primo do MySQL pres ten jejich management tooll, ze takto dlouho netrva samotny prikaz?

    Jsi si uplne jisty, ze z tech 80ms to zustava dele nez 8ms v providerovi? Ja osobne bych o tom pochyboval.....

  • Jarda Jirava said

    Michale, přiznávám, že jsem zůstal jen na úrovni aplikace, což byla nejspíše osudová chyba. Skutečně se po vyladění databáze vše posunulo do dimenzí, ve kterých je aplikace použitelná. Budiž mi chabou omlouvou to, že k db jsem neměl přístup a pouze jsem doufal, že je k importu připravena.

Add a Comment