it-swarm.com.de

Warum kann Twitter nicht skaliert werden, indem es Server hinzufügt, wie Websites wie Facebook?

Ich habe nach einer Erklärung gesucht, warum Twitter einen Teil seiner Middleware von Rails nach Scala migrieren musste. Was hinderte sie daran, die Art und Weise zu skalieren, die Facebook hat, indem es Server hinzufügte, wenn seine Benutzerbasis erweitert wurde. Genauer gesagt, was mit der Ruby/Rails-Technologie hat das Twitter-Team davon abgehalten, diesen Ansatz zu verfolgen?

50
Jason

Es ist nicht so, dass Rails nicht skaliert, sondern Anfragen nach "Live" -Daten in Ruby (oder einer beliebigen interpretierten Sprache) sind nicht skalierbar, da sie sowohl hinsichtlich der CPU- als auch der Speicherauslastung vergleichsweise viel teurer sind als ihre kompilierten Sprachpartner .

Wäre Twitter eine andere Art von Service, mit derselben enormen Benutzerbasis, aber mit seltener geänderten Daten, könnte Rails über das Zwischenspeichern eine praktikable Option sein. d. h. das vollständige Vermeiden von Live-Anforderungen an den Rails-Stack und das Abladen an den Front-End-Server und/oder den DB-Cache im Arbeitsspeicher. Ein hervorragender Artikel zu diesem Thema:

Wie Basecamp Next so verdammt schnell werden konnte

Allerdings hat Twitter Rails nicht allein wegen Skalierungsproblemen aufgegeben, sondern es wurde gewechselt, da Scala als Sprache bestimmte integrierte Garantien für den Status Ihrer Anwendung bietet, die interpretierte Sprachen nicht bieten können: Wenn dies kompiliert wird, können Zeitverschwendung wie Fettfinger-Tippfehler, falsche Methodenaufrufe, falsche Typdeklarationen usw. können einfach nicht existieren.

Für Twitter war TDD nicht genug. Ein Zitat von Dijkstra in Programming in Scala veranschaulicht diesen Punkt: "Testen kann nur das Vorhandensein von Fehlern beweisen, niemals ihre Abwesenheit". Als ihre Anwendung wuchs, wurden sie immer schwieriger, Fehler zu finden. Die magische Mystery-Tour wurde ein Hindernis für die Performance, und so wurde der Wechsel vorgenommen. Alles in allem ein überwältigender Erfolg, Twitter ist für Scala das, was Facebook PHP ist (obwohl Facebook einen eigenen ultraschnellen C++ - Präprozessor verwendet, der etwas schummelt ;-))

Zusammenfassend hat Twitter die Umstellung auf Leistung und Zuverlässigkeit vorgenommen. Natürlich neigt Rails dazu, sich an der Spitze der Innovation zu befinden, so dass die zu 99% nicht auf Twitter gehandelten Anwendungen der Welt mit einer interpretierten Sprache gut auskommen können (obwohl ich jetzt fest auf der kompilierten Sprache des Zauns stehe , Scala ist einfach zu gut!)

55
virtualeyes

Keine Plattform kann unendlich skaliert werden, während immer noch komplexe Datensätze verarbeitet werden, die sich von Moment zu Moment ändern. Sprache und Infrastruktur sind wichtig, aber wie Sie Ihre Site erstellen und wie die Datenzugriffsmuster aussehen, ist wichtiger.

Wenn Sie schon einmal Spiele wie Transport Tycoon oder Siedler gespielt haben, bei denen Sie Ressourcen transportieren müssen, wissen Sie, wie Sie mit der zunehmenden Nutzung der Infrastruktur auf dem neuesten Stand bleiben müssen. 

Das Skalieren von Plattformen wie Facebook und Twitter ist eine unendliche Aufgabe. Sie haben eine ständig wachsende Anzahl von Benutzern, und Sie müssen immer mehr Funktionen und Funktionen hinzufügen. Es ist ein kontinuierlicher Prozess des Upgrades eines Bits, der ein anderes Bit mehr belastet. 

Server auf das Problem zu werfen ist nicht immer die Antwort und kann manchmal mehr Probleme verursachen. 

11
user111013

http://highscalability.com/scaling-Twitter-making-Twitter-10000-percent-faster Links zu einer Reihe von Beiträgen zu den Änderungen, einschließlich einer anständigen Historie der im Laufe der Zeit unternommenen Schritte.

Die kurze Version ist, dass Ruby und Rails nicht die Leistung und Zuverlässigkeit bieten, die sie für den Service benötigen. Angesichts der Skala ist dies nicht überraschend. Die meisten COTS-Lösungen sind am großen Ende der Skala nicht zufriedenstellend.

Hohe Skalierbarkeit deckt viele Fragen zur Architektur an diesem oberen Ende für andere Standorte ab, sodass auch weitergehende Fragen in der Umgebung beantwortet werden können.

9
Daniel Pittman

Sie hätten vielleicht mehr Hardware auf das Problem werfen können, aber es ist viel teurer als einfach effizienteren Code zu schreiben. Wie viele High-Level-Frameworks ist Ruby on Rails in vielen Bereichen eine großartige Sache, aber Hochleistung gehört nicht dazu. Kompilierte Sprachen sind immer schneller als interpretierte Sprachen.

5
sosborn

Facebook (und Google) lassen sich durch Hinzufügen weiterer Server skalieren, bündeln jedoch gleichzeitig ihre Anwendung in verschiedene Dienste. Diese Dienste kommunizieren über eine vereinbarte Schnittstelle und einen bestimmten Typ, und sie können diese Dienste nun mit jeder Technologie ausbauen, die sie für richtig halten. Nur weil Sie lesen, dass Facebook PHP verwendet, bedeutet das nicht, dass alle Backend-Dienste von PHP bedient werden (und es macht auch keinen Sinn, da Sie in SOA einen beliebigen technischen Stack wählen können).

Ich denke, dieses Video ist die beste Antwort auf Ihre Frage:

"Von Ruby zur JVM" https://www.youtube.com/watch?v=ohHdZXnsNi8

1
Blankman

Lineare Zuwächse mit Parallelität (wie dies bei mehreren Servern der Fall ist) sind äußerst selten und sehr anwendungsabhängig. Ja, das gibt es - so erledigt die GPU den größten Teil ihrer Arbeit. Wenn Sie statische Seiten ohne Sitzungsstatus bereitstellen, ist dies auch der Fall.

In den meisten Fällen wird die Leistung durch Hinzufügen von Servern jedoch nicht linear erhöht (dh 10 Server sind nicht zehnmal schneller als 1 Server), und bedeutet , dass Sie Gewinne erzielen können auf einem einzelnen Server hat viel mehr Auswirkungen als nur das Hinzufügen von Servern. Es ist nicht so, dass Twitter keine Server hat, oder?

0

Ich denke, ein wichtiges bisschen fehlt hier die Plattform. Ja, wir hatten das kompilierte vs. interpretierte Argument und ein paar andere. Ein sehr wichtiger Aspekt war in der Tat die Plattform. Es gibt verschiedene Ruby-VMs, aber keine hat Twitter gefallen, obwohl sie es ziemlich gut gemacht haben. Aber Scala läuft auf der JVM, und Twitter-Ingenieure haben damit ziemlich viel Erfahrung. Warum haben sie JRuby nicht ausprobiert? Nun, ich denke, die oben genannten Gründe kommen hier ins Spiel.

0