Omezení MySql databáze

Na střední škole jsem začal vyvíjet nástroj na odesílání push zprávy. Funguje to tak, že se do něj uživatel zaregistruje nastaví svůj web a může začít sbírat odběratele. Je to vytvořené v Nette s MySql db, což bylo jedné co jsem tehdy uměl. Teď jsem se k projektu vrátil a trochu ho předělávám a rád bych ho dokončil. Mám ale strach, že mysql nebylo to nejlepší řešení, protože aby tento projekt uživil aspoň mě musel by mít třeba 150 uživatelů (eshopů, blogů, ...) a když každý bude mít jen 5 000 odběratelů a každý odběratel bude mít 50 přiřazených, dává dohromady hodně záznamů. Předpokládám že řešení bude NoSQL. Jaké doporučujete? A jako literaturu k tomu? A jaké jsou limity MySql db? Nebo je dobrý nápad mít pro každého uživatele jednu MySql db?

Já se tady jen tak zaháčkuji. Sbíráme desítky milionů záznamů denně a zatím nám to rok prochází, ale tak kdyby náhodou, ať jsem v obraze. :-D

Toho bych se nebál. Stačí tabulky trochu optimalizovat. Moje největší tabulka má 2.860.534 řádků a 676,8 MB. Bylo na šmírovací projekt, který zjišťoval na která klíčová slova má který IT web největší návštěvnost. Většina dotazů na ní je pod 1 vteřinu. Data jsou z roku 2015 http://cybersquatting.cz/sc8/index.php
/n
Případně mám ještě registr prodaných .cz domén, kde se data skládají z více tabulek. Největší má 301K záznamů a další v desítkách tisíc. Také jsem měl strach že když to naroste, tak se začnou objevovat problémy, ale zatím nic.
/n
Všechno šlape na sdíleném webhostingu. Pokud se ti projekt rozjede tak si pořídíš VPS s vyhrazeným výkonem procesorů anebo dedikovaný server. Tam to bude úplně jiná liga.

ty technické limity jsou o hodně dál. V praxi, ale nevhodně napsaná aplikace to utne mnohem dříve, nejproblematější věci pro mysql/mariadb, které vídám za mě jsou:
- ruční lockování tabulek a jejich nevhodná správa
- paralelní zápisy do stejného řádku (raději dělat insert a řešit výběr posledního záznamu)
- masivní použití blobů
- spousty indexů přes spousty sloupců, dlouhé textové indexy
- neoptimalizované dotazy, které končí s temporary tabulkou a zápisem na disk

Spravuji databáze s několika TB dat, hodinovými přírustky ve stovkám milionů záznamů, s desítkami tisíc tabulek, není to velký problém. Při velkém množství záznamů bývá největší problém špatné rozložení hodnot, které jsou indexované, přeci jen b-tree+ má určité vady a když se mu vše sejde v jednom segmentu, není to dobré, lámale se to přibližně kolem miliardy záznamů, to je ale pro tebe na hony daleko.

Určitě nedělej databáze/tabulky podle klienta, to výkonu nepřidá, max. pokud to dává smysl z hlediska práv a zabezpečení. Nesnaž se vymýšlet složité vazby a struktury. Používej innodb/tokudb místo myisam, ztráta dat může být fatální pro projekt.

Základy si přečteš na netu, mám rád tuhle knížku https://www.amazon.com/dp/1449314287/ občas jí pořád otevřu. Poté pro tebe může být poučná https://www.amazon.com/dp/1449373321/

Rozsah dat, o kterém se zmiňuješ není nikterak astronomický a nebude to dělat problémy.

Ja mam teda DB se 40 mld zaznamama, cca 12TB, denni prirustek kolem 150-200M ... a pouzivam ElasticSearch ke svy spokojenosti, protoze SQL bych neukonfiguroval :)

hodně záleží účel, relační databáze toho umí spousty, udrží mně konzistenci, integritu, stabilní odezvy v řádu ms, HW nároky relativně nízké. Pokud se používá stejně jako elastic (samozřejmě výjma fulltextu), taky se nemusí konfigurovat nic extra. U mysql mohu měnit indexy za běhu, u elasticu to tak snadné není. Mysql ukládá čísla násobně efekrivněji než elastic, velikost db může zkreslovat.

Elastic škáluje lineárně, dochází místo, přidám další servery, mít jich desítky není ani v českém prostředí pro některé klienty problém. U mysql (s galera clusterem) jsem pořád na max. třech serverech, zpravidla ale jen jedním a periodickými zálohami u malých projektů.

Mysql se dá levně pronajmout v rámci hostingu (dnes i cloudu) a nestarat se o něj (to by i tazateli mohlo pro jeho účel stačit), dnešní některé webové hostingy nemají db řešenou vůbec špatně. Na elastic potřebuji vlastní server, zpravidla víc, pronajmout se dá sice také, ale není to láca.

Mysql mám rád, ale věci jako elastic, cassandra a spousty jiných zase chtějí klienti, tak to nasazuji jak na běžícím pásu a nemohu říct, že při větším zatížení s tím je méně problémů :).

Můj menší hobby projekt používá PostgreSQL, obsahuje asi 8 mio poměrně rozsáhlých záznamů (je tam i binární sloupec 10 - 20kB) a celková velikost je 150 GB a naprosto v pohodě.

Některé operace trvají déle, třeba "UPDATE xx SET xx = xx" nad celou tabulkou se 4 mio záznamy prostě trvá dlouho (minuty).

Ale jinak do toho tlačím data současně přes asi 400 spojení a limitem je tam teda disk, kterej se nezastaví.

Je teda fakt, že všechno ještě běží v transakcích, takže to taky dělá nějakej overhead, zvlášť u velkých dotazů.

Běžné dotazy, na vytažení určité části těch dat (samozřejmě s indexy) trvají milisekundy.

PS: Jsem zapomněl dodat to důležité - ta PostgresSQL je normálně standardní Docker balík bez konfigurace (jen zvýšený limit počtu současných připojení). A ta aplikace taky není zrovna optimalizovaná a používá DB i jako "frontu" - tj. dost čtení a zápisů za sekundu jen na "management". Tj. kdyby se to udělalo trochu jinak, tak tenhle objem není ani citelný.

U těch push notifikací je úzké hrdlo odesílání - velmi náročné na CPU a RAM.

používat docker pro IO intensive operace jako je databáze není vůbec dobrý nápad, stejně tak používat v produkci cizí docker image, které nemám pod kontrolou, nemluvě o jejich aktualizování.

Původně odeslal TomášX

používat docker pro IO intensive operace jako je databáze není vůbec dobrý nápad, stejně tak používat v produkci cizí docker image, které nemám pod kontrolou, nemluvě o jejich aktualizování.

1. Volume snad nebudeš mít interní.

2. Od ofiko obrazků Dockeru jsou k dispozici zdroje, takže to není problém.

3. Pro menší projekt v tom nevidím vůbec problém.

4. To, že to mám v Dockeru jsem zdůraznil i proto, že to není konfigurované - tím spíše to konfigurovaná databáze musí zvládnout. Navíc to není ani veřejně dostupné. Je to můj tool, co mi běží vedle na PC.

Původně odeslal vaclav.hodek

1. Volume snad nebudeš mít interní.

2. Od ofiko obrazků Dockeru jsou k dispozici zdroje, takže to není problém.

3. Pro menší projekt v tom nevidím vůbec problém.

4. To, že to mám v Dockeru jsem zdůraznil i proto, že to není konfigurované - tím spíše to konfigurovaná databáze musí zvládnout. Navíc to není ani veřejně dostupné. Je to můj tool, co mi běží vedle na PC.

Interní, neinterní, volume vždy jde přes squashfs/overlayfs a to je přesně ta brzda, na diskově závislé databáze to není vůbec dobré, nefungují tam třeba atomické locky a mohou se poškodit data, dá se obejít přes /dev zařízení, ale to už není snadné.

k dispozici jsou zdroje jen do prvního base image, ten je binární tar. Ofiko zdroje jsou ale ověřované, avšak ne aktualizované, to si musíš hlídat sám, což se moc nedělá.

Právě menší projekty jsou v ohrožení, unikají přes tohle interní údaje a dochází ke kompromitaci vnitřních systémů, řeším pravidelně. Avšak v porovnání s Wordpressem to je nebe a dudy, pokud to aktualizuješ je to dobré.

Jasně, ale tady to doporučuješ veřejně :). Nekritizuji tvoje řešení, poskytují ostatním čtenářům pohled u druhé strany. Databáze se dneska již tolik nemusí konfigurovat, výchozí nastavení ve většině distribucí je dobré. Pokud databázi naistaluješ jako balíček v OS, aktualizuje se s OS, pokud v dockeru, musíš si jí aktualizovat sám, při přechodu na novější verzi nejsou žádné upgrade scripty, které jsou běžné u OS balíčků, většina lidí to pak neaktualizuje a to je za mě přesně problém těhle řešení.

Původně odeslal TomášX

Interní, neinterní, volume vždy jde přes squashfs/overlayfs a to je přesně ta brzda, na diskově závislé databáze to není vůbec dobré, nefungují tam třeba atomické locky a mohou se poškodit data, dá se obejít přes /dev zařízení, ale to už není snadné.

k dispozici jsou zdroje jen do prvního base image, ten je binární tar. Ofiko zdroje jsou ale ověřované, avšak ne aktualizované, to si musíš hlídat sám, což se moc nedělá.

Právě menší projekty jsou v ohrožení, unikají přes tohle interní údaje a dochází ke kompromitaci vnitřních systémů, řeším pravidelně. Avšak v porovnání s Wordpressem to je nebe a dudy, pokud to aktualizuješ je to dobré.

Jasně, ale tady to doporučuješ veřejně :). Nekritizuji tvoje řešení, poskytují ostatním čtenářům pohled u druhé strany. Databáze se dneska již tolik nemusí konfigurovat, výchozí nastavení ve většině distribucí je dobré. Pokud databázi naistaluješ jako balíček v OS, aktualizuje se s OS, pokud v dockeru, musíš si jí aktualizovat sám, při přechodu na novější verzi nejsou žádné upgrade scripty, které jsou běžné u OS balíčků, většina lidí to pak neaktualizuje a to je za mě přesně problém těhle řešení.

Nemá cenu se hádat. Nedoporučoval jsem, že to má použít v Dockeru. Naopak jsem to uvedl právě kvůli tomu, že Docker má vliv na výkon.

Provozovat databázi v Dockeru rozhodně nebude nebezpečnější. To vždy závisí na tom, kdo to dělá :-). A alespoň nemáš porty viditelné veřejně, i když si nenastavíš firewall. To je zase častý případ těch instalací mimo Docker... Pokud přistupuješ k Dockeru tak, že to pustíš a neřešíš, tak stejný přístup bude rizikový i při instalaci přímo na host OS.

No já nevím, ale každý rozumný si vypne automatické aktualizace databáze v OS a dělá to stejně ručně. Rozhodně bych nespoléhal na to, že migrace dat proběhne v pořádku. A mám k tomu dobrý důvod - zkušenosti.