it-swarm-eu.dev

Může MySQL přiměřeně provádět dotazy na miliardy řádků?

Plánuji ukládání skenů z hmotnostního spektrometru do databáze MySQL a rád bych věděl, zda je ukládání a analýza tohoto množství dat na dálku proveditelné. Vím, že výkon se velmi liší v závislosti na prostředí, ale hledám hrubý řád velikosti: budou dotazy trvat 5 dní nebo 5 milisekund?

Vstupní formát

Každý vstupní soubor obsahuje jeden běh spektrometru; každý běh se skládá ze sady prověřování a každé prohledávání má uspořádané pole datových bodů. Existuje trochu metadat, ale většina souboru se skládá z polí 32 nebo 64 bitů ints nebo float.

Hostitelský systém

 | ---------------- + --------------------------- - | OS | Windows 2008 64bitový | 
 | Verze MySQL | 5.5.24 (x86_64) | 
 | CPU 2x Xeon E5420 (celkem 8 jader) | 
 | RAM | 8 GB | 
 | SSD souborový systém | 500 GiB | 
 | HDD RAID | 12 TiB | 
 | ---------------- + ------------------------------- | 

Na serveru běží některé další služby využívající zanedbatelný čas procesoru.

Statistiky souborů

 | ------------------ + -------------- | 
 | počet souborů | ~ 16 000 | 
 | celková velikost | 1.3 TiB | 
 | minimální velikost | 0 bajtů | 
 | maximální velikost | 12 GiB | 
 | Střední | 800 MiB | 
 | Medián | 500 MiB | 
 | Celkové datové body | ~ 200 miliard | 
 | ------------------ + -------------- | 

Celkový počet datových bodů je velmi hrubý odhad.

Navrhované schéma

Mám v plánu dělat věci „správně“ (tj. Normalizovat data jako blázen), a tak by měla tabulka runs, tabulka spectra s cizím klíčem runs a tabulku datapoints s cizím klíčem k spectra.

Otázka datového bodu 200 miliard

Budu analyzovat napříč různými spektry a možná i více běhy, což povede k dotazům, které by se mohly dotknout milionů řádků. Za předpokladu, že všechno správně indexuji (což je téma pro jinou otázku) a nesnažím se zamíchat stovky MiB v síti, je to pro MySQL vzdáleně věrohodné?

Doplňující informace

Skenovaná data budou pocházet ze souborů ve formátu --- (mzML ve formátu XML. Maso tohoto formátu je v <binaryDataArrayList> prvky, kde jsou data uložena. Každé skenování vytvoří> = 2 <binaryDataArray> prvky, které dohromady vytvářejí dvourozměrné (nebo více) pole formuláře [[123.456, 234.567, ...], ...].

Tato data jsou jednorázová, takže výkon aktualizace a bezpečnost transakcí se netýkají.

Můj naivní plán pro databázové schéma je:

runs tabulka

 | název sloupce | typ | 
 | ------------- + ------------- | 
 | id | PRIMÁRNÍ KLÁVES | 
 | start_time | TIMESTAMP | 
 | jméno | VARCHAR | 
 | ------------- + ------------- | 

spectra tabulka

 | název sloupce | typ | 
 | ---------------- + ------------- | 
 | id | PRIMÁRNÍ KLÁVES | 
 | jméno | VARCHAR | 
 | index | INT | 
 | spektrum_typ | INT | 
 | zastoupení | INT | 
 | run_id | ZAHRANIČNÍ KEY | 
 | ---------------- + ------------- | 

datapoints tabulka

 | název sloupce | typ | 
 | ------------- + ------------- | 
 | id | PRIMÁRNÍ KLÁVES | 
 | spektrum_id | ZAHRANIČNÍ KLÁVES | 
 | mz | DOUBLE | 
 | num_counts | DOUBLE | 
 | index | INT | 
 | ------------- + ------------- | 

Je to rozumné?


Takže, jak jste možná mohli odvodit, jsem programátor, ne biolog v laboratoři, takže vědu téměř stejně dobře neznají jako skuteční vědci.

Tady je spiknutí jediného spektra (skenování) druhu dat, se kterými budu jednat:

Viewer screenshot

Cílem softwaru je zjistit, kde a jak významné jsou vrcholy. Používáme proprietární softwarový balíček, abychom to zjistili nyní, ale chceme napsat vlastní analytický program (v R), takže víme, co se to sakra děje pod listy. Jak vidíte, naprostá většina dat je nezajímavá, ale nechceme vyhodit potenciálně užitečná data, která náš algoritmus vynechal. Jakmile máme seznam pravděpodobných píků, se kterými jsme spokojeni, zbytek potrubí použije tento seznam píků spíše než hrubý seznam datových bodů. Předpokládám, že by stačilo uložit nezpracované datové body jako velké blob, takže mohou být v případě potřeby znovu analyzovány, ale pouze vrcholy jako odlišné položky databáze. V takovém případě by na spektrum existovalo jen několik desítek vrcholů, takže by bláznivé měřítko nemělo být problémem.

285
haxney

Nejsem moc obeznámen s vašimi potřebami, ale možná uložení každého datového bodu do databáze je trochu zbytečné. Zní to téměř jako přistupovat k ukládání knihovny obrázků ukládáním každého pixelu jako samostatného záznamu do relační databáze.

Obecně platí, že ukládání binárních dat do databází je většinou špatné. Obvykle existuje lepší způsob řešení problému. I když není přirozeně špatné ukládat binární data v relační databázi, často převažují nevýhody nad výhodami. Relační databáze, jak název zmiňuje, jsou nejvhodnější pro ukládání relačních dat. Binární data nejsou relační. Přidává velikost (často výrazně) do databází, může poškodit výkon a může vést k otázkám ohledně udržování miliardových záznamů MySQL. Dobrou zprávou je, že existují databáze zvláště vhodné pro ukládání binárních dat. Jedním z nich, i když to není vždy zřejmé, je váš systém souborů! Jednoduše přijďte s adresářem a strukturou pojmenování souborů pro vaše binární soubory, uložte je do MySQL DB společně s dalšími daty, která mohou přinést hodnotu dotazováním.

Dalším přístupem by bylo použití úložného systému založeného na dokumentech pro vaše datové body (a možná spektra) a používání MySQL pro běhy (nebo možná uvedení běhů do stejné DB jako ostatní).

117

Jednou jsem pracoval s velmi velkou (Terabyte +) MySQL databází. Největší stůl, který jsme měli, byl doslova přes miliardu řádků. To používalo MySQL 5.0, takže je možné, že se věci zlepšily.

Fungovalo to. MySQL data zpracovávala většinu času správně. Bylo to však nesmírně těžké. (Pokud chcete dostupnost šesti sigma úrovní s terabajtem dat, nepoužívejte MySQL. Byli jsme startup, který neměl žádné DBA a omezené prostředky.)

Jen zálohování a uložení dat bylo výzvou. Obnovení tabulky by trvalo několik dní, kdybychom to potřebovali.

Měli jsme četné tabulky v rozsahu 10–100 milionů řádků. Jakékoli významné připojení ke stolům bylo příliš časově náročné a trvalo by to věčně. Napsali jsme tedy uložené procedury, které „procházejí“ tabulky a spojují procesy proti rozsahům „id“. Tímto způsobem bychom zpracovali data 10 - 100 000 řádků najednou (připojte se proti číslům 1-100 000, poté 100 000–1 000 000 atd.). To bylo podstatně rychlejší než spojení s celým stolem.

Použití indexů na velmi velkých tabulkách, které nejsou založeny na primárním klíči, je také mnohem obtížnější. Mysql 5.0 ukládá indexy ve dvou kusech - ukládá indexy (jiné než primární index) jako indexy do hodnot primárního klíče. Indexovaná vyhledávání jsou tedy provedena ve dvou částech: První MySQL jde do indexu a odtáhne z něj hodnoty primárního klíče, které potřebuje najít, poté provede druhé vyhledávání v indexu primárního klíče, aby zjistil, kde jsou tyto hodnoty.

Síť tohoto je to pro velmi velké tabulky (1-200 miliónů plus řádky) indexování proti tabulkám je více omezující. Potřebujete méně, jednodušších indexů. A dokonce i jednoduché výběry, které nejsou přímo v indexu, se nemusí nikdy vrátit. Kde klauzule musí zasáhnout indexy nebo na to zapomenout.

Ale všechno, co bylo řečeno, věci skutečně fungovaly. MySQL jsme mohli použít s těmito velmi velkými tabulkami a provádět výpočty a získat odpovědi, které byly správné.

Pokus o provedení analýzy na 200 miliardách řádků dat by vyžadoval velmi kvalitní hardware a spoustu rukou a trpělivosti. Pouze udržování zálohovaných dat ve formátu, ze kterého byste mohli obnovit, by bylo významnou prací.

Souhlasím s odpověď srini.venigalla , že normalizace dat jako blázen zde nemusí být dobrý nápad. Spojení napříč několika tabulkami s tolika údaji vás otevře, až se dostanete k riziku druhů souborů , což by mohlo znamenat, že by se některé z vašich dotazů nikdy nevrátily. Denormalizace s jednoduchými celočíselnými klíči vám dá větší šanci na úspěch.

Všechno, co jsme měli, bylo InnoDB. Pokud jde o MyISAM vs. InnoDB: Hlavní věcí by bylo nemíchat tyto dva. Nemůžete opravdu optimalizovat server pro oba kvůli způsobu, jakým MySQL ukládá klíče a jiná data do mezipaměti. Vyberte jednu nebo druhou ze všech tabulek na serveru, pokud je to možné. MyISAM může pomoci s některými problémy s rychlostí, ale nemusí pomoci s celkovou prací DBA, kterou je třeba udělat - což může být vrah.

111
Kevin Bedell

normalizace dat jako blázen

Normalizace dat jako blázen nemusí být v tomto případě správnou strategií. Udržujte své možnosti otevřené ukládáním dat jak v normalizované podobě, tak i ve formě zhmotněných pohledů, které jsou pro vaši aplikaci velmi vhodné. Klíčem v tomto typu aplikací NENÍ zápis adhoc dotazů. Modelování dotazů je důležitější než modelování dat. Začněte s cílovými dotazy a usilovejte se o optimální datový model.

Is this reasonable?

Také bych vytvořil další plochý stůl se všemi údaji.

run_id | spectrum_id | data_id | <data table columns..> |

Tuto tabulku použiji jako primární zdroj všech dotazů. Důvodem je, aby se nemuselo dělat žádné spojení. Spojení bez indexování způsobí, že váš systém bude velmi nepoužitelný, a mít indexy na tak obrovských souborech bude stejně hrozné.

Strategie je, nejprve dotaz na výše uvedenou tabulku, vypsat výsledky do dočasné tabulky a připojit se k dočasné tabulce s vyhledávacími tabulkami Run and Spectrum a získat požadovaná data.


Analyzovali jste vaše potřeby zápisu a potřeby čtení? Bude velmi lákavé prokopávat SQL a přistupovat k nestandardním mechanismům ukládání dat. Podle mého názoru by to měla být poslední možnost.

Chcete-li zrychlit rychlost zápisu, můžete vyzkoušet metodu Handler Socket. Percona, pokud si pamatuji, balíčky Handler Socket v jejich instalačním balíčku. (žádný vztah k Perconě!)

http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html

70
srini.venigalla

Krátká odpověď je kvalifikovaná ano - protože počet řádků roste, přesné schéma, datové typy a operace, které vyberete, rostou na důležitosti.

Jak normalizujete svá data, záleží na operacích, které plánujete s uloženými daty provádět. Obzvláště vaše tabulka „datových bodů“ se jeví jako problematická - plánujete porovnat n-tý bod z nějakého daného spektra s mthem jiného? Pokud tomu tak není, může být jejich samostatné uložení chybou. Pokud vaše datové body nejsou osamocené, ale dávají smysl pouze v souvislosti s jejich přidruženými spektry, nepotřebujete PRIMÁRNÍ KLÁVES - postačí cizí klíč ke spektrům a postačí sloupec „n“ (váš indexový sloupec?) .

Definujte inter- a intra-spektrální operace, které musíte provést, a pak vymyslete nejlevnější způsob, jak je provést. Pokud je nutná rovnost, mohou být denormalizovány - možná s některými předem vypočítanými statistickými metadaty, které pomáhají vašim činnostem. Pokud absolutně potřebujete přístup v SQL k jednotlivým datovým bodům, zajistěte, abyste zmenšili velikost každého řádku na holý minimální počet polí a co nejmenší možný datový typ.

Největší MySQL, jakou jsem kdy osobně spravoval, bylo ~ 100 milionů řádků. Při této velikosti, kterou chcete udržet své řádky a tím i vaše pole pevná velikost - to MySQL umožňuje efektivně vypočítat pozici libovolného řádku v tabulce vynásobením časů pevné velikosti každého řádku (aritmetika přemýšlení ukazatele) - přesné údaje však závisejí na tom, jaký paměťový modul plánujete použít. Používejte MyISAM, pokud se s ním můžete dostat pryč, co mu chybí spolehlivost, kterou si vymyslí rychlost a ve vaší situaci by to mělo stačit. Nahraďte pole s proměnnou velikostí, například VARCHAR, za CHAR (n) a použijte RTRIM () ve vašich přečtených dotazech.

Jakmile jsou řádky vaší tabulky pevné šířky, můžete snížit počet bajtů pečlivým vyhodnocením celostátních datových typů MySQL (některé z nich jsou nestandardní). Každá 1-bajtová úspora, kterou můžete dosáhnout, převedením 4-bajtového INT na 3-bajtový MEDIUMINT vám ušetří ~ 1 MB na milion řádků - to znamená méně diskového vstupu/výstupu a efektivnější ukládání do mezipaměti. Použijte nejmenší možné datové typy, s nimiž se můžete dostat . Pečlivě vyhodnoťte typy s pohyblivou řádovou čárkou a zjistěte, zda můžete nahradit 8bajtové DOUBLE 4bajtové FLOATY nebo dokonce <8 bajtů NUMERICKY s pevnou čárkou . Spusťte testy, abyste se ujistili, že to, co si vyberete, vás později neusuší.

V závislosti na očekávaných vlastnostech vašeho datového souboru a požadovaných operacích může dojít k dalším úsporám v neobvyklejším kódování vašich hodnot (očekávané vzory/opakování, které lze kódovat jako index do sady hodnot, surová data, která mohou pouze významně přispět k metadata a být vyřazeny atd.) - ačkoli exotické, neintuitivní, destruktivní optimalizace jsou užitečné pouze tehdy, pokud byla vyzkoušena každá jiná možnost.

A co je nejdůležitější, bez ohledu na to, co nakonec uděláte, nepředpokládejte, že jste vybrali dokonalé schéma, a poté slepě začněte skládat 10 s milionů záznamů. Vytvořte velkou, ale spravovatelnou (řekněme 1-5%) sadu testovacích dat a ověřte správnost a výkon vašeho schématu. Podívejte se, jak různé operace provádějí (http://dev.mysql.com/doc/refman/5.0/en/using-explain.html), a ujistěte se, že vyvažujete své schéma a upřednostňujete nejčastější operace.

Řekl jsem krátce? Jejda. Každopádně hodně štěstí!

33
Ryan Flynn

Zdá se, že jediným důvodem, jak vyřadit data datových bodů z XML (na rozdíl od metadat, jako je čas a typ běhu) a do databázového formuláře, je, když analyzujete spektra napříč poli - tj. Možná najdete všechny běží s určitým podpisem. Teprve teď znáte svou problémovou doménu, ale to by se mohlo podobat ukládání hudby vzorkované při 96 kHz s 1 vzorkou na řádek. Nejsem si jistý, že velikost je problém víc, než jak se data používají. Dotaz na data by byl ekvivalentní dotazu na relativní amplitudu 2 minuty do písně napříč všemi písněmi The Beatles. Pokud znáte druhy analýz, které by mohly být provedeny, je docela možné, že provedení těchto signálů a jejich uložení do metadat o běhu může mít větší smysl.

Nejsem si také jistý, zda jsou vaše zdrojová data řídká. Je zcela možné, že spektrum v databázi by mělo obsahovat pouze nenulové položky, zatímco původní XML obsahuje nulové položky, takže váš celkový počet řádků může být mnohem menší než ve zdrojových datech.

Stejně jako mnoho otázek, tak před tím, než se zeptáme na to, jak MySQL pracuje s vaším modelem, je krok zpět a podíváme se na model a jak se bude používat, je pravděpodobně vhodnější, než se obávat výkonu, zatím.


Po přezkoumání aktualizací vašich otázek si myslím, že model, ve kterém jsou binární data uložena jako BLOB nebo jen ukazatel na soubor, je dostatečný a pracuje na úpravě modelu tak, aby ukládal data o významných vrcholech, které byly identifikovány, když jsou data první číst.

23
Cade Roux

Provozuji webovou analytickou službu s asi 50 databázovými servery, z nichž každý obsahuje mnoho tabulek přes 100 milionů řádků a několik z nich má tendenci být přes miliardu řádků, někdy až dvě miliardy (na každém serveru).

Představení je v pořádku. Jedná se o velmi normalizovaná data. Nicméně - mým hlavním zájmem při čtení je to, že budete dobře nad 4,2 miliardami řádků pro tyto tabulky (možná ne „běhy“, ale pravděpodobně další dvě), což znamená, že budete muset použít BIGINT namísto INT pro primární/cizí klíče.

Výkon MySQL s poli BIGINT v indexovaném sloupci je směšně hrozný ve srovnání s INT. Udělal jsem chybu, že jsem to udělal jednou se stolem, o kterém jsem si myslel, že by se mohl zvětšit o tuto velikost, a jakmile to zasáhlo několik stovek milionů řádků, výkon byl prostě propastný. Nemám hrubá čísla, ale když řeknu špatně, myslím Windows ME špatně.

Tento sloupec byl primárním klíčem. Převedli jsme ji zpět na magii INT a presto, výkon byl opět dobrý.

Všechny naše servery byly v té době na Debian 5 a MySQL 5.0. Od té doby jsme upgradovali na Debian 6 a Percona MySQL 5.5, takže se od té doby mohly věci zlepšit. Ale na základě mé zkušenosti zde ne, nemyslím si, že to bude fungovat velmi dobře.

18
Sean

Ať už to funguje nebo ne, vždy narazíte na stejný problém s jediným monolitickým paměťovým médiem: disky jsou pomalé. Při rychlosti 100 MB/s (docela dobré pro spřádání médií) trvá 3 hodiny, než přečtete 1TB tabulku; to za předpokladu, že vás žádná analýza nebo hledání nebo jiná zpoždění nezpomalí.

To je důvod, proč téměř každá instalace „velkých dat“ používá nějaký druh distribuovaného datového úložiště. Můžete utratit 8krát tolik peněz za vybudování jednoho super úžasného počítače pro provoz vaší databáze, ale pokud máte spoustu dat, která lze skenovat paralelně, máte téměř vždy lepší distribuci zatížení mezi 8 levnějších počítačů.

Projekty jako hadoop byly stavěny speciálně pro takové účely. Sestavíte klastr celé řady levných počítačů, rozložíte data do všech a paralelně je dotazujete. Je to jen jedno z půl tuctu řešení postavených na stejném nápadu, ale je to velmi populární řešení.

18
tylerl

Hm ... Vidím oly dva důvody, proč byste si vybrali tento druh datové struktury:

  • opravdu potřebujete udělat jakýkoli datový bod vs. jakýkoli dotaz na datový bod
  • máte v úmyslu provést veškerou svou logiku v SQL

Navrhuji nyní důkladně prozkoumat vaše požadavky a ověřit, že alespoň jeden z výše uvedených předpokladů je pravdivý. Pokud ani jedno není pravda, dělají věci jen pomaleji. Pro tento druh datového souboru bych navrhl nejprve zjistit, jak se očekává, že data budou přístupná, jaký druh přesnosti budete potřebovat atd. - a poté navrhnout databázi kolem těchto.

P.S: Mějte na paměti, že budete potřebovat nejméně 36 + 5 bajtů na datový bod, takže s 200B datovými body, které by vám měly poskytnout alespoň 8,2 TB požadované místo).

PPS: Nepotřebujete sloupec id v tabulce datapoints, pravděpodobně postačí PRIMARY KEY (spectrum_id, index) (jen mějte na paměti, že index může být vyhrazené slovo )

13

UPRAVIT:

NEDĚLEJTE TOTO V MYSQL S DATAMI ULOŽENÝMI NA JEDNOM DISKU - Jen čtení tohoto množství dat z jednoho média bude trvat hodiny. Musíte SCALE OUT, NOT UP.

A pokud chcete provádět efektivní analýzu dat, musíte data denormalizovat. Zde nenavrhujete online systém. Chcete crunch čísla, design odpovídajícím způsobem.

Původní odpověď pod řádkem.


Odpověď se bude lišit v závislosti na vašich dotazech, MySQL nemusí být pro tuto práci nejlepším nástrojem. Možná budete chtít podívat na řešení, které můžete škálovat „mimo“ a ne „nahoru“. Pokud jste ochotni vynaložit nějaké úsilí, možná byste se měli podívat na řešení Map Reduce, jako je Hadoop.

Pokud chcete dělat více ad-hoc dotazů Google BigQuery řešení může být pro vás dobrým řešením. Relevantní prezentace z Google I/O 2012: Crunching Big Data with BigQuery

Řešení bude tedy záviset na tom, zda se jedná o jednorázovou věc a zda chcete přiměřeně podporovat dotazy ad hoc.

12
mdolk

Nikdo se nezmínil, tedy můj návrh. Podívejte se na masivně střižená řešení MySQL . Podívejte se například na tuto vysoce uznávanou tumblr prezentace .

Koncept je:

  • Místo jedné extra velké databáze
  • Používejte mnoho malých, kteří drží části původních dat

Díky tomu můžete namísto snahy o zlepšení vertikálního výkonu měnit měřítko vodorovně. BigTable a GFS společnosti Google také používají levné horizontálně škálovatelné uzly k ukládání a dotazování petabajtů dat.

Budete však mít problémy, pokud potřebujete spouštět dotazy na různých střepech.


Pokud se někdo zajímal, podal jsem před nějakou dobou aplikaci sharding na hello-world. To je diskutováno zde v blogu. Použil jsem RavenDB a C #, ale detaily nejsou relevantní a myšlenka je stejná.
9
oleksii

Na jakém počítači budou data uložena? Je to sdílená úložná zařízení?

Konečným faktorem, který bude určovat čas vašeho dotazu, budou vaše pevné disky. Databáze a jejich optimalizátory dotazů jsou navrženy tak, aby co nejvíce snížily počet diskových vstupů/výstupů. Vzhledem k tomu, že máte pouze 3 tabulky, bude to provedeno docela spolehlivě.

Rychlost čtení/zápisu na pevném disku bude 200 až 300krát pomalejší než rychlost paměti. Hledejte pevné disky s velmi rychlou latencí a rychlostí čtení a zápisu. Pokud jsou všechna tato data na jednom 2-TB disku, pravděpodobně budete čekat dlouho, než budou dotazy dokončeny. Latence pevného disku je ~ 10-15 milisekund, zatímco latence paměti je kratší než 10nanosekund. Latence pevného disku může být 1000 až 2000x pomalejší než latence paměti. Pohyb mechanické paže na pevném disku je v celém tomto systému NEJVĚTŠÍ.

Kolik RAM máte? 16 GB)? Řekněme, že vám umožní pojmout 32 záznamů. Máte 16 000 souborů. Pokud se chystáte na lineární skenování všech datových bodů, můžete snadno skončit 5–10 sekund v době hledání samotného, ​​pak faktor přenosové rychlosti 50mb/s? Asi 7 hodin. Kromě toho budou muset být všechna dočasně uložená data uložena na pevný disk, aby se vytvořil prostor pro čtení nových dat.

Pokud používáte zařízení se sdíleným úložištěm, které ostatní uživatelé aktivně využívají ... nejlepší sázkou bude, že vše bude spuštěno v noci.

Pomáhá také snížit počet vnořených dotazů. Vnořené dotazy vedou k dočasným tabulkám, které váš pevný disk rozbijí ještě více. Doufám, že máte PLENTY volného místa na pevném disku.

Optimalizace dotazů může současně sledovat pouze jeden dotaz. Vnořené výběrové příkazy tedy nelze optimalizovat. JAK však víte, že konkrétní vnořený dotaz povede k vrácení malého datového souboru, ponechte si jej. Optimalizace dotazu používá histogramy a hrubé předpoklady, pokud víte něco o datech a dotazu, pokračujte a udělejte to.

Čím více budete vědět o způsobu, jakým jsou vaše data uložena na disk, tím rychleji budete moci psát své dotazy. Pokud bylo vše uloženo postupně na primárním klíči, může být užitečné třídit primární klíče vrácené z vnořeného dotazu. Pokud také můžete snížit množinu datových souborů, které musíte předem analyzovat, udělejte to. V závislosti na vašem systému sledujete přibližně 1 sekundu přenosu dat na soubor.

Pokud se chystáte upravit hodnoty Name (varchars), změnil bych je na datový typ s maximální velikostí, zabrání se tak fragmentaci a kompromis je jen několik bajtů paměti. Možná NVARCHAR s maximem 100.

Pokud jde o komentáře týkající se denormalizace tabulky. Myslím, že by mohlo být nejlepší ukládat datové body do větších skupin (možná jako spektra) a poté provést analýzu dat v python nebo v jazyce, který interaguje s databází.) Kouzelník.

7
JustinDanielson

Zní to jako scénář použití, kde chcete něco jako „relační sloupcový obchod“ jak je popsáno zde .

Možná nepochopím design, ale pokud se primárně zabýváte velkou sbírkou polí, jejich uložení do typických řádků orientovaných tabulek znamená, že každý prvek je podobný řezu. Pokud se zajímáte o plátky typickým způsobem, má to smysl, ale mohlo by to být méně efektivní, pokud se opravdu díváte na celé sloupce najednou.

Při načítání polí nemusíte nutně potřebovat spojení s jinou tabulkou, která je výsledkem normalizace, ale můžete řadu načíst spíše jako pole než hash.

Opravdu možná nepochopím problém a ani nenavrhuji konkrétní řešení.

Zde je další přednáška , která může být relevantní, i když se nejedná o aktuální nebo implementovatelné řešení.

6
RandallZ

Doporučuji zkusit rozdělit tabulku. V jedné tabulce máme více než 80 mil řádků (údaje o akciových trzích) a nemáme žádné potíže s rychlým přístupem k ní.

Podle toho, jak hodláte prohledávat svá data, byste měli vytvořit oddíly. V našem případě podle data funguje dobře, protože hledáme konkrétní data.

http://dev.mysql.com/doc/refman/5.1/en/partitioning-limitations.html

http://www.slideshare.net/datacharmer/mysql-partitions-tutorial

6
user9866

Ano, ale ...

Pracoval jsem s tabulkami, které měly 2 miliardy řádků. Očekávalo se však, že pouze dotazy pomocí PK budou rychlé.

A co je nejdůležitější, hardware měl dost RAM, aby se vešly celé tabulky v paměti. Když se to stalo problémem (v té době maximálním 96 GB), šlo se o vertikální rozdělení, přičemž velikost tabulky byla nastavena na každém stroj byl dostatečně malý na to, aby se vešel do paměti. Stroje byly také připojeny přes 10Gb vlákno, takže propustnost v síti nebyla tak velkým problémem.

MIMOCHODEM. vaše schéma vypadá jako něco, co se vejde do řešení NoSQL, pomocí run_id jako hashovací klíč pro spektra a spectrum_id jako hashovací klíč pro datové body.

5
vartec

O tomto tématu jsem psal na svém blogu: http://www.tocker.ca/2013/10/24/improving-the-performance-of-large-tables-in-MySQL.html =

Opakování některých klíčových bodů:

  • B-stromy se degradují, jak se zvětšují a nezapadají do paměti (MySQL zde není sám).
  • InnoDB má některé funkce, které pomáhají udržet určitý výkon (změna vyrovnávací paměti; dříve nazývaná „insert buffer“).
  • Rozdělení může také pomoci.

V komentářích mého příspěvku Tim Callaghan s tím souvisí: http://www.tokutek.com/resources/benchmark-results/benchmarks-vs-innodb-hdds/#iiBench

Což ukazuje vložení 1 miliardy řádků pomocí benchmarku iibench.

4
Morgan Tocker