Autor Téma: CTE nepoužívať pre veľký dataset  (Přečteno 467 krát)

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 3084
  • Karma: 29
    • Verze Delphi: XE7 professional
CTE nepoužívať pre veľký dataset
« kdy: 16-12-2017, 14:52:12 »
Nikde som nenarazil na to čo je veľký dataset. A ja to neviem :(  Je 25 000 záznamov veľký dataset?
Delphi XE7, FireBird
Expert na kladenie nejasne formulovaných otázok.

Online Delfin

  • Guru
  • *****
  • Příspěvků: 546
  • Karma: 26
  • SW konzultant
    • Verze Delphi: 2009, Tokyo
Re:CTE nepoužívať pre veľký dataset
« Odpověď #1 kdy: 16-12-2017, 15:42:25 »
Nikde som nenarazil na to čo je veľký dataset. A ja to neviem :(  Je 25 000 záznamov veľký dataset?

Na to neexistuje specificka odpoved. Ale 25k temer jiste ne (pokud nemas DBMS na tri osm svestce s par mega volne pameti - ze by musel chudacek Firebird swapovat CTE resultset na disk). Ale neni to jedno? Pokud uvazujes pouzit CTE pro nejakou rychle rostouci tabulku, co udelas v dobe az dosahne toho "velkeho limitu"? Vyrobis z ni temporary tabulku?

Pro nektere DBMS muze CTE prinest vyhodu, pro nektere ne. Zalezi jak pracuji uvnitr. Zmer pro svuj konkretni pripad a uvidis ;)
« Poslední změna: 16-12-2017, 15:47:07 od Delfin »
Shiny disco balls! I don't like :)

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 3084
  • Karma: 29
    • Verze Delphi: XE7 professional
Re:CTE nepoužívať pre veľký dataset
« Odpověď #2 kdy: 16-12-2017, 15:55:01 »
Dosť som si o tom čítal. O kladoch i záporoch. Tých 25k je v podstate horná hranica. Určené podľa WHERE. Aj by som si to zmeral, ale nemám toľko údajov. Len 1 200.
Ja som sa rozhodol pre použitie CTE na základe odporúčania, že je veľmi vhodné pre agregačné funkcie. A ja tam mám MIN(myDate), MAX(myDate) a tri cudzie kľúče.
« Poslední změna: 16-12-2017, 15:59:17 od Stanislav Hruška »
Delphi XE7, FireBird
Expert na kladenie nejasne formulovaných otázok.

Online Delfin

  • Guru
  • *****
  • Příspěvků: 546
  • Karma: 26
  • SW konzultant
    • Verze Delphi: 2009, Tokyo
Re:CTE nepoužívať pre veľký dataset
« Odpověď #3 kdy: 16-12-2017, 16:29:19 »
Dosť som si o tom čítal. O kladoch i záporoch. Tých 25k je v podstate horná hranica. Určené podľa WHERE. Aj by som si to zmeral, ale nemám toľko údajov. Len 1 200.
Ja som sa rozhodol pre použitie CTE na základe odporúčania, že je veľmi vhodné pre agregačné funkcie. A ja tam mám MIN(myDate), MAX(myDate) a tri cudzie kľúče.

Tak si je vygeneruj ;) A velmi vhodne, tezko posoudit. Clovek co Ti tohle radil nejspis vi jak ma Firebird implementovane CTE. Pro dany sloupec setrideny resultset pro MIN a MAX funkce jen tezko trumfnes. Ale tohle cele bude IMHO jen mikrooptimalizace. Osobne bych se staral spis o to jak se zbavit Firebirdu ;D
« Poslední změna: 16-12-2017, 16:31:36 od Delfin »
Shiny disco balls! I don't like :)

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 3084
  • Karma: 29
    • Verze Delphi: XE7 professional
Re:CTE nepoužívať pre veľký dataset
« Odpověď #4 kdy: 16-12-2017, 18:52:03 »
Citace
Tak si je vygeneruj
Už niečo mám, ale medzitým som zmenil štruktúru DB. Takže najprv dokončím čo robím. Potom už je malý predpoklad zmien v DB. Môžem pokračovať v generovaní testovacích údajov a ladiť aplikáciu.
Citace
Clovek co Ti tohle radil nejspis vi jak ma Firebird implementovane CTE
Všetky materiály som si stiahol z internetu. Pre rozumy chodím akurát tu. Bolo to všeobecné odporúčanie bez ohľadu na DB. Snáď jediné na ktorom sa všetci zhodli.
Citace
Osobne bych se staral spis o to jak se zbavit Firebirdu
Kde si bol, keď som sa pýtal ktorú DB mám nasadiť :-\
Delphi XE7, FireBird
Expert na kladenie nejasne formulovaných otázok.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 1966
  • Karma: 101
    • Verze Delphi: D2007, XE3, DX10
Re:CTE nepoužívať pre veľký dataset
« Odpověď #5 kdy: 16-12-2017, 19:07:12 »
Osobne bych se staral spis o to jak se zbavit Firebirdu ;D
Co mas krome osobni animozity proti FB?

Offline vandrovnik

  • Hrdina
  • ****
  • Příspěvků: 317
  • Karma: 21
    • Verze Delphi: 10.2
Re:CTE nepoužívať pre veľký dataset
« Odpověď #6 kdy: 16-12-2017, 19:44:10 »
25 tisíc záznamů je na normálně výkonném hardware ve Firebirdu jak nic, zejména pokud jsou pro přístup kloudně vytvořené indexy.

Na tabulce s 80 sloupci a 13 miliony záznamů jsem zkusil:
SELECT SUM(CAST(a.Radek as numeric(14,0))) FROM Objednavky2 a
- trvalo to 26 sekund

Pak:
SELECT SUM(CAST(a.Radek as numeric(14,0))) FROM Objednavky2 a
WHERE (a.Kod>100000)and(a.Kod<125000)
- trvalo to asi 0,5 sekundy

Samotný příkaz:
SELECT a.Radek FROM Objednavky2 a
WHERE (a.Kod>100000)and(a.Kod<125000)
- je hotový v podstatě hned, pak by samozřejmě trvalo případné procházení výsledku



Online Delfin

  • Guru
  • *****
  • Příspěvků: 546
  • Karma: 26
  • SW konzultant
    • Verze Delphi: 2009, Tokyo
Re:CTE nepoužívať pre veľký dataset
« Odpověď #7 kdy: 16-12-2017, 20:21:01 »
Osobne bych se staral spis o to jak se zbavit Firebirdu ;D
Co mas krome osobni animozity proti FB?

Kdyz vedle nej postavim napr. PostgreSQL tak zhruba, ehm, vsechno. Fakt, asi vsechno. Kdyz dotaz obratim, co ma Firebird oproti zminenemu PostgreSQL lepsi (muze byt embedded, a..., a...)?
Shiny disco balls! I don't like :)

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 3084
  • Karma: 29
    • Verze Delphi: XE7 professional
Re:CTE nepoužívať pre veľký dataset
« Odpověď #8 kdy: 16-12-2017, 20:55:59 »
a server nemá 600 MB. Tu mi každý namietne, že to je argument o ničom. Ak sa mi to podarí dotiahnuť do konca, tak embedded budem potrebovať. Vlastne to bola aj podmienka pre výber DB. Neviem či sa nájde zákazník so záujmom o serverovú verziu.
Lenže mne FB, na to čo robím, úplne postačuje. Sme už mimo témy a bol by som nerád, keby to skĺzlo tam kde nemá.
Delphi XE7, FireBird
Expert na kladenie nejasne formulovaných otázok.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 1966
  • Karma: 101
    • Verze Delphi: D2007, XE3, DX10
Re:CTE nepoužívať pre veľký dataset
« Odpověď #9 kdy: 16-12-2017, 20:58:33 »
Kdyz dotaz obratim, co ma Firebird oproti zminenemu PostgreSQL lepsi (muze byt embedded, a..., a...)?
Jenomze tak otazka nestoji: on se nerozhoduje o tom, jaky RDBMS vybrat pro pristi projekt, ale pouziva FB, umi ho, ma pro nej nastroje...

A v takove situaci mu doporucovat, ze hlavne se ma zbavit FB je IMHO pic*vina. S tou FB udela vse, co muze potrebovat i kdyz treba za cenu vytvareni SP. A pokud nema obrovska data nebo masivni paralelismu tak toho vetsinu udela sviznejc nez v PostgreSQL... Ona ma PostgreSql taky svoje mouchy, ja si vzpominam, jak me neuveritelne sr*la rychlost Count() (https://wiki.postgresql.org/wiki/Slow_Counting), coz je docela stezejni funkce pri obsluze paginatoru apod. zalezitosti.

Online Delfin

  • Guru
  • *****
  • Příspěvků: 546
  • Karma: 26
  • SW konzultant
    • Verze Delphi: 2009, Tokyo
Re:CTE nepoužívať pre veľký dataset
« Odpověď #10 kdy: 16-12-2017, 21:55:51 »
Jenomze tak otazka nestoji: on se nerozhoduje o tom, jaky RDBMS vybrat pro pristi projekt, ale pouziva FB, umi ho, ma pro nej nastroje...

Vim, proto jsem dal nakonec tlemiciho se smajlika ;)
Shiny disco balls! I don't like :)

Offline Miroslav Baláž

  • Plnoletý
  • ***
  • Příspěvků: 119
  • Karma: 4
    • Verze Delphi: D1,2,3,4,7,2005,2009, XE8,S,B,T10.2.2 Pro
Re:CTE nepoužívať pre veľký dataset
« Odpověď #11 kdy: 17-12-2017, 00:46:50 »
Stano, pre zaujímavosť som zaradil do porovnania aj Firebird embedded.
Možno by si mi mohol pomôcť s vyladením na rýchlosť.
Pozri prosím toto.
Pre zaujímavosť prikladám aj test pre FIREBIRD 3.0 EMBEDED
Čas bol poslabší cca 29 000 milisekúnd.
Kód: MySQL [Vybrat]
  1. CREATE TABLE sumar ( wordItem varchar( 64 ) NOT NULL primary key, eCategSet BIGINT, eFnFlagSet INTEGER );
Ďakujem Miro

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 3084
  • Karma: 29
    • Verze Delphi: XE7 professional
Re:CTE nepoužívať pre veľký dataset
« Odpověď #12 kdy: 17-12-2017, 09:36:18 »
Ja vôbec netuším čo po mne chceš. Som poslabší samouk. V podstate klikač komponentov. To je fakt. Musíš mi to dať po lopate. Buď ako súkromnú správu alebo na mail.
Ak budem vedieť, tak pomôžem.
Delphi XE7, FireBird
Expert na kladenie nejasne formulovaných otázok.

Offline Miroslav Baláž

  • Plnoletý
  • ***
  • Příspěvků: 119
  • Karma: 4
    • Verze Delphi: D1,2,3,4,7,2005,2009, XE8,S,B,T10.2.2 Pro
Re:CTE nepoužívať pre veľký dataset
« Odpověď #13 kdy: 17-12-2017, 21:51:34 »
Dotaz som ti poslal ako uzivatelovi FB.
Ze snad najdes v kode nieco, co by sa mohlo optimalizovat. Link je pri mojej ziadosti.
Vdaka tej ziadosti, poslal Delfin namet, ktory benchmark pre FB zrychlil 3-nasobne.
FB som do benchmarku zaradil preto, ze ma verziu embedded.
Pre potreby, ktore sledujem, je privlastok EMBEDDED pre databazu velka prednost.
To splnaju aj Access a MS SQL Server Local Edition (v podstate). SQL Compact Edition tiez, ale to je uplna strata casu, kde MS predviedol, ze strka neoverene veci na trh. Povodne to bolo pre PC a mobily, snad este v case, ked ani I-phone este nebol na trhu.
Aj posledne menovane databazy by z mojho pohladu vyhovovali, ale maju velkostne limity 2GB (access, len teoreticky, v praxi ovela menej) a SQL Server Local, ma data max 11GB.
Plus sa musia instalovat.
SQLite a FB sa instalovat nemusia, bezali by aj z USB. Tak preto mam tieto dve v benchmarku.
Keby niekto nieco testoval v mojej oblasti, zaujalo by ma to. Len som skusil.
Miro

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 3084
  • Karma: 29
    • Verze Delphi: XE7 professional
Re:CTE nepoužívať pre veľký dataset
« Odpověď #14 kdy: 17-12-2017, 21:58:12 »
Dostal som upozornenie, že vraj FB má od 25 GB problémy. Ty máš mesačne 7 GB :) To dlho nevydrží.
Delphi XE7, FireBird
Expert na kladenie nejasne formulovaných otázok.

Offline vandrovnik

  • Hrdina
  • ****
  • Příspěvků: 317
  • Karma: 21
    • Verze Delphi: 10.2
Re:CTE nepoužívať pre veľký dataset
« Odpověď #15 kdy: 17-12-2017, 22:48:12 »
Dostal som upozornenie, že vraj FB má od 25 GB problémy. Ty máš mesačne 7 GB :) To dlho nevydrží.

Byl by k téhle informaci i nějaký zdroj, nebo je to jen JPP?

Offline Miroslav Baláž

  • Plnoletý
  • ***
  • Příspěvků: 119
  • Karma: 4
    • Verze Delphi: D1,2,3,4,7,2005,2009, XE8,S,B,T10.2.2 Pro
Re:CTE nepoužívať pre veľký dataset
« Odpověď #16 kdy: 18-12-2017, 06:53:16 »
Dostal som upozornenie, že vraj FB má od 25 GB problémy. Ty máš mesačne 7 GB :) To dlho nevydrží.
Nezaujíma ma iba kapacita údajov. Ten multi GB projekt je okrajový. Mám aj dosť iných požiadaviek. Jedna dôležitá smeruje k názvom polí v tabuľkách. To sa možno na budúci rok zmení v novej verzii FB.
O kapacite pre údaje sa oficiálne hovorí tu:http://www.firebirdfaq.org/faq59/ Zdá sa, že tam problém nie je.
Inak, nič mi nebráni, aby som mal podporu pre tri/štyri databázy. Každá na niečo:)

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 3084
  • Karma: 29
    • Verze Delphi: XE7 professional
Re:CTE nepoužívať pre veľký dataset
« Odpověď #17 kdy: 18-12-2017, 07:31:58 »
Citace
Byl by k téhle informaci i nějaký zdroj, nebo je to jen JPP?
Delfin :)
Delphi XE7, FireBird
Expert na kladenie nejasne formulovaných otázok.

Online Delfin

  • Guru
  • *****
  • Příspěvků: 546
  • Karma: 26
  • SW konzultant
    • Verze Delphi: 2009, Tokyo
Re:CTE nepoužívať pre veľký dataset
« Odpověď #18 kdy: 18-12-2017, 08:16:37 »
Citace
Byl by k téhle informaci i nějaký zdroj, nebo je to jen JPP?
Delfin :)

Ano, JPP. Delfin to zazil na (vic nez jednom) produkcnim stroji s FB 2.5. Jakmile DB s tabulkou o par sloupcich se spoustou zaznamu prekrocila na velikosti cca 30 GB, nejjednodussi SQL prikazy jen nad tou velkou tabulkou sly vykonostne do haje, a to tezce. Index byl nastaven spravne, plan pri spousteni ten index pouzival. Administratori Firebird optimalizovali podle vsemoznych navodu, dokonce nekteri i upgradovali hardware (stroje mely pritom vykonostne dost velke rezervy a vyuziti FB serveru nebylo nijak vyjimecne velke). Nebylo nic co mely ty stroje evidentne spolecne. Nic z toho nepomohlo. Docasne pomahal backup & restore, coz nejspis uklidilo z databaze garbage.

Jsem si celkem jisty ze by pomohl tabulkovy partitioning. Ten bohuzel FB 2.5 neumel.
« Poslední změna: 18-12-2017, 08:47:11 od Delfin »
Shiny disco balls! I don't like :)

Offline vandrovnik

  • Hrdina
  • ****
  • Příspěvků: 317
  • Karma: 21
    • Verze Delphi: 10.2
Re:CTE nepoužívať pre veľký dataset
« Odpověď #19 kdy: 18-12-2017, 11:01:14 »
Citace
Byl by k téhle informaci i nějaký zdroj, nebo je to jen JPP?
Delfin :)

Ano, JPP. Delfin to zazil na (vic nez jednom) produkcnim stroji s FB 2.5. Jakmile DB s tabulkou o par sloupcich se spoustou zaznamu prekrocila na velikosti cca 30 GB, nejjednodussi SQL prikazy jen nad tou velkou tabulkou sly vykonostne do haje, a to tezce. Index byl nastaven spravne, plan pri spousteni ten index pouzival. Administratori Firebird optimalizovali podle vsemoznych navodu, dokonce nekteri i upgradovali hardware (stroje mely pritom vykonostne dost velke rezervy a vyuziti FB serveru nebylo nijak vyjimecne velke). Nebylo nic co mely ty stroje evidentne spolecne. Nic z toho nepomohlo. Docasne pomahal backup & restore, coz nejspis uklidilo z databaze garbage.

Jsem si celkem jisty ze by pomohl tabulkovy partitioning. Ten bohuzel FB 2.5 neumel.

To spíš působí dojmem, že nevadila velikost databáze, ale smetí, které se třeba neuklízelo průběžně. Dovedu si představit, že by to mohlo zlobit, pokud by třeba někde dlouho visela otevřená transakce, tu pak někdo konečně ukončí a sweeper začne dělat úklid, což zbrzdí i ostatní.

Online Delfin

  • Guru
  • *****
  • Příspěvků: 546
  • Karma: 26
  • SW konzultant
    • Verze Delphi: 2009, Tokyo
Re:CTE nepoužívať pre veľký dataset
« Odpověď #20 kdy: 18-12-2017, 21:52:12 »
To spíš působí dojmem, že nevadila velikost databáze, ale smetí, které se třeba neuklízelo průběžně. Dovedu si představit, že by to mohlo zlobit, pokud by třeba někde dlouho visela otevřená transakce, tu pak někdo konečně ukončí a sweeper začne dělat úklid, což zbrzdí i ostatní.

Taky mi to tak prislo. Nicmene nutno dodat ze se z te velke tabulky nikdy nic nemazalo. Jen rostla. Chapu ze prave pro tento pripad existuje tabulkovy partitioning, ale ten rozdil byl propastny po prekroceni prave te hranice velikosti ~30 GB - z dotazu v radech ms se na spusteni cekalo radove sekundy. A empiricky (generovanim zaznamu) bylo zjisteno ze nezalezelo jen na te nejvetsi tabulce, proto jsem tu velikost vubec zminil. Cert vi v cem byl problem.

Mozna FB krivdim a slo jen o chybu ktera byla k videni jen do verze 2.5, ale... Dokumentace, zpusob a doba vyvoje nove verze, moznosti, existujici rozsireni, podpora, nasazeni vice "hraci" proste na mnou oblibeny PG ani zdaleka nestaci. Ve srovnani s nim je FB hracka pro deti :P :)

A ne, argument typu "chci embedded DBMS" s tim ze budu na stroj ukladat desitky GB dat zkratka hazim za hlavu. To je IMHO nesmysl sam o sobe ("velky" objem dat zkratka uz patri na dedikovany, kdyz uz nic vic tak alespon radne zalohovany server).
« Poslední změna: 18-12-2017, 22:18:22 od Delfin »
Shiny disco balls! I don't like :)

 

S rychlou odpovědí můžete používat BB kódy a emotikony jako v běžném okně pro odpověď, ale daleko rychleji.

Jméno: E-mail:
Ověření:
Kolik je šest plus čtyři (slovem):