Qualche giorno fa Google ha rilasciato protobufs, un formato di interscambio binari, e così, dopo esserci sorbiti il mantra pluriennale dell’XML, il pendolo sembra tornare verso l’altro lato: binary is the new black ;-)

Il problema che protobufs ha in animo di risolvere è semplice ma, per una struttura come Google, di enorme importanza, ovvero, le dimensioni dei dati da spostare fra dischi, rete e memoria. Il punto, però, è che non è proprio una cosa comune avere i problemi di scalabilità di Google e quindi, se da un punto di vista ingegneristico è sensatis­simo che si siano posti il problemi di come far dimagrire i dati non vedo tutta ’sta rilevanza “for the rest of us”; perché, ne sono certo, fra poco sarà appunto “in” usare protobufs per tutto come qualche tempo fa con l’XML (che già non mi stava molto simpatico).

Altri commenti interes­santi (molto più dei miei).

Per gli aficionados di PostgreSQL c’è un articolo da non perdere su High Scalability che analizza l’architettura adottata da Skype, basata appunto su pgSQL, che è data per scalabile fino ad 1 miliardo di utenti.

Ci sono diversi aspetti rilevanti, fra cui il fatto che l’accesso al database è completamente incapsulato attraverso le stored procedures. Nel mio piccolo è un approccio che sto provando anch’io con un progetto che iniziato qualche mese fa e su cui posterò qualche info più approfondita quando sarà andato tutto in porto (si spera!).

L’idea che mi attira di questo approccio è che l’interfaccia con il databae risulta drasticamente semplificata: ci sono solo i para­metri d’ingresso e d’uscita. Senza contare i risparmi in termini di prestazioni.

Ad oggi, il difetto fondamentale di questa soluzione è che non può essere estesa anche alle select, dato che il planner di PostgreSQL non è in grado di analizzare la query in modo ottimale per poter usare la strategia più performante ma qualche miglioria è in arrivo con la versione 8.4.

E pensare che una volta ero convinto che le stored procedures fos­sero l’incarnazione del male… :-D

Amazon aggiunge un altro tas­sello, fondamentale, per rendere il “cloud computing for the rest of us” una realtà. Adesso è pos­sibile associare un IP statico al proprio account per poi gestire l’associazione indirizzo–istanza in modo libero, permettendo, ad esempio, la dismis­sione della vecchia istanza e l’attivazione della nuova in modo trasparente. #

Quasi quasi sposto questo blog… ;-)

Alex Bosworth mette alla prova SimpleDB, creando una bacheca (“bacheca”… :-/ non suona ottocentesca?) per mes­saggi e scopre l’acqua calda! Scherzi a parte: fa le scoperte che capitano a tutti i programmatori, e non solo a loro, quando si passa dal dire al fare.

Ad esempio, il non poter ordinare i dati, piuttosto che l’eventual consistency, pas­sando per il fatto che SimpleDB non ha supporto per le sequence. In un modo o nell’altro è riuscito ad aggirare tutti i problemi, salvo poi scoprire che a livello di API lo Unicode non è supportato; e questo è veramente incredibile.

A conti fatti, il responso è positivo, calcolando che è ancora in beta.

Altri post su SimpleDB.

Ho già parlato di SimpleDB, il servizio per database di Amazon.

Volevo solo segnalare, tramite questo post, che almeno per ora il tasso di errore sembra piuttosto alto, anche se non c’è nes­sun dettaglio sulle pos­sibili cause. Speriamo sia un problema limitato alla beta.

Sempre nello stesso post viene anche citata una delle questioni più discusse di SimpleDB: l’eventual consistency. Con questo termine si intende la capacità di un sistema distribuito di propagare in modo affidabile degli aggiornamenti, senza tuttavia garantire che lo stesso valore sia coerente in tutti i nodi.

Il rilascio di Leopard comprende anche la nuova versione di Xgrid che, com’è facile immaginare, si è evoluta sensibilmente rispetto alla pre­cedente e comincia anche ad essere utilizzata per altri prodotti di Apple, come Podcast Producer, su cui un giorno dovremo ritornare.  Tuttavia la cosa veramente interes­sante di Xgrid 2 è Scoreboard.

Lo scopo di Scoreboard è semplice: fornire un sistema per distribuire in modo selettivo i job di Xgrid. L’architettura per raggiungere questo scopo è un po’ più complessa da spiegare.

Prima di tutto serve un qualche tipo di criterio per selezionare i nodi di destinazione dei job. In Xgrid questo criterio è un semplice script di shell, che Scoreboard usa per calcolare il ranking di ogni nodo. Questo script, nella terminologia di Xgrid, è un Agent Ranking Tool (ART).

Alla sottomis­sione di un job, fornendo un ART, il controller lo eseguirà su ogni nodo e, in base al risultato, deciderà a quali nodi far eseguire il job e con quale priorità. Il risultato è un semplice valore numerico e se è uguale a zero il nodo viene scartato. Sta ovviamente a chi scrive l’ART il compito di produrre dei numeri sensati.

Gli ART pos­sono essere combinati producendo un risultato comples­sivo che è il prodotto dei singoli risultati. Usando la moltiplicazione diventa banale pre­servare la pos­sibilità di esclusione dei nodi: basta che uno degli ART dia come risultato zero.  Ma non è finita qui! È pos­sibile anche filtrare i nodi in base al valore del risultato: ad es. selezionando i nodi con un punteggio superiore a 1.000.

Trovo quest’idea molto interes­sante e anzi credo sia utilizzabile anche in altri scenari. Ad es. potremmo sfruttare l’infrastruttura che Xgrid mette a disposizione per distribuire aggiornamenti, configurazioni in maniera selettiva e robusta: basta legare il punteggio dell’ART alla pre­senza o meno dell’aggiornamento che stiamo distribuendo, evitando quindi la riapplicazione dell’aggiornamento nel caso in cui doves­simo ripetere 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 reazione più frequente che ho è: “E quindi?” – il suo commento finale su SimpleDB è esattamente il pensiero che ho avuto io:

It’s amazing that Microsoft and Google are sitting by and letting Amazon take all this ground in developer-land without even a hint of a response. It seems likely they have something in the works.

Ed è vero anche per le altre iniziative di Amazon, S3 e EC2.

In fondo, è ragionevole pensare che l’infrastruttura di Google sia persino più robusta, distribuita, scalabile di quella di Amazon, eppure, tutto tace.

Amazon continua a perseguire la sua strategia di servizi di virtualizzazione con l’offerta di una base dati: SimpleDB.

Che cos’è

SimpleDB offre la pos­sibilità di archiviare una serie di dati più o meno strutturati, con grande libertà e senza doversi sobbarcare gli oneri di manutenzione.

L’esempio usato in documentazione usa i fogli di calcolo per aiutare il lettore a farsi un’idea più concreta. Ogni foglio è pertinente a quello che viene chiamato un dominio, all’interno di ogni foglio/dominio, gli elementi archiviati sono le righe e i loro attributi le colonne; niente di sorprendente.

Le differenze, sia rispetto ai fogli di calcolo, sia rispetto ai database tradizionali, stanno nella pos­sibilità di avere più valori per un singolo attributo e/o attributi diversi per elementi appartenenti ad uno stesso foglio/dominio.

A cosa serve

Beh, è facile immaginare che tutti i sitarelli LAMP che usano MySQL per quattro dati striminziti e senza esigenze (né competenze, aggiungerei) per lo schema del database, pos­sono essere dei candidati ideali; anche un blog come questo.

Volendo dare una coloratura cinica, direi che la gestione dei dati è talmente poco considerata che la pos­sibilità di spararsi nei piedi mettendo in piedi basi di dati mal­fatte e ridondanti è considerata una cosa desiderabile da avere.

Tralasciando l’aspetto più legato alla progettazione, il fatto di poter esternalizzare i costi di gestione è sicuramente una gran cosa.

Il mio ideale si avvicina di più all’usare EC2 con un database di mia scelta, cosa pos­sibile, peraltro.

Conviene? Lo useresti?

Bella domanda… Il costo del servizio mi sembra piuttosto elevato: ci sono i costi di utilizzo CPU (0,14$/ora CPU); i costi di trasferimento dati ($0,10/GB in input, almeno $0,13/GB in output); i costi di storage ($1,50/GB per mese).

Costi a parte, trovo una certa “tensione” fra il proporre un servizio mas­sicciamente scalabile, da una parte, e l’ipersemplificazione delle problematiche di gestione dati, dall’altra. Voglio dire, le esigenze di scalabilità di solito si pongono con sistemi complessi non con basi dati para­gonabili ad un catalogo in Excel.

Link utili

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

Qualche giorno fa segnalando un articolo su High Scalability mi chiedevo in quale misura i vari RDBMS – o meglio, i loro sviluppatori – si sentis­sero interpellati da articoli come quello, in cui si buttano alle ortiche alcuni punti fermi dello sviluppo dei database come la normalizzazione dei dati, i vincoli d’integrità.

Bill de hÓra va anche oltre e si chiede se il teorema CAP (o la congettura?) non si applichi anche agli RDBMS, ovvero, se non sia inerentemente impos­sibile ottenere contemporaneamente distribuzione, consistenza e disponibilità.

Sarei curioso di sapere il parere di Chris Date…

Come dicevo ieri, High Scalability è una miniera di informazioni. In questo articolo viene discusso lo sharding per scalare in orizzontale applicazioni che si appoggiano ad un database SQL – praticamente il 90%, direi – per la gestione dei dati.

L’idea è quasi banale. Di solito il DBMS gira su una sola macchina e solo gli strati più alti dell’architettura, come l’application server e il server web vengono scalati in orizzontale; se si vogliono aumentare le pre­stazioni del DBMS si aggiorna l’hardware. Lo sharding cerca di risolvere questo problema segregando i dati in blocchi (o se pre­ferite, in schegge, traducendo direttamente shard). Ogni blocco è indipendente e quindi diventa pos­sibile rendere più lineare la scalabilità del sistema, aggiungendo hardware in modo progres­sivo solo quando richiesto.

Ho qualche dubbio sul fatto che i dati debbano essere neces­sariamente denormalizzati: credo dipenda molto dallo schema; anzi, direi che l’evitare la denormalizzazione dovrebbe essere uno dei criteri per “scheggiare” la base dati. Ovviamente, i vari sistemi DBMS sono anch’essi interpellati da problematiche e soluzioni come queste: è il loro settore, no?