it-swarm-eu.dev

Jak pomáhá dělení tabulek?

Mám potíže s pochopením výhod a nevýhod rozdělení tabulek. Chystám se začít pracovat na projektu, který by měl 8 tabulek a jednou z nich bude hlavní datová tabulka, která pojme 180–260 milionů záznamů. Protože to bude řádně indexovaná tabulka, tak přemýšlím o omezení záznamů tabulky na 20 milionů tímto způsobem, musím vytvořit 9-13 tabulek.

Ale nejsem si úplně jistý, jak to zlepší výkon, protože budou sedět na stejném počítači (32 GB RAM)?

Používám MySQL a tabulky by byly MyISAM a velká tabulka by měla index na poli id ​​a neexistují další složitosti, jako je fulltextové vyhledávání atd.

Prosvětlete prosím také rozdělení na tabulky a rozdělení databáze.

28
Rick James

Následující je jen šílené výkřiky a zuřivost ...

Pokud ponecháte všechna data v jedné tabulce (bez rozdělení disku), budete mít klíčové O (log n) časy vyhledávání. Vezměme si nejhorší index na světě, binární strom. Každý uzel stromu má přesně jeden klíč. Dokonale vyvážený binární strom s 268 435 455 (2 ^ 28 - 1) uzly stromů by byl výška 28. Pokud rozdělíte tento binární strom na 16 samostatných stromů, získáte 16 binárních stromů s 16 777 215 (2 ^ 24 - 1) uzly stromů pro výšku 24. Prohledávací cesta je snížena o 4 uzly, což je 14,287% snížení výšky. Je-li doba vyhledávání v mikrosekundách, je zkrácení doby hledání o 14,2887% nulové.

V reálném světě by index BTREE měl treenody s více klíči. Každé BTREE vyhledávání by provedlo binární vyhledávání na stránce s možným slušným do jiné stránky. Například, kdyby každá stránka BTREE obsahovala 1024 klíčů, výška stromu 3 nebo 4 by byla normou, skutečně krátká výška stromu.

Všimněte si, že účast na stole nesnižuje výšku BTREE, která je již malá. Při rozdělení na 260 miliónů řádků existuje dokonce vysoká pravděpodobnost, že bude mít více BTREE se stejnou výškou. Hledání klíče může pokaždé projít všemi kořenovými stránkami BTREE. Pouze jeden splní cestu potřebného rozsahu vyhledávání.

Nyní rozbalte. Všechny oddíly existují na stejném počítači. Pokud pro každý oddíl nemáte samostatné disky, budete mít rotace V/V disku a vřetena jako automatický úzký profil mimo výkon hledání oddílů.

V tomto případě vám paritioning by database nic nekoupí, pokud je id utitlized jediným vyhledávacím klíčem.

Rozdělení dat by mělo sloužit k seskupení dat, která jsou logicky a soudržně ve stejné třídě. Výkon hledání každého oddílu nemusí být hlavním hlediskem, pokud jsou data správně seskupena. Jakmile dosáhnete logického rozdělení, zaměřte se na dobu vyhledávání. Pokud pouze oddělujete data pouze pomocí id, je možné, že k mnoha řádkům dat nebude nikdy možné přistupovat pro čtení nebo zápisy. Nyní to by mělo být hlavní hledisko: Vyhledejte všechna nejčastěji přístupná ID a podle toho rozdělte oddíl. Všechna méně často přístupná ID by měla být umístěna v jedné velké archivní tabulce, která je stále přístupná vyhledáváním indexu pro dotaz „jednou za měsíc“.

Celkový dopad by měl mít alespoň dva oddíly: jeden pro často přístupné idy a druhý pro ostatní idy. Pokud jsou často přístupná ID poměrně velká, můžete ji případně rozdělit.

32
RolandoMySQLDBA

200 milionů řádků je určitě v rozsahu, ve kterém byste mohli mít prospěch z dělení tabulek. V závislosti na vaší aplikaci můžete vsadit některé z výhod uvedených níže:

  • Snadné vymazání starých dat Pokud potřebujete vymazat záznamy starší než (řekněme) 6 měsíců staré, můžete tabulku rozdělit podle data a poté vyměnit starší oddíly. Je to mnohem rychlejší než mazání dat z tabulky a často se to dá provést v živém systému. V případě operačního systému to může být užitečné pro údržbu systému.

  • Více diskových svazků Rozdělení diskových oddílů umožňuje rozdělit data a distribuovat diskový provoz na více diskových svazcích. U moderního řadiče RAID to pravděpodobně nebude problém pro OP.

  • Rychlejší prohledávání tabulek a rozsahů Opravdu by operační systém neměl dělat takové věci, ale datový sklad nebo podobný systém bude tento druh dotazů provádět kvantitativně. Prohledávání tabulek využívá hlavně sekvenční diskový provoz, takže jsou obvykle nejúčinnějším způsobem zpracování dotazu, který vrací více než několik procent řádků v tabulce.

    Dělení pomocí společného filtru (obvykle na základě času nebo období) umožňuje, aby velké kusy tabulky byly z takových dotazů odstraněny, pokud lze predikát rozeznat pomocí rozdělovacího klíče. Rovněž umožňuje rozdělení tabulky na více svazků, což může přinést významné zvýšení výkonu pro velké soubory dat. Normálně to není problém pro operační systémy.

Pro účely OP není pravděpodobné, že rozdělením na oddíly nebude dosaženo velkého přínosu pro provozní dotazy, ale může to být užitečné pro správu systému. Pokud existuje významný požadavek na vykazování agregátů na velkých objemech dat, může s tím pomoci vhodné schéma rozdělování.

Rozdělení oddílů umožňuje souběžné reorgs podle oddílů, pokud jsou všechny vaše indexy rozděleny na oddíly. Pokud ne, oddíly jsou stále mnohem menší a k reorgizaci používají méně pracovního prostoru. Interně může jakýkoli „dobrý“ DBMS dělat věci paralelně s tabulkami rozdělenými do oddílů. To pravděpodobně nezahrnuje MySQL nebo MyISAM, tho ....

1
Bill