Ich habe über eine Datenbank namens Starcounter gelesen. Es stellt fest, dass es Lasten handhaben kann, die eine "NoSql" -Datenbank nur verarbeiten kann, ohne Konsistenz zu verlieren. Soweit ich den CAP-Theorem verstehe, verliert man bei Verfügbarkeit von Konsistenz oder Verfügbarkeit die Verfügbarkeit oder Partitionstoleranz. Welchen Trick macht StarCounter also?
Ich kann mir vorstellen, dass StarCounter schnell ist, aber die Behauptung, dass NoSql Konsistenz verlieren muss, um mitzuhalten, scheint mir etwas seltsam zu sein. Kann mir bitte jemand erklären?
Vielen Dank im Voraus Roland
Das CAP-Theorem (aka Brewers Theorem) kann für eine einzelne Information (wie eine konsistente Datenbank) nicht geschlagen werden. Wenn Sie eine horizontal skalierte Datenbank haben, erhalten Sie keine Konsistenz und -Leistung. Diese Schlussfolgerung stammt aus den Gesetzen der Physik und lässt sich aus dem Brewerschen Theorem und Einsteins Relativitätstheorien ableiten. Sie müssen ein / aus skalieren, nicht aus. Nicht sehr "bewölkt", aber wie die Feinde von Galilei wahrscheinlich gestehen würden, wenn sie heute leben würden, macht die Natur einen schlechten Job bei der Auszeichnung menschlicher Mode.
Ich bin mir sicher, dass es andere Ansätze gibt, aber Starcounter funktioniert, indem er das Datenbankbild im RAM hostet. Anstatt Datenbankdaten in den Anwendungscode zu verschieben, werden Teile des Anwendungscodes in die Datenbank verschoben. Nur Daten in der endgültigen Antwort werden von dem ursprünglichen Platz im RAM-Speicher (wo sich die Daten an erster Stelle befanden) verschoben. Dadurch bleiben die meisten Daten bestehen, auch wenn Millionen von Anfragen pro Sekunde verarbeitet werden. Der Nachteil ist, dass die Datenbank die Programmiersprache Ihrer Anwendungslogik kennen muss. Der Vorteil liegt jedoch auf der Hand, wenn Sie jemals versucht haben, Millionen von HTTP-Anfragen pro Sekunde zu bedienen, die jeweils einen umfangreichen Datenbankzugriff erfordern.
Die Frage ist eine gute Frage. Es ist kein Wunder, dass Sie es seltsam finden, da es erst vor ein paar Jahren war, dass CAP bewiesen wurde (wurde zu einem Theorem). Viele Entwickler sind genauso enttäuscht wie ein Kind, wenn der theoretische Physiker ihm sagt, er solle aufhören, nach dem Perpetuum mobile zu suchen, weil es nicht funktionieren kann. Wir wollen immer noch die konsistente Scale-Out-Datenbank, nicht wahr?
Das CAP-Theorem besagt, dass jede Information keine Konsistenz (C), Verfügbarkeit (A) und Partitionstoleranz (P) haben kann. Es gilt für eine Informationseinheit (z. B. eine Datenbank). Sie können natürlich unabhängige Informationen haben, die anders funktionieren. Ein Stück könnte AP sein, ein anderes könnte CA sein und ein drittes könnte CP sein. Sie können nicht die gleichen Informationen wie CAP haben.
Das Problem mit der Unmöglichkeit des "P" in einer konsistenten und verfügbaren Datenbank führt dazu, dass eine horizontal skalierte Datenbank die Signalisierung zwischen den Knoten durchführen muss. Die Schlussfolgerung muss sein, dass selbst in hundert Jahren, CAP gibt, dass ein einzelnes Stück konsistenter Daten auf Hardware leben muss, die mit harten Drähten oder Lichtstrahlen verbunden ist.
Das Problem liegt in der Leistung, wenn Sie die horizontale Skalierung auf eine verfügbare konsistente Datenbank anwenden. Eine gute Leistung war der Grund für die horizontale Skalierung, das ist sehr schlecht. Da jeder Knoten immer dann mit den anderen Knoten kommunizieren muss, wenn es einen Datenbankzugriff gibt, um Konsistenz zu erreichen, und angesichts der Tatsache, dass die Signalisierung letztlich durch die Lichtgeschwindigkeit begrenzt ist, bleibt die traurige Tatsache, dass Datenbankwissenschaftler (wie auch CPU-Wissenschaftler) ) sind nicht nur hartnäckig, weil sie Scale-Out nicht als magische Wunderwaffe sehen. Es wird nicht passieren, weil es nicht passieren kann (jedoch könnten Teile Ihrer Datenbank in einem AP-Set platziert werden, also denken Sie daran, wir sprechen hier über konsistente Daten). Hinzufügen der Theorien von Einstein zum CAP-Theorem und der kleinen Box gewinnt das Cloud-Datenzentrum für konsistente Daten.
Der Zustand der Dinge in der Datenbank-Gemeinschaft ist ein bisschen wie der Zustand der Perpetuum Mobile-Maschinen, wenn Pferd und Wagen der Weg war, um zur Arbeit zu gelangen. Ohne theoretische Beweise dagegen, gewährten die Patentämter Hunderte von Patenten für unmögliche ewige Maschinen. Heute können wir darüber lachen, aber wir haben ähnliche Situationen in der Datenbankindustrie mit konsistenten Scale-Out-Datenbanken. Wenn Sie jemanden behaupten, dass er eine Scale-Out-ACID-Datenbank hat, seien Sie vorsichtig. Erst nach dem dot com crash haben Mathematiker am MIT bewiesen, dass Brewer direkt am CAP-Theorem offiziell geboren wurde, also ist die Jagd auf das Unmögliche leider noch nicht ausgestorben. Man kann dies, wenn man will, mit der Art und Weise vergleichen, wie Nachzügler jahrelang versuchten, die ewige Maschine zu erfinden, nachdem die moderne theoretische Physik sie vernünftigerweise hätte stoppen sollen. Alte Angewohnheiten sterben schwer (ich entschuldige mich bei jedem, der auf dem Stack Overflow ist und immer noch Zeichnungen von Lagern und Armen macht, die sich ad finitum bewegen - ich will nicht beleidigend sein).
Alles ist jedoch nicht verloren. Nicht alle Informationen müssen konsistent sein. Nicht alle Teile müssen horizontal skaliert werden. Sie müssen nur das Brewers-Theorem akzeptieren und das Beste daraus machen.
Bei Anwendungen wie Facebook wird Konsistenz unterdrückt. Dies ist in Ordnung, da Daten einmal eingegeben werden und dann von einem einzelnen Benutzer manipuliert werden.Dennoch können wir die Nebenwirkungen der alltäglichen Facebook-Nutzung erleben, wie Dinge, die für eine Weile in und aus der Existenz kommen.
In den meisten Geschäftsanwendungen müssen Daten jedoch korrekt sein. Die Summe aller Konten in Ihrer Buchhaltung muss null betragen. Ihr Lagerbestand muss gleich 8 sein, wenn Sie 2 von 10 Artikeln verkauft haben, auch wenn mehrere Nutzer aus demselben Bestand kaufen.
Das Problem beim Skalieren verfügbarer Daten besteht darin, dass Sie ohne Partitionstoleranz auskommen müssen. Dieses ausgefallene Wort bedeutet einfach, dass Sie jederzeit zwischen den Knoten in Ihrer Cloud signalisieren müssen. Und da das Licht ein paar Nanosekunden benötigt, um einen einzelnen Meter zurückzulegen, wird dies unmöglich, ohne dass das Scale-out-Ergebnis weniger Leistung als mehr Leistung bringt. Dies gilt natürlich nur für konsistente Daten. Die Implikationen davon sind den Ingenieuren von Intel, AMD, Oracle et. al für eine lange Zeit. Es ist nicht ihre Wissenschaftler haben nicht von der Skalierung gehört. Es ist nur so, dass sie die Welt akzeptieren, wie Einstein sie beschrieben hat.
Wenn Sie die Mathematik machen, finden Sie, dass ein einzelner PC Anweisungen für jeden Menschen hat, der auf der Erde lebt, für jede Sekunde, die er ausführt (google auf "moderne CPU" und "MIPS"). Wenn Sie etwas mehr Mathe machen, zum Beispiel den Gesamtumsatz von Amazon.com (Sie finden ihn auf www.nasdaq.com), geteilt durch den Preis eines durchschnittlichen Buches, werden Sie feststellen, dass die Gesamtzahl der Verkaufstransaktionen passen kann RAM eines einzelnen modernen PC. Die coole Sache ist, dass die Anzahl der Artikel, Kunden, Bestellungen, Produkte etc. die gleiche Menge an Platz belegt wie im Jahr 1950. Bilder, Video und Audio haben an Größe zugenommen, aber numerische und textuelle Informationen wachsen nicht Artikel. Sicher, die Anzahl der Transaktionen wächst, aber nicht in der gleichen Phase wie die Computerleistung wächst. Die logische Lösung besteht also darin, schreibgeschützte Daten und AP-Daten horizontal zu skalieren und Geschäftsdaten zu skalieren.
Datenbank-Engines und Geschäftslogik, die in einer VM ausgeführt werden (wie die Java VM oder die .NET CLR), verwenden normalerweise ziemlich effektiven Maschinencode. Dies bedeutet, dass das Verschieben von Speicher den Flaschenhals des Gesamtdurchsatzes für eine konsistente Datenbank überschattet. Dies wird oft als die Speicherwand bezeichnet (Wikipedia hat einige nützliche Informationen).
Der Trick besteht darin, Code in das Datenbankbild zu übertragen, anstatt Daten vom Datenbankbild in den Code zu übertragen (wenn ein MVC- oder ein MVVM-Muster verwendet wird). Dies bedeutet, dass der konsumierende Code im selben Adressraum wie das Datenbank-Image ausgeführt wird und dass Daten niemals verschoben werden (und die Festplatte lediglich Transaktionen und Images sichert). Daten können im ursprünglichen Datenbankbild verbleiben und müssen nicht in den Speicher der Anwendung kopiert werden. Anstatt die Datenbank als RAM-Datenbank zu behandeln, wird die Datenbank als Primärspeicher behandelt. Alles bleibt stehen.
Nur Daten, die Teil der endgültigen Benutzerantwort sind, werden aus dem Datenbankimage verschoben. Bei großen Anwendungen mit hunderten von Millionen gleichzeitiger Benutzer sind dies typischerweise nur wenige Millionen Anfragen pro Sekunde, was bei einem einzelnen PC kein Problem darstellt, da die HTTP-Paketierung auf Gateway-Servern erfolgt. Glücklicherweise skalieren solche Server wunderbar, da sie keine Daten gemeinsam nutzen müssen.
Wie sich herausstellt, ist die Festplatte bei sequentiellen Schreibvorgängen schnell, so dass eine überfallene Festplatte Terabytes bestehen oder sich jede Minute ändern kann.
Normalerweise skalieren Sie keinen Starcounter-Knoten. Es skaliert statt hinein. Dies funktioniert gut für einige Millionen gleichzeitige Benutzer. Um darüber hinauszugehen, müssen Sie weitere Starcounter-Knoten hinzufügen. Sie können verwendet werden, um Daten zu partitionieren (aber dann verlieren Sie Konsistenz und Starcounter ist nicht für die Partitionierung ausgelegt, daher ist es weniger elegant als Lösungen wie Volt DB). Eine bessere Alternative ist die Verwendung der zusätzlichen Starcounter-Knoten als Gateway-Server. Diese Server sammeln einfach alle eingehenden HTTP-Anfragen für jeweils eine Millisekunde an. Dies klingt nach kurzer Zeit, reicht aber aus, um tausende Anfragen zu sammeln, wenn Sie sich entschieden haben, Starcounter zu skalieren. Der Stapel von Anfragen wird dann tausend Mal pro Sekunde an den ZLATAN-Knoten (Zero Latency Atomicity Node) gesendet. Jeder dieser Stapel kann Tausende von Anfragen enthalten. Auf diese Weise können einige hundert Millionen Benutzersitzungen von einem einzelnen ZLATAN-Knoten bedient werden. Obwohl Sie mehrere ZLATAN-Knoten haben können, gibt es immer nur einen aktiven ZLATAN-Knoten. So wird das CAP-Theorem geehrt. Um darüber hinauszugehen, müssen Sie den gleichen Kompromiss wie Facebook und andere berücksichtigen.
Ein weiterer wichtiger Hinweis ist, dass der ZLATAN-Knoten keine Anwendungen mit Daten bereitstellt. Stattdessen wird der Code des Anwendungscontrollers vom ZLATAN-Knoten ausgeführt. Die Kosten für die Serialisierung / Deserialisierung und das Senden von Daten an eine Anwendung sind weitaus größer als die Verarbeitung der Steuerungslogikzyklen. I.e.Der Code wird an die Datenbank gesendet und nicht umgekehrt (ein herkömmlicher Ansatz besteht darin, dass die Anwendungen nach Daten fragen oder Daten senden).
Die Verwendung der Datenbank als "Heap" für die Programmiersprache anstelle eines Remote-Systems für die Serialisierung und Deserialisierung ist ein Trick, den Starcounter VMDBMS nennt. Wenn sich die Datenbank im RAM befindet, sollten Sie Daten nicht von einem Platz im RAM zu einem anderen Platz im RAM verschieben, was bei den meisten RAM-Datenbanken der Fall ist.
Es gibt keinen "Trick". Starcounter spricht von Geschwindigkeit, während CAP / NoSQL von Skalierbarkeit spricht. Es gibt einen Kompromiss zwischen Features + Skalierbarkeit vs. Geschwindigkeit.
Manchmal ist es in Ordnung, die Skalierbarkeit zu ignorieren, wenn Sie an anderen Stellen Engpässe nachweisen können. Zum Beispiel sollte sich ein neuer Startup nicht darum kümmern, dass seine Website auf eine Million Nutzer skaliert wird. Sie sollten sich darum sorgen, ihre ersten hundert Nutzer zu bekommen. (Erinnert sich jemand daran, wie oft Twitter in den frühen Tagen ausgefallen war?) Starcounter kann nützlich sein, wenn die Transaktionsrate viel höher ist als die Trefferquote Ihrer Webseite.
Auf der anderen Seite vertraue ich niemandem, der alle "NoSQL" -Datenbanken zusammenfasst. Die verschiedenen NoSQL-Datenbanken sind unterschiedlicher als gleich. Sie haben radikal unterschiedliche Architekturen und Eigenschaften. Einige von ihnen skalieren auf Tausende von Knoten, einige von ihnen skalieren nicht über einen Knoten hinaus. Manchmal verlangsamt das Hinzufügen von Skalierbarkeit Sie. Manchmal beschleunigt das Entfernen von Features Sie.
Tags und Links nosql cap starcounter