Kompresija podataka na SSD-u

[Quantum]

Izgleda da pametni Microsoftov SQL Server 2010 (!) bas i ne voli kada se pokusava kreirati nova baza na komprimiranoj particiji; posto vec duze vremena na razvojnom racunalu imam komprimirani SSD, dok nisam iskljucio kompresiju na folderu sa datafileovima, SQL je odbijao suradnju, tako da bi mozda bilo zgodno ukljuciti nekakav disclaimer - ukljucenjem kompresije, za ocekivati je da ce neke aplikacije imati problema.

Zanimljivo (ali ne i neocekivano) je da se to desilo upravo Microsoftu na vlastitom OS-u i vlastitom FS-u.

Bravo, MS.

[antrax]

Naravno da su zbog kompresije moguci problemi, iako bi trebalo bit transparentno. No bez testiranja tesko je reci sta raid, sta ne radi sve. S druge strane, pa tko jos koristi mssql!? :P (mala sala)

[Quantum]

Autor antrax

S druge strane, pa tko jos koristi mssql!? :P (mala sala)

Pa samo luzeri Iako, pravi plac i skrgut zubi pocinje kad te prisile da koristis DB2.

Da se mene pita, ja bih koristio NoSQL/Cassandru ili, u najgorem slucaju Oracle, ali - tko pita nas, imžinjere?

[antrax]

ma tko te pita danas ista vise... nedavno smo morali slagat neki windows server na izricit zahtjev jednog klijenta, pa smo se svadali tko ce to radit jer nitko iz principa nije htio popustit i preuzet odgovornost odrzavanja. Na kraju dopalo drugi odjel u kojem se srecom nasao netko s dovoljno labilnim karakterom

Al to je tako. Moras nekad nesto i gotovo.

No, dosta OT rekao bih :cheers:

[Old Iggy]

Autor Quantum

Jedan mali dodatak koji se tice kompresije - izgleda da pametni Microsoftov SQL Server 2010 (!) bas i ne voli kada se pokusava kreirati nova baza na komprimiranoj particiji; posto vec duze vremena na razvojnom racunalu imam komprimirani SSD, dok nisam iskljucio kompresiju na folderu sa datafileovima, SQL je odbijao suradnju, tako da bi mozda bilo zgodno ukljuciti nekakav disclaimer - ukljucenjem kompresije, za ocekivati je da ce neke aplikacije imati problema.

Zanimljivo (ali ne i neocekivano) je da se to desilo upravo Microsoftu na vlastitom OS-u i vlastitom FS-u.

Bravo, MS.

Pa, realno, bravo za njih jer je najgluplja moguća stvar stavljati baze na kompresirani prostor. Kako se od baza traži veliki IOPS, to radi enormne probleme i performanse padaju drastično.

[antrax]

pa jasno iggy, ali nekako ovo smrdi na testnu lokalnu bazu za developera, a ne za deploy. Pa tko bi u kriticnom okruzenju drzao kompresiju ukljucenu, kapacitet je nesto jeftiniji ipak sam po sebi

[Old Iggy]

Autor antrax

pa jasno iggy, ali nekako ovo smrdi na testnu lokalnu bazu za developera, a ne za deploy. Pa tko bi u kriticnom okruzenju drzao kompresiju ukljucenu, kapacitet je nesto jeftiniji ipak sam po sebi

Developer koji nema mjesta nego komprimira particije?

Same baze jako "usko" surađuju s diskom i normalno je da ne žele tako raditi. A sumnjam da ima opcija pri instalaciji "for developer only".

[antrax]

da, ne bi vjerovao, ali to je realnost nasih programera. Ja sam s mojim 128GB diskom sretan k'o mali crvic, o 256gb nisam mogao ni sanjat, vec ovaj kostao ko 1/3 racunala koje se odobrava.. I to sam se morao izborit da si sam nabavljam jer bi mi firma uvalila v100 inace, a u tom slucaju mogu i mehanicki disk koristit skoro.

nema opcije, hehe, al pristupa bazi ima jako malo, pa bilo koji disk i procesor izlaze na kraj s tolikim opterecenjem. Ionako razvojni/testni set podataka u te svrhe nikad nije bas narocito ogroman.

Zavisi o tome sta se razvija, jasno. plus, cijena dedicated DB servera za vise od par programera je zanemariva, pa cemu drzat svako na svom racunalu i baktat se sa svime ako moze bit centralizirano, sto danas nije nikakav problem.

treba nam tema za spam

[Old Iggy]

Autor antrax

da, ne bi vjerovao, ali to je realnost nasih programera. Ja sam s mojim 128GB diskom sretan k'o mali crvic, o 256gb nisam mogao ni sanjat, vec ovaj kostao ko 1/3 racunala koje se odobrava.. I to sam se morao izborit da si sam nabavljam jer bi mi firma uvalila v100 inace, a u tom slucaju mogu i mehanicki disk koristit skoro.

nema opcije, hehe, al pristupa bazi ima jako malo, pa bilo koji disk i procesor izlaze na kraj s tolikim opterecenjem. Ionako razvojni/testni set podataka u te svrhe nikad nije bas narocito ogroman.

Zavisi o tome sta se razvija, jasno. plus, cijena dedicated DB servera za vise od par programera je zanemariva, pa cemu drzat svako na svom racunalu i baktat se sa svime ako moze bit centralizirano, sto danas nije nikakav problem.

treba nam tema za spam

Realno, iz iskustva, svakom developeru treba običan, nikakav SSD disk. Nauče se pa rade sr***a.

A ovo sa serverom je standard. par virtualki i peri miško.

[Quantum]

Autor Old Iggy

Pa, realno, bravo za njih jer je najgluplja moguća stvar stavljati baze na kompresirani prostor. Kako se od baza traži veliki IOPS, to radi enormne probleme i performanse padaju drastično.

Autor Old Iggy

Developer koji nema mjesta nego komprimira particije?

Same baze jako "usko" surađuju s diskom i normalno je da ne žele tako raditi. A sumnjam da ima opcija pri instalaciji "for developer only".

Ne govorimo o produkcijskoj, vec o razvojnoj, lokalnoj bazi.

Od softvera koji kosta tolike novce, minimum koji ocekujem je smislena poruka o gresci (ako je vec graceful degradation previse za ocekivati), a ne kripticni pop-up o nemogucnosti kreiranja datafileova.

Ne vidim sto te cudi u tome da si moramo komprimirati particije? Radimo u Hrvatskoj....

Autor Old Iggy

Realno, iz iskustva, svakom developeru treba običan, nikakav SSD disk. Nauče se pa rade sr***a.

A ovo sa serverom je standard. par virtualki i peri miško.

Ne znam o kakvom iskustvu govorimo, ali proslo je doba razvoja web-stranica u Notepadu ili kubne jednadzbe iz Turbo Pascala. Danasnji razvojni alati (barem ako govorimo Java enterprise razvoju) su prilicno ogromni, tehnologija vrlo zahtjevna, a vec i prilicno jednostavne aplikacije zahtjevaju prilicno resursa, osobito ako su deployane na enterprise web-servere.

SSD je objektivni minimum i nuznost za svaki developerski stroj, jer direktno i vrlo osjetno utjece na produktivnost. Jak CPU/GPU i ne toliko (ovisno o problemskoj domeni), ali SSD i barem 4 GB RAM-a su minimum minimuma za normalan i ugodan rad.

Nazalost, svijest o tome (kao i poslovicna skrtost i neobrazovanost HR poslodavaca) daleko je od toga da se to shvati - jos se stavljaju 32-bitni Windowsi sa 5400 RPM diskovima na koje se nakrka baza, aplikacijski server i razvojni alat, pa se cudom cude kad im za hot-redeploy/publish jedne klase treba po 5 minuta. Tako se softver ne razvija, vec se samo nabijaju troskovi i raste nezadovoljstvo klijenta.


Da barem malo budem on-topic: Antrax, masivno hvala za ovaj tutorial - da ima negdje rep increase, sad bih to stisnuo

[Old Iggy]

Autor Quantum

Ne govorimo o produkcijskoj, vec o razvojnoj, lokalnoj bazi.

Od softvera koji kosta tolike novce, minimum koji ocekujem je smislena poruka o gresci (ako je vec graceful degradation previse za ocekivati), a ne kripticni pop-up o nemogucnosti kreiranja datafileova.

Ne vidim sto te cudi u tome da si moramo komprimirati particije? Radimo u Hrvatskoj....

Upravo zato što je i razvojno i Hrvatska, niti treba SSD niti petljanje s kompresijom. Za razvoj je dosta 7200 disk, za test mala okolina virtualki, ako baš netko želi SSD najmanji problem za nabaviti mali disk za test. No očekivati da baza po defaultu radi na komprimiranom disku je smiješno za očekivati, čak i od developera.

Autor Quantum

Ne znam o kakvom iskustvu govorimo, ali proslo je doba razvoja web-stranica u Notepadu ili kubne jednadzbe iz Turbo Pascala. Danasnji razvojni alati (barem ako govorimo Java enterprise razvoju) su prilicno ogromni, tehnologija vrlo zahtjevna, a vec i prilicno jednostavne aplikacije zahtjevaju prilicno resursa, osobito ako su deployane na enterprise web-servere.

SSD je objektivni minimum i nuznost za svaki developerski stroj, jer direktno i vrlo osjetno utjece na produktivnost. Jak CPU/GPU i ne toliko (ovisno o problemskoj domeni), ali SSD i barem 4 GB RAM-a su minimum minimuma za normalan i ugodan rad.

Nemojmo biti smiješni. Malo bi se SSD, malo kompresija. SSD nije standard ni u "enterprise" okolini u RH, a s druge strane postao je enormno jeftin i nikakav problem za nabavu bilo kakvom developeru, tj. njegovoj firmi.

Autor Quantum

Nazalost, svijest o tome (kao i poslovicna skrtost i neobrazovanost HR poslodavaca) daleko je od toga da se to shvati - jos se stavljaju 32-bitni Windowsi sa 5400 RPM diskovima na koje se nakrka baza, aplikacijski server i razvojni alat, pa se cudom cude kad im za hot-redeploy/publish jedne klase treba po 5 minuta. Tako se softver ne razvija, vec se samo nabijaju troskovi i raste nezadovoljstvo klijenta.

Ali developer možda shvati kako SW radi u praksi.
Nego, tko ima toliko licenci da sve to trpa svakom developeru na stroj?

[Quantum]

Autor Old Iggy

Upravo zato što je i razvojno i Hrvatska, niti treba SSD niti petljanje s kompresijom. Za razvoj je dosta 7200 disk, za test mala okolina virtualki, ako baš netko želi SSD najmanji problem za nabaviti mali disk za test. No očekivati da baza po defaultu radi na komprimiranom disku je smiješno za očekivati, čak i od developera.

To je ocjena iz iskustva ili procjenom palac x pi? Sto to uopce znaci "dosta"? Ako je "dosta" ekvivalent sa "moze raditi", onda je "dosta" i 4200 RPM disk sa 2 GB RAM-a, jedino sto ce koristan rad (gdje "koristan rad" definiramo kao "pisanje testable koda relevantnog za klijenta koji placa nas rad") teziti u nulu.

Aritmetika je prilicno trivijalna - (vrlo okvirni izracun) ako disk kosta 500 kn, a inzenjerski sat kosta 200 kn i ja SSD-om ustedim mjesecno 5 sati koje umjesto na cekanje potrosim na pisanje koda, onda ja taj disk isplatim po workstationu za 15 radnih dana, a ostalo je usteda. Ne govorimo ovdje o kupnji SSD-mrcina od 512 GB, vec o nabavci 64-128 GB modela - Intel G2 generacije? Zasto ne, sasvim je nebitno.

Sto se tice baze, nije sporno da je bad practice stavljanje baze na komprimiranju particiju, ali ipak, nekakav ocekivani minimum je koliko-toliko smislena poruka o gresci (sto, admittedly, pocinje biti sve veci luksuz, barem kad se govori o Microsoft softveru ili, nedajbog, IBM-u). Najzad, ono sto je smijesno je ocekivati od developera da se brine za bazu, pa cak i od administratora.

Nemojmo biti smiješni. Malo bi se SSD, malo kompresija. SSD nije standard ni u "enterprise" okolini u RH, a s druge strane postao je enormno jeftin i nikakav problem za nabavu bilo kakvom developeru, tj. njegovoj firmi.

Nema govora o humoru - stvar je prilicno ozbiljna, jer se radi o vremenu, tj. novcu (sto sam argumentirao iznad). Kompresija je u sprezi sa non-SF SSD-om odlicna stvar, a cinjenica da (jos) nije standard u enterprise okolini u RH nije relevantan argument za nasu diskusiju - razlozi neprihvacanja u enterprise okolini (iz mog iskustva) rangiraju od predrasuda o nepouzdanosti, preko ogranicenog budzeta do ocitog neznanja, inertnosti pa, rekao bih i autizma. Ovdje, medjutim, govorimo o razvojnom okruzenju, gdje se slazemo da je SSD postao vrlo jeftin i, u krajnjoj liniji, dovoljno pouzdan, pa je razlog za otpor prema istima - meni prilicno nejasan.

Ali developer možda shvati kako SW radi u praksi.
Nego, tko ima toliko licenci da sve to trpa svakom developeru na stroj?

Nisam shvatio ovo prvo, ali ovo drugo - nije problem developera. Zar se sumar brine da li je pila kupljena, posudjena, iznajmljena ili ukradena? On radi, ali ce bitno brze (i bolje) napraviti svoj posao ako radi motorkom, a ne rucnom pilom - to je teza koju ja zastupam.

Osobno sam nerijetko bio prisiljen imati razvojnu bazu na vlastitom stroju, sto ima odredjenih prednosti (u razvojnom smislu), ali smatram svakako boljim rjesenjem imati separiranu, dijeljenu, razvojnu instancu baze na odvojenom stroju. Zasto se to tako radi, to je sad pitanje za drugu raspravu, ali smatram da developer niti treba, a niti moze odgovarati na pitanje o (ne-)postojanju licenci.

[Old Iggy]

Autor Quantum

To je ocjena iz iskustva ili procjenom palac x pi? Sto to uopce znaci "dosta"? Ako je "dosta" ekvivalent sa "moze raditi", onda je "dosta" i 4200 RPM disk sa 2 GB RAM-a, jedino sto ce koristan rad (gdje "koristan rad" definiramo kao "pisanje testable koda relevantnog za klijenta koji placa nas rad") teziti u nulu.

Iz iskustva. i da, takvim developerima bi dao da testiraju na točno takvoj, opisanoj okolini.
Na stranu što nikako ne mogu nazvati developerom nekog tko ne poznaje osnove onog s čim radi, u ovom slučaju način rada s bazom, zašto je to loše i na koji način može doći do relevantne informacije o problemu.

Autor Quantum

Aritmetika je prilicno trivijalna - (vrlo okvirni izracun) ako disk kosta 500 kn, a inzenjerski sat kosta 200 kn i ja SSD-om ustedim mjesecno 5 sati koje umjesto na cekanje potrosim na pisanje koda, onda ja taj disk isplatim po workstationu za 15 radnih dana, a ostalo je usteda. Ne govorimo ovdje o kupnji SSD-mrcina od 512 GB, vec o nabavci 64-128 GB modela - Intel G2 generacije? Zasto ne, sasvim je nebitno.

Onaj tko ne može takvo što sebi priuštiti (a o tome sam točno i rekao - mali SSD je danas jeftin i za takve stvari OK) nema što raditi u ovom poslu, nije bitno da li je firma ili pojedinac.
A ove varijante (kompresija, da ne govorim deduplikacija, thin provisioning i slični elementi) jesu pokazatelji koliko netko poznaje tehnologiju.

Autor Quantum

Sto se tice baze, nije sporno da je bad practice stavljanje baze na komprimiranju particiju, ali ipak, nekakav ocekivani minimum je koliko-toliko smislena poruka o gresci (sto, admittedly, pocinje biti sve veci luksuz, barem kad se govori o Microsoft softveru ili, nedajbog, IBM-u). Najzad, ono sto je smijesno je ocekivati od developera da se brine za bazu, pa cak i od administratora.

Ne razumijem uopće, za početak, kako nekome može pasti na pamet takvo nešto. koliko vidim, čak je i poruka greške smislena.

Inače, developer je taj koji radi najveći kaos na bazi, nažalost. I upravo je krasan primjer današnjih produkcijskih situacija - najčešće problem u produkcijama i jest u kodu.

Autor Quantum

Nema govora o humoru - stvar je prilicno ozbiljna, jer se radi o vremenu, tj. novcu (sto sam argumentirao iznad). Kompresija je u sprezi sa non-SF SSD-om odlicna stvar, a cinjenica da (jos) nije standard u enterprise okolini u RH nije relevantan argument za nasu diskusiju - razlozi neprihvacanja u enterprise okolini (iz mog iskustva) rangiraju od predrasuda o nepouzdanosti, preko ogranicenog budzeta do ocitog neznanja, inertnosti pa, rekao bih i autizma. Ovdje, medjutim, govorimo o razvojnom okruzenju, gdje se slazemo da je SSD postao vrlo jeftin i, u krajnjoj liniji, dovoljno pouzdan, pa je razlog za otpor prema istima - meni prilicno nejasan.

Upravo zato što se radi o vremenu i novcu takve perverzije su mi, s poslovne strane gledano, apsolutno neprihvatljive.
Enterprise SSD kod nas (kao i vani) nije u igri jer je iznimno rijetko potreban, tamo gdje ima smisla (ekstremno rijetke baze, storage tiering) se odavno koristi, još uvijek je jako nepozdan ukoliko nije SLC (koji je pak ekstremno skup) i nećeš baš naići na iste samo zato jer su se developeri zaigrali.

Autor Quantum

Nisam shvatio ovo prvo, ali ovo drugo - nije problem developera. Zar se sumar brine da li je pila kupljena, posudjena, iznajmljena ili ukradena? On radi, ali ce bitno brze (i bolje) napraviti svoj posao ako radi motorkom, a ne rucnom pilom - to je teza koju ja zastupam.

To neka kaže šefu. Ali kako će koristiti SSD mora reći sebi u ogledalu.

Autor Quantum

Osobno sam nerijetko bio prisiljen imati razvojnu bazu na vlastitom stroju, sto ima odredjenih prednosti (u razvojnom smislu), ali smatram svakako boljim rjesenjem imati separiranu, dijeljenu, razvojnu instancu baze na odvojenom stroju. Zasto se to tako radi, to je sad pitanje za drugu raspravu, ali smatram da developer niti treba, a niti moze odgovarati na pitanje o (ne-)postojanju licenci.

Gdje se ne radi?

[Quantum]

Autor Old Iggy

Iz iskustva. i da, takvim developerima bi dao da testiraju na točno takvoj, opisanoj okolini.
Na stranu što nikako ne mogu nazvati developerom nekog tko ne poznaje osnove onog s čim radi, u ovom slučaju način rada s bazom, zašto je to loše i na koji način može doći do relevantne informacije o problemu.

Moje iskustvo je potpuno suprotno.

I dok mi je zamislivo da bi takva okolina (ako je dobro promisljena i odrzavana) bila (potencijalno cak i produktivnija) alternativa stavljanju SSD-a na razvojne okoline, postavlja se niz pitanja - tko bi to odrzavao, kako i koliko bi to kostalo? Bi li se to isplatilo s obzirom na relativno nizak i jednokratan trosak instalacije SSD-a u razvojno racunalo? Smatram da tesko.

Tvrdim da si pristup koji ti zagovaras mogu priustiti samo veci developerski timovi i projekti (recimo, 15+ ljudi), dok je on potpuno neprikladan za manje timove, manje projekte i manje firme - jasno, govorimo o hrvatskim gabaritima.

Sto se tice opaske o bazi, niti tu pricamo o osnovama, niti je tu rijec uopce o ingerenciji developera, koja zavrsava sa tablicom u bazi. Developer je tek konzument usluge koju bi trebao provideati dedicirani DBA - koji bi trebao znati sto se smije, sto ne i kako rijesiti te probleme.
Naravno, sve to vrijedilo bi za funkcionirajuci razvojni proces (dakle, luksuz i wishful thinking u RH), a ne svastarenje na koje smo vecina nas ovdje prisiljeni.
Najzad, stojim pri svom opcenitom stavu da kvalitetan softver (neovisno koji i kakav), treba biti sve samo ne kriptican u prijavi gresaka.

Onaj tko ne može takvo što sebi priuštiti (a o tome sam točno i rekao - mali SSD je danas jeftin i za takve stvari OK) nema što raditi u ovom poslu, nije bitno da li je firma ili pojedinac.
A ove varijante (kompresija, da ne govorim deduplikacija, thin provisioning i slični elementi) jesu pokazatelji koliko netko poznaje tehnologiju.

Pa upravo to sam i ja rekao - ako je pitanje cijene gotovo irelevantno, cemu otpor ka objektivnom poboljsanju produktivnosti?

Ne razumijem uopće, za početak, kako nekome može pasti na pamet takvo nešto. koliko vidim, čak je i poruka greške smislena.

Inače, developer je taj koji radi najveći kaos na bazi, nažalost. I upravo je krasan primjer današnjih produkcijskih situacija - najčešće problem u produkcijama i jest u kodu.

Osobno ne razumijem kako nekome u ovom poslu moze NE pasti na pamet takvo nesto. Cisti inzenjerski rezon - imas ogranicena sredstva, ogranicen prostor i vrlo jeftin nacin da si povecas produktivnost i ucinis rad ugodnijim, sigurno laksi (i skoro beskonacno jefiniji) nego opet zicanje poslodavca da ti kupi novi i veci SSD (a sadasnji si vec jedva izmolio) te cekanje mjesecima na isti.
Kompresija na SSD-u je upravo to: smanjenjem zauzeca diska direktno pozitivno utjeces na njegove performanse, a dobici daleko nadmasuju gubitke pa si neto u plusu.

Iz mog iskustva, najveci hinderance i problem su (nakon korisnika, naravno) opcenito bili administratori. Tocno je da postoje developeri koji ne znaju (i, sto je najgore - odbijaju znati) neke osnove rada sa tehnologijom - ovim drugima bih smjesta zaljepio ili smanjenje place ili otkaz. Medjutim, bespotrebne komplikacije koje su administratori skloni sloziti, posve neopravdana paranoja, totalno nepracenje tehnologija i trendova te blatantno kreiranje posla samo radi kreiranja posla su bile najvece poteskoce i primus razlozi zasto je projekt kasnio.

Upravo zato što se radi o vremenu i novcu takve perverzije su mi, s poslovne strane gledano, apsolutno neprihvatljive.
Enterprise SSD kod nas (kao i vani) nije u igri jer je iznimno rijetko potreban, tamo gdje ima smisla (ekstremno rijetke baze, storage tiering) se odavno koristi, još uvijek je jako nepozdan ukoliko nije SLC (koji je pak ekstremno skup) i nećeš baš naići na iste samo zato jer su se developeri zaigrali.

Kakve perverzije? Zelimo si maksimizirati ustedu novca, ubrzati produktivnost i uciniti rad ugodnijim - kako su to perverzni zahtjevi?

To neka kaže šefu. Ali kako će koristiti SSD mora reći sebi u ogledalu.

S ovim prvim se slazem, ali mozes li pojasniti ovo drugo?

Gdje se ne radi?

Sorry, nisam shvatio pitanje: gdje se ne radi - sto?

[Old Iggy]

Autor Quantum

Moje iskustvo je potpuno suprotno.

I dok mi je zamislivo da bi takva okolina (ako je dobro promisljena i odrzavana) bila (potencijalno cak i produktivnija) alternativa stavljanju SSD-a na razvojne okoline, postavlja se niz pitanja - tko bi to odrzavao, kako i koliko bi to kostalo? Bi li se to isplatilo s obzirom na relativno nizak i jednokratan trosak instalacije SSD-a u razvojno racunalo? Smatram da tesko.

Koliko bi koštalo? Ti troškovi su bitno manji od mjesečnog troška hladnog pogona par developera. Ako je posao u pitanju, to je kikiriki.

Autor Quantum

Tvrdim da si pristup koji ti zagovaras mogu priustiti samo veci developerski timovi i projekti (recimo, 15+ ljudi), dok je on potpuno neprikladan za manje timove, manje projekte i manje firme - jasno, govorimo o hrvatskim gabaritima.

Trošak par SSD-ova "malim" developerima je nikakav. Trošak cijele razvojne okoline za manje timove se isplati jednim poslom. Na stranu što se sve da složiti i u nekom VPS-u za početak.

Sve ozbiljne firme u RH koje se time bave imaju poprilično kompleksne razvojne okoline baš u tu svrhu.

Autor Quantum

Sto se tice opaske o bazi, niti tu pricamo o osnovama, niti je tu rijec uopce o ingerenciji developera, koja zavrsava sa tablicom u bazi. Developer je tek konzument usluge koju bi trebao provideati dedicirani DBA - koji bi trebao znati sto se smije, sto ne i kako rijesiti te probleme.

Točno. Zato se i nema što čuditi porukama o greškama. A ako se time petlja na ikakav način, treba dobro poznavati zašto nešto ne radi.
Isto tako, neki developer koji radi s bazama mora poznavati u detalje kako one rade ako ga itko želi smatrati osrednjim developerom.

Autor Quantum

Naravno, sve to vrijedilo bi za funkcionirajuci razvojni proces (dakle, luksuz i wishful thinking u RH), a ne svastarenje na koje smo vecina nas ovdje prisiljeni.

Nema tu nikakvog luksuza ni wishful thinkinga. To je standard. kao što nije standard testiranje okoline na SSD-ima.

Autor Quantum

Najzad, stojim pri svom opcenitom stavu da kvalitetan softver (neovisno koji i kakav), treba biti sve samo ne kriptican u prijavi gresaka.

Daleko od toga. Svaki ozbiljniji sustav je često puno "nerazumljiviji" i nije mu ni svrha biti razumljiv. Onaj tko s time radi mora poznavati detalje, posebno kad je ne baš jeftin SW u pitanju.

Autor Quantum

Pa upravo to sam i ja rekao - ako je pitanje cijene gotovo irelevantno, cemu otpor ka objektivnom poboljsanju produktivnosti?

Koji otpor?

Autor Quantum

Osobno ne razumijem kako nekome u ovom poslu moze NE pasti na pamet takvo nesto. Cisti inzenjerski rezon - imas ogranicena sredstva, ogranicen prostor i vrlo jeftin nacin da si povecas produktivnost i ucinis rad ugodnijim, sigurno laksi (i skoro beskonacno jefiniji) nego opet zicanje poslodavca da ti kupi novi i veci SSD (a sadasnji si vec jedva izmolio) te cekanje mjesecima na isti.
Kompresija na SSD-u je upravo to: smanjenjem zauzeca diska direktno pozitivno utjeces na njegove performanse, a dobici daleko nadmasuju gubitke pa si neto u plusu.

Kompresija diska je krasan metod za usera vulgaris, ali apsolutni no-no za baze. Onaj tko to ne zna, ne razumije ili se tome čudi nema što raditi u IT-u.

Autor Quantum

Iz mog iskustva, najveci hinderance i problem su (nakon korisnika, naravno) opcenito bili administratori. Tocno je da postoje developeri koji ne znaju (i, sto je najgore - odbijaju znati) neke osnove rada sa tehnologijom - ovim drugima bih smjesta zaljepio ili smanjenje place ili otkaz. Medjutim, bespotrebne komplikacije koje su administratori skloni sloziti, posve neopravdana paranoja, totalno nepracenje tehnologija i trendova te blatantno kreiranje posla samo radi kreiranja posla su bile najvece poteskoce i primus razlozi zasto je projekt kasnio.

Pitanje "paranoje" i administratorskih zahtjeva je jako kompleksno, no u praksi su ti zahtjevi u najvećem broju slučajeva ekstremno manji od realnih potreba okoline.

Autor Quantum

Kakve perverzije? Zelimo si maksimizirati ustedu novca, ubrzati produktivnost i uciniti rad ugodnijim - kako su to perverzni zahtjevi?

Perverzija o SSD-ovima i kompresiji. Protuprirodan blud.

Autor Quantum

S ovim prvim se slazem, ali mozes li pojasniti ovo drugo?

Vrlo jednostavno, na upravi je dati developeru sredstva za rad (da bi mu bilo lakše), a na njemu da radi s tim kako spada (tj., da ne testira na istom i da ne koristi ono što ne shvaća).

Autor Quantum

Sorry, nisam shvatio pitanje: gdje se ne radi - sto?

Gdje se ne radi test na razvojnoj okolini?