Kürzlich habe ich erfahren, dass (angeblich aufgrund von Lizenzänderungen). Das hat mich zum Nachdenken gebracht, denn in den letzten Jahren habe ich viele Artikel gesehen, die MongoDB als schrecklich darstellen und behaupten, dass man es niemals verwenden sollte. Aber in dieser Zeit ist MongoDB zu einem viel reiferen Produkt geworden. Was ist passiert? Ist all der Hass tatsächlich das Ergebnis von Fehlern in der Anfangsmarketingstrategie der neuen Datenbank? Oder verwenden die Leute MongoDB einfach in den falschen Kontexten?
Falls es Ihnen so vorkommt, als würde ich MongoDB verteidigen, lesen Sie bitte den am Ende des Artikels.
Ein neuer Trend
Ich arbeite seit mehr Jahren in der Softwareindustrie, als es höflich wäre zu sagen, jedoch habe ich dennoch nur einen kleinen Teil der Trends miterlebt, die unsere Branche geprägt haben. Ich habe das Aufkommen von 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain… die Liste ist endlos. Jedes Jahr tauchen neue Prinzipien auf. Einige verblassen schnell, während andere die Art und Weise, wie Software entwickelt wird, grundlegend verändern.
Jeder neue Trend führt zu einer allgemeinen Aufregung: Die Menschen springen selbst auf den Zug auf oder folgen dem Lärm, den andere erzeugen – und bewegen sich mit der Masse. Dieser Prozess wurde von Gartner im kategorisiert. Obwohl umstritten, beschreibt dieses Diagramm ungefähr, was mit Technologien geschieht, bevor sie schließlich nützlich werden.
Doch hin und wieder taucht eine neue Innovation auf (oder es geschieht eine Art zweite Wiederkunft, wie in diesem Fall), die nur von ihrer spezifischen Anwendung vorangetrieben wird. Im Fall von NoSQL war der Hype stark beeinflusst durch das Aufkommen und den rasanten Anstieg von MongoDB. Nicht MongoDB stellte diesen Trend auf: Tatsächlich hatten große Internetunternehmen mit der Verarbeitung großer Datenmengen Probleme, was zur Wiederbelebung von nicht-relationalen Datenbanken führte. Die allgemeine Bewegung begann mit Projekten wie Bigtable von Google und Cassandra von Facebook, doch MongoDB wurde die bekannteste und zugänglichste NoSQL-Datenbank, die den meisten Entwicklern zur Verfügung stand.
Hinweis: Sie könnten denken, dass ich dokumentorientierte DBs mit spaltenorientierten DBs, Schlüsselwertspeichern oder einer der vielen anderen Arten von Datenspeichern, die unter die allgemeine Definition von NoSQL fallen, vermische. Und Sie haben recht. Aber damals herrschte Chaos. Alle waren besessen von NoSQL, es wurde für alle absolut notwendig, obwohl viele die Unterschiede zwischen den verschiedenen Technologien nicht erkennen konnten. Für viele wurde MongoDB zum Synonym für NoSQL.
Und die Entwickler stürzten sich darauf. Die Idee einer schemalosen Datenbank, die magisch für jede Herausforderung skalieren kann, war äußerst verlockend. Etwa 2014 schien es, als überall dort, wo zuvor eine relationale Datenbank wie MySQL, Postgres oder SQL Server verwendet wurde, nun MongoDB-Datenbanken eingerichtet wurden. Auf die Frage, warum dies der Fall war, konnten Sie von der banalen Antwort „es ist die Skalierung des Webs“ bis hin zu der durchdachteren Antwort „meine Daten sind sehr schwach strukturiert und passen gut in eine schemalose Datenbank“ alles hören.
Es ist wichtig zu beachten, dass MongoDB und dokumentenorientierte Datenbanken im Allgemeinen eine Reihe von Problemen mit traditionellen relationalen Datenbanken lösen:
- Strikte Schema: mit einer relationalen Datenbank müssen Sie, wenn Sie dynamisch generierte Daten haben, entweder eine Menge zufälliger "verschiedener" Datenspalten erstellen, Datenblobs hineinschieben oder eine Konfiguration verwenden. …all dies hat erhebliche Nachteile.
- Schwierigkeiten beim Skalieren: wenn die Daten so zahlreich sind, dass sie nicht auf einen Server passen, bot MongoDB Mechanismen, um sie auf mehreren Maschinen zu skalieren.
- Komplexe Schemaänderungen: keine Migrationen! In einer relationalen Datenbank kann die Änderung der Datenbankstruktur ein enormes Problem darstellen (insbesondere wenn die Datenmenge sehr groß wird). MongoDB hat den Prozess erheblich vereinfacht. Es wurde so einfach gestaltet, dass Sie das Schema einfach im laufenden Betrieb aktualisieren und sehr schnell weiterarbeiten können.
- Schreibgeschwindigkeit: die Leistung von MongoDB war gut, insbesondere bei sorgfältiger Konfiguration. Selbst die Standardkonfiguration von MongoDB, die oft kritisiert wurde, zeigte einige beeindruckende Leistungswerte.
Alle Risiken liegen bei Ihnen.
Die potenziellen Vorteile von MongoDB waren enorm, insbesondere für bestimmte Problemlösungen. Liest man die obige Liste ohne Kontext und ohne Erfahrung, könnte man den Eindruck gewinnen, dass MongoDB eine wirklich revolutionäre Datenbankmanagementsystem ist. Das einzige Problem war, dass die genannten Vorteile mit einer Reihe von Vorbehalten verbunden waren, von denen einige im Folgenden aufgeführt sind.
Um fair zu sein, wird niemand bei 10gen/MongoDB Inc. behaupten, dass das Folgende nicht wahr ist; es handelt sich einfach um Kompromisse.
- Transaktionsverlust: Transaktionen sind ein zentrales Merkmal vieler relationaler Datenbanken (nicht aller, aber der meisten). Transaktionsunterstützung bedeutet, dass Sie mehrere Operationen atomar ausführen können und sicherstellen können, dass die Daten konsistent bleiben. Natürlich kann die Transaktionsfähigkeit bei NoSQL-Datenbanken innerhalb eines Dokuments erfolgen, oder Sie können zweiphasige Commits verwenden, um transaktionale Semantik zu erhalten. Aber Sie müssen diese Funktionalität selbst implementieren… was eine schwierige und zeitaufwändige Aufgabe sein kann. Oft erkennen Sie die Probleme nicht, bis Sie feststellen, dass die Daten in der Datenbank in ungültige Zustände geraten, weil die Atomarität der Operationen nicht gewährleistet werden kann. Hinweis: Viele haben mir mitgeteilt, dass in MongoDB 4.0 im letzten Jahr Transaktionen eingeführt wurden, allerdings mit einigen Einschränkungen. Die Schlussfolgerung aus dem Artikel bleibt unverändert: Bewerten Sie, wie gut die Technologie Ihren Bedürfnissen entspricht.
- Verlust der relationalen Integrität (Fremdschlüssel): Wenn Ihre Daten Beziehungen enthalten, müssen Sie diese im Anwendung anwenden. Das Vorhandensein einer Datenbank, die diese Beziehungen berücksichtigt, wird einen erheblichen Teil der Arbeit mit der Anwendung und damit auch von Ihren Programmierern entlasten.
- Fehlende Möglichkeit, die Datenstruktur anzuwenden: Strenge Schemata können manchmal ein großes Problem darstellen, sind jedoch auch ein leistungsstarkes Werkzeug für eine ordentliche Datenstrukturierung, wenn sie richtig verwendet werden. Dokumentenbasierte Datenbanken wie MongoDB bieten eine unglaubliche Flexibilität im Schema, aber diese Flexibilität entbindet von der Verantwortung, die Daten in Ordnung zu halten. Wenn Sie sich nicht darum kümmern, müssen Sie am Ende viel Code in der Anwendung schreiben, um Daten zu berücksichtigen, die nicht in der Form gespeichert sind, die Sie erwarten. Wie wir in unserem Unternehmen Simple Thread oft sagen ... eine Anwendung wird irgendwann neu geschrieben, aber die Daten werden ewig leben. Hinweis: MongoDB unterstützt die Schemaüberprüfung; sie ist nützlich, bietet jedoch nicht dieselben Garantien wie eine relationale Datenbank. Vor allem beeinflusst das Hinzufügen oder Ändern der Schemaüberprüfung nicht die bestehenden Daten in der Sammlung. Sie müssen selbst sicherstellen, dass Sie die Daten gemäß dem neuen Schema aktualisieren. Entscheiden Sie selbst, ob dies für Ihre Bedürfnisse ausreichend ist.
- E eigene Abfragesprache / Verlust des Ökosystems von Werkzeugen: Das Aufkommen von SQL war eine absolute Revolution, und seitdem hat sich nichts geändert. Es ist eine unglaublich mächtige Sprache, aber auch ziemlich komplex. Die Notwendigkeit, Abfragen an eine Datenbank in einer neuen Sprache zu konstruieren, die aus JSON-Fragmenten besteht, wird von Menschen mit Erfahrung in SQL als 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 Übergang zu einer Datenbank, die SQL nicht unterstützt, bedeutet, dass Sie die meisten dieser Werkzeuge nicht verwenden können oder die Daten in SQL übersetzen müssen, um sie zu verwenden, was sich als komplizierter herausstellen kann, als Sie denken.
Viele Entwickler, die sich für MongoDB entschieden haben, hatten oft kein klares Verständnis der Kompromisse und sprangen häufig kopfüber ins kalte Wasser, indem sie es als primäres Datenspeicher-System einsetzten. Danach war es oft unglaublich schwierig, zurückzukehren.
Was hätte man anders machen können?
Nicht alle sprangen gleich kopfüber und prallten auf den Boden. Aber viele Projekte setzten MongoDB an Stellen ein, wo es einfach nicht passte – und sie werden noch viele Jahre damit leben müssen. Hätten diese Organisationen etwas Zeit investiert und ihre Technologieentscheidungen systematisch überdacht, hätten viele eine andere Wahl getroffen.
Wie wählt man die richtige Technologie aus? Es gab mehrere Versuche, einen systematischen Rahmen zur Bewertung von Technologien zu schaffen, wie etwa und , aber ich denke, das ist übertrieben kompliziert.
Viele Technologien lassen sich vernünftig bewerten, indem man nur zwei grundlegende Fragen stellt. Das Problem liegt darin, die Menschen zu finden, die verantwortlich darauf antworten können, Zeit mit der Suche nach Antworten investieren und dabei unvoreingenommen bleiben.
Wenn Sie mit einem Problem nicht konfrontiert sind, benötigen Sie kein neues Werkzeug. Punkt.
Frage 1: Welche Probleme versuche ich zu lösen?
Wenn Sie mit einem Problem nicht konfrontiert sind, benötigen Sie kein neues Werkzeug. Punkt. Es ist nicht notwendig, nach einer Lösung zu suchen und dann ein Problem zu erfinden. Wenn Sie nicht auf ein Problem gestoßen sind, das eine neue Technologie deutlich besser löst als Ihre bestehende Technologie, gibt es hier nichts zu diskutieren. Wenn Sie in Erwägung ziehen, diese Technologie zu nutzen, nur weil Sie gesehen haben, wie andere sie verwenden, überlegen Sie, mit welchen Problemen sie konfrontiert sind, und fragen Sie sich, ob Sie ähnliche Probleme haben. Es ist einfach, Technologie zu übernehmen, weil andere es tun; die Herausforderung besteht darin, zu verstehen, ob Sie mit den gleichen Problemen konfrontiert sind.
Frage 2: Was verliere ich?
Das ist zweifellos eine schwierigere Frage, da es erforderlich ist, sowohl die alte als auch die neue Technologie gründlich zu verstehen. Manchmal können Sie die Neue nicht wirklich begreifen, bis Sie etwas mit ihr aufgebaut haben oder einen Mitarbeiter mit entsprechender Erfahrung haben.
Wenn Sie weder das eine noch das andere haben, sollten Sie über die minimalen Investitionen nachdenken, um den Wert dieses Instruments zu bestimmen. Und wenn Sie investieren, wie schwierig wird es sein, die Entscheidung zurückzunehmen?
Die Menschen vermasseln immer alles
Wenn Sie versuchen, diese Fragen so objektiv wie möglich zu beantworten, denken Sie an eines: Sie werden gegen die menschliche Natur kämpfen müssen. Es gibt eine Reihe von kognitiven Verzerrungen, die überwunden werden müssen, um Technologien effektiv zu bewerten. Hier sind nur einige:
- — jeder weiß davon, aber es ist trotzdem schwer, sich dagegen zu wehren. Stellen Sie einfach sicher, dass die Technologie tatsächlich Ihren realen 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, alle sind diesem kognitiven Verzerrung ausgesetzt.
- Wir neigen dazu, das Vorhandene zu sehen und das Fehlende zu übersehen. Dies kann, kombiniert mit dem Neuheitseffekt, zu Chaos führen, da man nicht nur die neue Technologie überschätzt, sondern auch ihre Nachteile ignoriert..
Eine objektive Bewertung ist nicht einfach, aber das Verständnis grundlegender kognitiver Verzerrungen hilft, rationalere Entscheidungen zu treffen.
Zusammenfassung
Wenn eine Innovation auftritt, sollte man mit großer Vorsicht auf zwei Fragen reagieren:
- Löst dieses Werkzeug ein reales Problem?
- Verstehen wir die Kompromisse gut?
Wenn Sie diese beiden Fragen nicht sicher beantworten können, machen Sie einen Schritt zurück und denken Sie nach.
War MongoDB also die richtige Wahl? Auf jeden Fall; wie bei den meisten engineering-Technologien hängt es von vielen Faktoren ab. Viele, die diese beiden Fragen beantwortet haben, haben von MongoDB profitiert und tun dies weiterhin. Wer das nicht getan hat, sollte hoffentlich eine wertvolle und nicht allzu schmerzhafte Lektion über den Hype-Zyklus gelernt haben.
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 gewesen wäre. Ich weiß, dass 10gen/MongoDB Inc. anfangs sehr mutig war, indem sie unsichere Standardeinstellungen festlegten und MongoDB überall (insbesondere bei Hackathons) als universelle Lösung für den Umgang mit jeglichen Daten förderten. Wahrscheinlich war das eine Fehlentscheidung. Aber es bestätigt den hier beschriebenen Ansatz: Diese Probleme hätten schon bei einer oberflächlichen Bewertung der Technologie sehr schnell erkannt werden können.
Quelle: habr.com
