it-swarm-eu.dev

Jak velikost databáze ovlivňuje výkon: Teorie vs. realita

Tam je hodně tam, že říká, že velikost databáze by neměla nijak výrazně ovlivnit výkon. Dokud se indexy v tabulkách vejdou do paměti, měla by databáze zůstat funkční.

Jaká je však realita? Pokud architektura databáze není nejlepší, indexy se nevejdou do paměti a existuje potenciálně mnoho redundantních dat, existují významné zisky, které je třeba dosáhnout jednoduše odstraněním redundantních dat? Odhaduji, že by bylo možné smazat 60–80% dat v mé databázi.

Věřím, že snížení velikosti databáze a zvýšení hodnoty RAM tak, aby se indexy mohly vejít do paměti) by znamenalo výrazné zvýšení výkonu, což by poskytlo nějaký prostor pro dýchání po dobu několika měsíců, aby se systém znovu prohledal.

Existují také další faktory, jako je IO, fragmentace, pracovní datový soubor atd., Které ovlivňují výkon na základě velikosti databáze?

9
Oliver P

Záleží zcela na tom, co děláte s daty.

U základních transakcí vložení/aktualizace/smazání, které mají vliv jen na několik řádků, pak nárůst velikosti dat pravděpodobně není velkým hlediskem. Databáze použije indexy v paměti pro přístup na správnou stránku. Když tabulky již nezapadají do paměti, získáte více chyb v mezipaměti. Režie však může být nepatrná - v závislosti na databázi, konfiguracích databáze a hardwarových konfiguracích.

Pokud provádíte dotazy, které vyžadují prohledávání v celé tabulce, bude váš výkon s velikostí dat lineárně nebo horší. Indexy mohou situaci ve skutečnosti ještě zhoršit, a to náhodným přístupem na stránky, což pak do značné míry zaručuje, že chybí mezipaměť.

Alternativou k větší paměti je zvýšená rychlost disku - disk SSD může poskytnout ohromné ​​zlepšení.

Je nepravděpodobné, že by pouze mít více dat ovlivnilo výkon, pokud nebudou tabulky použity v dotazech. Jsou data nadbytečná v tabulce nebo napříč tabulkami? Mít velké tabulky, které se nikdy nezvyknou, je chaotický, ale má minimální dopad na výkon. Je možné si představit, že pokud máte zilliony zbytečných tabulek, pak by kompilace dotazů mohla začít trvat déle.

8
Gordon Linoff

Pravidlo ladění číslo jedna AMM (Add More Memory) je jednoduché. Je to také ten, který je velmi nákladný a na konci není účinný, pokud existují problémy se selektivitou. I když databáze zcela zapadá do paměti, může být výkon aplikace špatný. V nejhorším případě z důvodu zamykání a blokování během velmi a-selektivního provádění SQL. Ty by měly být stanoveny jako první. Jedním z důvodů je souběžnost, která je jako bít - a držet - přestávky, pokud každý SQL přistupuje ke všem datům v tabulce pokaždé.

Ujistěte se, že žádný SQL nemá přístup k více řádkům, než je potřeba. To dává nejefektivnější způsob, jak udržet dobrý výkon. Normální databáze ví, jak zacházet s io a provádí nějakou formu ukládání do mezipaměti nejpoužívanějších dat.

Pokud vaše aplikace již minimalizovala všechny možné přístupy a již používáte nejrychlejší diskové systémy, zvažte použití polí skutečné paměti flash. Mohou nahrnout výkon na jiné úrovni.

2
ik_zelf

Přečtěte si tyto příspěvky:

Tipy, jak vaše data co nejmenší:

Navrhněte své tabulky tak, aby se minimalizoval jejich prostor na disku. To může mít za následek obrovské zlepšení snížením množství dat zapsaných na disk a čtení z disku. Menší tabulky obvykle vyžadují méně hlavní paměti, zatímco jejich obsah se během zpracování dotazu aktivně zpracovává. Jakékoli zmenšení místa pro data tabulky také vede k menším indexům, které lze zpracovat rychleji.

MySQL podporuje mnoho různých paměťových modulů (typy tabulek) a formátů řádků. U každé tabulky se můžete rozhodnout, kterou metodu ukládání a indexování použijete. Výběr správného formátu tabulky pro vaši aplikaci vám může přinést velké zvýšení výkonu.

Můžete získat lepší výkon pro tabulku a minimalizovat úložný prostor pomocí zde uvedených technik: - Používejte nejúčinnější (nejmenší) možné typy dat. MySQL má mnoho specializovaných typů, které šetří místo na disku a paměť. Například pokud chcete získat menší tabulky, použijte menší typy celých čísel. MEDIUMINT je často lepší volbou než INT, protože sloupec MEDIUMINT využívá o 25% méně místa.

  • Pokud je to možné, deklarujte sloupce NENÍ NULL. Díky tomu je vše rychlejší a ušetříte jeden bit ve sloupci. Pokud opravdu potřebujete NULL ve své aplikaci, měli byste ji určitě použít. Ve výchozím nastavení jej nepoužívejte ve všech sloupcích.

  • Pokud v tabulkách MyISAM nemáte žádné sloupce s proměnnou délkou (sloupce VARCHAR, TEXT nebo BLOB), použije se formát řádků s pevnou velikostí.

  • Tabulky InnoDB používají kompaktní formát úložiště. Ve verzích MySQL starších než 5.0.3 obsahují řádky InnoDB některé redundantní informace, například počet sloupců a délku každého sloupce, dokonce i pro sloupce s pevnou velikostí. Ve výchozím nastavení jsou tabulky vytvářeny v kompaktním formátu (ROW_FORMAT = COMPACT). Přítomnost formátu kompaktních řádků snižuje úložný prostor řádků asi o 20% za cenu zvýšení využití CPU pro některé operace. Pokud je vaše pracovní vytížení typické, které je omezeno rychlostí přístupu do mezipaměti a rychlostí disku, bude pravděpodobně rychlejší. Pokud se jedná o vzácný případ, který je omezen rychlostí procesoru, může být pomalejší.

Kompaktní formát InnoDB také mění způsob ukládání sloupců CHAR obsahujících data UTF-8. S ROW_FORMAT = REDUNDANT zabírá UTF-8 CHAR (N) 3 × N bajtů, vzhledem k tomu, že maximální délka znaku kódovaného UTF-8 jsou tři bajty. Mnoho jazyků lze psát primárně pomocí jednobajtových znaků UTF-8, takže pevná délka úložiště často ztrácí místo. S formátem ROW_FORMAT = COMPACT InnoDB přiděluje pro tyto sloupce proměnné množství úložiště v rozsahu od N do 3 × N bajtů, v případě potřeby odstraněním koncových mezer. Minimální délka úložiště je udržována jako N bajtů, aby se v typických případech usnadnila aktualizace na místě.

  • Primární index tabulky by měl být co nejkratší. Díky tomu je identifikace každého řádku snadná a efektivní

  • Vytvořte pouze indexy, které opravdu potřebujete. Indexy jsou dobré pro vyhledávání, ale špatné, když potřebujete rychle ukládat data. Pokud k tabulce přistupujete většinou hledáním kombinace sloupců, vytvořte na nich index. První část indexu by měl být nejpoužívanějším sloupcem. Pokud při výběru z tabulky vždy používáte mnoho sloupců, měl by být první sloupec v indexu ten, který má nejvíce duplikátů, aby se dosáhlo lepší komprese indexu.

  • V některých případech může být užitečné rozdělit na dvě tabulky, které jsou skenovány velmi často. To platí zejména v případě, že se jedná o tabulku dynamického formátu a je možné použít menší tabulku statického formátu, kterou lze použít k nalezení příslušných řádků při skenování tabulky.

1
Mahesh Patil