NewSQL versus traditionelle Optimierung / Sharding [geschlossen]

Wir sind ein kleines Startup mit einer schreiblastigen SAAS-App und kommen (endlich!) An den Punkt, an dem unsere Nutzung Skalierungsprobleme aufwirft. Wir haben ein kleines Team, daher wissen wir es sehr zu schätzen, Sysadmin an Heroku und RDS auszulagern.

Während Heroku (meistens) in Ordnung ist, haben wir ein paar Probleme mit RDS:

Skalierung. Dies ist die größte Sorge. Derzeit führen wir eine XL-RDS-Instanz aus. Wir werden mit einfachen Optimierungen noch eine Weile auskommen, aber wenn wir nicht einige wesentliche strukturelle Änderungen an unserer App vornehmen, werden wir irgendwann einen Engpass bekommen.

Auch die Ausfallzeit für das Ändern der Instanzgröße ist schlecht.

Verfügbarkeit. Wir führen eine Multi-AZ-Instanz aus, damit wir einen einzelnen AZ-Ausfall überstehen. Aber RDS basiert auf EBS, was mich angesichts der Geschichte und des Designs von EBS ziemlich beunruhigt.

Preis. Unsere RDS Rechnung ist 4x was wir Heroku bezahlen. Es macht mir nichts aus, Amazon dafür zu bezahlen, dass ich keinen Sysadmin anheuere, aber ich würde gerne etwas günstigeres finden.

Meiner Ansicht nach haben wir zwei Optionen für die Zukunft: den traditionellen Ansatz (Sharding, Ausführen eines nächtlichen Jobs, um Teile unserer Datenbank schreibgeschützt zu machen usw.); oder eine NewSQL-Lösung (Xeround, VoltDB, NimbusDB usw.).

Traditionelle Profis: Es wurde schon oft gemacht und es gibt ziemlich übliche Wege, dies zu tun.

Traditionelle Nachteile: Es wird viel Arbeit erfordern und die App erheblich komplexer machen. Es wird auch die sekundären Probleme mit RDS (Verfügbarkeit und Preis) nicht lösen.

NewSQL-Profis: Angeblich skalieren diese Lösungen unsere Datenbank horizontal, ohne den Anwendungscode zu ändern (vorbehaltlich einiger Einschränkungen der SQL-Funktionalität, z. B. der Nichtverwendung pessimistischer Sperren). Dies würde uns eine Menge Arbeit ersparen. Es würde auch die Zuverlässigkeit verbessern (kein Single Point of Failure) und die Kosten senken (keine XL-Instanz außerhalb der Geschäftszeiten ausführen müssen, nur um eine Spitzenauslastung zu gewährleisten).

NewSQL-Nachteile: Diese Lösungen sind relativ jung, und ich konnte keine guten Bewertungen oder Aufzeichnungen über die Erfahrungen der Leute mit ihnen in Produktions-Apps finden. Ich habe nur eine als gehostete Lösung (Xeround) gefunden. Ohne diese Lösung müssten wir also Ressourcen in sysadmin investieren.

Ich frage mich, was meine Meinung dazu ist, was meine beste Option wäre.

Xeround ist furchtbar verlockend (gehostetes NewSQL), aber ich habe keine guten Informationen für die Produktion gefunden. Bei den wenigen Tweets, die ich gesehen habe, haben sich die Leute darüber beschwert, dass es ein bisschen langsam ist. Ich bin ziemlich nervös, mich auf etwas zu begeben, das so ungetestet erscheint.

Die konservative Seite von mir sagt, ich solle bei RDS bleiben und einen traditionellen Ansatz verfolgen. Aber es wird sehr teuer in Bezug auf die Entwicklerzeit.

Und dann fragt sich ein Teil von mir, ob es einen anderen Weg gibt, vielleicht eine kampferprobte gehostete NewSQL-Lösung, von der ich noch nichts gehört habe. Oder vielleicht eine NewSQL-Lösung, die wir selbst hosten müssten, aber das hat eine wirklich solide Geschichte.

Vielen Dank im Voraus für Ihre Gedanken.

Antworten auf die Frage(3)

Ihre Antwort auf die Frage