Wie Pinterest mit 6 Ingenieuren auf 11 Millionen Nutzer skalieren konnte

Pinterests Weg zur Skalierung

Pinterests Skalierungsprozess lässt sich in vier Phasen einteilen:

1. Die Phase der Selbstfindung: Ein kleines Engineering-Team bewältigte schnelles Prototyping und sich wandelnde Produktanforderungen.
2. Die Phase des Experimentierens: Der sprunghafte Anstieg der Nutzerzahlen machte schnelle Skalierung nötig, führte aber zu einem komplexen und fragilen System.
3. Die Phase der Reife: Die Architektur wurde mit ausgereiften und skalierbaren Technologien wie MySQL, Memcache und Redis vereinfacht.
4. Die Phase der Regression: Nachdem die passende Architektur vorhanden war, wurde horizontal skaliert, um weiteres Wachstum zu tragen.

Kerntechnologien

Pinterest priorisierte Technologien, bei denen Zuverlässigkeit, Verständlichkeit und Skalierbarkeit im Vordergrund stehen:

• MySQL: Eine stabile relationale Datenbank, die sich leicht warten lässt.
• Memcache: Entlastet Datenbank-Lesezugriffe, indem häufig abgefragte Daten im Speicher gecacht werden.
• Redis: Ein flexibler Datenspeicher, der verschiedene Datenstrukturen verarbeiten kann.
• Solr: Eine Suchplattform, die sich schnell einsetzen lässt.

Datenbank-Skalierung: Clustering vs. Sharding

Pinterest betrachtete zwei Ansätze, um die Datenbank zu verteilen:

Clustering

• Wenn Daten eintreffen, wird der optimale Knoten bestimmt und die Daten auf mehrere Knoten repliziert.
• Vorteile sind automatische Skalierung, einfache Einrichtung und gesicherte Datenverfügbarkeit; Nachteile sind jedoch Komplexität, mangelnde Reife und schwierige Upgrades.

Sharding

• Daten werden in kleine Chunks aufgeteilt, und jeder Chunk wird auf einem unabhängigen Server platziert.
• Vorteile sind eine einfache Architektur, unabhängige Skalierung und klare Datenverantwortung; Nachteile sind fehlende Joins und Transaktionen auf Datenbankebene sowie höhere Komplexität in der Anwendung.

Pinterest entschied sich wegen negativer Erfahrungen mit Clustering für Sharding.

Umstellung auf eine Sharding-Architektur

Pinterest stellte während eines Feature-Freezes schrittweise auf Sharding um:

1. Joins entfernen: Alle MySQL-Joins wurden entfernt, stattdessen kamen Denormalisierung und Caching zum Einsatz.
2. ID-basiertes Sharding: Es wurde auf Basis von 64-Bit-IDs geshardet, um das Routing der Daten zu vereinfachen.

Nachteile von Sharding und Lösungen

• Migrationsskripte: Das Übertragen der Daten in die Sharding-Infrastruktur war zeitaufwendig.
• Anwendungslogik: Da Joins und Transaktionen auf Datenbankebene fehlen, musste die Datenkonsistenz in der Anwendung sichergestellt werden.
• Schemaänderungen: Änderungen am Schema mussten für alle Shards geplant und angewendet werden.
• Berichtserstellung: Für Reports mussten mehrere Shards zusammengeführt werden.

Erkenntnisse

Wichtige Lehren aus Pinterests Weg zur Skalierung:

• Einfachheit ist entscheidend: Leicht verständliche Technologien helfen bei der Problemlösung und reduzieren Risiken.
• Skalierbarkeit zuerst: In Umgebungen mit schnellem Wachstum sollte Skalierbarkeit Vorrang haben, selbst wenn dafür Datenbankfunktionen geopfert werden.
• Für horizontale Skalierung entwerfen: Eine Architektur wählen, bei der sich mit wachsender Nutzerbasis Ressourcen hinzufügen lassen.