Výkon různých přístupů k časově založeným datům

Na jednu stranu je dobře, že jste otevřeli novou otázku. Ale na druhou stranu, extrahováním jednoho dotazu a dotazem, zda funguje rychleji, ztrácí kontext předchozí otázky, je nová otázka příliš izolovaná. Jak jistě víte, správa databáze, správa zdrojů (paměť/mezipaměť, disk, cykly CPU), správa kódu (dobrého nebo špatného), který tyto prostředky využívá, to vše je součástí celého obrazu. Výkon je obchodní hra, nic není zadarmo.

1. Nejdůležitější problém, který jsem měl, byla duplikace sloupce EndDate, který lze snadno odvodit. Duplicitní sloupce se rovná Aktualizovat anomálie. Smirkingman poskytl klasický příklad:některé dotazy dostanou jeden výsledek a jiné dotazy dostanou druhý. To je prostě nepřijatelné pro velké organizace; nebo v bankách (alespoň ve vyspělých zemích), kde jsou data auditována a chráněna. Porušili jste základní pravidlo normalizace a musíte zaplatit penále.

   • Aktualizovat Anomailes; dvě verze (již podrobné). Auditoři nemusí projít systémem.

   • Velikost tabulky
     V každé velké tabulce je to problém a zvláště v časových řadách nebo časových datech, kde je počet sloupců malý a počet řádků obrovský. Tak co, někdo řekne, místo na disku je levné. Ano, stejně jako pohlavní choroby. Důležité je, k čemu slouží a jak dobře se o něj člověk stará.

     • Prostor na disku
       Na PC může být levný, ale na produkčním serveru není. V podstatě jste přidali 62 % k velikosti řádku (13 plus 8 se rovná 21), a tedy k velikosti tabulky. V bance, ke které jsem aktuálně přidělen, je každé oddělení, které vlastní data, zpoplatněno následovně, úložiště založené na SAN je vše, co existuje. Údaje jsou za GB za měsíc (nejedná se o špičkovou australskou banku):

       1,05 $ za RAID5 Unmirrored
       (víme, že je pomalý, ale je levný, jen na něj neuvádějte důležité informace, protože pokud se rozbije, po výměně nového disku za tepla nebo za studena to trvá několik dní aby se znovu synchronizoval.)

       2,10 $ za RAID5 Mirrored
       V SAN, to je.

       4,40 $ za RAID1+0
       Minimum pro produkční data, zálohované protokoly transakcí a noční výpisy z databáze.

       9,80 $ za RAID1+0 Replicated
       Na identické rozvržení SAN na jiném místě odolném proti bombám. Přerušení výroby během několika minut; téměř nulová transakční ztráta.

     • Paměť/Cache
       Ok, Oracle ji nemá, ale seriózní bankovní databáze mají mezipaměti a jsou spravovány. Vzhledem k jakékoli konkrétní velikosti mezipaměti se do stejné velikosti mezipaměti vejde pouze 62 % řádků.

     • Logické a fyzické I/O
       Což znamená o 50 % více I/O pro čtení tabulky; jak streamování do mezipaměti, tak čtení disku.

2. Zda dotaz funguje lépe nebo hůře izolovaně, je tedy akademickým problémem. V kontextu výše uvedeného tabulka je pomalý a má o 62 % horší výkon po celou dobu, při každém přístupu. A ovlivňuje všechny ostatní uživatele na serveru. Většině správců databází bude jedno (já bych rozhodně ne), jestli formulář poddotazu funguje poloviční rychlostí, protože jejich bonus je vázán na přijetí auditu, nejen na výkon kódu.

   • Kromě toho je tu další výhoda, že nikdy nebudete muset znovu navštěvovat kód a opravovat transakce kvůli anomáliím aktualizací.

   • A transakce mají méně bodů k aktualizaci, takže jsou menší; méně blokovacích zámků atd.

3. Souhlasím, že diskuse v komentářích jsou obtížné. Ve své odpovědi jsem podrobně a vysvětlil dva dílčí dotazy. Došlo k nedorozumění:mluvili jste o tomto poddotazu (v klauzuli WHERE poddotaz tabulky ) a mluvil jsem o druhém poddotazu (v seznamu sloupců skalární poddotaz ), když jsem řekl, že funguje stejně rychle nebo rychleji. Nyní, když to bylo vyčištěno, nemohu říci, že první dotaz výše (poddotaz v klauzuli WHERE, tabulka) bude fungovat stejně rychle jako druhý dotaz (s duplikovaným sloupcem); první musí provést 3 skeny, zatímco druhý provede pouze 2 skeny. (Troufám si říct, že druhý bude skenovat tabulku.)

   Jde o to, že kromě problému s izolací to není spravedlivé srovnání, uvedl jsem poznámku o skalárních poddotazech. Nedoporučoval bych, aby dotaz na 3 skeny byl stejně rychlý nebo rychlejší než dotaz na 2 skeny.

   Prohlášení, které jsem učinil o poddotazu tabulky 3 skenování (který zde cituji), je třeba brát v plném kontextu (buď tento příspěvek in toto, nebo výše uvedený). Neustupuji od toho.

   Půlku života trávím odstraňováním nelegálních alternativ, jako jsou duplicitní sloupce, které jsou založeny na otázce výkonu, přičemž tvůrci skandují mantru stůl je pomalý, takže se „denormalizovali na výkon“. Výsledkem, který lze předvídat, než začnu, je stůl poloviční velikosti, který je celkově dvakrát rychlejší . Times Series je zde nejčastější otázkou (odkaz odkazuje na jinou otázku, která odkazuje na jinou), ale představte si problém v bankovní databázi:denně OpeningExposure a ClosingExposure podle Security za Holding za UnitTrust podle Portfolio .

4. Dovolte mi však odpovědět na otázku, která nebyla položena. Tento druh interakce je normální, není neobvyklý při práci s interními vývojovými týmy; přichází minimálně jednou za měsíc. Crash hot vývojář už napsal a otestoval svůj kód, pomocí tabulky s duplikovaným sloupcem to letí a teď se to zastavilo, protože to nedám do db.

   Ne, otestuji to v kontextu celého systému a:

   • v polovině času se tabulka zařadí bez sloupce EndDate, protože neexistuje žádný velký problém s tím, že půlsekundový dotaz se nyní provádí za jednu sekundu.

   • V druhé polovině času není výkon [table subquery] přijatelný, takže implementuji booleovský (bitový) indikátor pro identifikaci IsCurrent . To je mnohem lepší než duplikovaný sloupec a poskytuje rychlosti 2 skenování.

   • Ani za milion let mě nedonutíte duplikovat sloupek; přidání 62 % k velikosti tabulky; zpomalení tabulky v plném kontextu pro více uživatelů o 62 %; a riskovat selhání auditu. A to nejsem zaměstnanec, nedostávám prémie.

   Nyní by to stálo za otestování:dotaz s duplicitním sloupcem vs dotaz s IsCurrent indikátor, v plném kontextu celkového využití zdrojů.

5. Smirkingman uvedl dobrou věc. A přeformuluji to jasně, aby nedošlo k fragmentaci a následnému napadení jednoho nebo druhého fragmentu. Prosím, nerozebírejte to:

   Relační databáze,
   Normalizovaná zkušeným relačním modelářem na skutečnou pátou normální formu
   (žádné anomálie aktualizací; žádné duplicitní sloupce),
   s úplným dodržováním vztahů
   (IDEF1X, zejména týkající se minimalizace Id Primární klíče; a tím neochromit sílu relačního enginu)
   bude mít za následek více menších tabulek, menší databázi
   s menším počtem indexů,
   vyžadujících méně spojení
   (je to tak, více stolů, ale méně spojení),
   a překoná vše, co porušuje některá z těchto pravidel
   na stejném hardwaru a podniku platforma db
   (nezahrnuje freeware, MS, Oracle; ale nenechte se tím zastavit),
   v plném kontextu produkčního použití OLTP
   alespoň o jeden řád
   a bude mnohem jednodušší jej používat
   a měnit
   (nikdy není potřeba „refaktoring“).

   Udělal jsem to nejméně 80krát. Dva řády nejsou neobvyklé, pokud to dělám sám, spíše než abych poskytoval rámec pro někoho jiného, ​​aby to udělal.

Ani mě, ani lidi, se kterými pracuji nebo kteří mě platí, nezajímá, co udělá jeden dotaz izolovaně.