Forum » Programiranje » Ena za MythBusters: določanje dolžin varchar polj
Ena za MythBusters: določanje dolžin varchar polj
JanBrezov ::
Nekako so me naučili, da je pri rezervaciji polj tipa varchar v podatkovnih bazah pametno, da se te rezervira za 2^n znakov: npr. če potrebujemo 500 znakov, potem rezerviraj 512, če 1000, potem raje 1024 itd. Razlaga bi naj bila, da je to bolj "naravno" za računalnik; programi pomnilnik običajno berejo/pišejo po blokih.
Mi zna kdo razložit, ali ima tak pristop kak smisel ali je zgolj poklicna deformacija računalničarja? Uporabljam MySql in MS SQL Server baze; verjetno so razlike v internem delovanju.
Mi zna kdo razložit, ali ima tak pristop kak smisel ali je zgolj poklicna deformacija računalničarja? Uporabljam MySql in MS SQL Server baze; verjetno so razlike v internem delovanju.
BlueRunner ::
Nima smisla in je samo deformacija, ki danes nima več povezave z realnostjo.
Prva napaka je v temu, da se za varchar velikost 2^n dejansko rezervira še dodaten pomnilnik (dva ali več zlogov - bytov), ki povedo koliko je v polju dejansko znakov + zlog za polja, ki so lahko tudi NULL. Torej je že v izhodišču tovrstna alokacija fubar.
Druga napaka je razmišljanje v potencah, namesto večkratnikih. Za CPE je naravna enota obdelave pomnilnika velikost besede. Torej 4 zloge pri 32-bitnih CPE ali pa 8 zlogov pri 64-bitnih CPE. Torej ima smisla govoriti o večkratnikih te velikosti in ne o potencah 2. Če pa vzameš za velikost bloka dejansko velikost pomnilniške besede (pri DDR je to 128 bitov oziroma 16 zlogov), pa si s tem zaključil, saj se podatke zajema in vrača v pomnilnik v tej velikosti. To pomeni, da prebrati 1 zlog ali pa prebrati 16 zlogov ne predstavlja nikakršne razlike in lahko pravilna poravnava dejansko prinese nekaj malega razlike, v primerih, kjer bi bil blok razdeljen preko meje 16 zlogov. Glede na to, da govorimo o varchar-ih, ki so praviloma večji od 16 zlogov, je to že itak game over.
Tretja napaka je to, da ljudje pozabljajo na podatkovno strukturo na diskih (ali pa niso nikoli imeli formalne izobrazbe). Glede na to, da je govora o varchar-u, je verjetno govora o RDBMS. Pri teh pa se podatki na disku rangirajo v vrstice, vrstice pa v strani. Enota pri delu z diskom pa je celotna stran in ne samo vrstica (velikost strani pa je povezana z velikostjo blokov na disku - 512 zlogov, 1024 zlogov, 2048 zlogov, ...). Čeprav velikosti strani na prvi pogled sledijo pravilu potenc, pa je nesmisel, da bi jih poskušal slediti, ker je osnoven namen obdelava v blokih (straneh), pri čemer je delo RDBMS veliko bolj optimalno, če v eni potezi iz počasnega pomnilnika potegne več vrstic, kot pa eno po eno. Tukaj se pač izkorišča lokalnost podatkov pri poizvedbah, kar pomeni, da je dejansko zaželjeno, da vsaka stran vsebuje več vrstic, ne pa samo eno. Torej tudi tukaj odpade kakršno koli poravnavanje.
Skratka: morda je nekoč, nekje daleč v kakšni arheološki prazgodovini morda celo res obstajal kakšen razlog za "potenčenje", vendar pa lahko mirne duše vsaj za zadnjih 20 let rečem, da ga več ni. Če že, potem večaš polje po večkratnikih neke osnovne enote poravnave, ne pa s potenčenjem.... Če pa malo razmisliš s kakšnimi podatki se igraš (varchar) in okolje v katerem jih obdeluješ (RDBMS) pa lahko tudi pri teh pozabiš na poravnave. Preden pride podatek iz diska do pomnilnika in iz pomnilnika do CPE bo večina "blokov" na katere ima smisla poravnavati podatke postalo nerelevantnih, ker je polje večkrat preveliko.
Poravnave na meje blokov se izplačajo, kadar je govora o individualni obdelavi podatkov, ki so manjši od najmanjše fizične (ne pa tudi logične) enote obdelave na CPE ali MMU.
Prva napaka je v temu, da se za varchar velikost 2^n dejansko rezervira še dodaten pomnilnik (dva ali več zlogov - bytov), ki povedo koliko je v polju dejansko znakov + zlog za polja, ki so lahko tudi NULL. Torej je že v izhodišču tovrstna alokacija fubar.
Druga napaka je razmišljanje v potencah, namesto večkratnikih. Za CPE je naravna enota obdelave pomnilnika velikost besede. Torej 4 zloge pri 32-bitnih CPE ali pa 8 zlogov pri 64-bitnih CPE. Torej ima smisla govoriti o večkratnikih te velikosti in ne o potencah 2. Če pa vzameš za velikost bloka dejansko velikost pomnilniške besede (pri DDR je to 128 bitov oziroma 16 zlogov), pa si s tem zaključil, saj se podatke zajema in vrača v pomnilnik v tej velikosti. To pomeni, da prebrati 1 zlog ali pa prebrati 16 zlogov ne predstavlja nikakršne razlike in lahko pravilna poravnava dejansko prinese nekaj malega razlike, v primerih, kjer bi bil blok razdeljen preko meje 16 zlogov. Glede na to, da govorimo o varchar-ih, ki so praviloma večji od 16 zlogov, je to že itak game over.
Tretja napaka je to, da ljudje pozabljajo na podatkovno strukturo na diskih (ali pa niso nikoli imeli formalne izobrazbe). Glede na to, da je govora o varchar-u, je verjetno govora o RDBMS. Pri teh pa se podatki na disku rangirajo v vrstice, vrstice pa v strani. Enota pri delu z diskom pa je celotna stran in ne samo vrstica (velikost strani pa je povezana z velikostjo blokov na disku - 512 zlogov, 1024 zlogov, 2048 zlogov, ...). Čeprav velikosti strani na prvi pogled sledijo pravilu potenc, pa je nesmisel, da bi jih poskušal slediti, ker je osnoven namen obdelava v blokih (straneh), pri čemer je delo RDBMS veliko bolj optimalno, če v eni potezi iz počasnega pomnilnika potegne več vrstic, kot pa eno po eno. Tukaj se pač izkorišča lokalnost podatkov pri poizvedbah, kar pomeni, da je dejansko zaželjeno, da vsaka stran vsebuje več vrstic, ne pa samo eno. Torej tudi tukaj odpade kakršno koli poravnavanje.
Skratka: morda je nekoč, nekje daleč v kakšni arheološki prazgodovini morda celo res obstajal kakšen razlog za "potenčenje", vendar pa lahko mirne duše vsaj za zadnjih 20 let rečem, da ga več ni. Če že, potem večaš polje po večkratnikih neke osnovne enote poravnave, ne pa s potenčenjem.... Če pa malo razmisliš s kakšnimi podatki se igraš (varchar) in okolje v katerem jih obdeluješ (RDBMS) pa lahko tudi pri teh pozabiš na poravnave. Preden pride podatek iz diska do pomnilnika in iz pomnilnika do CPE bo večina "blokov" na katere ima smisla poravnavati podatke postalo nerelevantnih, ker je polje večkrat preveliko.
Poravnave na meje blokov se izplačajo, kadar je govora o individualni obdelavi podatkov, ki so manjši od najmanjše fizične (ne pa tudi logične) enote obdelave na CPE ali MMU.
JanBrezov ::
Res je, kar pravi BlueRunner (dodatno branje).
Ko se podatki berejo za procesiranje, se poleg podatka berejo še metapodatki stolpca, v primeru varchar je to še vsaj dolžina niza. Sploh pa govorimo o tipu varchar: že poanta tega tipa je, da zaseda le toliko, kolikor je potrebno - podano število določe le zgornjo mejo. V realnosti podatki nikoli ne zadanejo bloka, če že, gre verjetno za napako (načrtovali smo premalo zgornjo mejo).
Mit ovržen!
Ko se podatki berejo za procesiranje, se poleg podatka berejo še metapodatki stolpca, v primeru varchar je to še vsaj dolžina niza. Sploh pa govorimo o tipu varchar: že poanta tega tipa je, da zaseda le toliko, kolikor je potrebno - podano število določe le zgornjo mejo. V realnosti podatki nikoli ne zadanejo bloka, če že, gre verjetno za napako (načrtovali smo premalo zgornjo mejo).
Mit ovržen!
Ericssony ::
Ja potem pa v dokumentaciji naletiš na to:
ntext, text, and image data types will be removed in a future version of MicrosoftSQL Server. Avoid using these data types in new development work, and plan to modify applications that currently use them. Use nvarchar(max), varchar(max), and varbinary(max) instead.
ntext, text, and image data types will be removed in a future version of MicrosoftSQL Server. Avoid using these data types in new development work, and plan to modify applications that currently use them. Use nvarchar(max), varchar(max), and varbinary(max) instead.
technolog ::
No sej MicrosoftSQL se me ne dotakne preveč. Če bom pač prisiljen kdaj delat na njem, potem bomo pač mel varchar().
technolog ::
To seveda govorim če je polje nad recimo 500 znakov. Za kak mail še vedno uporabim VARCHAR...
Se mi zdi pa da dolžina ni preveč pomembna koliko napišeš. Naprimer razlike med 100 in 200 ni, vse deluje isto, ker za shranjevanje dolžine porabiš en byte. Pozna se pa razlika med 1023 in 1024 naprimer, en byte za dolžino več.
Če gledate pa na performance, potem pač uporabljaš CHAR in se tako izogneš fragmentaciji tabele.
Se mi zdi pa da dolžina ni preveč pomembna koliko napišeš. Naprimer razlike med 100 in 200 ni, vse deluje isto, ker za shranjevanje dolžine porabiš en byte. Pozna se pa razlika med 1023 in 1024 naprimer, en byte za dolžino več.
Če gledate pa na performance, potem pač uporabljaš CHAR in se tako izogneš fragmentaciji tabele.
BlueRunner ::
VARCHAR je pri meni passé, sedaj dam kar vedno TEXT.
Ta odločitev mora biti stvar globokega razmisleka...
Če po takšnem polju nikoli ne iščeš in njegovo vsebino le redko vlečeš do odjemalca, je to idealna rešitev. Podatek za to kje se nahaja LOB je v vrstici kratek in večino dela (recimo po pravilu 80:20) pobere samo ta podatek, ne pa celotne vsebine, ki jo smatraš za nerelevantno.
Če je kateri koli izmed zgornjih dveh pogojev kršen, potem se praviloma ustreliš v nogo. Ker se vsebina za LOB-e hrani izven vrstice, potem vsako iskanje po teh podatkih in vsak prevzem teh podatkov na odjemalca povzroči dodatne zahteve za branje iz diska iz drugih lokacij. Te dodatne zahteve za branje pa povzročijo povečanje števila IOPS-ov in dvig latence, ker so LOB-i lokacijsko neodvisni od strani, ki se jo bere in na disku tipično predaleč od obdelovane strani, da bi jih sistemski vnaprejšnje branje (readahead) ujelo.
Edini bonus je, če je polje v 80%+ dejansko NULL in s tem do dodatnih premikov glave diskov in prenosov podatkov ne pride - NULL stanje je vedno zapisano v vrstici in ne izven vrstice.
Videl sem že nekaj relacijskih baz, kjer je bil TEXT uporabljen preveč "demokratično" in je posledično trpela odzivnost celotnega sistema.
Ja potem pa v dokumentaciji naletiš na to:
ntext, text, and image data types will be removed in a future version of MicrosoftSQL Server. Avoid using these data types in new development work, and plan to modify applications that currently use them. Use nvarchar(max), varchar(max), and varbinary(max) instead.
Oh, zadeva je še malo grša. TEXT/NTEXT/IMAGE tipi se pri MSSQL hranijo izven strani, razen če je omogočena možnost hranjenja znotraj strani. N-VAR-CHAR|BINARY(max) tipi pa se hranijo znotraj vrstice, če je to možno, oziroma izven vrstice kot LOB-i, če se jih ne da stlačiti znotraj vrstice. Se pa doda možnost, da jih lahko označiš, da se izrecno hranijo izven vrstice kot LOB. Tako, da boš moral za 1:1 ekvivalent upoštevati še nekaj drugih stvari, preden boš dosegel identičen efekt.
Juck... na prvi pogled čisto dobra stvar, po drugi strani pa bo to izvor prihodnjih bolečin, kjer bodo nekatere poizvedbe hitre, nekatere pa počasne. Saj nekateri bomo vedeli kaj iskati, ne moreš pa pričakovati, da bo nekdo, ki ne pozna drobovja sistema, znal potegniti ven kalkulator in izračunati koliko je v njegovi shemi meja dolžine podatka, preden se bo ta podatek "prelil" v LOB način hranjenja. Če imaš recimo natačno aplikacijo, ki s podatki ravna odgovorno (zahteva samo tisto, kar odjemalec res potrebuje), bo prestavitev podatkov v vrstico po nepotrebnem povečala IO čase in obremenila vse poizvedbe samo zato, ker je brihtna buča pozabila omeniti, da naj se var*(max) polje hrani izven vrstice. Potem pa bo rešitev največkrat izbrana iz nabora večji al več CPE/RAM/HDD/... (XX.000 EUR) namesto popravka sheme (X00 EUR).
Jp. Težko je biti dober DBA za več kot en RDBMS in še težje je neukim pojasniti kako pomembno je natančno poznavanje sistema s katerim delaš...
Zgodovina sprememb…
- spremenilo: BlueRunner ()
krho ::
Postgresql v svojih navodilih pravi, da med varchar in text ni razlike. Med char in varchar pa je ampak samo na račun dodatnega uporabbljenega prostorqa in paddinga.
PgSQL FTW
PgSQL FTW
si.Mail odprto-kodni odjemalec elektronske pošte. - http://www.simail.si
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net
BlueRunner ::
PgSQL se obnaša tako, kot se privzeto obnašajo var*(max) pri MSSQL. Zaplet pa je to, da MSSQL var*(xxx) polj z definirano dolžino ne "prelije" po LOB načinu, ampak zateži, da je vrstica prevelika. PgSQL pa še vedno avtomatično prelije.
WarpedGone ::
Oracle tudi clobe hrani inline dokler ne presežejo 4k v "skritem" VARCHAR2 polju (če mu to dovoliš).
Po drugi strani so pa vse aplikacije, kjer je pomembno kako točno tole hraniš - FBD (Fail By Design).
Po drugi strani so pa vse aplikacije, kjer je pomembno kako točno tole hraniš - FBD (Fail By Design).
Zbogom in hvala za vse ribe
BlueRunner ::
No, še vedno ti izbiraš kje se bo kaj hranilo. Govoriti o FBD kadar je to faktor, če sam pač še nisi imel tovrstnih težav, pa je neumno. Konkreten primer: ETL aplikacija, ki jo zanima le nekaj polj v tabeli med katerimi ni LOB-ov in je razlika med hranjenjem v vrstici ali izven vrstice zaradi večjega obsega podatkov lahko tudi 15% porabljenega časa (oziroma debela ura). Tukaj je dejansko potrebno vedeti kaj se dogaja pod havbo. Če narediš kiks, ti bo ETL trejal predolgo, diski pa bodo bolj obremenjeni, kot je to res potrebno, kar v OLTP ni nepomemben faktor. Če imaš dovolj podatkov, se te zadeve še kako hitro seštejejo. Če pa je celotna baza na disku manjša od delovnega pomnilnika, pa je o resnih omejitvah itak smešno govoriti. Pa takšne obdelave sploh niso eksotika. Ko začneš šteti IOPS-e, ti bo vsaka malenkost pomagala.
No, še vedno pa lahko pokličem naročnika in sem mu opravičim, ker je aplikacija zanič in, da lahko to nemudoma popravi tako, da zapravi še nekaj denarja za dodaten strežnik + licence, da se bo na njega sprotno odlagalo transakcijske loge in bo vpliv ETL na delovanje OLTP in trajanje izvedbe samega ETL procesa skrajšano na najmanjši možen mero. Sicer je vrednost tega "doplačila" čez palec nekih 10x toliko, kolikor je znašal strošek za sprogramirati sam ETL, ampak to verjetno ni pomembno, anede?
Če že hočeš FBD, je to takrat, kadar načrt ne upošteva in ne izkorišča (ali pa se izogibam) tehničnim lastnostim izbrane tehnologije. Če tvoj problem ni vezan na IO in IOPS-e, potem lokacija hranjanja LOB-ov pač ni pomembna. Če pa je in če tega na razpoznaš, boš pa ti v FBD.
No, še vedno pa lahko pokličem naročnika in sem mu opravičim, ker je aplikacija zanič in, da lahko to nemudoma popravi tako, da zapravi še nekaj denarja za dodaten strežnik + licence, da se bo na njega sprotno odlagalo transakcijske loge in bo vpliv ETL na delovanje OLTP in trajanje izvedbe samega ETL procesa skrajšano na najmanjši možen mero. Sicer je vrednost tega "doplačila" čez palec nekih 10x toliko, kolikor je znašal strošek za sprogramirati sam ETL, ampak to verjetno ni pomembno, anede?
Če že hočeš FBD, je to takrat, kadar načrt ne upošteva in ne izkorišča (ali pa se izogibam) tehničnim lastnostim izbrane tehnologije. Če tvoj problem ni vezan na IO in IOPS-e, potem lokacija hranjanja LOB-ov pač ni pomembna. Če pa je in če tega na razpoznaš, boš pa ti v FBD.
WarpedGone ::
>> Če narediš kiks, ti bo ETL trejal predolgo, diski pa bodo bolj obremenjeni,
Katerikoli klasičen disk ima throughputa nekaj 100 IOPS.
Če ti to postane resna omejitev je to FBD, pa se skrivaj za katerokoli kratico hočeš.
Katerikoli klasičen disk ima throughputa nekaj 100 IOPS.
Če ti to postane resna omejitev je to FBD, pa se skrivaj za katerokoli kratico hočeš.
Zbogom in hvala za vse ribe
BlueRunner ::
Katerikoli klasičen disk ima throughputa nekaj 100 IOPS.
Kot prvo. Ni nekaj 100 IOPS-ov, pa če se na glavo postaviš. Sploh pa ne pri "katerem koli" klasičnem disku. Imel boš srečo, če boš iz solo mehanskega diska pri tipično obremenitvi za podatkovne baze izvlekel nad 200 IOPS za pisanje/branje. Pa še to samo zato, ker je tipičen "promet" na disku mešanica zaporednih in naključnih dostopov, kar mejo dviguje. Sicer pa je teoretičen maksimum naključnih dostopov za Savvio 15k 196 IOPS-ov. Torej nekaj 100 my ass. Če boš zaradi neznanja zaj***l tudi lokalnost podatkov, potem bo porazdelitev še bolj naključna in posledično IOPS-i še nižji, kot bi lahko bili.
Kot drugo. Ali veš kako malo je dejansko realnih 80 IOPS-ov (generičen 7200 SATA disk) za podatkovno bazo? Mislim... verjel ali ne je razlika med nekaj 10MB bazo in dvema sočasnima uporabnikoma na delovni postaji in nekaj 100GB tabelo in 50 sočasnih tekočih poizvedb na strežniku (rang baze in obrementive, ki je tudi pri nas reden pojav, da ne bom pretiraval v kakšne eksotične Google/Facebook dimenzije). Sedaj pa si računaj IOPS-e. Tisto 10MB bazo ne rabiš niti normalizirati, pa bo še vedno "letela". Uporabniki Access-a to dokazujejo vsakodnevno.
A gremo še naprej? RAID in njegov vpliv na IOPS-e? Večanje dolžine vrste in trgovanje med latenco in propustnostjo? Jp. To so "malenkosti", ki jih moraš obvladovati, če ne želiš sam postati FBS - failure by stupidity.
Če ti to postane resna omejitev je to FBD, pa se skrivaj za katerokoli kratico hočeš.
Če meniš, da so dejanske izkušnje skrivanje, potem pa tudi OK. Zgoraj si navedel smetje, ki kaže tvoje neznanje na področju problematike diskovnih podsistemov za DBMS. Imaš še kakšno na to temo ali pa boš samo ponavljal "pametno" kratico?
WarpedGone ::
V vsej svoji modrosti nisi sposoben dojet napisanga.
Reku sm "nekaj sto" ker se nočem zapletat a je to 197 al 198 ker je totalno irelevantno in za nekaj velikostnih razredov premalo, da bi to lahko bil dela kateregakoli rednega onilne procesa.
Če ti karkoli rednega in časovno občutljiva češe LOBe na tak ali drugačen način je to FBD. In je čisto vseeno a so inline, kako se prelivajo in ostalo intelektualno sranje s katerim morda celo podvojiš celotne performanse. A so še vedno nesprejemljive.
Splezaj iz svojga koščenega stolpa in začni razumet napisano.
Reku sm "nekaj sto" ker se nočem zapletat a je to 197 al 198 ker je totalno irelevantno in za nekaj velikostnih razredov premalo, da bi to lahko bil dela kateregakoli rednega onilne procesa.
Če ti karkoli rednega in časovno občutljiva češe LOBe na tak ali drugačen način je to FBD. In je čisto vseeno a so inline, kako se prelivajo in ostalo intelektualno sranje s katerim morda celo podvojiš celotne performanse. A so še vedno nesprejemljive.
Splezaj iz svojga koščenega stolpa in začni razumet napisano.
Zbogom in hvala za vse ribe
BlueRunner ::
Reku sm "nekaj sto" ker se nočem zapletat a je to 197 al 198 ker je totalno irelevantno in za nekaj velikostnih razredov premalo, da bi to lahko bil dela kateregakoli rednega onilne procesa.
Super. Ali je cca. 80, kolikor potegnejo generični 7200 diski še vedno "nekaj sto"? Sicer pa IMHO "nekaj sto" ni dve-sto in seveda premalo za delo v količkaj bolj obremenjen OLTP sistemu, kot si tudi sam ugotovil. Si jih pa sam privlekel ven, da je probem FBD, če je to premalo. Hm... ali se sedaj strinjaš, da to je premalo in, da si pač nekaj narobe zapisal, ali pa se boš še v drugo premislil in rekel, da le ni premalo in, da je znova kriv FBD?
Če ti karkoli rednega in časovno občutljiva češe LOBe na tak ali drugačen način je to FBD.
Aha. Sedaj šele razumem. Spreminjaš svojo predhodno trditev, da je FBD to, da mora aplikacija upoštevati lastnost RDBMS, da vtakne LOB v samo vrstico, v novo izjavo, da je FBD to, kar počneš s temi LOB-i.
S prvo izjavo se še vedno ne strinjam in lepo, da jo umikaš, ker je neumnost. Z novo izjavo, ki opisuje nekaj čisto drugega, pa se večinoma strinjam. Čeprav ima tudi svoje izjeme, o katerih se tebi verjetno ne sanja. Vsaj po odnosu do to problematike sodeč, je tvoja strategija reševanja RDBMS težav očitno skrita nekje med "ne da se" in "kupimo večjo gajbo". Vse ostalo pa je ...
In je čisto vseeno a so inline, kako se prelivajo in ostalo intelektualno sranje s katerim morda celo podvojiš celotne performanse.
... po tvojem mnenju očino "intelektualno sranje". No. Mislim, da pač nisi dojel, ali pa pod svojo skalo ne želiš dojeti, je to, da ti lahko baza LOB-e podtakne v vrstico, s čemer postanejo predmet branja, povečajo obremenitev IOPS-ov in znižajo propustnost tudi v primeru, da se tega po tvoje imenovanega "inline" LOB-a sploh ne dotakneš. Oracle že ve zakaj je privzeta vrednost takšna, kot je, PgSQL tukaj nekaj manevrira, MSSQL pa spreminja paradigmo iz Oraclove v PgSQL.
Če izkušnje, ki pridejo s konkretno kilometrino in jih ne moreš pobrati kar tako in kjerkoli že, šteješ za "intelektualno sranje", je to tvoj problem. Kot sem že zgoraj napisal. Sem srečal že kar nekaj "mojstrov", ki so jim takšne izkušnje nekoliko srmdele, pa so bili na koncu še vedno čisto dobre volje, da so se na praktičnem primeru naučili to, kar sem se jaz naučil pred njimi... niso to neke velike skrivnosti, jim pa na žalost t.i. "mojstri" ne dajejo velike teže, dokler ne trčijo ob steno in je problem pač potrebno podrobno proučiti.
Hmm... tudi sam delam napake. Zadnja cvetka je bila posledica mojega nepoznavanja razlik v delovanju različnih datotečnih sistemov. Po nekaj brskanja po "intelektualnem sranju" sem uspel propustnost zadevnega RDBMS zvišati iz povprečja 100 operacij/s na povprečje 400 operacij/s brez spremembe strojne ali programske opreme. Yay! Še več takšnega "intelektualnega sranja" prosim, če se le da! Morda pa imaš čudne občutke glede višine svoje plače tudi zaradi odnosa do "intelektualnega sranja" in ne samo zaradi pomankanja takta.
Splezaj iz svojga koščenega stolpa in začni razumet napisano.
Splezaj izpod svoje skale in sprevidi, da je svet večji, kot ga ta trenutek vidiš okoli sebe. Kar se tiče razumevanja, pa vse lepo in prav. Samo vmes ne spreminjaj vsebine izjav.
Zgodovina sprememb…
- spremenilo: BlueRunner ()
WarpedGone ::
Še vedno ne znaš brat?
>> Mislim, da pač nisi dojel, ali pa pod svojo skalo ne želiš dojeti, je to, da ti lahko baza LOB-e podtakne v vrstico, s čemer postanejo predmet branja, povečajo obremenitev IOPS-ov in znižajo propustnost tudi v primeru, da se tega po tvoje imenovanega "inline" LOB-a sploh ne dotakneš.
In kaj potem počnejo tam? CLOBe vlečt zraven ko maš zahtevo visoke prepustnosti je ta FBD, katerega se očitno zelo sramuješ, da se tako vpletaš vanj in vlečeš ven cifre, kaj vse da so sposobni posamezni HDDji kar je totalno irelevantno za sam problem. Slama kar leti iz slamnatih mož...
Skratka: Če nek problem rešuješ tako, da se ti CLOBi motajo med nogami si falil zasnovo. Slaba vest?
>> Po nekaj brskanja po "intelektualnem sranju" sem uspel propustnost zadevnega RDBMS zvišati iz povprečja 100 operacij/s na povprečje 400 operacij/s brez spremembe strojne ali programske opreme.
Lipstick on a pig.
>>Yay! Še več takšnega "intelektualnega sranja" prosim, če se le da!
Jaz bi prosil manj intelektualnega sranja pri izvedbi in več pri zasnovi komplet sistema.
Dober sistem ima kvaliteto/performanse inherentne sami zasnovi in NISO posledica junaštva posameznih bluerunnerjev.
>> Samo vmes ne spreminjaj vsebine izjav.
Kaj? Boš lepo pokazal, katero izjavo sem spremenil al pa te bom mogu prestavit iz ranga relevantnih sogovornikov med občasne bluzatorje. "Oprosti".
>> Mislim, da pač nisi dojel, ali pa pod svojo skalo ne želiš dojeti, je to, da ti lahko baza LOB-e podtakne v vrstico, s čemer postanejo predmet branja, povečajo obremenitev IOPS-ov in znižajo propustnost tudi v primeru, da se tega po tvoje imenovanega "inline" LOB-a sploh ne dotakneš.
In kaj potem počnejo tam? CLOBe vlečt zraven ko maš zahtevo visoke prepustnosti je ta FBD, katerega se očitno zelo sramuješ, da se tako vpletaš vanj in vlečeš ven cifre, kaj vse da so sposobni posamezni HDDji kar je totalno irelevantno za sam problem. Slama kar leti iz slamnatih mož...
Skratka: Če nek problem rešuješ tako, da se ti CLOBi motajo med nogami si falil zasnovo. Slaba vest?
>> Po nekaj brskanja po "intelektualnem sranju" sem uspel propustnost zadevnega RDBMS zvišati iz povprečja 100 operacij/s na povprečje 400 operacij/s brez spremembe strojne ali programske opreme.
Lipstick on a pig.
>>Yay! Še več takšnega "intelektualnega sranja" prosim, če se le da!
Jaz bi prosil manj intelektualnega sranja pri izvedbi in več pri zasnovi komplet sistema.
Dober sistem ima kvaliteto/performanse inherentne sami zasnovi in NISO posledica junaštva posameznih bluerunnerjev.
>> Samo vmes ne spreminjaj vsebine izjav.
Kaj? Boš lepo pokazal, katero izjavo sem spremenil al pa te bom mogu prestavit iz ranga relevantnih sogovornikov med občasne bluzatorje. "Oprosti".
Zbogom in hvala za vse ribe
Jst ::
Nisem bral vseh komentarjev, ker ko sem naletel na BlueRunerjevega posta, sem vse preskočil, ker je zajel bistvo.
Bi pa rad pripomnil še nekaj.
Ko se odločite, katero bazo boste uporabljali in si narišete tabele in relacije med njimi, je OBVEZNO prebrati še help/guidline/optimizing database, kjer so opisani vsi triki za čimbolj optimalno delovanje ter vse stravi, katerih se je dobro ogniti, če le lahko.
Tako ti bo baza delala zelo dobro, potem ko pa imaš enkrat testno bazo z veliko podatkov, imaš pa orodja, kjer vidiš, kaj se da še narediti oz. kje imaš bottleneck.
Bi pa rad pripomnil še nekaj.
Ko se odločite, katero bazo boste uporabljali in si narišete tabele in relacije med njimi, je OBVEZNO prebrati še help/guidline/optimizing database, kjer so opisani vsi triki za čimbolj optimalno delovanje ter vse stravi, katerih se je dobro ogniti, če le lahko.
Tako ti bo baza delala zelo dobro, potem ko pa imaš enkrat testno bazo z veliko podatkov, imaš pa orodja, kjer vidiš, kaj se da še narediti oz. kje imaš bottleneck.
Islam is not about "I'm right, you're wrong," but "I'm right, you're dead!"
-Wole Soyinka, Literature Nobelist
|-|-|-|-|Proton decay is a tax on existence.|-|-|-|-|
-Wole Soyinka, Literature Nobelist
|-|-|-|-|Proton decay is a tax on existence.|-|-|-|-|
BlueRunner ::
WarpedGone je izjavil:
>> Samo vmes ne spreminjaj vsebine izjav.
Kaj? Boš lepo pokazal, katero izjavo sem spremenil al pa te bom mogu prestavit iz ranga relevantnih sogovornikov med občasne bluzatorje. "Oprosti".
WarpedGone je izjavil:
Oracle tudi clobe hrani inline dokler ne presežejo 4k v "skritem" VARCHAR2 polju (če mu to dovoliš).
Po drugi strani so pa vse aplikacije, kjer je pomembno kako točno tole hraniš - FBD (Fail By Design).
WarpedGone je izjavil:
Če ti karkoli rednega in časovno občutljiva češe LOBe na tak ali drugačen način je to FBD.
Prva izjava pravi, da so FBD "vse aplikacije, kjer je pomembno kako se LOB-e hrani". Druga izjava pravi, da je FBD "vse kar redno in časovno občutljivo" češe LOB-e.
Morda sem blesav, vendar pa to ni eno in isto. Lahko pa me razsvetliš in poveš kako ti ne bluziš.
WarpedGone je izjavil:
>> Mislim, da pač nisi dojel, ali pa pod svojo skalo ne želiš dojeti, je to, da ti lahko baza LOB-e podtakne v vrstico, s čemer postanejo predmet branja, povečajo obremenitev IOPS-ov in znižajo propustnost tudi v primeru, da se tega po tvoje imenovanega "inline" LOB-a sploh ne dotakneš.
In kaj potem počnejo tam? CLOBe vlečt zraven ko maš zahtevo visoke prepustnosti je ta FBD, katerega se očitno zelo sramuješ, da se tako vpletaš vanj in vlečeš ven cifre, kaj vse da so sposobni posamezni HDDji kar je totalno irelevantno za sam problem. Slama kar leti iz slamnatih mož...
Jp. Res je. Nisi dojel od kje LOB-i "pridejo tam notri".
HDD-je si ti sam prvi prvlekel ven in jih napadel, pa še ta slamnat mož je bil malo pokvečen, ker ne zdrži kritičnega pogleda. Jp. Slama kar leti iz slamnatih mož. Še posebej tistih, ki jih ti postavljaš in ne služijo ničemer.
WarpedGone je izjavil:
Skratka: Če nek problem rešuješ tako, da se ti CLOBi motajo med nogami si falil zasnovo. Slaba vest?
Si prebral kdaj in kako ti pridejo pod noge? Očitno ne.
WarpedGone je izjavil:
>>Yay! Še več takšnega "intelektualnega sranja" prosim, če se le da!
Jaz bi prosil manj intelektualnega sranja pri izvedbi in več pri zasnovi komplet sistema.
Dober sistem ima kvaliteto/performanse inherentne sami zasnovi in NISO posledica junaštva posameznih bluerunnerjev.
Joj kriza. Res, da nisem omenjal, da je bila baza načrtovana l. 2003 za pričakovano povečanje dela za 5 let (2 leti je tako ali tako delala na "sposojenem času"). "Junaštvo", če že hočeš bluziti, pa je bilo sestavljeno iz tega, da sem se vrnil nazaj k osnovam in "na terenu" preveril kje je ozko grlo. Bravo jaz, da je bila ZASNOVA dovolj dobra, da sem življenjsko dobo aplikacije podaljšal še za ocenjena tri leta. Zaradi dobre zasnove in ne junaštva. Sicer, pa upam, da veš kaj je to Demingov cikel in v kakšni obliki se pojavlja v sveti računalništva. No, jaz sem naredil cikel check, act, ki sta mu ponovno sledila plan in do fazi. Pa me tega ni niti najmanj sram.
Seveda pa je tebi v celoti pobegnila ilustracija tega, da je vsakdo zmotljiv in, da se lahko resnične napake v resničnem življenju odpravlja tudi z "intelektualnim sranjem". Še več: tukaj in sedaj trdim, da brez t.i. "intelektualnega sranja" svojega dela kot strokovnjak sploh ne moreš strokovno opraviti.
Sam lahko po tej izmenjavi dodam še, da so to zate pač "pearls before swine". Spreminjanje osnovne izjave, čemur sledi še to, da sam notri privlečeš HDD-je, doživiš njihovo cefranje nato pa meni praviš, da postavljam slamnate može, ... Morda dodaš še kaj na temo?
WarpedGone ::
Le to, da še vedno ne znaš brat.
Edit, za druge:
Hočeš dokaz? HDD sm privlekel not, ker ko so v igri LOBi v svojem osnovnem namenu obstoja (veliko vsebine), maš hudo veliko šanso da tega ne bo v cachu (če nek določen RDMS sploh to kešira) in sekaš po diskih. Ven sm privleku napihnjeno zgornjo mejo IOPSov HDD za ilustracijo, kako je to omejujoč dejavnik, kateremu se moraš izogibat kot hudič križa, če in kjer se le da tut v najbolšem sploh primeru ko maš superduper diskovje s 500 IOPS. Ti pa si ves penast planil v to zgornjo mejo in hitel dokazovat kako da so realne cifre pol nižje.
Halo? Cefranje ja. Total miss of a point.
Sej neki obvladaš, ampak tale tvoj ponos te Hebe big time. 2 leti praviš da so se LOBi čist neopazno motali med nogami "časovno občutljivih" zadev, pol je pa zaradi povečanja obsega to postalo problem?
Ne kupim. To je bil problem že od samega začetka, le da se ni nihče prtožu dokler vse skupaj ni šlo na dno morja, ko je začela goret rdeča luč in tulit sirena. Morda si na koncu izpadu junak, ampak js se s takimi junaštvi nebi glih hvalu.
Glede spreminjanja izjav:
Jaz prvič:
>> Po drugi strani so pa vse aplikacije, kjer je pomembno kako točno tole hraniš - FBD (Fail By Design).
Branje LOBa ne sme bit na "kritični poti" (da bi se način kako je ta shranjen pomembno odrazil). V teh obdelavah morš met vse kar nucaš za redno procesiranje v "stabilnih" tipih, v gostih tabelah minimalno nujno poindexirano. Ne vem s katero bazo delaš, da ti clobi v tabeli redčijo podatke, v oraclu je lob lokator 4 byte dolg podatek. Nič posebnega. Kritični podatki se naj berejo iz hitrih zadev, ne pa iz LOBov.
Jaz drugič:
>> Če ti karkoli rednega in časovno občutljiva češe LOBe na tak ali drugačen način je to FBD.
Isto povedano z drugimi besedami.
Al boš pa podal primer, kjer je maš časovno kritično zadevo in je blo nujno ponucat LOBe in isto ni bilo možno dosečt brez njih.
Će baza neki omogoča, še ne pomeni, da je res nujno in pametno tist tut uporabljat.
Edit, za druge:
Hočeš dokaz? HDD sm privlekel not, ker ko so v igri LOBi v svojem osnovnem namenu obstoja (veliko vsebine), maš hudo veliko šanso da tega ne bo v cachu (če nek določen RDMS sploh to kešira) in sekaš po diskih. Ven sm privleku napihnjeno zgornjo mejo IOPSov HDD za ilustracijo, kako je to omejujoč dejavnik, kateremu se moraš izogibat kot hudič križa, če in kjer se le da tut v najbolšem sploh primeru ko maš superduper diskovje s 500 IOPS. Ti pa si ves penast planil v to zgornjo mejo in hitel dokazovat kako da so realne cifre pol nižje.
Halo? Cefranje ja. Total miss of a point.
Sej neki obvladaš, ampak tale tvoj ponos te Hebe big time. 2 leti praviš da so se LOBi čist neopazno motali med nogami "časovno občutljivih" zadev, pol je pa zaradi povečanja obsega to postalo problem?
Ne kupim. To je bil problem že od samega začetka, le da se ni nihče prtožu dokler vse skupaj ni šlo na dno morja, ko je začela goret rdeča luč in tulit sirena. Morda si na koncu izpadu junak, ampak js se s takimi junaštvi nebi glih hvalu.
Glede spreminjanja izjav:
Jaz prvič:
>> Po drugi strani so pa vse aplikacije, kjer je pomembno kako točno tole hraniš - FBD (Fail By Design).
Branje LOBa ne sme bit na "kritični poti" (da bi se način kako je ta shranjen pomembno odrazil). V teh obdelavah morš met vse kar nucaš za redno procesiranje v "stabilnih" tipih, v gostih tabelah minimalno nujno poindexirano. Ne vem s katero bazo delaš, da ti clobi v tabeli redčijo podatke, v oraclu je lob lokator 4 byte dolg podatek. Nič posebnega. Kritični podatki se naj berejo iz hitrih zadev, ne pa iz LOBov.
Jaz drugič:
>> Če ti karkoli rednega in časovno občutljiva češe LOBe na tak ali drugačen način je to FBD.
Isto povedano z drugimi besedami.
Al boš pa podal primer, kjer je maš časovno kritično zadevo in je blo nujno ponucat LOBe in isto ni bilo možno dosečt brez njih.
Će baza neki omogoča, še ne pomeni, da je res nujno in pametno tist tut uporabljat.
Zbogom in hvala za vse ribe
Zgodovina sprememb…
- spremenilo: WarpedGone ()
BlueRunner ::
Eh, brez veze. To je postal mudslinging bath, kjer več ni govora o optimiziranju RDBMS-jev ampak samo še prerekanje kdo je kaj napisal. Odneham, ker nima smisla.
Hvala enako.
Napisal si dobesedno: "Katerikoli klasičen disk ima throughputa nekaj 100 IOPS. Če ti to postane resna omejitev je to FBD" Morda sem res ne znam brati, vendar se to bere, kakor, da IOPS-i niso problem, ne pa kot, da so ena izmed bistvenih omejitev. V najboljšem je dvoumno kaj si želel povedati. Bo pa verjetno še kdo drug lahko kaj povedal na temo kako se tvoj stavek pravilno prebere.
LOB-i niso del tega primera in ne vem zakaj vpeljuješ novega slamnatega moža. Poanta, ki so ji zgrešil dvakrat zaporedoma, je, da se moraš poglobiti tudi v malo bolj obskurne in na prvi pogled nepovezane stvari, če želiš biti vsaj približno učinkovit. Pa mi sedaj najdi kogarkoli normalnega na svetu, ki si ne želi, da bi dobil več (učinka) za manj (denarja).
Preberi si malo o katerih vse bazah smo se že pogovarjali in kako se katere obnašajo z LOB-i (pa ne samo character, tudi binary LOB-i so v igri). Če še vedno nisi groknil, potem si tudi ti kriv površnega branja.
Če ne spremljaš teme ali pa ne znaš brati, potem lahko res prijaviš takšno neumnost.
Sem ga podal. Če ga ti nisi sposoben perbrati in dojeti kje se pojavi težava, potem ti ne morem pomagati.
Se strinjam. Sedaj pa pojdi nazaj in za božjo voljo preberi o čemu je tekla beseda, ko si uletel s svojo neumnostjo FBD-ja.
Če mora kdo od kje splezati, bi moral ti splezati izpod skale.
Najboljša cvetka, kar si jih zapisal, je pa tale: "In je čisto vseeno a so inline, kako se prelivajo in ostalo intelektualno sranje s katerim morda celo podvojiš celotne performanse". Če mene "hebe" ponos, tebe izgleda "hebe" še nekaj drugega, mnogo pomembnejšega.
Le to, da še vedno ne znaš brat.
Ven sm privleku napihnjeno zgornjo mejo IOPSov HDD za ilustracijo, kako je to omejujoč dejavnik, kateremu se moraš izogibat kot hudič križa
Sej neki obvladaš, ampak tale tvoj ponos te Hebe big time. 2 leti praviš da so se LOBi čist neopazno motali med nogami "časovno občutljivih" zadev, pol je pa zaradi povečanja obsega to postalo problem?
Ne vem s katero bazo delaš, da ti clobi v tabeli redčijo podatke, v oraclu je lob lokator 4 byte dolg podatek. Nič posebnega. Kritični podatki se naj berejo iz hitrih zadev, ne pa iz LOBov.
Jaz drugič:
>>> Če ti karkoli rednega in časovno občutljiva češe LOBe na tak ali drugačen način je to FBD.
Isto povedano z drugimi besedami.
Al boš pa podal primer, kjer je maš časovno kritično zadevo in je blo nujno ponucat LOBe in isto ni bilo možno dosečt brez njih.
Će baza neki omogoča, še ne pomeni, da je res nujno in pametno tist tut uporabljat.
Če mora kdo od kje splezati, bi moral ti splezati izpod skale.
Najboljša cvetka, kar si jih zapisal, je pa tale: "In je čisto vseeno a so inline, kako se prelivajo in ostalo intelektualno sranje s katerim morda celo podvojiš celotne performanse". Če mene "hebe" ponos, tebe izgleda "hebe" še nekaj drugega, mnogo pomembnejšega.
Zgodovina sprememb…
- spremenilo: BlueRunner ()
BlueRunner ::
WarpedGone je izjavil:
Zakaj je skoraj vcel tvoj post prečrtan?
Sem na vrhu napisal: "Eh, brez veze. To je postal mudslinging bath, kjer več ni govora o optimiziranju RDBMS-jev ampak samo še prerekanje kdo je kaj napisal. Odneham, ker nima smisla."
Zadnjih X postov se dajeva kdo je kaj napisal. B.v. IOPS-i diskov so še nekako relevanten podatek, ki ima nekaj zveze s temo (ne glede na najino skupno nepismenost), ostalo pa je že res čisto mimo. Naknadno pa sem vse prečrtal, ker nisem vedel, če je to že kdo vmes prebral ali ne. Pa da ne bi bilo potem komenatarjev v stilu, da se vadim vem.
Mimogrede na temo IOPS-ov: "magične" številke, ki dobro držijo so za 7200 cca 80; za 10k cca 120 in za 15k cca 180. Kako je s SSD-ji pa naj pove nekdo, ki ima izkušnje. RAID polja se za potrebe branja seštevajo (2x RAID0 s 7200 == cca. 160 IOPs za branje). Za potrebe pisanja pa se delijo glede na tip RAID-a, ker je potreben zapis na več diskov hkrati. RAID5 je dobra izbira za baze, kjer je veliko branja in malo pisanja ter slaba izbira za baze, kjer je veliko pisanja. Običajno bodo IOPS-i najpogostejša omejitev relevantna za design baze in se je vsaj o njih dobro izobraziti.
Če slučajno še kdo uporablja ext3 format particij za podatkovne baze, naj se jih čim prej znebi oziroma prilagodi particije tako, da si ne bo nevede ubijal performance (kot se je dogajalo moji bazi).
Zgodovina sprememb…
- spremenilo: BlueRunner ()
Jst ::
Jaz sploh ne razumem, zakaj sta se skregala, ker je očitno, da smo tu udeleženi vsaj trije programerji, ki nam je ponagajala baza in potem ko smo ugotovili kaj je narobe, je bil to ponavadi kakšen robni primer. Recimo nekaj let nazaj na PervasiveSQL sem opazil, da si je bolje/hitreje podatke iz različnih tabel sfiltrirati na serverju, prenesti na klienta v .xml (to sem uporabil jaz) in tam izvajati mahinacije, kot pa uporabiti "v teoriji hitejši SQL stavek" za vrnjene podatke, kot je v večini primerov v tisti bazi/aplikaciji.
Enako ima PervasiveSQL quirke z procedureami na server strani in indexi čudne lastnosti, ki se pojavijo takorekoč iz danes na jutri. Pač moral sem delati s to bazo, ki jo sovražim, ker je tech support kretenski in niti Baza sama ni nek biser ampak za tist denar ne moreš pričakovati kaj boljšega. Upam da se nikoli več ne bom rabil za**bavati z Pervasive!
Drugače se pa lahko vsi skregamo o kakšnih robnih pogojih različnih baz/konfiguracij, uporabljamo kratice, ki jih razumemo samo mi in si večamo muda in tolčemo po prsih.
Enako ima PervasiveSQL quirke z procedureami na server strani in indexi čudne lastnosti, ki se pojavijo takorekoč iz danes na jutri. Pač moral sem delati s to bazo, ki jo sovražim, ker je tech support kretenski in niti Baza sama ni nek biser ampak za tist denar ne moreš pričakovati kaj boljšega. Upam da se nikoli več ne bom rabil za**bavati z Pervasive!
Drugače se pa lahko vsi skregamo o kakšnih robnih pogojih različnih baz/konfiguracij, uporabljamo kratice, ki jih razumemo samo mi in si večamo muda in tolčemo po prsih.
Islam is not about "I'm right, you're wrong," but "I'm right, you're dead!"
-Wole Soyinka, Literature Nobelist
|-|-|-|-|Proton decay is a tax on existence.|-|-|-|-|
-Wole Soyinka, Literature Nobelist
|-|-|-|-|Proton decay is a tax on existence.|-|-|-|-|
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | SSD v strežnikih (strani: 1 2 )Oddelek: Strojna oprema | 8529 (6292) | tiborrr |
| » | Samsung prvi s kartico UFSOddelek: Novice / Ostale najave | 8164 (6531) | MrStein |
| » | SSD vs. mehanicni trdi diskOddelek: Strojna oprema | 1648 (1105) | b3D_950 |
| » | Real-time databaseOddelek: Programska oprema | 1566 (1083) | kunigunda |
| » | Znane podrobnosti o tretji generaciji Intelovih SSD-jevOddelek: Novice / Diski | 9085 (8151) | Icematxyz |