it-swarm-eu.dev

Timeseries: SQL nebo NoSQL?

Nezajímá mě obecné rozdíly mezi SQL a NoSQL (nebo jejich tradiční rozdíly).

V současné době se dívám na změnu úložiště našich interních časových řad. Všechny obsahují finanční údaje z řady různých zdrojů. V současné době ukládáme naše data do proprietární databáze. Je to velmi NoSQL, které má svůj vlastní dotazovací jazyk.

Zajímám se o vstup do komunity: Jak byste ukládali data do databáze SQL? Jaké jsou výhody pro použití SQL přes NoSQL, konkrétně pro časové řady? Jsem šílený, že jsem uvažoval o uložení tohoto do SQL?

Naše data se skládají z milionů časových řad, z nichž každá obsahuje přibližně 10% milionů záznamů. Časové řady jsou uspořádány hierarchicky:/Market/Instrument/Value/Frequency, kde:

  • Trh je burza cenných papírů atd., V podstatě sbírka nástrojů, obvykle podobných nástrojů.
  • Nástroj je nástroj. Může to být indikátor (Brent Crude), kapitál (GOOG) atd
  • Hodnota je jedním z více typů dat pro nástroj. Mohlo by to být blízké, vysoké, nízké atd
  • Frekvence je frekvence hodnot konkrétních časových řad. Týdenní, denní, měsíční, klíště, libovolné atd.

Jak budou data uložena v SQL db? Jeden velký stůl (možná rozdělený na něco), jedna tabulka na trh nebo nástroj, jedna tabulka na časové řady.

Děkuji předem.

33
Nicolas

Obecně platí, že pro takový strukturovaný datový soubor mám podezření, že byste mohli napsat vlastní formát dat, který byl pro většinu denních operací rychlejší (tj. Malá data se stahují z libovolného času). Výhoda přechodu na standardní nástroj DB je pravděpodobně v některých doplňcích, například dotazy ad hoc, vícenásobný přístup, replikace, dostupnost atd. Je také snazší najmout pomoc při údržbě standardního datového úložiště.

Pokud bych byl požádán o nastavení databáze pro ukládání těchto dat, udělal bych následující:

Navrhované schéma

(1) Základní údaje jsou umístěny do četných (1000) jednotlivých tabulek, z nichž každá obsahuje dva sloupce:

  1. čas: buď datový typ SQL DATETIME nebo číselný typ z nějaké epochy (toto je primární klíč)
  2. value: zadáno podle vašich údajů. Implicitně bych se pohyboval s jednoduchou přesností, nicméně pro finanční transakce může být vhodnější datový typ s pevným bodem. To je pravděpodobně neindexované.

Tyto tabulky se poměrně zvětší a možná je budete chtít ručně rozdělit podle (například) roku. Ale budete muset zkontrolovat výkon systému a naladit podle potřeby.

Tyto tabulky potřebují jedinečná jména a existuje několik možností. Mohou být čitelné člověkem (např. Nyse_goog_dailyhighs_2010) nebo (moje preference) náhodně. V každém případě je vyžadována sada tabulek metadat a náhodné názvy tabulek brání vývojářům v tom, aby do názvu odvozovali cokoli, co by nemělo být odvozeno.

(2) Data Meta se ukládají do samostatných tabulek, jak to vyžaduje aplikace :

Ke sledování metadat je nutná další tabulka nebo sada tabulek. Tyto tabulky budou obsahovat údaje o výměně, přístroji, hodnotě, frekvenci, časovém období, provenience (odkud data pocházejí) a vše ostatní, co potřebujete. Ty jsou mapovány na názvy datových tabulek.

Pokud je k dispozici dostatek dat, mohlo by toto vyhledávání ve skutečnosti poskytnout název tabulky a název databáze, což by umožňovalo určitý druh implementace shardingu dat (pokud je to správné použití termínu). Ale držel jsem to v rezervě.

Poté jsem na aplikační vrstvě dotazoval metadatové tabulky, abych určil, kde byla moje data umístěna, a poté provedl relativně jednoduché dotazy na velkých datových tabulkách, abych získal svá data.

Výhody:

  • Moje (relativně omezená) zkušenost spočívá v tom, že databáze obecně zvládají větší počet malých tabulek snadněji než menší počet velkých tabulek. Tento přístup také umožňuje snazší údržbu (např. Čištění starých dat, opětovné vytvoření poškozené tabulky, vytvoření/opětovné načtení ze záloh, přidání nové entity). To zcela odděluje různé druhy dat, pokud (například) máte data různou rychlostí nebo vyžadují různé typy dat.

  • Tento koncept hubené tabulky by měl také umožnit rychlý přístup na disk pro to, co mám podezření, že je nejběžnějším dotazem, souvislým rozsahem dat z jedné entity. Většina datových aplikací je omezena vstupně/výstupně na disku, takže se vyplatí zvážit. Jak již komentátor již naznačil, jedná se o ideální aplikaci pro databázi orientovanou na sloupce, ale zatím musím najít produkt orientovaný na sloupce, který je dostatečně mainstreamový, abych mohl vsadit svou kariéru. Toto schéma se docela blíží.

Nevýhody:

  • Přibližně polovina místa na disku je věnována ukládání časových razítek, když zcela upřímně 100 nebo 1000 z tabulek bude mít přesně stejná data ve sloupci časové razítko. (Ve skutečnosti je to požadavek, pokud chcete provést snadné připojení tabulek).

  • Ukládání názvů tabulek a provádění dynamického vyhledávání vyžaduje hodně složitosti aplikací a řetězcových operací, což mě nutí krčit se. Ale stále se zdá lepší než alternativy (diskutováno níže).

Úvahy:

  • Dávejte pozor na zaokrouhlování ve svém časovém poli. Chcete, aby vaše hodnoty byly dostatečně kulaté, aby umožnily spojení (pokud je to vhodné), ale dostatečně přesné, aby byly jednoznačné.

  • Dávejte pozor na časové zóny a letní čas. Je těžké je otestovat. Vynucoval bych požadavek UTC na úložiště dat (což by mě mohlo udělat nepopulární) a zpracovávat převody v aplikaci.

Varianty:

Některé varianty, které jsem zvažoval, jsou:

Skládání dat: Pokud jsou časové úseky rovnoměrně rozloženy, použijte jeden sloupec časových razítek a (například) 10 datových sloupců. Časové razítko nyní odkazuje na čas prvního datového sloupce a další datové sloupce jsou považovány za rovnoměrně rozmístěné mezi tímto časovým razítkem a dalším. To ušetří spoustu úložiště, které bylo dříve používáno k ukládání časových razítek, za cenu značné složitosti dotazů nebo aplikací. Dotazy na jednu entitu v sousedním rozsahu nyní vyžadují méně přístupu na disk.

Multiplexování: Je-li známo, že více časových řad používá stejnou časovou řadu, použijte jednu časovou značku a (například) 10 sloupců dat, jak je popsáno výše . Nyní však každý sloupec představuje jinou časovou řadu. To vyžaduje aktualizaci tabulky metadat, která není vyhledáním názvu tabulky a sloupce. Úložný prostor je snížen. Dotazy zůstávají jednoduché. Bez ohledu na rozsah, dotazy na jednu entitu však nyní vyžadují výrazně více přístupu na disk.

Mega-tabulka: Vezměte koncept "multi-plexování" do extrému a vložte všechna data do jedné tabulky, jednou časové řady na sloupec. To vyžaduje velké množství přístupu na disk pro souvislý rozsah, dotazy na jednu entitu a je to noční můra údržby. Například přidání nové entity nyní vyžaduje příkaz MODIFY TABLE v tabulce mnoho TB).

Další diskuse o tomto formátu naleznete v různých odpovědích v: Příliš mnoho sloupců v MySQL

Plně normalizovaná tabulka: Namísto použití mnoha tabulek se dvěma sloupci můžete použít jednu tabulku se třemi sloupci, kde jsou sloupce čas, data a hodnota. Nyní vaše tabulky metadat potřebují pouze vyhledávat hodnoty ID, nikoli názvy názvů sloupců nebo sloupců, což umožňuje tlačit více logiky do dotazů SQL, nikoli do aplikační vrstvy.

Přibližně 2/3 úložiště je nyní spotřebováno normalizačními sloupci, takže to bude vyžadovat hodně místa na disku.

Můžete použít pořadí primárních klíčů (dataid, timestamp) pro rychlé souvislé dotazy na jednu entitu. Nebo pro rychlejší vkládání můžete použít pořadí primárních klíčů (časové razítko. Dataid).

I po zvážení těchto variací je však můj plán dalšího vývoje spousta tabulek, každý po dvou sloupcích. To nebo metoda, kterou brzy zveřejní někdo moudřejší než já :).

26
Pursuit

Pomocí MongoDB můžete vytvářet sbírky za běhu velmi rychle. Podívejte se na uspořádání dat do samostatných databází a kolekce v těchto databázích. Zvažte, kolik paměti budete muset zkusit uchovat každý střep v systémové paměti - pokud potřebujete rychlé vyhledávání. Hloupé držet se in-house řešení, pokud tam je něco čerstvější tam, že se bude vyvíjet v souladu s liniemi, které potřebujete. Zní to jako dobrá iniciativa.

1
Dantalion