CTE nepoužívať pre veľký dataset

[Stanislav Hruška]

Nikde som nenarazil na to čo je veľký dataset. A ja to neviem   Je 25 000 záznamov veľký dataset?

[Delfin]

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

[Stanislav Hruška]

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.

[Delfin]

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

[Stanislav Hruška]

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.

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.

Osobne bych se staral spis o to jak se zbavit Firebirdu

Kde si bol, keď som sa pýtal ktorú DB mám nasadiť

[pf1957]

Osobne bych se staral spis o to jak se zbavit Firebirdu

Co mas krome osobni animozity proti FB?

[vandrovnik]

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

[Delfin]

Osobne bych se staral spis o to jak se zbavit Firebirdu

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...)?

[Stanislav Hruška]

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á.

[pf1957]

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.

[Delfin]

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

[Miroslav Baláž]

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

[Stanislav Hruška]

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.

[Miroslav Baláž]

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

[Stanislav Hruška]

Dostal som upozornenie, že vraj FB má od 25 GB problémy. Ty máš mesačne 7 GB To dlho nevydrží.

[vandrovnik]

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?

[Miroslav Baláž]

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:)

[Stanislav Hruška]

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

Delfin

[Delfin]

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.

[vandrovnik]

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í.

[Delfin]

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

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).