Hallo zusammen, ich bin Bucai Chen~
YouTube ist nach Google die zweitbeliebteste Website. Im Mai 2019 wurden jede Minute mehr als 500 Stunden Videoinhalte auf die Plattform hochgeladen.
Die Video-Sharing-Plattform hat mehr als 2 Milliarden Nutzer, wobei täglich mehr als 1 Milliarde Stunden Video abgespielt werden und Milliarden von Aufrufen generiert werden. Das sind unglaubliche Zahlen.
Dieser Artikel bietet eine ausführliche Erläuterung der von YouTube verwendeten Datenbank und Back-End-Dateninfrastruktur, die es der Videoplattform ermöglicht, so große Datenmengen zu speichern und auf Milliarden von Nutzern zu skalieren.
Dann lasst uns anfangen.
1. Einführung
Die Reise von YouTube begann im Jahr 2005. Da das mit Risikokapital finanzierte Technologie-Startup weiterhin Erfolg hatte, wurde es im November 2006 von Google für 1,65 Milliarden US-Dollar übernommen.
Vor der Übernahme durch Google bestand ihr Team aus:
- Zwei Systemadministratoren
- Zwei Skalierbarkeitssoftware-Architekten
- Zwei Feature-Entwicklern
- Zwei Netzwerktechnikern
- One Name DBA
2. Backend-Infrastruktur
YouTube‘ s Backend-Microservices werden in Python, Datenbank, Hardware, Java (unter Verwendung des Guice-Frameworks) und Go geschrieben. Die Benutzeroberfläche ist mit JavaScript geschrieben.
Die Hauptdatenbank ist MySQL, das von Vitess unterstützt wird. Vitess ist ein Datenbankclustersystem, das zur horizontalen Erweiterung von MySQL verwendet wird. Verwenden Sie außerdem Memcache zum Caching und Zookeeper für die Knotenkoordination.
Beliebte Videos werden über ein CDN bereitgestellt, während allgemeine, weniger häufig abgespielte Videos aus der Datenbank abgerufen werden.
Wenn jedes Video hochgeladen wird, erhält es eine eindeutige Kennung und wird von einem Batch-Job verarbeitet. Dieser Job führt mehrere automatisierte Prozesse aus, wie z. B. das Generieren von Miniaturansichten, Metadaten, Videoskripten, Kodierung, Festlegen des Monetarisierungsstatus und mehr.
VP9 und H.264/MPEG-4 AVC Advanced Video Coding-Codecs werden zur Videokomprimierung verwendet und sind in der Lage, Videos in HD- und 4K-Qualität mit der halben Bandbreite anderer Encoder zu kodieren.
Video-Streaming verwendet Dynamic Adaptive Streaming basierend auf dem HTTP-Protokoll, einer adaptiven Bitraten-Streaming-Technologie, mit der hochwertiges Video-Streaming von einem herkömmlichen HTTP-Webserver erreicht werden kann. Mit dieser Technologie können den Zuschauern Inhalte mit unterschiedlichen Bitraten bereitgestellt werden. Der YouTube-Client passt die Videowiedergabe automatisch an die Internetverbindungsgeschwindigkeit des Betrachters an, um Pufferzeiten zu minimieren.
Ich habe den Videotranskodierungsprozess von YouTube einmal in einem speziellen Artikel besprochen, siehe „Wie YouTube qualitativ hochwertige Videos mit geringer Latenz bereitstellt“.
Hier finden Sie eine kurze Einführung in die Backend-Technologie der Plattform. Die von YouTube verwendete Hauptdatenbank ist MySQL. Lassen Sie uns nun herausfinden, warum das Entwicklerteam von YouTube das Bedürfnis verspürte, Vitess zu schreiben. Welche Probleme hatten sie mit ihrer ursprünglichen MySQL-Umgebung, die sie dazu veranlassten, ein zusätzliches Framework darüber zu implementieren?
3. Warum Sie Vitess benötigen
Die Website verfügt zunächst nur über eine Datenbankinstanz. Wenn die Website wächst, müssen Entwickler die Datenbank horizontal erweitern, um den steigenden QPS-Anforderungen (Abfragen pro Sekunde) gerecht zu werden.
3.1 Master-Slave-Replik
Das Replikat wird der Master-Datenbankinstanz hinzugefügt. Leseanforderungen werden an die Primärdatenbank und Replikate weitergeleitet, um die Belastung der Primärdatenbank zu verringern. Das Hinzufügen von Replikaten trägt dazu bei, Engpässe zu lindern, den Lesedurchsatz zu erhöhen und die Haltbarkeit des Systems zu erhöhen.
Der Masterknoten verarbeitet den Schreibverkehr, und der Masterknoten und der Replikatknoten verarbeiten gleichzeitig den Leseverkehr.
In diesem Szenario ist es jedoch möglich, veraltete Daten aus dem Replikat zu lesen. Wenn eine Anfrage die Daten des Replikats liest, bevor der Master die Informationen auf dem Replikat aktualisiert, erhält der Viewer veraltete Daten.
Zu diesem Zeitpunkt sind die Daten des Masterknotens und des Replikatknotens inkonsistent. In diesem Fall handelt es sich bei den inkonsistenten Daten um die Anzahl der Aufrufe eines bestimmten Videos auf dem Primär- und Replikatknoten.
Eigentlich ist das überhaupt kein Problem. Den Zuschauern wird eine leichte Inkonsistenz bei der Anzahl der Aufrufe doch nichts ausmachen, oder? Darüber hinaus kann das Video in ihrem Browser gerendert werden.
Die Daten zwischen dem Masterknoten und dem Replikatknoten werden schließlich konsistent sein.
Die Ingenieure waren also sehr zufrieden und auch das Publikum war sehr zufrieden. Mit der Einführung von Replikaten geht es reibungslos voran.
Die Website erfreut sich weiterhin großer Beliebtheit und die QPS steigen weiter. Die Master-Slave-Replika-Strategie hat nun Schwierigkeiten, mit dem Wachstum des Website-Verkehrs Schritt zu halten.
Was jetzt tun?
3.2 Sharding
Die nächste Strategie besteht darin, die Datenbank zu fragmentieren. Sharding ist neben Master-Slave-Repliken, Master-Master-Repliken, Föderationen und Denormalisierung eine der Möglichkeiten, relationale Datenbanken zu erweitern.
Datenbank-Sharding ist kein einfacher Prozess. Dies erhöht die Komplexität des Systems erheblich und erschwert die Verwaltung.
Allerdings muss die Datenbank fragmentiert werden, um dem Wachstum von QPS gerecht zu werden. Nachdem Entwickler die Datenbank aufgeteilt haben, werden die Daten auf mehrere Computer verteilt. Dadurch erhöht sich der Schreibdurchsatz des Systems. Anstatt nur eine Master-Instanz für die Verarbeitung von Schreibvorgängen zuständig zu sein, können Schreibvorgänge jetzt auf mehreren Shard-Maschinen erfolgen.
Außerdem werden für jede Maschine separate Kopien erstellt, um Redundanz und Durchsatz zu gewährleisten.
Die Popularität der Plattform nimmt weiter zu, da von Content-Erstellern große Datenmengen zur Datenbank hinzugefügt werden.
Um Datenverluste oder die Nichtverfügbarkeit von Diensten aufgrund von Maschinenausfällen oder unbekannten externen Ereignissen zu verhindern, ist es notwendig, dem System Katastrophenmanagementfunktionen hinzuzufügen.
3.3 Katastrophenmanagement
Unter Katastrophenmanagement versteht man Notfallmaßnahmen bei Stromausfällen und Naturkatastrophen (z. B. Erdbeben, Brände). Es muss redundant sein und Benutzerdaten in Rechenzentren in verschiedenen geografischen Regionen der Welt sichern. Der Verlust von Benutzerdaten oder die Nichtverfügbarkeit des Dienstes sind nicht gestattet.
Das Vorhandensein mehrerer Rechenzentren auf der ganzen Welt trägt außerdem dazu bei, dass YouTube die Systemlatenz reduziert, da Benutzeranfragen an das nächstgelegene Rechenzentrum weitergeleitet werden, anstatt an Ursprungsserver auf verschiedenen Kontinenten weitergeleitet zu werden.
Jetzt können Sie sich vorstellen, wie komplex die Infrastruktur werden kann.
Oft führen nicht optimierte vollständige Tabellenscans zum Absturz der gesamten Datenbank. Datenbanken müssen vor fehlerhaften Abfragen geschützt werden. Alle Server müssen nachverfolgt werden, um einen effizienten Service zu gewährleisten.
Entwickler benötigen ein System, das die Komplexität des Systems abstrahiert, es ihnen ermöglicht, Skalierbarkeitsprobleme zu lösen und das System mit minimalen Kosten zu verwalten. All dies führte dazu, dass YouTube Vitess entwickelte.
4.Vitess: Ein System zur horizontalen Erweiterung des MySQL-Datenbankclusters
Vitess ist ein Datenbankclustersystem, das auf MySQL läuft und eine horizontale Erweiterung von MySQL ermöglicht. Es verfügt über integrierte Sharding-Funktionen, die es Entwicklern ermöglichen, die Datenbank zu skalieren, ohne der Anwendung Sharding-Logik hinzufügen zu müssen. Dies ähnelt der Funktionsweise von NoSQL.
Vitess übernimmt auch Failover und Backup automatisch. Es verwaltet Server und verbessert die Datenbankleistung, indem es ressourcenintensive Abfragen intelligent umschreibt und Caching implementiert. Neben YouTube wird das Framework auch von anderen namhaften Playern der Branche genutzt, wie beispielsweise GitHub, Slack, Square, New Relic usw.
Vitess kommt ins Spiel, wenn Sie Unterstützung für ACID-Transaktionen und starke Konsistenz benötigen und gleichzeitig eine relationale Datenbank genauso schnell skalieren möchten wie eine NoSQL-Datenbank.
Bei YouTube hat jede MySQL-Verbindung einen Overhead von 2 MB. Für jede Verbindung fallen kalkulierte Kosten an, und wenn die Anzahl der Verbindungen zunimmt, muss zusätzlicher RAM hinzugefügt werden.
Vitess ist in der Lage, diese Verbindungen zu sehr geringen Kosten über einen Verbindungspool zu verwalten, der auf der Parallelitätsunterstützung der Programmiersprache Go basiert. Es verwendet Zookeeper, um den Cluster zu verwalten und auf dem neuesten Stand zu halten.
5. Bereitstellung in der Cloud
Vitess ist Cloud-nativ und eignet sich gut für die Cloud-Bereitstellung, da die Kapazität genau wie beim Cloud-Modell schrittweise zur Datenbank hinzugefügt wird. Es kann als Kubernetes-fähige, cloudnative verteilte Datenbank ausgeführt werden.
Bei YouTube läuft Vitess in einer Containerumgebung und nutzt Kubernetes als Container-Orchestrierungstool.
Im heutigen Computerzeitalter läuft jeder große Dienst in der Cloud in einer verteilten Umgebung. Die Ausführung von Diensten in der Cloud bietet viele Vorteile.
Google Cloud Platform ist eine Reihe von Cloud-Computing-Diensten, die auf derselben Infrastruktur basieren, die auch die internen Endbenutzerprodukte von Google wie Google Search und YouTube verwenden.
Jeder große Onlinedienst verfügt über eine polyglotte Persistenzarchitektur, da ein Datenmodell, ob relational oder NoSQL, nicht alle Nutzungsszenarien des Dienstes abdecken kann.
Während der Recherche für diesen Artikel konnte ich keine Liste spezifischer Google Cloud-Datenbanken finden, die von YouTube verwendet werden. Ich bin mir jedoch ziemlich sicher, dass dort GCP-spezifische Produkte wie Google Cloud Spanner, Cloud SQL, Cloud Datastore, Memorystore usw. verwendet werden. usw. Verschiedene Funktionen laufender Dienste.
In diesem Artikel werden die Datenbanken beschrieben, die von anderen Google-Diensten wie Google Adwords, Google Finance, Google Trends usw. verwendet werden.
6.CDN
YouTube nutzt das globale Netzwerk von Google für die Bereitstellung von Inhalten mit geringer Latenz und geringen Kosten. Mit global verteilten POP-Edge-Punkten ermöglicht es Kunden, Daten schneller abzurufen, ohne sie vom Ursprungsserver abrufen zu müssen.
Bisher habe ich über die von YouTube verwendeten Datenbanken, Frameworks und Technologien gesprochen. Jetzt ist es an der Zeit, über Speicher zu sprechen.
Wie speichert YouTube so große Datenmengen (jede Minute werden 500 Stunden Videoinhalt hochgeladen)?
7. Datenspeicherung: Wie speichert YouTube so große Datenmengen?
Videos werden auf Festplatten in Google-Rechenzentren gespeichert. Diese Daten werden von Google File System und BigTable verwaltet.
GFS Google File System ist ein verteiltes Dateisystem, das von Google für die Verwaltung großer Datenmengen in verteilten Umgebungen entwickelt wurde.
BigTable ist ein verteiltes Datenspeichersystem mit geringer Latenz, das auf dem Google File System basiert und zur Verarbeitung von Daten auf PB-Ebene verwendet wird, die auf Tausenden von Maschinen verteilt sind. Es wird in mehr als 60 Google-Produkten verwendet.
Das Video wird also auf der Festplatte gespeichert. Beziehungen, Metadaten, Benutzereinstellungen, Profilinformationen, Kontoeinstellungen, zugehörige Daten, die zum Abrufen des Videos aus dem Speicher usw. benötigt werden, werden alle in MySQL gespeichert.
7.1 Kommerzielle Plug-and-Play-Server
Google-Rechenzentren verfügen über homogene Hardware und die Software wird intern entwickelt, um Tausende unabhängiger Servercluster zu verwalten.
Die von Google bereitgestellten Server können die Speicherkapazitäten des Rechenzentrums verbessern. Es handelt sich bei allen um kommerzielle Server (Commodity-Server), die auch als kommerzielle Standardserver (kommerzielle Standardserver) bezeichnet werden. Diese Server sind preisgünstig, weit verbreitet und werden in großen Mengen gekauft. Sie können die gleiche Hardware im Rechenzentrum mit minimalem Kosten- und Kostenaufwand ersetzen oder konfigurieren.
Da der Bedarf an zusätzlichem Speicher steigt, werden neue Commodity-Server in das System eingebunden.
Nach Auftreten von Problemen werden kommerzielle Server in der Regel direkt ausgetauscht statt repariert. Sie sind nicht maßgeschneidert und ihre Verwendung ermöglicht es Unternehmen, die Infrastrukturkosten im Vergleich zum Betrieb maßgeschneiderter Server erheblich zu senken.
7.2 Speicherfestplatten für Rechenzentren
YouTube benötigt täglich über ein Petabyte neuen Speicher. Rotierende Festplatten sind aufgrund ihrer geringen Kosten und hohen Zuverlässigkeit das primäre Speichermedium.
SSD-Solid-State-Laufwerke haben eine höhere Leistung als rotierende Festplatten, da sie auf Halbleitern basieren, aber der Einsatz von SSDs in großem Maßstab ist nicht kosteneffektiv.
Sie sind ziemlich teuer und neigen dazu, mit der Zeit Daten zu verlieren. Daher sind sie für die Speicherung von Archivdaten ungeeignet.
Außerdem entwickelt Google eine neue Serie von Festplatten, die für große Rechenzentren geeignet sind.
Es gibt fünf Schlüsselmetriken, anhand derer die Qualität der für die Datenspeicherung gebauten Hardware beurteilt werden kann:
- Die Hardware sollte in der Lage sein, Hochgeschwindigkeits-Ein- und Ausgabevorgänge in der Größenordnung von Sekunden zu unterstützen.
- Es sollte den von der Organisation festgelegten Sicherheitsstandards entsprechen.
- Es sollte eine höhere Speicherkapazität im Vergleich zu gewöhnlicher Speicherhardware haben.
- Die Anschaffungskosten für Hardware, die Stromkosten und die Wartungskosten sollten alle akzeptabel sein.
- Festplatten sollten zuverlässig und latenzstabil sein.
Das obige ist der detaillierte Inhalt vonWie speichert YouTube riesige Videodateien?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
