Qualche giorno fa Google ha rila­sciato pro­to­bufs, un for­mato di inter­scam­bio binari, e così, dopo esserci sor­biti il man­tra plu­rien­nale dell’XML, il pen­dolo sem­bra tor­nare verso l’altro lato: binary is the new black ;-)

Il pro­blema che pro­to­bufs ha in animo di risol­vere è sem­plice ma, per una strut­tura come Google, di enorme impor­tanza, ovvero, le dimen­sioni dei dati da spo­stare fra dischi, rete e memo­ria. Il punto, però, è che non è pro­prio una cosa comune avere i pro­blemi di sca­la­bi­lità di Google e quindi, se da un punto di vista inge­gne­ri­stico è sen­sa­tis­simo che si siano posti il pro­blemi di come far dima­grire i dati non vedo tutta ’sta rile­vanza “for the rest of us”; per­ché, ne sono certo, fra poco sarà appunto “in” usare pro­to­bufs per tutto come qual­che tempo fa con l’XML (che già non mi stava molto simpatico).

Altri com­menti inte­res­santi (molto più dei miei).

Per gli afi­cio­na­dos di PostgreSQL c’è un arti­colo da non per­dere su High Scalability che ana­lizza l’archi­tet­tura adot­tata da Skype, basata appunto su pgSQL, che è data per sca­la­bile fino ad 1 miliardo di utenti.

Ci sono diversi aspetti rile­vanti, fra cui il fatto che l’accesso al data­base è com­ple­ta­mente incap­su­lato attra­verso le sto­red pro­ce­du­res. Nel mio pic­colo è un approc­cio che sto pro­vando anch’io con un pro­getto che ini­ziato qual­che mese fa e su cui posterò qual­che info più appro­fon­dita quando sarà andato tutto in porto (si spera!).

L’idea che mi attira di que­sto approc­cio è che l’interfaccia con il data­bae risulta dra­sti­ca­mente sem­pli­fi­cata: ci sono solo i para­me­tri d’ingresso e d’uscita. Senza con­tare i risparmi in ter­mini di prestazioni.

Ad oggi, il difetto fon­da­men­tale di que­sta solu­zione è che non può essere estesa anche alle select, dato che il plan­ner di PostgreSQL non è in grado di ana­liz­zare la query in modo otti­male per poter usare la stra­te­gia più per­for­mante ma qual­che miglio­ria è in arrivo con la ver­sione 8.4.

E pen­sare che una volta ero con­vinto che le sto­red pro­ce­du­res fos­sero l’incarnazione del male… :-D

Amazon aggiunge un altro tas­sello, fon­da­men­tale, per ren­dere il “cloud com­pu­ting for the rest of us” una realtà. Adesso è pos­si­bile asso­ciare un IP sta­tico al pro­prio account per poi gestire l’associazione indirizzo–istanza in modo libero, per­met­tendo, ad esem­pio, la dismis­sione della vec­chia istanza e l’attivazione della nuova in modo tra­spa­rente. #

Quasi quasi spo­sto que­sto blog… ;-)

Alex Bosworth mette alla prova SimpleDB, creando una bacheca (“bacheca”… :-/ non suona otto­cen­te­sca?) per mes­saggi e sco­pre l’acqua calda! Scherzi a parte: fa le sco­perte che capi­tano a tutti i pro­gram­ma­tori, e non solo a loro, quando si passa dal dire al fare.

Ad esem­pio, il non poter ordi­nare i dati, piut­to­sto che l’even­tual con­si­stency, pas­sando per il fatto che SimpleDB non ha sup­porto per le sequence. In un modo o nell’altro è riu­scito ad aggi­rare tutti i pro­blemi, salvo poi sco­prire che a livello di API lo Unicode non è sup­por­tato; e que­sto è vera­mente incredibile.

A conti fatti, il responso è posi­tivo, cal­co­lando che è ancora in beta.

Altri post su SimpleDB.

Ho già par­lato di SimpleDB, il ser­vi­zio per data­base di Amazon.

Volevo solo segna­lare, tra­mite que­sto post, che almeno per ora il tasso di errore sem­bra piut­to­sto alto, anche se non c’è nes­sun det­ta­glio sulle pos­si­bili cause. Speriamo sia un pro­blema limi­tato alla beta.

Sempre nello stesso post viene anche citata una delle que­stioni più discusse di SimpleDB: l’even­tual con­si­stency. Con que­sto ter­mine si intende la capa­cità di un sistema distri­buito di pro­pa­gare in modo affi­da­bile degli aggior­na­menti, senza tut­ta­via garan­tire che lo stesso valore sia coe­rente in tutti i nodi.

Il rila­scio di Leopard com­prende anche la nuova ver­sione di Xgrid che, com’è facile imma­gi­nare, si è evo­luta sen­si­bil­mente rispetto alla pre­ce­dente e comin­cia anche ad essere uti­liz­zata per altri pro­dotti di Apple, come Podcast Producer, su cui un giorno dovremo ritor­nare.  Tuttavia la cosa vera­mente inte­res­sante di Xgrid 2 è Scoreboard.

Lo scopo di Scoreboard è sem­plice: for­nire un sistema per distri­buire in modo selet­tivo i job di Xgrid. L’architettura per rag­giun­gere que­sto scopo è un po’ più com­plessa da spiegare.

Prima di tutto serve un qual­che tipo di cri­te­rio per sele­zio­nare i nodi di desti­na­zione dei job. In Xgrid que­sto cri­te­rio è un sem­plice script di shell, che Scoreboard usa per cal­co­lare il ran­king di ogni nodo. Questo script, nella ter­mi­no­lo­gia di Xgrid, è un Agent Ranking Tool (ART).

Alla sot­to­mis­sione di un job, for­nendo un ART, il con­trol­ler lo ese­guirà su ogni nodo e, in base al risul­tato, deci­derà a quali nodi far ese­guire il job e con quale prio­rità. Il risul­tato è un sem­plice valore nume­rico e se è uguale a zero il nodo viene scar­tato. Sta ovvia­mente a chi scrive l’ART il com­pito di pro­durre dei numeri sensati.

Gli ART pos­sono essere com­bi­nati pro­du­cendo un risul­tato com­ples­sivo che è il pro­dotto dei sin­goli risul­tati. Usando la mol­ti­pli­ca­zione diventa banale pre­ser­vare la pos­si­bi­lità di esclu­sione dei nodi: basta che uno degli ART dia come risul­tato zero.  Ma non è finita qui! È pos­si­bile anche fil­trare i nodi in base al valore del risul­tato: ad es. sele­zio­nando i nodi con un pun­teg­gio supe­riore a 1.000.

Trovo quest’idea molto inte­res­sante e anzi credo sia uti­liz­za­bile anche in altri sce­nari. Ad es. potremmo sfrut­tare l’infrastruttura che Xgrid mette a dispo­si­zione per distri­buire aggior­na­menti, con­fi­gu­ra­zioni in maniera selet­tiva e robu­sta: basta legare il pun­teg­gio dell’ART alla pre­senza o meno dell’aggiornamento che stiamo distri­buendo, evi­tando quindi la riap­pli­ca­zione dell’aggiornamento nel caso in cui doves­simo ripe­tere la procedura.

Links utili:

• “Xgrid Leopard: the good, the bad, the ugly, and the new stuff”;
• “Xgrid Leopard: Scoreboard rules!”.

Per quanto spesso non sia d’accordo con Dave Winer – anche se la rea­zione più fre­quente che ho è: “E quindi?” – il suo com­mento finale su SimpleDB è esat­ta­mente il pen­siero che ho avuto io:

It’s ama­zing that Microsoft and Google are sit­ting by and let­ting Amazon take all this ground in developer-land without even a hint of a response. It seems likely they have some­thing in the works.

Ed è vero anche per le altre ini­zia­tive di Amazon, S3 e EC2.

In fondo, è ragio­ne­vole pen­sare che l’infrastruttura di Google sia per­sino più robu­sta, distri­buita, sca­la­bile di quella di Amazon, eppure, tutto tace.

Amazon con­ti­nua a per­se­guire la sua stra­te­gia di ser­vizi di vir­tua­liz­za­zione con l’offerta di una base dati: SimpleDB.

Che cos’è

SimpleDB offre la pos­si­bi­lità di archi­viare una serie di dati più o meno strut­tu­rati, con grande libertà e senza doversi sob­bar­care gli oneri di manutenzione.

L’esempio usato in docu­men­ta­zione usa i fogli di cal­colo per aiu­tare il let­tore a farsi un’idea più con­creta. Ogni foglio è per­ti­nente a quello che viene chia­mato un domi­nio, all’interno di ogni foglio/dominio, gli ele­menti archi­viati sono le righe e i loro attri­buti le colonne; niente di sorprendente.

Le dif­fe­renze, sia rispetto ai fogli di cal­colo, sia rispetto ai data­base tra­di­zio­nali, stanno nella pos­si­bi­lità di avere più valori per un sin­golo attri­buto e/o attri­buti diversi per ele­menti appar­te­nenti ad uno stesso foglio/dominio.

A cosa serve

Beh, è facile imma­gi­nare che tutti i sita­relli LAMP che usano MySQL per quat­tro dati stri­min­ziti e senza esi­genze (né com­pe­tenze, aggiun­ge­rei) per lo schema del data­base, pos­sono essere dei can­di­dati ideali; anche un blog come questo.

Volendo dare una colo­ra­tura cinica, direi che la gestione dei dati è tal­mente poco con­si­de­rata che la pos­si­bi­lità di spa­rarsi nei piedi met­tendo in piedi basi di dati mal­fatte e ridon­danti è con­si­de­rata una cosa desi­de­ra­bile da avere.

Tralasciando l’aspetto più legato alla pro­get­ta­zione, il fatto di poter ester­na­liz­zare i costi di gestione è sicu­ra­mente una gran cosa.

Il mio ideale si avvi­cina di più all’usare EC2 con un data­base di mia scelta, cosa pos­si­bile, peraltro.

Conviene? Lo useresti?

Bella domanda… Il costo del ser­vi­zio mi sem­bra piut­to­sto ele­vato: ci sono i costi di uti­lizzo CPU (0,14$/ora CPU); i costi di tra­sfe­ri­mento dati ($0,10/GB in input, almeno $0,13/GB in out­put); i costi di sto­rage ($1,50/GB per mese).

Costi a parte, trovo una certa “ten­sione” fra il pro­porre un ser­vi­zio mas­sic­cia­mente sca­la­bile, da una parte, e l’ipersemplificazione delle pro­ble­ma­ti­che di gestione dati, dall’altra. Voglio dire, le esi­genze di sca­la­bi­lità di solito si pon­gono con sistemi com­plessi non con basi dati para­go­na­bili ad un cata­logo in Excel.

Link utili

• “Amazon SimpleDB™- Limited Beta”;
• “Product: Amazon’s SimpleDB”;
• “The Current Pros and Cons List for SimpleDB”.

Qualche giorno fa segna­lando un arti­colo su High Scalability mi chie­devo in quale misura i vari RDBMS – o meglio, i loro svi­lup­pa­tori – si sen­tis­sero inter­pel­lati da arti­coli come quello, in cui si but­tano alle orti­che alcuni punti fermi dello svi­luppo dei data­base come la nor­ma­liz­za­zione dei dati, i vin­coli d’integrità.

Bill de hÓra va anche oltre e si chiede se il teo­rema CAP (o la con­get­tura?) non si appli­chi anche agli RDBMS, ovvero, se non sia ine­ren­te­mente impos­si­bile otte­nere con­tem­po­ra­nea­mente distri­bu­zione, con­si­stenza e disponibilità.

Sarei curioso di sapere il parere di Chris Date…

Come dicevo ieri, High Scalability è una miniera di infor­ma­zioni. In que­sto arti­colo viene discusso lo shar­ding per sca­lare in oriz­zon­tale appli­ca­zioni che si appog­giano ad un data­base SQL – pra­ti­ca­mente il 90%, direi – per la gestione dei dati.

L’idea è quasi banale. Di solito il DBMS gira su una sola mac­china e solo gli strati più alti dell’architettura, come l’application ser­ver e il ser­ver web ven­gono sca­lati in oriz­zon­tale; se si vogliono aumen­tare le pre­sta­zioni del DBMS si aggiorna l’hardware. Lo shar­ding cerca di risol­vere que­sto pro­blema segre­gando i dati in bloc­chi (o se pre­fe­rite, in schegge, tra­du­cendo diret­ta­mente shard). Ogni blocco è indi­pen­dente e quindi diventa pos­si­bile ren­dere più lineare la sca­la­bi­lità del sistema, aggiun­gendo hard­ware in modo pro­gres­sivo solo quando richiesto.

Ho qual­che dub­bio sul fatto che i dati deb­bano essere neces­sa­ria­mente denor­ma­liz­zati: credo dipenda molto dallo schema; anzi, direi che l’evitare la denor­ma­liz­za­zione dovrebbe essere uno dei cri­teri per “scheg­giare” la base dati. Ovviamente, i vari sistemi DBMS sono anch’essi inter­pel­lati da pro­ble­ma­ti­che e solu­zioni come que­ste: è il loro set­tore, no?