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

Online vandrovnik

  • Hrdina
  • ****
  • Příspěvků: 382
  • Karma: 29
    • 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ů: 197
  • Karma: 5
    • 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ů: 3212
  • Karma: 30
    • 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.

Offline Delfin

  • Guru
  • *****
  • Příspěvků: 742
  • Karma: 32
  • 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 »
I'm a soldier, so don't panic!

Online vandrovnik

  • Hrdina
  • ****
  • Příspěvků: 382
  • Karma: 29
    • 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í.

Offline Delfin

  • Guru
  • *****
  • Příspěvků: 742
  • Karma: 32
  • 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 »
I'm a soldier, so don't panic!

 

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

Upozornění: do tohoto tématu bylo naposledy přispěno před 120 dny.
Zvažte prosím založení nového tématu.

Jméno: E-mail:
Ověření:
Křestní jméno zpěváka Gotta: