Melyik adatbázis motor alkalmas egy query-n belül multi-thread-re?

Adott egy rendszer, ahol idoszakonkent egy eleg durva query-t kell futtatni. (Mysql) Jelenleg, mivel no a feldolgozando adat, a query mar tobb mint egy oraig fut. A kerdesem, hogy letezik olyan adatbazis motor, ami tud egyetlen queryt tobb CPU magon is futtatni?

A kerdes nyilvan elmeleti, a fejleszto nem fogja csak a kedvunkert atirni a programjat. Csak erdekelne, hogy letezik-e ilyen rendszer.

Hozzászólások

Szerkesztve: 2021. 06. 04., p – 09:17

1.Lehet, hogy a query nem jó, nem optimális

2.Ha jó, akkor éjszakai adatkarbantartásként futtatni és eredményeket elmenteni nappali felhasználáshoz nem opció?

3. Több memória a szervernek?

Szoval modositani nem lehet a queryt, de megnezni gondolom meg lehet (global log, ha maskepp nem), es futtatni ra egy 'EXPLAIN ANALYZE'-t.

Nem hiszem hogy a CPU a bottleneck a mysql alatt, mondom ezt ugy hogy sok 100 gigas db-kkel is talalkozom. Foleg ha no az adtok mennyisege, eleg hamar elfogy a memoria, betelik a cache, illetve a disk io is gond lehet. Meg kene nezni a mysql beallitasokat, novelni a key/table cache-t, adni neki tobb ram-ot, nvme ssd-re vagy ramdiskre rakni a db-t stb. Ez ad par jo tippet:

https://github.com/major/MySQLTuner-perl

de az is lehet, hogy nem eleg vagy nem jo az index a tablakon, az is durvan meg tudja fogni. lattam mar olyan szervert, ahol egy hianyzo index miatt 100x lassabb volt egy query. mar a vilag osszes vasat meg akartak venni ala, pedig csak meg kellett volna nezni miert is lassu :)

Bennyh-nek teljesen igaza van, a tapasztalat általában az, hogy nem a szerver gyenge, csak rosszul / nem hatékonyan van megírva a query és/vagy rosszult tervezettek a táblák és indexek. A praxisomban az esetek 90+%-ában ez volt a helyzet.

 

Oracle biztosan tudja a többivel sajnos nincs tapasztalatom. De nem árt hozzá tudni jó query-t írni, mert egy rosszul megírt esetén hiába küzd az optimizer, nincs esélye párhuzamosan futtatni.

 

Tippem alapján a postgres is tud ilyet, de ezt nem tudom biztosan állítani

Ez a query kb. mindent beolvas? Dumpold ki az adatbázist /dev/null-ba, hogy lásd, mennyi idő csak az adatok beolvasása. Aztán ahhoz képest már látni fogod, hogy mennyi idő megy el IO-ra és mennyi CPU-ra.

A query legalább vázlatát látni kellene. Addig csak általános dolgok hangozhatnak el.

Hibás, elcseszett query áll legtöbbször a háttérben.

- nem a querynek megfelelőek az indexek, netán a query hibás és így nem tudja indexelés gyorsítani
- agyonjoinolt query, nem optimális sorrendben végrehajtva

Ezek hozzáértő kezekkel való kijavíttatásával sokkal többet nyersz, mintsem a nyers erő 10-szeresére növelésével.

amugy akkor rakjon mindenre, artani nem sokat art :)

Kivéve ha intenzív írás is van. Ekkor a sok indexet is vezetnie kell, ráadásul biztonsági okokból másolaton keresztül.
Azaz szénné terheli a szervert az új rekord felvétele, netán rekord módosítása.

Egyébként index optimalizáláshoz ez is hozzátartozik:
      https://www.mysqltutorial.org/mysql-index/mysql-composite-index/
      https://dataschool.com/sql-optimization/multicolumn-indexes/

A "mindenre" helyett célszerű inkább azt az elvet tartani, hogy amire kell.

Tovabba neha az index - ha az optimalizalo rosszul dont - hatrany is lehet. Erre talaltak ki mysql8 eseten a visible tulajdonsagot. Ezzel a hatasa ki/be kapcsolhato. De ez nagyon side effect. Akkor fordulhat elo foleg ha nincs rendes index, kenytelen valaszt egy nem hasznosat. Szoval nem gyakori. 

@BCsabaEngine

a fejleszto nem fogja csak a kedvunkert atirni a programjat.

A fejlesztő vajon tényleg a kedvetekért írja át, vagy köteles kijavítani a pénzért eladott, hibás elgondolása mentén írt programját, ami végülis alkalmatlan a feladatra?
Vagy megvédendő az általa használt megoldást, arra vonatkozólag tud-e részletes műszaki állásfoglalást adni, hogy ennél (jelentősen) gyorsabb megoldás erre a feladatra tényleg nem implementálható. Ekkor viszont gáz, ha rámutattok, hogy de.

Valahol nagyon szomorú, hogy mára megtanultunk ennyire alkalmazkodni a hitvány szoftverek világához. "Ez van, ilyen a szoftver ..."

A fejlesztő vajon tényleg a kedvetekért írja át, vagy köteles kijavítani a pénzért eladott, hibás elgondolás mentén írt programját?

Az egy nagyon érdekes jogi kérdés, hogy a "lassú query" hibás teljesítésnek számít-e. Ha én éttermet nyitok, és rosszabbul (de olcsóbban) főzök, mint a Costes-ben, akkor jogos a reklamáció? IANAL, de ha a szerződésben nincs vállalás a sebességre, akkor nem beszélhetünk kötelességről, mert jelenleg semmi nem tiltja, hogy valaki középszerű szakember legyen.

Nagyon sok múlik azon, hogy milyen a query, és hogy az I/O a bottleneck vagy a CPU. És ha a CPU a bottleneck, akkor sem biztos, hogy párhuzamosítható a query. Legtöbbet olyan alaposan megtervezett esetben nyerhetsz vele, ha a tábládat több adatfile-ban tárolod, amik egymástól független disk-ekre kerülnek, és a query úgy párhuzamosítható, hogy mindegyik file-on párhuzamosan dolgozik.

Amit keresel, azt többnyire parallel query execution-nek hívják, és az Oracle, MS SQL, PostgeSQL támogatja:

https://docs.oracle.com/cd/B10500_01/server.920/a96524/c20paral.htm

https://docs.microsoft.com/en-us/sql/relational-databases/thread-and-ta…

https://www.postgresql.org/docs/10/parallel-query.html

A MySQL esetén nem igazán van ilyen, csak kb. egyetlen speciális esetre, a COUNT(*) kifejezésre implementálták, és úgy látszik, ez azóta sem haladt előre:

https://www.percona.com/blog/2019/01/23/mysql-8-0-14-a-road-to-parallel…

Ha csak elméleti a kérdés, mert úgysem írja át, akkor miért rugózni rajta? Hogy felidegesítsétek magatokat?

Az adatok a ti cégetek tulajdonai, ha az Ő szerverén van, vagy akár a ti szervereteken, de nem fértek hozzá az már aggályos alapból. 
Ha pedig az adatokhoz valamilyen formában hozzáfértek, pl. lehet éjszaka futtatni backup-ot amit megkaptok, ezt pedig egy másik SQL szerverre felteheted, akkor gyakorlatozhatsz jobb lekérdezés írásán.
Sok, főképp "felhős" (a valóságban 1 szerveres) cég aki ilyen rendszereket szolgáltatásként ad el, nem akarja kiadni az ügyfél adatait. Ennek legfőképp az alábbi okai lehetnek:
- Széngyellik a katyvaszt amit te nem láthatsz
- Nem megfelelően tervezték
- Nem tudják külön szedni az egyes cégek adatait könnyen
- Közös adatok nincsenek megfelelően kezelve
- Egyszerűen így is fizet mindenki, még holnap is megélnek

Tippre én is a gagyi lekérdezés és a BMW-s (indexet nem használ) programozói hibára gondolnék.
Nekem volt olyan, hogy MsSQL + .NET kliens program olyan 2-3 percig köpött ki egy napi adatot. Majd hozzáférést kaptunk az adatbázishoz és olyan 2-3mp lett a lekérdezés eredménye egy hónapnyi adatra. Igaz az a semmire sem jó PHP-ban volt megírva.

Szerkesztve: 2021. 06. 04., p – 10:15

sajnos magat a query-t nem tudom megosztani, de egy kb 3500-4000 fos ceg idonyilvantartasat (blokkolas) adja at a rendszer a berszamfejtesi programnak. (Ha ez segit valamit, hogy egy ilyen muveletnel, ennyi felhasznaloval mennyi az uptimalis futas) 

 

Meg ha a query is a fos (valoszinu) javitani akkor sem tudjuk, mert bar nalunk vannak az adatok es nalunk fut minden, egy ilyen durva beavatkozas a kodba mar szerzodeses dolgokat is feszegetne (kb minden elkovetkezo hibaert mi lennenk a felelosek...)

Azt nézted, hogy mekkora a CPU és az IO terhelés a kérés lefutása alatt? Valóban segíthetne a multi-thread?

Ha ez csak egy egyszerű kigyűjtés, akkor nem lehet megoldás, az adatbázisról SLAVE replikát készíteni egy olyan VM-re vagy fizikai gépre, ahol a teljes adatbázis elfér ramdisken, és azon lefuttatni a kérdéses lekérést? És ha attól lassú a query mert közben adatok is kerülnek a rendszerbe, és folyamatosan újraindexel, akkor a query lefutásának idejére a replikálást ki is lehetne kapcsolni.

Nem kotekedni akarok, de azt ki tudod fejteni hogy egy Explain kimenetenek (tabla, index es mezo nevek maszkolva) megosztasa milyen erdeket, szerzodest vagy barmit sertene?
Nem ad tobb informaciot a rendszerrol es kodrol mint az atalaln is linkelet grafana screenshotok

Ha jól számolok, és havonta van a bérszámfejtés, akkor ez kevesebb, mint 300000 adat. Az egy átlag mysql-nek sem lenne szabad megkottyanjon, nem hogy egy órán át tartson...

Egy időben elemeztem mysql kéréseket, és érdekes eredmény volt, hogy bizonyos esetekben, hiába volt meg az adott rendezés szerinti index, mégsem használta. Ilyen esetben direkt meg lehet mondani neki, melyik indexet használja. Persze, ha a kód nem módosítható, akkor ez is marad elméleti síkon.

Az explain kimenete tényleg tanulságos lehetne, anonimizálva is.

Volt már hasonló téma itt, akkor is mintha ilyen blokkolásos lett volna az alap probléma. Lehet, hogy ugyanaz a rendszer két külön cégnél? :-)

Ha belegondoltok ennyi adat be kellene hogy férjen memóriába! Ha 300000 adat, akkor bejegyzésenként 1000 bájttal számolva is 300MB adatról beszélünk:

 

 * Benyaljuk az egészet RAM-ba - egyedül idő alapon kell egy fa index, akkor ki lehet olvasni csak a megfelelő értékeket.

 * RAM-ban megoldjuk a számításokat

... profit.

Gondolom dolgozónként fut egy rosszul optimalizált query, és folyton újraolvas mindent.

Az adott esetre megoldás lehet esetleg, ha az adott táblából a régi adatokat egy historikus táblába átmozgatod. Így az eredeti táblában csak az az adat marad, ami valóban érintett az adott hó elszámolásában, így kisebb táblán gyorsabb lesz minden művelet. Persze egy működő rendszer alatt így átfaragni egy táblát kissé problémás lehet, de a kód módosítása nélkül meg lehet csinálni :-)

Most nem akarok azzal jönni, hogy "bezzeg én hobbiból jobbat írtam", mert biztosan nem fedi le teljesen az esetet, de nálam évekig ment otthon egy harmatgyenge "szerver"-en számítógép használat mérés.

DHCP lease time 5 percre állítva, ha jött új kérés, be a db-be. Ez az összes nyomorult kütyüt beleszámolva (telefonok, TV, stb.) egy hónap alatt >100.000 bejegyzést csinált, ami még mindig nem felel meg ennyi ember belépés-kilépés adatainak, de legalábbis hasonló nagyságrend.

Ezen a gépen (>10 éves atom) minden egyes DHCP kérésnél lefutott egy összegzés is, ami a logolt kéréseket összesítette, hogy tól-ig adataim legyenek (folytatólagos kérés, visszaadás, lejárás, stb.). Kb. nulla optimalizáció volt mögötte, mégsem fektette meg a gépet. Ilyen néhány milliós táblákat az SQL-nek röhögve kell vinnie, ha nem, ott valami el van rontva.

De ha ésszel nem tudunk skálázni, akkor skálázzunk baltával: nem lehet a régi adatokat áttenni egy másik db-be? Kell az még? Ha csak a tárgyév, vagy az előző két év adataiból dolgozik, már nagy csökkenés az adatmennyiségben. És sajnos ha annyira el van rontva a query, hogy O(n)-nél rosszabban skálázódik, akár O(n^2)-el, akkor hiába fogod a gép paramétereit az egekig növelni, az adatmennyiség előbb-utóbb utol fogja érni.

Az hogy van hogy a disk utilization 100%, a bandwidth kb 0, a cpu-nál meg megint az látszik hogy io-ra vár?

[!!] Joins performed without indexes: 4665466 -- szerintem itt lesz a hiba, valamelyik joinodhoz kellene még egy index

(más: én azokat a cpu meg diszk grafikonokat inkább stackelve jeleníteném meg)

Erdekes, hogy a disk utliziation 100%-ra ugrik, mig az IO bandwidth alig-alig pislakol. Erre mi a magyarazat?

 

A join buffer legyen nagy, min. 16MB, de ha van memoria, siman 128-256MB is lehet. Mysql join-kor ugye csinal egy temporary table-t. Ez a heap-en van (TYPE=HEAP). Ha a tabla elerne ezt a meretet, akkor kiirja diszkre(ami ugye tetu lassu lesz). Igazabol lehet akarmekkora, max. nem lesz hely a memoriaban masnak - probald ki, valszeg segit valamennyit, ha tetu lassu query-d van!

 

UPDATE: itt talaltam egy par erdekes tuning tippet: https://haydenjames.io/my-cnf-tuning-avoid-this-common-pitfall/

A disk IO bandwidth szerint az elején van egy olvasás aztán meg nem haszálja semmi a diszket, se írás, se olvasás.

De a Disk Utilization chart szerint egy órán keresztül meg folyamatosan használja valami a diszket.
Meg a CPU chartod is azt mutatja hogy sokat vár IO-ra a CPU.

Ez a kettő eléggé ellentmond egymásnak, ezt az amit nem értek.

Én a kettő közül a másodiknak hinnék, mert azt tudjuk hogy nem fér bele a db-d a memóriába, akkor meg kell hogy olvasson-írjon a diszkről.

Ami valoszinubbnek tunik, hogy az elteres oka az, hogy *hol* meri, amit mer.

Saccra azt mondanam, hogy a disk utilization a cache _elott_ mer (tehat a virtualis device-ot), a disk io meg cache _utan_ (a fizikai device-ot). Ebbol azt a kovetkeztetest vonnam le, hogy az adatbazis maga picurka, megis rengeteg ir/olvas. Vagyis: a szoftveres optimalizalja szepen a query-jet, a masik meg, hogy te nem a megfelelo helyen bizgeted a memoriat. Adhatsz te neki 3 TB-ot is, ha tovabbra is diszkre probalja menteni szerencsetlen mysql az ideiglenes tablakat heap helyett... A mysql memory tuning kornyeken kell szetnezni, millionyi kivalo doksi irja le, hogy mi micsoda.

Persze ehhez tudni kellene a mysql verzioszamat, mert nem mindegy.

Engedtessék meg egy másik vélemény is a témában amely árnyalja azokat a "tényeket", miszerint "köteles kijavítani a pénzért eladott, hibás elgondolása mentén írt programját" illetve BMW-s indexelés a hiba oka.

Ritkán de én is belefutok olyan igényekbe, amelyek arra építenek, hogy a számítógépek biztosan gyorsak és nagyon gyorsak. És mivel minden adat ott van, ezeket gyorsan ki lehet nyerni. Igen, gyorsan ki lehet nyerni, kockás füzettel 1 hónap lenne 4 embernek (+hiba), SQL által 4 óra. Ezeket lehetne persze másképp tervezni, felkészíteni ezekre az esetekre, de ha nem egyedi szoftvert írsz, akkor tudod 1m Ft alatt adni, cserébe nem 100%-ban a cégre lesz felkészítve.

De hozok egy példát is, amely az ügyfelek számára "triviális", a valóságban az adatok _messze vannak_ logikailag, ezért kijön az eredmény, egy SQL-be belefér, de nem 50ms a futásideje: "Elmúlt negyedév kimenő számláihoz rakjuk oda a bevételi oldal árát, hogy a haszonkulcs látható legyen". A feladat pontosítva úgy néz ki, hogy a kimenő számla dátuma (nem fontos hogy számal kelte vagy teljesítés, egyszerűsítsünk) előtti utolsó nagy beszerzés (mennyiség több mint 100, azaz nem 1-2db), ami nem raktárak között mozgott, hanem szállítólevél volt árát tegyük mellé. Ha az egy szállítólevél volt, akkor persze a számlán szereplő végső összeget jelenítsük meg. Ha visszáru volt, akkor az sem játszik, mert a selejt raktárba megy. Ez akárhogy is nézzük a negyedév 1m számlatételéhez 1m subquery lesz, mert nincs semmilyen fix kapcsolat a bejövő és kimenő konkrét mennyiségek között. Folyamatos FIFO számítás van, de nem pont azt a párosítást adja, amit az ügyfél kért. Excelbe hamarabb mellérakom és FKERES-sel megtalálom (igazából nem), de ezek SQL-ben messzi adatok.

Ügyfeleknek mindig szoktak példát mondani, hogy megértsék, erre a fentire pl: Az OTP régióvezetője azt kéri, hogy az elmúlt egy hónap összes tranzakciójához rakjuk hozzá, hogy akkor abban a fiókban mennyi összeg állt rendelkezésre, kimutatva azt, hogy nem volt-e valahol túlfogyás vagy túlkészletezés. Ez 1m tranzakciónál egy erős subquery lesz! Bármilyen aggregátummal (napi pénzkészlet külön táblában /nap/fiók/deviza) nem állja meg a helyét, mert a 11h-s tranzakciónál már nem a reggeli kezdő összeg játszik. "De hát ott van minden adat Forintban, csak ki kell számolni..." szokott lenni a válasz.

Régen OLAP kockák voltak nagy, lassan lefutó, több szempontból analizálandó adathalmazokra. Mostanság éjjel lefutó és perzisztensen eltárolt összesítéseket szeretünk javasolni. Reggelre megvan, ha 1-3 hónap kell egyben, akkor sem nagysárendileg sem jellegét tekintve nem fog hiányozni belőle a ma reggel 9-11.30-ig keletkezett tranzakciók.

@BCsabaEngine

Very elegáns. Megírodik valahogy a lekérdezés, majd viszontlátásra, és utána az üzemeltetés nyakán megy az ugrálás, hogy szaraszerver oldják meg. Jellemzően az történik, hogy sosem gondoltak arra, hogy mondjuk 100k-s nagyságrend fölé mehet a rekordszám, a szervert jellemzően roppant spórolva vették, hiszen milyen sokat is költöttek a fejlesztésre ugye, majd jönnek a problémák. Általában az adatok jeletős  része archiválható (nem biztos, hogy 10+ év adatsorával kell bohóckodni, elég az utsó 3..., és a régebbieket külön kezelni stb.), a másik az említett index használat (részleges) hiánya és remekbeszabott lekérdezések összehozása. Természetesen a világ összes pénzét el lehet költeni HW-re, nagyon szivesen építek, telepítek, meg adok át ilyesmit, csak nem biztos, hogy ez az adott megrendelőnek tényleg jó..., node ha a fejlesztők ezt igénylik...

Akinek olyan igényei vannak, az lesz szíves az igényekhez rendelni az erőforrásokat, és amikor a szerverbe kell az NVMe SSD, a sok RAM, és sok CPU, akkor nem problémázni.

Ugyanakkor az RBMS-ek lekérdezés optimalizációja körül igen nagy eltérések vannak. Előfordult, hogy ugyanaz PostgreSQL-lel másodpercen belül ment, ami az akkori MySQL-nél bőven sokperces volt. Nyilván az RDBMS csere nem egy hipphopp történet, de a típuson belüli frissítést lehet tesztelni.

Jelen esetben munkaidő adatokról van szó. Vajon mindíg az összes adaton megy a "matek" vagy csak az aktuális hónap 1-től vannak a táblában?

Zárásként még azt tenném hozzá, hogy a fejlesztés egy ideje erős CPU-kon (4GHz+ turbo) és minimum SATA SSD-ken, de már sok esetben NVMe-n megy, mindez lokálisan, minimál késleltetéssel egy SAN-hoz képest. Ezek a konfigok jellemzően sokkal gyorsabbak egyszálon, mint egy értelmesen kifizethető szerver, pláne nagyvállalati. Tessék megnézni a dualsocket CPU-k turbo órajelét, azok jellemzően 3-3,5GHz körül vannak, esetleg elmennek 4GHz-ig, de egy clusterben lévő szervernél nehéz lesz a nettó 1 szálas teljesítményt kicsikarni, mert sok VM fut.

a vegevel nagyon egyetertek. en eleg sok adatfeldolgozast, konverziot csinaltam, van ami hetekig fut. raengedtem ugyanazt egy 48 magos (2 cpu-s) szerverre, 2.1ghz-es ddr4 memoriaval, a cpu orajel is 2.4ghz volt. meg ugye mivel 2 cpu, buffered ram, az sem segit sokat rajta.

a lenyeg, hogy egy sima desktop 4 magos i5-on gyorsabban futott, igaz az 4ghz folotti orajellel, 2.66ghz memoriaval. akkor sem jon ki a matek, hogy miert gyorsabb, de az, jo 30%-al. valoszinu a memoria eleres sebessege a donto. de akkor is vicces, hogy egy kb 120eFt-os pc leveri a 6 millios hp szervert...

kezdem megerteni a googlet, hogy draga sokmagos szerverek helyett dzsunka pc-ket kot clusterbe inkabb...

Valszin ennyit számít az órajel és hogy nem pattog a CPU-k között a processz, pláne ha nem multithread. Azért az a 2,4GHz-es CPU jó esetben is csak 3-3,2GHz-ig turbóz és ha sokszálon megy a biznisz, akkor nem fog sokkal 2,4GHz fölé menni.

Egy partnernél most az lett a menő, hogy bizonyos felhasználásra single socket E-22xx Xeon a nyerő. 8 mag, majdnem 5GHz-es turbó, teljes brutalitás a kategóriájában.

Nem cáfolni szeretném, amit írsz, de a helyzet nem egyszerű.

Például egy szerverbe simán lehet több száz GB vagy akár TB-nyi RAM-ot venni, aminél nincs gyorsabb (jó-jó, CPU cache..., tudom). Ezenkívül CPU-n belül is brutális eltérések vannak: egy Bronz és Platinum között nemcsak az árcédula különbözik.

De az tény, ha a 100GB RAM-os i9-es fejlesztő gépről átkerül a szoftver egy ócska CPU-ra és 32GB RAM-ra, akkor nem feltétlenül kell csodát várni.

Konkrét eset: van egy ügyfél, aki központi tárolóról lokális SSD-re migrálta a rendszereit, merthogy túl lassú. Tény, hogy az általuk használt tároló technológia messze volt az optimálistól, az volt a kiindulás, hogy lokális SSD-nél semmi nem lehet gyorsabb. Vittünk egy AF tárolót nem is legújabb, legerősebb kivitelben/konfigurációban, ~40%-kal (!!!) gyorsabban futott rajta a feldolgozásuk, mint helyi SSD-n, ráadásul a szerver CPU valamivel gyengébb volt AF esetben.

Sajnos van ilyen helyzet nem is kevés, hogy a fejlesztő alatti ürrakétán elmegyeget a dolog, majd a produktiv környezetben meg nem megy elég jól. Ekkor kiderül hogy kevés egy ócska Xeon-os gép 32GB RAM-al. 

Azt azért ne felejtsük el, hogy egy munkaidőnyílvántartás és jelenléti adatokat összesítő megoldásról van szó, ha jól értettem a kérdést feltevő fórumtársat.
Funkcionalitásban pedig ezt már a 386-os korban is megoldották, hogy értelmes emberi időn belül kiköpjön adatot. Na jó, hanem nem 386-ossal akkor egy P1-essel már biztosan volt ilyen rendszer amit használtak is. 

Akkor még ezeket a programokat úgy írták, hogy odafigyeltek rá. Most pedig a fejlődésnek köszönhetően csak jó gyorsan összehányják. Építőkocka szerü modulokból, mert OOP az cool, néha közben nem is OOP, csak egyszerűen egy Skretch-hez hasonló valami lesz csak épp betükkel leírva. Mondanám elsőre a JAVA-t, vagy .NET-et, amik kb a kókány megoldások táptalajának tekinthetőek. Manapság szerintem ezt a kitüntető helyet átveszi a böngészős hulladékgyártás, javascript hegyek, electron. Ahol végűlis teljesen elfogadott, hogy egy chat alkalmazás ami szöveget és fájlokat küld és fogad az 80MB méret felett legyen, fogyaszthat akár 512MB RAM-ot is. Közben egy távoli vezérlést biztosító program 3MB-os mérettel van és 100MB alatt eszik RAM-ot.
Természetesen lehet mindenben kókány programot írni és jót is. De van ami a környezete és a szerszámoskészlete miatt a kókány megoldás felé hajlik amit kiköp magából.
Majd az elbxxxxott programot üzemeltetési oldalról kókányolják tovább, amíg világ a világ. Elsőre talán akár a mai napon is eladott DBF alapú ilyen olyan adafeldolgozó rendszerek ugranak be, ami SMB-n megosztott fájlokkal dolgozik, és évente van vele 5-10 esetben gond, alapjáraton. Majd a rendszergarázda megolda, hiszen ő mindenhez IS ért. Próbálja menteni, próbálja javítani, próbálja gyorsítani, de lényegében csak küzd mint disznó a jégen.

De hogy ON is legyek, és bocsánat az OFF-ért. 
Elvileg hozzáfér teljesen az adatbázishoz. Ha jól értettem a lekérdezést is tudja, hogy mi az, valószínűleg tudja is értelmezni a táblaszerkezetet. Tuti nem 1-2 órát bűvészkedett már vele.
Szerintem kellene egy akár online replikációt vagy dump-ot csinálnia amit tud bűvölni, akár másik SQL szerveren, tehát ebbe sehogy nem kavarna be a dolog.
Majd írjon hozzá egy megfelelő lekérdezést, vagy irasson valakivel, ha a program eredeti készítője nem akarja, vagy nem képes rá. Esetleg ha jól működik és össze akarja rugni a port az eredeti program készítővel akkor ez meg is lesz jó alapnak hozzá.
100% sőtt 1000% hogy egy ilyen funkcionalitásu dolog kiszámításához értelmes idő alatt nem kell a valamelyik szuperszámítógépen időt bérelni. Sőtt nem kell hozzá csilliárd RAM sem vagy Terra Hertz-es processzor sem.

Nem ócska az a Xeon, hanem egyszerűen nem arra ment a beszerzés, hogye a 3+ áv komulatív adathalmazát instant feldolgozza. Mert semmi gond, van instantfeldolgozós szupervas, csak amint az árát meglátják instant szívroham lesz, hiszen: "dehát most (értsd 2-3 éve) vettük ezt a gépünket az is milyen drága volt". A másik probléma, hogy a redundáns tápos single socket gépek a gyártóknál nem voltak divatosak, tisztelet kivételnek persze.

Pont pár napja jött egy szembe egy naaaaaagy gyártó remek ajánlata, amiben már 650 bruttóért kapsz egy 4208-as Xeont (2019 Q2-ből amúgymellesleg), egy táppal és 16-32GB memóval, hdd nélkül. Ez mindenki számára egy konkrét büntetés és nem szerver, de a naaaaaagy gyártó persze csodálkozik, hogy "a másodlagos piac" mennyire szalad. Hogy jót is mondjak, azért létezik gyártó, ahol egész pofás singlesocket gép érhető el: https://www.fujitsu.com/global/products/computing/servers/primergy/rack…

Webes, főleg webáruház jellegű, vonalon rendszeres a kűzdelem, amikor 10-20-30, vagy akár 100 millió rekordos táblák gyűlnek fel és megy a csodálkozás. A fejlesztőknek perrrsze semmire sincs ideje, meg kell szokni és hogy szaraszerver. Node drágafejlesztő urak, a sysadmin hozott anyagból dolgozik. Egyrészt nem szokták az orrára kötni az alkalmazást, hiszen akkor úgyis megszólja, másrészt mond egy olyan számot a leendő szerverre, hiszen szintén mentő viszi el a beruházót, ergo lesz egy valamilyen nagyjából vállalható gép, amin majd valahogy megy a dolog, valameddig. Amikor azt mondja, hogy "fogalmam sincs", hogy a vadiúj fejlesztésű és nulla éles tapasztalattal futó apphoz milyen gép kell majd 1-2 év múlva, akkor bénaszar.

Lehet, hogy nem ment át, de nem annak a pártján vagyok, hogy pakoljuk csak a vasat az alkalmazás alá. Sőt. Mivel inkább infrastruktúra oldalon vagyok "érdekelt", én is küzdök ezekkel a dolgokkal, most is van egy ilyen belassulás dolog, amikor biztosan nem az infrastruktúra az oka, de hát az üzemeltetésnél csapódik ki a dolog.

Én még nem sok olyan szoftvert láttam, ahol egyértelműen leírták volna, hogy milyen esetben mi a teljesítmény igény. A fejlesztőknek sok esetben halvány lila gőzük sincs arról, mi az az IOPS. Az eddigi legjobb méretezések mind olyanok voltak, amikor egy meglévő rendszer alatt kellett hardvert cserélni: volt mit mérni, lehetett tudni, mit kell alá pakolni. Minden más méretezés sokkal inkább művészet és tapasztalat alapú, mert a szoftver szállító leír valamit, amivel talán nem lesz lassú (még mostanában is találkoztam olyan elvárásokkal, amik RAID10-et fogalmaztak meg egyértelműen 10+ éves szövegmaradványként).

A következő válasz, amit ír valaki az nem minden esetben az előzővel ellentétes irányzatot tükröz. Éreztem, hogy nem vagy már tejfelsszájú a témakörben. Lehet jópár tapasztalatod már. 
Ez a "ritmnus" itt lehet már abból alakult ki, hogy általában a pozitiv és negatív oldal osztja egymásnak az észt, egy egy reakcióra szükségszerű az ellenreakció.
Pedig nincs is pozitív és negatív oldal, csak alladin. :)

Jó kérdés, hogy a topic gazdája megpróbája-e amit írtam, vagy valahol elcsúszik a dolog, és kivitelezhetetlen. 

> az elmúlt egy hónap összes tranzakciójához rakjuk hozzá, hogy akkor abban a fiókban mennyi összeg állt rendelkezésre, kimutatva azt, hogy nem volt-e valahol túlfogyás vagy túlkészletezés. Ez 1m tranzakciónál egy erős subquery lesz!

Ellenben ha úgy oldod meg, hogy fiókonként végig mész idő szerint a tranzakciókon, végigpörgeted, hogy mikor mi volt az állapot, akkor az összes adatot pontosan egyszer kell végigolvasni időrendben. Igen, programozni kell, nem lehet (én nem tudnám) SQL-en belül megoldani, de megoldható a feladat gyors lefutással.

Ha mysql alapu, probaltad mar a percona-t? abban van par hasonlo durva feature.

 

Igy latatlanban senki sem fog tudni segiteni. En annyit tudok mondani, hogy rossz design. SQL mondjuk kapasbol szar (emberi korulmenyek kozott skalazhatatlan, a DB mindig egy bottleneck lesz); egy normalisan megtervezett nosql-l jocskan elorebb vagy. Az is igaz viszont, hogy a szarul megirt szoftver barmilyen DB-vel szar lesz, a jol megirt meg alapvetoen mindegyik DB-vel jo.

Kerdes, hogy akik jo szoftver tudnak irni, mivel szeretnek, szeretnenek inkabb dolgozni. :) Tapasztalataim szerint nem sql-el.

probaltatok mar particionalni az adatbazist? bar ilyen keves rekordnal lehet nem fog szamitani

neked aztan fura humorod van...

Amugy, ilyen helyzetben en megneznem, mi van az SLA-ban. Ha nincs, akkor menedzserre boritani az asztalt, hogy vallalhatatlan szerzodeseket kot. Nyilvan nem varhato el toled, hogy csak ugy garantalj valaszidoket, amikor nem is te dontod el, hogy mit fog futtatni a rendszer?

Szerkesztve: 2021. 06. 04., p – 14:29

Folvettem 64 GB ramra (40 Gb-ot adtam az SQL servernek) es 2M-ra emeltem a join_buffer_size-t de nem volt merheto gyorsulas a queryben (1 ora volt most is)

1 gb adatnyi saját db-t csesztetek . Nálam a kérdés kb az, hogy 0.1 vagy 0.01 vagy 0.001 mp a lekérdezés . Szerintem db-t tervezni tudni kell.