Google betrieb über 60 Produkte auf einer einzigen Bigtable statt auf einer Datenbank pro Produkt

Bis 2004 stand jedes Google-Produkt vor demselben Problem: riesige Mengen strukturierter Daten zu speichern, von Web-Crawls über Satellitenbilder bis hin zu Finanz-Feeds. Ein eigenes Speichersystem pro Produkt zu bauen war teuer, und Standarddatenbanken konnten die erforderliche Skalierung nicht erreichen, daher entwarf das Unternehmen ein einziges gemeinsames System.

Bigtable bietet ein einfaches Modell: eine dünn besetzte, sortierte Map, indiziert nach Zeile, Spalte und Zeitstempel, wobei Werte als nicht interpretierte Bytes gespeichert werden. Anwendungen legen ihr eigenes Layout fest, steuern die Datenlokalität und entscheiden sogar, ob Daten aus dem Speicher oder von der Festplatte bereitgestellt werden, während die Plattform Partitionierung, Replikation und Failover auf Tausenden von Standard-Servern übernimmt.

Zum Zeitpunkt des Papers von 2006 nutzten mehr als sechzig Google-Produkte, darunter Google Analytics, Google Finance, Personalized Search und Google Earth, Bigtable. Die Cluster reichten von einer Handvoll bis zu Tausenden von Servern und speicherten jeweils bis zu mehrere hundert Terabyte.

Ein gemeinsamer Speicher; jedes Produkt passt sein Schema an

Eine Plattform verteilt die Entwicklungs- und Betriebskosten auf viele Produkte

Anwendungen steuern das Layout, sodass das Modell einfach bleibt, obwohl die Nutzungen sich unterscheiden

Standard-Server plus automatische Partitionierung skalieren auf Petabytes

Ein gemeinsames System bedeutet, dass ein Team es für alle härten kann

Bevor man ein Produkt skaliert, sollte man das gemeinsame Fundament einmal bauen: Ein System, das viele Teams anpassen, ist besser als viele maßgeschneiderte Systeme, die niemand gemeinsam verbessern kann.

Bigtable blieb das Rückgrat von Googles eigenen Diensten und wurde später zu einem Google-Cloud-Angebot, dem „NoSQL-Pionier“: ein verwalteter Key-Value- und Wide-Column-Speicher für latenzempfindliche Personalisierungs-, Clickstream- und IoT-Workloads, mit zu HBase und Cassandra kompatiblen APIs. Seine Ideen prägten auch Open-Source-Nachbauten wie HBase.