Velká databáze s častými operacemi nad daty – jak na to?

Zdravím všechny, potřeboval bych poradit od někoho, kdo má zkušenosti s většími databázemi (řádově miliony řádků). Pracuji na agregátoru, který agreguje velké množství nabídek a navíc se nad nimi pokouší počítat různé statistiky na základě jejich parametrů. Když tato automatika běží, v podstatě jsou nepřetržitě upravovány řádky jeden za druhým (nebo dejme tomu 50% záznamů, u kterých došlo ke změně). Server je tedy poměrně vytížený a to by měl ještě obsloužit návštěvníky webu a agregovaná data jim poskytnout s nějakou rozumnou odezvou (pokud automatické výpočty neběží, odezva je dobrá... pokud běží, dostává se pod únosnou úroveň). Potřeboval bych tedy poradit jakým směrem se vydat. Uvažuji nad: Prosté navýšení výkonu serveru (to mi nepřijde jako vhodné řešení - s nárůstem počtu dat se dostanu do stejné situace)? Provádět výpočty na samostatném serveru (případně na více strojích) a databázi pak replikovat na jiný server? Něco jiného? Druhý dotaz - výpočet nad jednou položkou trvá nějaký nenulový čas. Dejme tomu 0,5s. Za 24 hodin potřebuji upravit 1 mil položek. 1 den má 86400 vteřin. Jak toto řešit? (paralelně, větší výkon?). Podotýkám, že se jedná opravdu o složitější aplikaci (cca 200 tabulek) a rada typu "dej tam indexy" není to co hledám. V tomto ohledu je databáze poměrně optimalizovaná. Jinak používáme PostgreSql a celé to běží v Google Cloud (aktuálně 4 jádra a 16 GB ram). Samozřejmě používáme i cachování a takové ty běžné věci. Budu rád za jakékoli nasměrování správným směrem. Díky!

Bez nejakych statistik, tezko delat zavery - rozdelit DB tabulky mezi 2 servery?Zacal bych tim, ze je potreba zkusit pomale dotazy v DB logice, podivat se na delky radku - zda je DB dobre navrzena

Bez blizsi znalosti nevim. Zkusil bych se zamyslet nad rozbitím databáze do mensich celku propojenych nějakým api.

Díky za rady. Předpokládejme, že databáze je navržená dobře (i když tomu tak být nutně nemusí). Jde mi spíš o obecné řešení situace, kdy se data neustále mění a přitom je potřebuji s rychlou odezvou poskytnout uživateli (klidně s nějakým zpožděním). Takže použít více strojů a výsledek pak poskládat dohromady?Jde mi o to, abych nevymýšlel kolo:-)

Staci jeden spatny dotaz a vykon jakkoli silneho reseni je nepouzitelnyJak dlouhe jsou radky, ktere se casto aktualizuji? Nesly by rozdelit do vice radku s vazbou, klidne 1:1 ?Jak jste na tom s transakcemi? Je nutne je pouzivat?

To s tím jedním úzkým místem beru. Řádky by někde zřejmě také rozdělit šly - zlepšení by to zřejmě přineslo, ale nejsem si jistý jestli tak markantní. Většina dotazů (updatů) je odbavena do 100 ms což mi na velké tabulce nepřijde hodně. Stejně se ale dříve nebo později dostanu do stavu, že nezvládnu všechny položky upravit za 24 hod a musím to nějak řešit.Transakce používám tam, kde to z mého pohledu má smysl - není to tedy takže by vše probíhalo v transakcích.

Ako som pochopil bottleneck je kombinacia on-the-fly updatov (OLTP) spolu so snahou generovat reporty. Upresni viacej popis:1. DDL alebo ER diagram2. OLTP SQL3. OLAP/batch SQL4. velikost tabulky, pocet riadkov na tabulky, MB/GB, pocet stlpcov5. typicka "selectivita" joinov pre SQL z 2. & 3. -> ake mnozstvo riadkov je zatiahnute do joinu (% a abs. cisla, pomer na stranach joinu)Riesi sa to rozne, zavisi i na architekture dalsieho spracovania alebo ci je ochota/moznost zmenit technologiu. Napr.:A. mat dve db/stroje -> aktualna situacia je ulozena na jednom stroji, zmeny ("CDC" - change data capture) sa zaznamenava na druhom ale nie cez update, ale insert (append noveho riadku s ID alebo timestamp, zalezi opat na technologii/oblubenosti YMMV), v pripade potreby sa pocitaju agregacie na druhom stroji (avsak iba cez dirty read) z poslednych zaznamovB. mozno by stalo za to skusit Google BigTable alebo ekvivalenty u AWS ci M$, mozno znova ukladat zmeny (neupravovat riadky) a reporty budu bezat nad poslednymi variantami, raz za cas sa stare zaznamy vyhodia (miesto a CPU stoji $)C. opat iny typ technologie (Teradata?) a fyzicky prestavat model (optimalizovat) na danu aplikaciu -> vtedy by om sa zacal pytat, ci tam je dostatocne RoISkutocne uzivatelia potrebuju/platia si za reporty na stotinu presne? Nemas tam moc indexov?Otazka ohladom navrhu db je stale na mieste, kedze i dokonaly navrh az po 3NF (nebodaj po 5NF -> zatial som v praxi nevidel, i 1NF je niekedy problem) sa nemusi mat rad s skutocnym ucelom resp. so sucasnym uzivanim.Z toho popisu sa mozem iba domnievat.

Relační databáze mají obecně se škálováním dost problém, zvážil bych nosql databázi, která lze škálovat o řád lépe.Také bych zvážil cloud, preferoval bych Amazon a dal bych to na DynamoDB a na zpracování bych použil Lambda funkce, které umožňují velmi dobré škálování.Osobně jsem provozoval databázi o milionech řádcích na mysql a bylo to úplně stejně hrozné, jako tady popisuješ. Pokud tu aplikaci uděláš serverless na Amazonu, tak výkonem to určitě zmákneš, druhá věc bude cena, ale to si můžeš nasimulovat na vzorku dat a zpočítat, kolik by tě to tak asi měsíčně stálo.

Díky všem za rady - některé technologie šly zatím mimo mě. Takže prozkoumám co a jak je možné a uvidíme. Samozřejmě nechci tvrdit, že stávající databáze je dokonalá, ale už prošla několika vlnami optimalizací a podařilo se tam dost věcí vyladit. Hlavní problém vidím v tom, že každá operace nějaký čas trvá..no a když jich je hodně...:-) Dejme tomu, že bych ušetřil nějaký způsobem půlku času, ale v momentě, kdy místo 1 mil řádků budou 2 mil řádků..tak jsem tam co jsem byl a přitom to není žádný řádový nárůst.

BigQuery - Analytics Data Warehouse | Google Cloud Platform

Budem detailista (domnievam sa, ze v tomto subfore je snaha o aku-taku technicku presnost):

Napsal bart28;1398676

Relační databáze mají obecně se škálováním dost problém, zvážil bych nosql databázi, která lze škálovat o řád lépe.

-> tvrdenie je viac nez odvazne, "generalizovane", dokonca zavadzajuce.