Zpracování velmi velkých dat pomocí mysql

Dokáže MySQL rozumně provádět dotazy na miliardy řádků? -- MySQL dokáže „zpracovat“ miliardy řádků. "Přiměřeně" závisí na dotazech; pojďme se na ně podívat.

Je InnoDB (MySQL 5.5.8) správnou volbou pro řádky s mnoha miliardami? -- 5.7 má některá vylepšení, ale 5.5 je docela dobrá, i když je téměř 6 8 let a na pokraji již není podporován.

Nejlepší úložiště dat pro miliardy řádků – pokud máte na mysli „Engine“, pak InnoDB.

Jak velká může být databáze MySQL, než se výkon začne zhoršovat -- Opět to závisí na dotazech. Mohu vám ukázat 1000 řádkovou tabulku, která se zhroutí; Pracoval jsem s tabulkami s miliardami řádků, které hučí.

Proč by mohlo být MySQL pomalé s velkými tabulkami? -- Skenování rozsahu vede k I/O, což je ta pomalá část.

Dokáže Mysql zpracovat tabulky, které pojmou asi 300 milionů záznamů? -- opět ano. Limit je někde kolem bilionu řádků.

(pro tabulky InnoDB, což je můj případ) zvýšení velikosti innodb_buffer_pool_size (např. až 80 % RAM). Také jsem zde na blogu Percona našel některá další nastavení ladění výkonu MySQL -- ano

mít v tabulce správné indexy (pomocí EXPLAIN na dotazy) -- no, podívejme se na ně. V tomto kritickém lze udělat mnoho chyb oblast.

rozdělení tabulky -- "Rozdělení není všelék!" Naznačuji to na mém blogu

MySQL Sharding – v současnosti je to DIY

Klastrování MySQL -- V současné době je nejlepší odpovědí nějaká možnost založená na Galeře (PXC, MariaDB 10, DIY w/Oracle). "Group Replication" společnosti Oracle je životaschopným uchazečem.

Rozdělení nepodporuje FOREIGN KEY nebo "globální" UNIQUE .

UUID v rozsahu, o kterém mluvíte, systém nejen zpomalí, ale ve skutečnosti ho zabijí. UUID typu 1 může být řešením.

Rychlost vkládání a sestavení indexu -- Existuje příliš mnoho variant, než aby bylo možné poskytnout jedinou odpověď. Podívejme se na vaši nezávaznou CREATE TABLE a jak hodláte data vložit.

Spousta spojení -- "Normalizovat, ale nepřenormalizovat." Zejména nenormalizujte datum a čas, plovoucí nebo jiné „souvislé“ hodnoty.

Vytvořte souhrnné tabulky

2,3 milionu transakcí denně – pokud to je 2,3 milionu vložení (30/s), pak není velký problém s výkonem. Pokud je to složitější, může být zapotřebí RAID, SSD, dávkové zpracování atd.

vypořádat se s takovým objemem dat -- Pokud je většina aktivity s „nedávnými“ řádky, pak buffer_pool pěkně „uloží“ aktivitu do mezipaměti, čímž se vyhne I/O. Pokud je aktivita „náhodná“, pak MySQL (nebo kdokoli else) bude mít I/O problémy.

Zmenšení datových typů pomáhá v tabulce, jako je ta vaše. Pochybuji, že ke specifikaci fuel_type potřebujete 4 bajty . Existuje několik 1bajtových přístupů.