Optimalizace / cache složitých sql dotazů rubrika: Databáze: SQL

3 jan_4
položil/-a 26.11.2015

Zdravím,

v rámci naší aplikace (nad MySQL databází) si může uživatel "naklikat" vlastní dotaz / filtr nad daty která k jeho účtu patří. Jelikož ten odtaz co si uživatel vytvoří může být poměrně komplikovaný napříč několika tabulkami a sloupci z nichž ne každý je indexovaný, může být ten dotaz ve výsledku docela pomalý. Část těch dat je ve formě jakéhosi logu, takže klasická cache nepřichází v úvahu, protože neustále přibývají nová data.

A vzhledem k tomu že aplikace pak s takovým dotazem tu a tam pracuje, přemýšlím jak tuto situaci nějak zoptimalizovat.

Je pro to nějaká vhodná cesta? Například nějak MySQL říct že tenhle konkrétní dotaz se bude opakovat tak aby se na to nějak připravilo?

díky za radu

Komentáře

  • roman.hocke : Dotaz - pokud byste všechny sloupce, co si uživatelé "naklikají" indexoval - pomohlo by to znatelně rychlosti těch dotazů? (Neřeším teď, že by se zpomalily inserty a spol.) Pokud ano, tak byste mohl indexovat preventivně všechno (pokud vás netrápí velikost) nebo vytvářet a rušit indexy dynamicky podle toho, jaké dotazy si uživatelé naklikají k používání (teda pokud jde o styl "naklikám si dotaz a pak ho léta používám", čili ne na jednorázové naklikání). — 27.11.2015
odkaz
8 tdvorak
odpověděl/-a 27.11.2015
 
upravil/-a 27.11.2015

Od začátku počítat, že každý dotaz bude pomalý a náročný. Tomu uzpůsobit aplikaci:

  • Všude pracovat s dotazem a výsledky asynchronně. Neblokovat si tím hlavní aplikaci.

  • dotazy volat třeba přes Hystrix nebo nějakou obdobu pro jiný jazyk. Tím získáš monitoring, timeout, fallbacky, circuit breaker. Částečně tak ochráníš databázi od přetížením jedním klientem a budeš mít představu, co se děje.

  • Pokud by dotazy příliš vytěžovaly databázový stroj, pak využít na tyto dotazy jiný DB stroj s nastavenou replikací dat z hlavní databáze (read only slave).

Komentáře

  • nov.ondrej : Ta mantra o asynchroním přístupu to už je fakt nemoc. Já všude používám threadové servery a nemám problém. Asi všichni jedou na nějakým jednoduchým nodejs server, nebo něčem horším. Jina asynchroní přístup nic nevyřeší, jen v pozadí vyrobí vlákno, který to zpracuje synchroně. Databáze samotná všechno řeší ve vláknech, tam to ani jinak nejde. — 27.11.2015
  • kohven : @nov.ondrej: Nevím kolik lidí jede na nodejs, ale vcelku dost lidí pořád ještě vytváří tlusté klienty. A tam se některým "daří" blokovat aplikaci poměrně často. — 27.11.2015
  • Kit : @kohven: Node.js považuješ za tlustého nebo tenkého klienta? Z mého pohledu je tlustým klientem, protože sežere docela dost RAM. — 27.11.2015
  • tdvorak : @nov.ondrej: takže ten jeden thread, co máš na request, zablokuješ načítáním z DB a čekáš a čekáš. Až načteš, začneš načítat něco dalšího. Místo toho, abys asynchronně nastartoval jednotlivý úlohy a na konci jen všechno poskládal? — 27.11.2015
  • nov.ondrej : @tdvorak zpravidla se mi daří dělat to formou jeden request jedno query, které se ptá na všechno naráz. Zadruhé, záleží na systému a na zátěži. Rozhodit práci po celém threadpool znamená, že ostatní uživatelé budou čekat, až má práce skončí. Je otázkou, zda potřebuju superrychlou odezvu, nebo je pro mě důležité neblokovat ostatní uživatele. Jakmile se latence dostane nad 200 ms, pak možná má smysl přemýšlet o nějakém asynchroním řešení - čti: použít nějaký threadový pool. Protože asynchroní operace jsou ve skutečnosti synchronní, jen si vytváří nový thread a k tomu připočti overhead na správu threadpoolu a předávání dat do něj a pak zpět do dispatcheru (a samotná latence dispatcheru). Dokud to tedy není potřeba, nemá smysl se tím zabývat. (za mých mladých let jsme měli apache, ten měl 32 workerů a každý request dostal jednoho, a vystačilo to na mnoho projektů) — 27.11.2015
  • kohven : @Kit: node.js považuji za běhové prostředí. Rozhodně ne za klienta. Za tlustého klienta považuji něco, co se připojuje na server, neběží v prohlížeči a nutně nevyžaduje http. Resp. desktopová aplikace, co se připojuje na server. Nicméně s dnešníma SPA už se ty rozdíly mezi tlustým a tenkým klientem stírají. Ale pro tenhle případ to dává smysl, protože javascript (v tenkém klientu) s neblokujícími operacemi více počítá a díky funkcionální povaze většinou nedělá lidem takové problémy psát asynchronně, jako např. v C. Možná je to z mé strany tak trochu diskusní faul, protože vím, jak to myslel tdvorak a přesto jsem psal o trochu jiném blokování na straně klienta, kde jde spíš o zamrzání GUI, ale s potřebností "mantry o asynchronním přístupu" to docela souvisí. — 27.11.2015
  • nov.ondrej : V mé C++ knihovně jsou normálně servisní vlákna a promisy, jako v js. A jsou tam už delší dobu. Nicméně promisy (future) jsou i součástí C++11. Doufám, že teď už budou lidi psát kód slušněji. Nicméně žádný klient by neměl rozhodit server. Pak ho totiž může rozhodit i Dos attack — 27.11.2015

Pro zobrazení všech 6 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.

Aktuální otázky v rubrice Databáze: SQL

Otázky uživatele jan_4