Novice » Zasebnost » Pri Facebooku napisali svoj PHP prevajalnik
BlueRunner ::
V vsemu imaš prav, pa da še dopišem na temo "vsega vseeno ne moreš tlačiti v RDBMS".
RDBMS so uporabni za obdelovanje povezav med relacijami, teh povezav pa je pri dovolj velikem številu vrstic preprosto preveč. Ne skalirajo. Preveč stvari je preveč razpršenih na preveč sistemov in koordinacija med njimi pobere preveč časa. Konsistenca je lepa stvar, vendar pa včasih ni nujno potrebna. Kadar je ne potrebuješ, jo pač lahko tudi žrtvuješ.
Normalizacija (kot garant konsistence) ima tudi dodatne posledice in ena izmed njih je ta, da žrtvuješ CPU cikle za prostor na diskovju. Pri omejenih količinah podatkov, ki so visoko strukturirani, to gre. Pri nestrukturiranih in ogromnih količinah podatkov, pa se lahko zgodi, da CPU-ja preprosto več ne moreš skalirati ne horizontalno, ne vertikalno. Diskovje pa (sploh pri današnji relativni ceni/GiB) lahko skaliraš skoraj neomejeno. Sicer je problem, če ima neprestano pokvarjenih kakšnih 10.000 diskov, ampak to se da s pravo arhitekturo obvladati. S tem pa, ko to obvladaš, lahko bazo tudi denormaliziraš in na njej omogočiš višje performanse za vzporedne map-reduce postopke, ki predstavljajo večino priprave podatkov za takšna "informacijska spletna mesta".
Posledica? Sedaj smo ven vrgli normalizacijo, s čemer smo negirali vse dobre lastnosti RDBMS. Podatke smo strukturirali po ločenih tabelah ("stolpična" baza namesto "vrstične", v kateri je ena tabela en stolpec). Vse smo razmetali na N sistemov. R(dbms) zaradi tistega R, ki ga ne uporabljamo, postane odvečen, saj ga ne izkoriščaš na način, kot je bil načrtovan. Torej ga iz slike črtaš in greš naprej.
RDBMS so uporabni za obdelovanje povezav med relacijami, teh povezav pa je pri dovolj velikem številu vrstic preprosto preveč. Ne skalirajo. Preveč stvari je preveč razpršenih na preveč sistemov in koordinacija med njimi pobere preveč časa. Konsistenca je lepa stvar, vendar pa včasih ni nujno potrebna. Kadar je ne potrebuješ, jo pač lahko tudi žrtvuješ.
Normalizacija (kot garant konsistence) ima tudi dodatne posledice in ena izmed njih je ta, da žrtvuješ CPU cikle za prostor na diskovju. Pri omejenih količinah podatkov, ki so visoko strukturirani, to gre. Pri nestrukturiranih in ogromnih količinah podatkov, pa se lahko zgodi, da CPU-ja preprosto več ne moreš skalirati ne horizontalno, ne vertikalno. Diskovje pa (sploh pri današnji relativni ceni/GiB) lahko skaliraš skoraj neomejeno. Sicer je problem, če ima neprestano pokvarjenih kakšnih 10.000 diskov, ampak to se da s pravo arhitekturo obvladati. S tem pa, ko to obvladaš, lahko bazo tudi denormaliziraš in na njej omogočiš višje performanse za vzporedne map-reduce postopke, ki predstavljajo večino priprave podatkov za takšna "informacijska spletna mesta".
Posledica? Sedaj smo ven vrgli normalizacijo, s čemer smo negirali vse dobre lastnosti RDBMS. Podatke smo strukturirali po ločenih tabelah ("stolpična" baza namesto "vrstične", v kateri je ena tabela en stolpec). Vse smo razmetali na N sistemov. R(dbms) zaradi tistega R, ki ga ne uporabljamo, postane odvečen, saj ga ne izkoriščaš na način, kot je bil načrtovan. Torej ga iz slike črtaš in greš naprej.
BigWhale ::
Vsekakor se strinjam, vendar pa treba dodati, da relacije nad podatki se vedno ostanejo vendar jih ohranjas na nekoliko bolj abstrakten nacin.
Cudilo bi pa me, ce ne bi imel Oracle, ki naj bi se imel za resno bazo, taksnega ne-relacijskega podatkovnega modela podprtega.
Cudilo bi pa me, ce ne bi imel Oracle, ki naj bi se imel za resno bazo, taksnega ne-relacijskega podatkovnega modela podprtega.
BlueRunner ::
Oh, ima ima... 11g R2 ima stolpično hrambo podatkov. Ne me pa vprašati, če ponujajo kaj količinskega popusta za nakup 5000 instanc v HA konfiguraciji z vključeno to opcijo.
Sicer pa je bazirati takšen sistem na komercialnem xDBMS navaden idiotizem. Lahko si MS privošči to početi s svojo programsko opremo, ali pa Oracle s svojo. Ne boš pa vrgel nekaj mio $ kapitala samo za licence, še preden pokažeš prvo spletno stran. OSS je tukaj edina rešitev, ker lahko prideš skozi z faktor nižjim stroški v katere je vključen lasten razvoj, prilagajanje, ipd...
Sicer pa je bazirati takšen sistem na komercialnem xDBMS navaden idiotizem. Lahko si MS privošči to početi s svojo programsko opremo, ali pa Oracle s svojo. Ne boš pa vrgel nekaj mio $ kapitala samo za licence, še preden pokažeš prvo spletno stran. OSS je tukaj edina rešitev, ker lahko prideš skozi z faktor nižjim stroški v katere je vključen lasten razvoj, prilagajanje, ipd...
Zgodovina sprememb…
- spremenilo: BlueRunner ()
nodrim ::
http://www.reclaimprivacy.org/facebook - preveri, kako imaš nastavljene nastavitve zasebnosti in označi kar je kritičnega
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | V Kiberpipi ta tedenOddelek: Novice / Kiberpipa | 2824 (2469) | cholt45 |
» | Pri Facebooku napisali svoj PHP prevajalnik (strani: 1 2 )Oddelek: Novice / Zasebnost | 16328 (13831) | nodrim |
» | .py pretvorba v .exeOddelek: Programiranje | 2388 (2174) | marjan_h |
» | Brenčanje novih zvočnikovOddelek: Zvok in slika | 3021 (2615) | bibip |
» | Kater program za delat Hip Hop glasbo?Oddelek: Zvok in slika | 2062 (1912) | Blazzz |