Neulich habe ich erfahren, dass (es wird gesagt, wegen der Änderungen der Lizenz). Das hat mich zum Nachdenken gebracht, denn in den letzten Jahren habe ich eine Menge Artikel gesehen, die beschreiben, wie schrecklich MongoDB ist und dass niemand es jemals benutzen sollte. Aber in dieser Zeit ist MongoDB zu einem viel ausgereifteren Produkt geworden. Was ist passiert? Erklärt sich all der Hass wirklich aus den Anfangsfehlern im Marketing dieser neuen Datenbank? Oder wenden die Leute MongoDB einfach nicht dort an, wo es notwendig ist?
Wenn Sie zufällig denken, dass ich MongoDB verteidige, lesen Sie bitte am Ende des Artikels.
Neuer Trend
Ich arbeite seit mehr Jahren in der Softwarebranche, als man angenehm sagen kann, aber dennoch habe ich nur einen kleinen Teil der Trends erlebt, die unsere Branche getroffen haben. Ich habe das Aufkommen von 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... die Liste ist endlos. Jedes Jahr tauchen neue Tendenzen auf. Einige verlöschen schnell, während andere die Art und Weise, wie Software entwickelt wird, grundlegend verändern.
Rund um jeden neuen Trend entsteht ein gewisser allgemeiner Hype: Die Menschen springen entweder selbst in das Boot oder sehen den Lärm, der von anderen erzeugt wird – und folgen dem Pulk. Dieser Prozess wurde von der Firma Gartner in kodifiziert. Obwohl umstritten, beschreibt dieses Diagramm ungefähr, was mit Technologien passiert, bevor sie letztendlich nützlich werden.
Aber gelegentlich erscheint (oder ist eine zweite Ankunft, wie in diesem Fall) eine neue Innovation, die nur durch eine bestimmte Implementierung angetrieben wird. Im Falle von NoSQL war der Hype stark durch das Aufkommen und den raschen Aufstieg von MongoDB geprägt. Nicht MongoDB hat diesen Trend ins Leben gerufen: Tatsächlich hatten große Internetunternehmen Probleme mit der Verarbeitung großer Datenmengen, was zur Rückkehr nicht-relationaler Datenbanken führte. Die allgemeine Bewegung begann mit Projekten wie Bigtable von Google und Cassandra von Facebook, aber genau MongoDB wurde zur bekanntesten und zugänglichsten Implementierung der NoSQL-Datenbank, auf die die meisten Entwickler Zugriff hatten.
Hinweis: Sie könnten denken, dass ich Dokumentdatenbanken mit spaltenorientierten Datenbanken, Schlüssel/Wert-Speichern oder einem der zahlreichen anderen Datenspeichertypen mische, die unter die allgemeine Definition von NoSQL fallen. Und Sie haben recht. Aber zu der Zeit herrschte Chaos. Alle waren besessen von NoSQL, es wurde jedem wichtig. absolut notwendig, obwohl viele die Unterschiede zwischen den verschiedenen Technologien nicht gesehen haben. Für viele ist MongoDB zu einem Synonym für NoSQL geworden.
Und die Entwickler stürzten sich darauf. Die Vorstellung einer schemafreien Datenbank, die magisch skaliert, um jedes Problem zu lösen, war ziemlich verlockend. Um 2014 schien es, dass überall, wo ein Jahr zuvor eine relationale Datenbank wie MySQL, Postgres oder SQL Server verwendet wurde, MongoDB-Datenbanken bereitgestellt wurden. Auf die Frage, warum, könnten Sie eine banale Antwort wie "es ist die Skalierung des Webs" oder eine durchdachtere Meinung wie "meine Daten sind sehr schwach strukturiert und passen gut in eine schemafreie Datenbank" erhalten.
Es ist wichtig zu bedenken, dass MongoDB und Dokumentendatenbanken im Allgemeinen eine Reihe von Problemen im Vergleich zu traditionellen relationalen Datenbanken lösen:
- Strenges Schema: Bei einer relationalen Datenbank sind Sie gezwungen, wenn Sie dynamisch generierte Daten haben, entweder eine Menge zufälliger "verschiedener" Daten-Spalten zu erstellen, Blobs von Daten zu stopfen oder eine ... all dies hat erhebliche Nachteile.
- Schwierigkeiten beim Skalieren: Wenn die Daten so umfangreich sind, dass sie nicht auf einen Server passen, bietet MongoDB Mechanismen, um sie auf mehreren Maschinen zu skalieren.
- Komplexe Schemaänderungen: keine Migrationen! In einer relationalen Datenbank kann die Änderung der Datenbankstruktur ein großes Problem darstellen (besonders wenn die Datenmenge sehr groß wird). MongoDB hat den Prozess erheblich vereinfacht. Es wurde so einfach gestaltet, dass Sie das Schema einfach unterwegs aktualisieren und sehr schnell vorankommen können.
- Schreibgeschwindigkeit: Die Leistung von MongoDB war gut, insbesondere bei angemessener Konfiguration. Selbst die Originalkonfiguration von MongoDB, für die sie oft kritisiert wurde, zeigte einige beeindruckende Leistungsdaten.
Alle Risiken liegen bei Ihnen
Die potenziellen Vorteile von MongoDB waren enorm, insbesondere für bestimmte Klassen von Problemen. Wenn man die obige Liste liest, ohne den Kontext zu verstehen und ohne Erfahrung zu haben, könnte man den Eindruck gewinnen, dass MongoDB tatsächlich eine revolutionäre DBMS ist. Das einzige Problem war, dass die oben genannten Vorteile mit einer Reihe von Vorbehalten verbunden waren, von denen einige unten aufgeführt sind.
Um der Gerechtigkeit willen, wird niemand bei 10gen/MongoDB Inc. sagen, dass das Folgende unwahr ist; es sind einfach Kompromisse.
- Verlust von Transaktionen: Transaktionen sind ein Hauptmerkmal vieler relationaler Datenbanken (nicht aller, aber der meisten). Transaktionsfähigkeit bedeutet, dass Sie mehrere Operationen atomar ausführen können und garantieren können, dass die Daten konsistent bleiben. Natürlich kann die Transaktionsfähigkeit bei einer NoSQL-Datenbank innerhalb eines Dokuments oder mithilfe von Zwei-Phasen-Commits erreicht werden, um transaktionale Semantik zu erhalten. Aber Sie müssen diese Funktionalität selbst implementieren... was eine komplexe und mühsame Aufgabe sein kann. Oft bemerken Sie die Probleme nicht, bis Sie sehen, dass die Daten in der Datenbank in ungültige Zustände geraten, weil es unmöglich ist, die Atomarität der Operationen zu garantieren. Hinweis: Viele haben mir mitgeteilt, dass in MongoDB 4.0 im letzten Jahr Transaktionen eingeführt wurden, aber mit einer Reihe von Einschränkungen. Die Schlussfolgerung aus dem Artikel bleibt die gleiche: Bewerten Sie, inwieweit die Technologie Ihren Bedürfnissen entspricht.
- Verlust relationaler Integrität (Fremdschlüssel): Wenn Ihre Daten Beziehungen enthalten, müssen Sie diese im Anwendungscode berücksichtigen. Eine Datenbank, die diese Beziehungen einhält, erleichtert erheblich die Anwendung und somit auch die Arbeit Ihrer Programmierer.
- Fehlende Möglichkeit, Datenstrukturen anzuwenden: Strenge Schemata können manchmal ein großes Problem darstellen, sind aber auch ein leistungsfähiges Mittel zur guten Datenstrukturierung, wenn sie richtig eingesetzt werden. Dokumentenbasierte Datenbanken wie MongoDB bieten eine unglaubliche Flexibilität im Schema, doch diese Flexibilität überträgt die Verantwortung für die Datenintegrität auf den Benutzer. Wenn Sie sich nicht darum kümmern, müssen Sie letztendlich viel Code in der Anwendung schreiben, um mit Daten umzugehen, die nicht in der Form gespeichert sind, die Sie erwarten. Wie oft in unserem Unternehmen Simple Thread gesagt wird... eine Anwendung wird irgendwann neu geschrieben, aber die Daten werden für immer bestehen bleiben. Hinweis: MongoDB unterstützt die Schemaüberprüfung: sie ist nützlich, bietet jedoch nicht die gleichen Garantien wie eine relationale Datenbank. Zunächst beeinflusst das Hinzufügen oder Ändern der Schemaüberprüfung keine vorhandenen Daten in der Sammlung. Sie müssen sicherstellen, dass Sie die Daten gemäß dem neuen Schema aktualisieren. Entscheiden Sie selbst, ob dies für Ihre Bedürfnisse ausreichend ist.
- Eigene Abfragesprache / Verlust des Ökosystems von Werkzeugen: Die Einführung von SQL war eine absolute Revolution, und seitdem hat sich nichts verändert. Es ist eine unglaublich leistungsfähige Sprache, aber auch ziemlich komplex. Die Notwendigkeit, Abfragen an eine Datenbank in einer neuen Sprache zu konstruieren, die aus JSON-Schnipseln besteht, wird von erfahrenen SQL-Nutzern als ein großer Rückschritt angesehen. Es gibt ein ganzes Universum von Werkzeugen, die mit SQL-Datenbanken interagieren: von IDEs bis hin zu Reporting-Tools. Der Wechsel zu einer Datenbank, die kein SQL unterstützt, bedeutet, dass Sie die meisten dieser Werkzeuge nicht verwenden können oder die Daten in SQL umwandeln müssen, was sich als schwieriger herausstellen kann, als Sie denken.
Viele Entwickler, die MongoDB ausprobiert haben, verstanden die Kompromisse nicht recht und tauchten oft kopfüber ein, indem sie sie als primären Datenspeicher einrichteten. Danach war es häufig unglaublich schwierig, zurückzukehren.
Was hätte anders gemacht werden können?
Nicht alle sprangen kopfüber und schlugen auf den Boden auf. Aber viele Projekte haben MongoDB dort installiert, wo sie einfach nicht hinpasste – und sie müssen noch viele Jahre damit leben. Wenn diese Organisationen etwas Zeit in die systematische Überlegung ihrer Technologieauswahl investiert hätten, hätten viele eine andere Wahl getroffen.
Wie wählt man die richtige Technologie aus? Es gab einige Versuche, einen systematischen Rahmen zur Bewertung von Technologien zu schaffen, wie z. B. und , aber ich denke, dass es übertrieben kompliziert ist.
Viele Technologien können vernünftig bewertet werden, indem man nur zwei grundlegende Fragen stellt. Das Problem besteht darin, Personen zu finden, die verantwortungsbewusst darauf antworten können, sich Zeit nehmen, um Antworten zu suchen und ohne Vorurteile.
Wenn Sie auf kein Problem stoßen, brauchen Sie kein neues Werkzeug. Punkt.
Frage 1: Welche Probleme versuche ich zu lösen?
Wenn Sie mit einem bestimmten Problem nicht konfrontiert sind, benötigen Sie kein neues Werkzeug. Punkt. Es ist nicht nötig, nach einer Lösung zu suchen und dann ein Problem zu erfinden. Wenn Sie nicht auf ein Problem gestoßen sind, das die neue Technologie deutlich besser löst als Ihre bestehende Technologie, gibt es hier nichts zu besprechen. Wenn Sie darüber nachdenken, diese Technologie zu verwenden, weil Sie gesehen haben, wie andere sie nutzen, überlegen Sie, mit welchen Problemen sie konfrontiert sind, und fragen Sie sich, ob Sie dieselben Probleme haben. Es ist einfach, Technologie zu übernehmen, weil andere sie nutzen; die Schwierigkeit liegt darin, zu verstehen, ob Sie mit denselben Problemen konfrontiert sind.
Frage 2: Auf was verzichte ich?
Das ist sicherlich eine schwierigere Frage, da man tief graben und sowohl die alte als auch die neue Technologie gut verstehen muss. Manchmal kann man die neue Technologie nicht wirklich verstehen, bis man etwas damit gebaut hat oder man einen Mitarbeiter hat, der über entsprechende Erfahrung verfügt.
Wenn Sie beides nicht haben, macht es Sinn, über die minimalen möglichen Investitionen nachzudenken, um den Wert dieses Werkzeugs zu bestimmen. Und wenn Sie Investitionen tätigen, wie schwierig wird es sein, die Entscheidung rückgängig zu machen?
Die Menschen machen immer alles kaputt
Wenn Sie versuchen, diese Fragen so objektiv wie möglich zu beantworten, denken Sie an eines: Sie müssen gegen die menschliche Natur ankämpfen. Es gibt eine Reihe kognitiver Verzerrungen, die überwunden werden müssen, um Technologien effektiv zu bewerten. Hier sind einige davon:
- – jeder weiß davon, aber es ist dennoch schwer, dagegen anzukämpfen. Stellen Sie einfach sicher, dass die Technologie wirklich Ihren tatsächlichen Bedürfnissen entspricht.
- – viele Entwickler neigen dazu, Technologien, mit denen sie lange gearbeitet haben, zu unterschätzen und die Vorteile neuer Technologien zu überschätzen. Nicht nur Programmierer, jeder ist dieser kognitiven Verzerrung ausgesetzt.
- – wir neigen dazu, das Gesehene wahrzunehmen und das Fehlende zu übersehen. Dies kann in Kombination mit dem Effekt der Neuheit zu Chaos führen, da Sie nicht nur die neue Technologie an sich überschätzen, sondern auch ihre Mängel ignorieren..
Eine objektive Bewertung ist nicht einfach, aber das Verständnis der grundlegenden kognitiven Verzerrungen hilft, rationalere Entscheidungen zu treffen.
Zusammenfassung
Wenn eine Innovation auftaucht, müssen wir mit großer Vorsicht zwei Fragen beantworten:
- Löst dieses Werkzeug ein echtes Problem?
- Verstehen wir die Kompromisse gut?
Wenn Sie diese beiden Fragen nicht sicher beantworten können, machen Sie ein paar Schritte zurück und denken Sie nach.
War MongoDB überhaupt die richtige Wahl? Natürlich ja; wie bei den meisten Engineering-Technologien hängt das von vielen Faktoren ab. Viele, die diese beiden Fragen beantwortet haben, haben von MongoDB profitiert und tun dies weiterhin. Wer das nicht getan hat, hat hoffentlich eine wertvolle und nicht zu schmerzhafte Lektion über den Hype-Zyklus gelernt.
Haftungsausschluss
Ich möchte klarstellen, dass ich weder Liebe noch Hass für MongoDB empfinde. Es gab einfach keine Probleme, für die MongoDB die beste Lösung wäre. Ich weiß, dass 10gen/MongoDB Inc. zu Beginn sehr mutig handelte, indem sie unsichere Standardwerte festlegten und MongoDB überall (insbesondere bei Hackathons) als universelle Lösung für die Verarbeitung beliebiger Daten förderten. Das war wahrscheinlich eine schlechte Entscheidung. Aber es bestätigt den hier beschriebenen Ansatz: Diese Probleme waren sogar bei einer oberflächlichen Bewertung der Technologie sehr schnell zu erkennen.
Quelle: habr.com
