/MEGOLDVA/ Mysql mennyire stabil, ha egyidőben 10.000 lekérdezést kap?

Szerverek

Van ahol azt olvastam, hogy a mysql viszonylag hamar kiakad az egyidejű lekérdezések számát tekintve, van ahol millióst írnak, hogy jól terhelhető.... mi az igazság?

  • 1611 megtekintés

Én is úgy emlékszem hogy Mysql-t használtak, annó írtak is egy nagyon szép blog bejegyzést arról hogy lecserélték Galera Mysql clusterre a korábbi master/slave megldásukat. Sajnos nem találom most hirtelen, de úgy emlékszem nagyon tanulságos írás (vagy esetleg videó?) volt.

( Sixday v | 2022. 02. 11., p – 14:46 )

Mysql csak ugy naturban egymaga nem tud egyidejuleg 10.000 lekerdezest kezelni.

Van egy max connection szamod, ez altalaban parszazas nagysagrend memoria fuggvenyeben, azon bejonnek kliensek, betolnak egy queryt-t, megvarjak a valaszt, betoljak a kovetkezot, stb.

Termeszetesen a single mysql-nel vannak fenyevekkel komolyabb cluster setupok, galera, percona, ndb, kulonfele mysql load balancerek amik poolingot is tudnak, cloud providereknel mindenfele managed service-k amik komolyan skalazhatok (persze komoly penzert).

Roviden:

A trabant meg az audi is auto negy kerekkel, de az egyikkel stabil 180-200-al elautozol nemetorszagba es csak tankolni allsz meg, a masiknak meg ha vegsebesseggel tolod (100-110) akkor mar a kivezeton besul a motorja.

Szoval minden a setuptol fugg.

( uid_6201 v | 2022. 02. 11., p – 14:53 )

Csinálsz egy elcseszett táblaszerkezeten egy több táblán keresztül joinolt lekérdezést, és másodpercenként 1-től elszáll. De bármelyik SQL, mert nem a szerverrel van a gond, hanem a rosszul átgondolt táblaszerkezettel illetve hibásan összerakott lekérdezéssel.

Ez gyakori hiba szokott lenni.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ :)

Szóval igen, csinálhatsz bármit, mert jön majd a millió rekordos tábla, ami persze tesztkor erős izgalmi állapotban mondjuk 1000 rekordot tartalmazott, aztán kapjuk az üzemeltetésen a szaraszerver "még ezt sem tudjátok megoldani" típusú csodálatos emaileket. Amikor felvillantod, hogy merre kéna optimalizálni, akkor nincs rá idő, és amúgy se b*****gasd ilyesmivel, amikor a plusz szervert vázolod fel, meg az NVMe-t, akkor meg hát az sokba kerül. Innentől meg ez megy végtelenciklusban, mert valahogy a reggeli agykisűtőgép viszi magával a korábbi infókat. Tudom tudom, a szenyó, lusta és amúgy is antiszocális sysadmin csak kussoljon és dolgozzon.... Dolgozni dolgozna, de csodát ritkán tud tenni, pláne ha a környezet olyan, amilyen.

Nagyon számít. Néhány 100 iops, ha valami sokdiszkes RAID1+0, meg sok cache, akkor esetleg ezres nagyságrend. E mellé tedd oda az újabb NVMe-k akár milliós IOPS értékét és sokGB-os szekvenciális átvitelét. Mondjuk ehhez az sem árt, ha RAM, és megfelelő MySQL beállítások is vannak. :) Az igényekhez kell rendelni az erőforrásokat, mert nyilván van a HDD és az NVMe SSD között még bőven több lépcső. :)

A legutolso melohelyemen ahol mysql-el kellett behatoan foglalkoznom es hasonlo problemank volt, az volt a megoldas hogy felraktuk amazon RDS-be.

Es amikor egy szaros 800mb-os adatbazist kb. 20 tablaval nem vitt el a 8xlarge gep 32 cpu maggal meg 128G rammal "mert az amazon is szar" akkor a szepen odahivtuk az engineering directort es kozoltuk a mr. lead developerrel hogy hogy na akkor most lehet megmagyarazni hogyan lehet az hogy a vilag legnagyobb felhoszolgaltatojanal mindenki segghulye a mysqlhez es neked van igazad. Nem sikerult neki :)

( kassaiviktor | 2022. 02. 11., p – 15:15 )

ölem már le mysql egy kéréssel

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

Három napra (02.10, 02.11 éa 02.14) szétosztva küldték/küldik, így napi ~460-470E jóváírás oszlik meg az összes érintett bank között. És van esély arra is, hogy a napi 10 IG2 ciklusra elosztva kapja a bank a tranzakciókat, ergo óránként 46-47E tranzakciót kell a bankoknak összesen pluszban feldolgozni a szokásos forgalmon felül. Ez az egyik.
A másik, hogy a mobilbank nem az IG2, nem a számlavezető rendszer, úgyhogy Gyagya Gyurinak semmi dolga nem volt/nincs a beérkező utalásokkal, ő csak egy frontend, ami megjeleníti az adatokat, illetve amin keresztül tranzakciókat tudsz indítani (azaz meg tudod mondani a számlavezető rendszernek, hogy egy adott tranzakciót indítson el.)

( secretx v | 2022. 02. 12., szo – 09:40 )

Az egyik cegnel egy 100 gigas mysql db-t gyilkol 1500 user, megy flottul. A titka 2 dolog nalam uzemeltetesi oldalon, egy fasza my.cnf es 128g ram :)

Nyilvan a kod is biztosan jo, de az nem az en reszortom..

Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( Raynes v | 2022. 02. 12., szo – 18:32 )

Természetesen bullshit. A MySQL-t egész nagy oldalak is használják, amik egyidejűleg 10 ezer feletti lekérdezést/beszúrást is nyomnak az adatbázisba. Az egész attól függ, hogy milyen hardvert teszel alá, és hogy van indexelve, optimalizálva az adatbázis.

Bár én úgy tudom, hogy mióta az Oracle megvette a Sun-t, egyre többen elfordulnak a MySQL-től, és helyette egy opensource forkját használják, ami MariaDB néven fut. Természetesen az is épp úgy MySQL, ugyanazokat tudja mindben, csak a neve más a projektnek, hogy az Oracle-nek ne legyen köze hozzá.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Meg ha odafigyelnek a lekérdezésekre, és nem próbálnak meg adattárházi lekérdezést weboldalilag futtatni. :) Kedvencem még mindíg a postgresql levlistás kérdés, hogy hát van egy lekérdezésük, ami 16-20 órán át fut, amivel most nincs gond, de valamit bővítenek (gondolom a cégen), és a rekordszám megnő, és nekik 24 órán belül kell a queryt futtatni. :) Legalább 10+ éves dolog, de lehet 15+, még nemnagyon volt SSD.

erről az "ugyanazokat tudjá"-ról azért vannak fenntartásaim...

pl. milyen dolog, hogy pl. a sync_binlog alapból 0, mert a MariaDB úgy döntött, hogy inkább gyorsak legyünk, mint vigyázzunk az adatokra? az ember beállít egy replikációt s egy áramszünet szétnyomja az egészet.

Vagy MDEV-24275. Egy minor verzióba bekerül egy ilyen "feature"... a standard "stable" debian 10-esen nyomsz egy update-et és utána szívsz vele... (persze, ez nem a debian hibája és már meg lett javítva). bármikor bele lehet futni egy ilyenbe.

szóval, hogy merjen tenni az ember ilyenek után production rendszerre mariadb-t?

( uid_6201 v | 2022. 02. 14., h – 11:42 )

Szerkesztve: 2022. 02. 14., h – 12:09

Na felcsigáztatok, mégnéztem, hogy egy 9 éves i5-3337u procis laptop + SSD felállásban mennyire fürge egy 100_000 soros egyszerű, egyindexes táblánál.
MariaDB esetén 13300 lekérés/másodperc tempót sikerült elérnem C-ben írt klienssel. Pythonból csak 3200. Lassú a Python.
Viszont 10 szálon elindítva a C progit, 31100 lekérés/másodperc ment, a MySQL szépen többszálas kiszolgálásban dolgozott a 2+2HT felépítésű 9 éves laptop procin.

Összehasonlításként elővettem a Redis-t. Natív TCP klienst írtam hozzá Rust-ban, ez volt most a kézenfekvő számomra. Redis esetén 31600 kulcs alapú lekérést tudott kiszolgálni szintén 100_000 kulcsos táblából másodpercenként.
Szintén 10 szálon terhelve az egyetlen szálon futó Redis 58500 kiszolgálás/másodperc lett. Ha a Redis konfigban 2 szálat engedtem, akkor 73000/másodperc lett a Redis kiszolgálási tempója.

Alma vs. körte - bár való igaz, hogy lehetnek olyan adatok, amiket egyszer elég cache-be berántani, és utána onnan kiszolgálni. (Anno az iwiw alatt is bőven volt mysql (mm clusterek, shardolt db-kkel), redissel, memcached-del megtámogatva - volt benne bőven vudu-mágia (RIP :( vudumen), de akkori viszonyok között kifejezetten jól teljesítettek. )

Teljesen igaz, de kíváncsi voltam. Viszont Redis esetén már a kliensek limitálták a tempó növelést ezen a régi 2+2HT-s procin.

Egyébként mint feljebb írtam, láttam már olyan lekérést elcseszett sokmillió rekordos táblában, amikor elég volt neki egy lekérés is másodpercenként. Minden egyes sor adott oszlopát kivette, transzformálta majd összehasonlította a konstanssal. Pedig csak a konstanst kellett volna betranszformálni és akkor indexelt lekérdezés mehetett volna villámgyorsan.
De ilyenek az agyon joinolt táblaszerkezetek meg a like "%akármi%" förmedvények is. Szétmatekolja a táblát, mire kiszedi az adatot.

Rendre leakadnak fejlesztőék, amikor próbálom beléjük plántálni, hogy esetleg például ami olyan, azt cache-ből (redis...) szippantsák fel, és nagyritkán frissítsék. Ha csak félóránként frissül, az egy másodpercenként 1000-es lekérdezési igényhez képest tökre ritka. Azon is lepődtek már meg, hogy az 5.4-es PHP-nál, amit ők kértek!, a 7.2 vagy 7.3, sokszor gyorsabb volt az adott feladatban, és reklamáltak, hogy szaraszerver. Aztán mókolhattam nekik a szerverre 7.x PHP-t, amit aztán mégsem használtak, mert majd valahogy máshogy oldják meg. Fő a koncepció! :) Ehhez képest még ahogy írod, csodákat tudnak SQL fronton összehozni.

Amikor olyat is elkövet egy "fejlesztő", hogy for ciklusban connect, update, disconnect, ahol a ciklusváltozó egyébként egy select eredménye, akkor azon kívül, hogy elküldöm melegebb éghajlatra, nem tudom, mit lehetne mondani... És volt ilyen...
 

Kössz az infót! Érdekes. Egyébként maga a téma is. MariaDB-t használunk, igaz nagyon kevés a kliens (python). Az adatmennyiség azért nem olyan kevés naponta 17ezerx40 mérési adat keletkezik, ezt kell projecthez, kliensekhez, külső mérőkonténerekhez rendelni. (A táblaszerkezet nem túl bonyolult.)

> Sol omnibus lucet.

Az adatmennyiség azért nem olyan kevés naponta 17ezerx40 mérési adat keletkezik, ezt kell projecthez, kliensekhez, külső mérőkonténerekhez rendelni.

Nálam (IoT Guru) most jelenleg 750-800 req/min körül van a beküldött adatok száma, az naponta 1-1,2 millió bejegyzés, jelentős része historikusan akár évekre visszamenőleg tárolva, grafikon rajzolva, de ez lófasz terhelés.

https://iotguru.cloud

( STP | 2022. 02. 14., h – 15:08 )

Ugye a limits beállítással kezded a mókát?