Jacopo mi ha segnalato questo post,
in cui viene spiegato come FriendFeed memorizza su un database MySQL dati schema-less.
L'idea è quella di memorizzare una versione serializzata delle nostre entities, nel caso di FriendFeed in formato JSON.
La tabella ha la seguente struttura:
CREATE TABLE entities (
added_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
id BINARY(16) NOT NULL,
updated TIMESTAMP NOT NULL,
body MEDIUMBLOB,
UNIQUE KEY (id),
KEY (updated)
) ENGINE=InnoDB;
La cosa, che trovo, interessante è la motivazione che ha spinto ad adottare tale struttura cito dal post:
As our database has grown, we have tried to iteratively deal with the scaling issues that come with rapid growth. We did the typical things, like using read slaves and memcache to increase read throughput and sharding our database to improve write throughput. However, as we grew, scaling our existing features to accomodate more traffic turned out to be much less of an issue than adding new features.
In particular, making schema changes or adding indexes to a database with more than 10 - 20 million rows completely locks the database for hours at a time. Removing old indexes takes just as much time, and not removing them hurts performance because the database will continue to read and write to those unused blocks on every INSERT, pushing important blocks out of memory.
Ayende ne parla nel post Designing a document database: What next? ed
esiste anche un'implementazione open source chiamata CouchDB
Questa idea è un'eventuale alternativa ai classici database relazionali, nel caso in cui ci si trovi in condizioni analoghe.