Új hozzászólás Aktív témák

• #20911 inf3rno nagyúr dabadab #20910

  Új Válasz 2025-11-06 16:47:02 #20911

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  inf3rno

  nagyúr

  válasz dabadab #20910 üzenetére

  Jaja, most büszke vagyok. Mondtam is a főnöknek, hogy fel fognak gyorsulni a dolgok.

• #20910 dabadab titán inf3rno #20909

  Új Válasz 2025-11-05 23:14:12 #20910

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dabadab

  titán

  válasz inf3rno #20909 üzenetére

  Hát akkor volt értelme tesztelni

• #20909 inf3rno nagyúr inf3rno #20908

  Új Válasz 2025-11-05 19:07:36 #20909

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  inf3rno

  nagyúr

  válasz inf3rno #20908 üzenetére

  Mértem még közben egy bulk insertet. Az talán 5%-al gyorsabb, mint a JSON-os megoldás, viszont közel sem annyira kényelmes ér rugalmas, mint az INSERT SELECT a JSON-al, úgyhogy komplexebb helyzetekben nincs is igazán értelme foglalkozni vele.

  Ami még érdekes itt, hogy egyes dátumokra mentek értékeket. Aztán bizonyos tábláknál összefüggő dátum tartományok alakulhatnak ki, amiknél azonos az érték. Azt találtam, hogyha 5+ dátumot átfog egy átlagos tartomány, akkor már megéri from-to tárolni, mert jóval gyorsabb az írása és az olvasása is. Batchben frissíteni úgy, hogy ne fragmentálódjon közepesen bonyolult, de azért megoldható.

  Így bizonyos tábláknál a sima 100-as tranzakciós megoldáshoz képest 50x-es írási sebesség is elérhető. Ez kb. olyan, mintha 1 perc alatt bemenne, ami most 1 órába telik. Azért az nem semmi. A problémásabb tábláknál is 5-10 perc, ami várható 1 óra helyett.

  

• #20908 inf3rno nagyúr dabadab #20901

  Új Válasz 2025-10-31 16:32:57 #20908

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  inf3rno

  nagyúr

  válasz dabadab #20901 üzenetére

  Na benchmarkoltam, egyelőre csak annyit, hogy 10.000 rekord van, és másik 10.000-el írjuk felül INSERT ON DUPLICATE KEY UPDATE-el. A sebességek ilyenek voltak:
  - egyesével beküldve: 6.000 record/sec
  - tranzakcióban beküldve 100-as kötegekben: 10.000 record/sec
  - tranzakcióban beküldve 250-es kötegekben: 10.000 record/sec
  - JSON-ban beküldve CTE-vel 100-as kötegekben: 80.000 record/sec
  - JSON-ban beküldve CTE-vel 250-es kötegekben: 95.000 record/sec
  - JSON-ban beküldve CTE-vel 10.000-es kötegekben: 110.000 record/sec

  Nekem ebből az jött le, hogy JSON-ban fogom beküldeni CTE-vel ahelyett, hogy tranzakcióval szarakodnék. A 250-es köteg tűnik optimálisnak. Annyi talán még elveszhet, ha valami nagyon félrecsúszik, nem zabál annyi memóriát és sebességben elég közel van a 10.000-es köteghez.

  Még csinálok majd egy 4. változatot, aminél először SELECT FOR UPDATE-el lekérem, hogy mi változott, aztán csak utána tolom rá az INSERT ON DUPLICATE KEY UPDATE-et. Így le tudom naplózni a tényleges változásokat is. De ezt csak akkor lépem meg, ha nem annyira lassú, mondjuk hozza legalább az egyszerűbb JSON-os változat 80%-át sebességben.

• #20907 Sonja nagyúr

  Új Válasz 2025-10-15 15:33:18 #20907

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sonja

  nagyúr

  Érdekes programozási nyelvet találtam.

  Cursed Lang

  "The only compiled language that lets you code with "sus", "slay", and "vibez" while achieving near-c performance."

• #20906 VikMorroHun őstag JoinR #20903

  Új Válasz 2025-10-09 21:34:39 #20906

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  VikMorroHun

  őstag

  válasz JoinR #20903 üzenetére

  Alakul a dolog. A pár száz byte-os logból sikerült 12 KB-osat csinálni.

• #20905 inf3rno nagyúr dabadab #20901

  Új Válasz 2025-10-05 15:43:01 #20905

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  inf3rno

  nagyúr

  válasz dabadab #20901 üzenetére

  Hát benchmarknál arra gondoltam, hogy beviszek 10 millió rekordot, aztán beküldök újabb 10 milliót úgy, hogy abból 50k ami tényleges változtatás. Nagyjából valami ilyesmire lehet készülni, max 25 millióra. Igazából a 100 az ilyen hasraütésre született vagy nem tudom mi volt a megfontolás mögötte, simán lehet, hogy 1000 vagy 10000 lesz helyette, most tervezzük újra a rendszert.

• #20904 inf3rno nagyúr coco2 #20899

  Új Válasz 2025-10-05 15:40:35 #20904

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  inf3rno

  nagyúr

  válasz coco2 #20899 üzenetére

  Nem akarok itt komplett SQL-t írni. Nagyjából úgy néz ki, hogy a SELECT-be rakok egy JSON-t a 100 értékről, azt beparsolja, aztán INNER JOIN-al illesztem a meglévő táblára az értékeket az ON részében meg lesznek a kulcsok meg az, hogyha az érték eltérő, akkor kerüljön csak kiválasztásra. Az INSERT ON DUPLICATE KEY UPDATE meg erre a kiválasztott halmazra íródik.

  A 3-as jó lenne, de tudok nélküle élni.

  Igazából csak kíváncsi voltam kinek mi a véleménye, megérzése. Így is úgy is le fogom benchmarkolni legalább az első kettőt.

• #20903 JoinR őstag VikMorroHun #20902

  Új Válasz 2025-10-05 15:10:01 #20903

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  JoinR

  őstag

  válasz VikMorroHun #20902 üzenetére

  Van benne egy kis programminghorror vibe.

• #20902 VikMorroHun őstag

  Új Válasz 2025-10-05 14:54:33 #20902

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  VikMorroHun

  őstag

  Ha már log:
  A programom 8-10 példányban fut egyszerre, de néha egyik-másik meghibásodik valamiért (nem jöttem rá, mitől). Nincs hibaüzenet, nincs összeomlás, egyszerűen csak megáll, és nem csinál semmit. Eléggé véletlenszerű a dolog; tesztelésnél nem jelentkezik, csak élesben, viszont sok pénzbe kerülhet, ha előfordul, úgyhogy csináltam egy kis log filet, amibe folyamatosan irkálják a dolgaikat, és mindegyik tudja ellenőrizni az összes többit. Ha valamelyik azt látja, hogy leállt az egyik, akkor újraindítja. Tök jó, működik (és így az is kiderült, hogy naponta többször is előfordul ez a hiba). Az egyiket én magam állítottam le, mert nincs rá szükség. A naplóban viszont benne maradt, és buzgón "indították is újra" a nem létező programot. Ok, írtam hozzá egy ellenőrző függvényt, hogy ha valami nem létezik, akkor ne akarják újraindítani, akkor se, ha a naplóban van róla adat. Eredmény: csak fél óránként próbálják újraindítani. Néha egy óráig semmi, aztán valamelyiknek megint feltűnik, hogy nini, hiszen ez leállt, akkor újraindítjuk! Ma írtam hozzá egy másik függvényt, ami kiüti a nem létező programhoz tartozó azonosítót a naplóból, hátha így már nem akarják újraindítani. Kíváncsi vagyok, mi lesz a jövő héten.

  Nyilván, ha törlöm a naplót, akkor nincs adat, ami alapján újraindítanák a nem létező programpéldányt, de azért kíváncsi vagyok, sikerül-e végre rendesen megcsinálni...

• #20901 dabadab titán inf3rno #20898

  Új Válasz 2025-10-04 21:12:57 #20901

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dabadab

  titán

  válasz inf3rno #20898 üzenetére

  Teljesen tippre az első tűnik a gyorsabbnak, de 100 értéknél tulajdonképpen mindegy is.

  Ha viszont tényleg le akarod mérni, hogy a te konkrét adatbázisodnál, a te adataiddal melyik a gyorsabb, akkor meg kapcsold be a slowlogot (egy long_query_time=0 után minden query slow querynek fog számítani) és nézd meg.

Új hozzászólás Aktív témák