Výsledky 1 až 25 z 77

Téma: Helios Green aneb nejsprasenejsi aplikace kterou znam

Hybrid View

Předcházející příspěvek Předcházející příspěvek   Další příspěvek Další příspěvek
  1. #1
    Administrátor マツダ mince Avatar uživatele Marty
    Založen
    07.10.2002
    Bydliště
    Praha, Sanctuary
    Věk
    43
    Příspěvky
    8 225
    Vliv
    300

    Standardní Re: Helios Green aneb nejsprasenejsi aplikace kterou znam

    Ono jak tak koukám nejsou clusterovaný indexy nikde, což je dost na nic - minimálně zavedením clusterovanýho indexu snížíš počet fyzických IO operací při čtení o 1, a to je při tabulce do 8 mld záznamů z 4 na 3, při <4 mil. záznamů pak z 3 na 2 !

    BTW bacha na to, všespásný to není - negeneruj clusterovaný indexy nad blbejma typama sloupců. Ideální je to mít nad int / auto increment, což v případě cislo_subjektu popř. cislo_objektu nad např. lcs.sk_polozka je - sice asi aplikační logikou, ale to není v zásadě podstatný. V opačným případě dochází k page splitům v indexu a nutnosti přeorganizovat celej index při insertu hodnoty, která není na konci již existujících hodnot v klíči indexu.
    CUBE> Ryzen 7 7700X + Arctic Lq Frzr III 64 GB DDR5-6000 ◦ ASUS TUF B650PLUS ◦ ASUS RTX3060 OC 12GB ◦ Kingston KC3000 2TB ◦ SS G12 GM-650 Gold ◦ Samsung S27A800 4K
    WORK> HP EliteBook 845 G9 ◦ Ryzen 5 PRO 6550 ◦ 32 GB DDR3 ◦ 2048 GB nVME SSD ◦ 14.1" 1920x1080 LED + 2x 32" Dell 4K ◦ Win11 Enterprise
    SERVER> HP ProLiant Microserver Gen8 ◦ Intel Core i5-3540T ◦ 16 GB DDR3 ◦ 180 GB SSD + 2x4 TB WD RED + 2x16 TB Toshiba ◦ 10GbE NIC
    PHOTO> Canon EOS 70D ◦ EF 70-200/4L ◦ EF-S 10-18 STM ◦ EF 50/1.8II ◦ EF-S 40/2.8 STM ◦ Yongnuo YN-568EX ◦ Tamrac 5534
    HOMECINEMA> TV Samsung UE55Q55T 55" 4K ◦ DVD Pioneer DV-310K ◦ AVR Yamaha RX-V359 ◦ SPK Dexon Allegro 5.0
    OTHERSTUFF> Mikrotik RB760iGS ◦ Mikrotik CSS610
    ◦ Mikrotik CRS326 ◦ UniFi WLAN ◦ Xerox B235 ◦ Canon PiXMA MG5350

  2. #2
    Administrátor mince Avatar uživatele Jezevec
    Založen
    08.10.2002
    Bydliště
    Teplice
    Příspěvky
    6 738
    Vliv
    300

    Standardní Re: Helios Green aneb nejsprasenejsi aplikace kterou znam

    Pro zajimavost, podle tech kretenu je to, ze zaznam v logu neobsahuje ZADNOU vazbu na doklad ke kterymu patri normalni ....
    IMPROBE AMOR, QUID NON MORTALIA PECTORA COGIS - krutá jsi, lásko, kam až ty doženeš smrtelná srdce -- Vergilius
    Mnoho je prostředků, které léčí lásku, ale žádný není spolehlivý.
    S tím, čeho se na nás dopustili druzí se už nějak vyrovnáme. Horší je to s tím, čeho jsme se na sobě dopustili sami.
    -- Francois La Rochefoucauld
    Nabídnout přátelství tomu, kdo chce lásku, je jako dát chleba tomu, kdo umírá žízní.

  3. #3

    Standardní Re: Helios Green aneb nejsprasenejsi aplikace kterou znam

    Citace Původně odeslal Marty Zobrazit příspěvek
    Ono jak tak koukám nejsou clusterovaný indexy nikde, což je dost na nic - minimálně zavedením clusterovanýho indexu snížíš počet fyzických IO operací při čtení o 1, a to je při tabulce do 8 mld záznamů z 4 na 3, při <4 mil. záznamů pak z 3 na 2 !

    BTW bacha na to, všespásný to není - negeneruj clusterovaný indexy nad blbejma typama sloupců. Ideální je to mít nad int / auto increment, což v případě cislo_subjektu popř. cislo_objektu nad např. lcs.sk_polozka je - sice asi aplikační logikou, ale to není v zásadě podstatný. V opačným případě dochází k page splitům v indexu a nutnosti přeorganizovat celej index při insertu hodnoty, která není na konci již existujících hodnot v klíči indexu.
    Ano, z vlastní zkušenosti souhlasím, je to obecný problém architektury tříd v Helios Green. Helios Green používá "posun do META", kdy všechny hlavičkové záznamy v jsou subjekty, tím získává datový návrh značně na flexibilitě, ale klesá také silně výkonnost databázového stroje. Pokud tabulky jako subjekty nebo sk_polozka narostou do desetimilionovych řádů, pak dochází k vzájemné blokaci uživatelů při určitých operacích, pracujícíh s větší množinou záznamů. Je vcelku jedno, jestli uživatelů je 100 nebo 5, blokuje se tabulka subjekty a treba take sk_polozka a vyrobce na to ma specialni udelatko, kterym blokovani presahujic rozumny cas odstreluje, jinak je treba restart SQL Serveru.
    Řëšením by měla být dle mého názoru archivace záznamů do archivní databáze. Pro opravdu veliké projekty, kde vznikají miliony záznamů skladových pohybů relativně rychle, se myslím Helios Green nehodí, pro střední firmu ale je OK.

Informace o tématu

Users Browsing this Thread

Toto téma si právě prohlíží 1 uživatelů. (0 registrovaných a 1 anonymních)

Klíčová slova k tématu

Pravidla přispívání

  • Nemůžete zakládat nová témata
  • Nemůžete zasílat odpovědi
  • Nemůžete přikládat přílohy
  • Nemůžete upravovat své příspěvky
  •