Das habe ich kürzlich herausgefunden (z. B. aufgrund von Lizenzänderungen). Mir kam der Gedanke, dass ich in den letzten Jahren eine Menge Artikel darüber gesehen habe, 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? Ist der ganze Hass wirklich auf Fehler zu Beginn der Vermarktung des neuen DBMS zurückzuführen? Oder verwenden die Leute MongoDB einfach am falschen Ort?
Wenn Sie plötzlich das Gefühl haben, dass ich MongoDB verteidige, lesen Sie bitte am Ende des Artikels.
Neuer Trend
Ich bin schon seit mehr Jahren in der Softwarebranche tätig, als man mit Recht sagen kann, aber ich habe immer noch nur einen Teil der Trends miterlebt, die unsere Branche treffen. Ich habe den Aufstieg von 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain miterlebt … die Liste ist endlos. Jedes Jahr gibt es neue Trends. Einige verschwinden schnell, während andere die Art und Weise, wie Software entwickelt wird, grundlegend verändern.
Um jeden neuen Trend herum entsteht eine gewisse allgemeine Aufregung: Die Leute springen entweder selbst ins Boot oder sehen den Lärm, den andere erzeugen – und folgen der Menge. Dieser Prozess wurde von Gartner kodifiziert . Obwohl umstritten, beschreibt diese Grafik grob, was mit Technologien passiert, bevor sie schließlich für den Einsatz nützlich werden.
Aber von Zeit zu Zeit gibt es (oder wie in diesem Fall ein zweites Kommen) eine neue Innovation, die nur durch eine konkrete Umsetzung vorangetrieben wird. Im Fall von NoSQL wurde der Hype maßgeblich durch das Aufkommen und den kometenhaften Aufstieg von MongoDB vorangetrieben. MongoDB hat diesen Trend nicht ausgelöst: Tatsächlich bekamen 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 es war MongoDB, das zur berühmtesten und zugänglichsten Implementierung der NoSQL-Datenbank wurde, auf die die meisten Entwickler Zugriff hatten.
Hinweis: Sie denken vielleicht, dass ich Dokumentdatenbanken mit Spaltendatenbanken, Schlüssel-/Wertspeichern oder einer der vielen anderen Arten von Datenspeichern verwechsle, die unter die allgemeine Definition von NoSQL fallen. Und du hast recht. Doch damals herrschte Chaos. Jeder ist von NoSQL besessen, es ist alles geworden absolut notwendig, obwohl viele die Unterschiede zwischen den verschiedenen Technologien nicht erkannten. Für viele ist MongoDB geworden auch mit NoSQL.
Und die Entwickler sind darauf aufgesprungen. Die Idee einer schemalosen Datenbank, die sich auf magische Weise skalieren lässt, um jedes Problem zu lösen, war ziemlich verlockend. Um das Jahr 2014 schien es, als würden vor einem Jahr überall dort, wo eine relationale Datenbank wie MySQL, Postgres oder SQL Server verwendet wurde, MongoDB-Datenbanken eingesetzt. Wenn Sie nach dem Grund gefragt werden, können Sie Antworten von dem banalen „Das ist die Größe des Webs“ bis zum nachdenklicheren „Meine Daten sind sehr locker strukturiert und passen gut in eine Datenbank ohne Schema“ erhalten.
Es ist wichtig, sich daran zu erinnern, dass MongoDB und Dokumentendatenbanken im Allgemeinen eine Reihe von Problemen mit herkömmlichen relationalen Datenbanken lösen:
- Strenges Schema: Wenn Sie bei einer relationalen Datenbank dynamisch generierte Daten haben, müssen Sie entweder eine Reihe zufälliger „verschiedener“ Datenspalten erstellen, Datenblobs hineinschieben oder eine Konfiguration verwenden … das alles hat erhebliche Nachteile.
- Schwierigkeit der Skalierung: Wenn so viele Daten vorhanden sind, dass sie nicht auf einen Server passen, bietet MongoDB Mechanismen an, die eine Skalierung auf mehrere Maschinen ermöglichen.
- Komplexe Schaltungsmodifikationen: keine Migrationen! In einer relationalen Datenbank kann das Ändern der Datenbankstruktur ein großes Problem darstellen (insbesondere wenn viele Daten vorhanden sind). MongoDB konnte den Prozess erheblich vereinfachen. Und es ist so einfach gemacht, dass Sie das Schema einfach unterwegs aktualisieren und sehr schnell weitermachen können.
- Leistung schreiben: Die Leistung von MongoDB war gut, insbesondere bei richtiger Abstimmung. Selbst die oft kritisierte Out-of-the-Box-Konfiguration von MongoDB zeigte einige beeindruckende Leistungswerte.
Alle Risiken liegen bei Ihnen
Die potenziellen Vorteile von MongoDB waren enorm, insbesondere bei bestimmten Problemklassen. Wenn Sie die obige Liste lesen, ohne den Kontext zu verstehen und keine Erfahrung zu haben, könnten Sie den Eindruck gewinnen, dass MongoDB wirklich ein revolutionäres DBMS ist. Das einzige Problem bestand darin, dass die oben aufgeführten Vorteile mit einer Reihe von Einschränkungen verbunden waren, von denen einige unten aufgeführt sind.
Um fair zu sein, niemand bei 10gen/MongoDB Inc. Ich werde nicht sagen, dass das Folgende nicht wahr ist, das sind nur Kompromisse.
- Verlust von TransaktionenA: Transaktionen sind ein Kernmerkmal vieler relationaler Datenbanken (nicht aller, aber der meisten). Transaktional bedeutet, dass Sie mehrere Vorgänge atomar ausführen und sicherstellen können, dass die Daten konsistent bleiben. Natürlich kann bei einer NoSQL-Datenbank die Transaktionalität innerhalb eines einzelnen Dokuments erfolgen, oder Sie können zweiphasige Commits verwenden, um die Transaktionssemantik zu erhalten. Sie müssen diese Funktionalität jedoch selbst implementieren ... was eine schwierige und zeitaufwändige Aufgabe sein kann. Oft erkennt man das Problem erst, wenn man sieht, dass die Daten in der Datenbank einen ungültigen Zustand annehmen, weil es unmöglich ist, die Atomizität der Vorgänge zu garantieren. Hinweis: Viele haben mir gesagt, dass Transaktionen letztes Jahr in MongoDB 4.0 eingeführt wurden, allerdings mit einigen Einschränkungen. Die Schlussfolgerung aus dem Artikel bleibt dieselbe: Beurteilen Sie, wie die Technologie Ihren Anforderungen entspricht.
- Verlust der relationalen Integrität (Fremdschlüssel): Wenn zwischen Ihren Daten Beziehungen bestehen, müssen Sie diese in der Anwendung anwenden. Eine Datenbank, die diese Beziehungen berücksichtigt, wird der Anwendung und damit Ihren Programmierern viel Arbeit abnehmen.
- Unfähigkeit, die Datenstruktur anzuwenden: Strikte Schemata können manchmal ein großes Problem sein, aber sie sind auch ein leistungsstarker Mechanismus für eine gute Datenstrukturierung, wenn sie mit Bedacht eingesetzt werden. Dokumentdatenbanken wie MongoDB bieten eine unglaubliche Schemaflexibilität, aber diese Flexibilität nimmt Ihnen die Verantwortung, die Daten sauber zu halten, weg. Wenn Sie sich nicht um sie kümmern, schreiben Sie am Ende viel Code in Ihre Anwendung, um Daten zu berücksichtigen, die nicht in der erwarteten Form gespeichert werden. Wie man in unserem Unternehmen oft sagt: „Simple Thread“: Die Anwendung wird eines Tages neu geschrieben, aber die Daten bleiben für immer bestehen. Hinweis: MongoDB unterstützt die Schemavalidierung, was nützlich ist, aber nicht die gleichen Garantien wie eine relationale Datenbank bietet. Erstens wirkt sich das Hinzufügen oder Ändern der Schemavalidierung nicht auf vorhandene Daten in der Sammlung aus. Sie müssen sicherstellen, dass Sie die Daten gemäß dem neuen Schema aktualisieren. Entscheiden Sie selbst, ob dies für Ihre Bedürfnisse ausreicht.
- Eigene Abfragesprache / Verlust des Tool-Ökosystems: 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, Datenbankabfragen in einer neuen Sprache zu erstellen, die aus JSON-Fragmenten besteht, wird von Leuten, die Erfahrung mit SQL haben, als großer Rückschritt angesehen. Es gibt ein ganzes Universum an Tools, die mit SQL-Datenbanken interagieren, von IDEs bis hin zu Reporting-Tools. Der Wechsel zu einer Datenbank, die SQL nicht unterstützt, bedeutet, dass Sie die meisten dieser Tools nicht verwenden können oder dass Sie die Daten in SQL konvertieren müssen, um sie verwenden zu können, was schwieriger sein kann, als Sie denken.
Viele Entwickler, die sich an MongoDB wandten, verstanden die Kompromisse nicht wirklich und stürzten sich oft kopfüber in die Einrichtung von MongoDB als primären Datenspeicher. Danach war es oft unglaublich schwierig, zurückzukehren.
Was hätte anders gemacht werden können?
Nicht jeder sprang mit dem Kopf voran und stürzte auf den Boden. Doch viele Projekte haben die MongoDB-Basis dort installiert, wo sie einfach nicht hineinpasste – und werden noch viele Jahre damit leben müssen. Hätten sich diese Organisationen etwas Zeit genommen, um ihre Technologieentscheidungen methodisch zu prüfen, hätten viele eine andere Wahl getroffen.
Wie wählt man die richtige Technologie aus? Es gab mehrere Versuche, einen systematischen Rahmen für die Technikfolgenabschätzung zu schaffen, wie z и , aber es scheint mir, dass dies eine unnötige Komplexität ist.
Viele Technologien können intelligent bewertet werden, indem nur zwei grundlegende Fragen gestellt werden. Das Problem besteht darin, Menschen zu finden, die diese Fragen verantwortungsvoll beantworten können, sich die Zeit nehmen, Antworten zu finden und unvoreingenommen sind.
Wenn Sie kein Problem haben, brauchen Sie kein neues Werkzeug. Punkt.
Frage 1: Welche Probleme versuche ich zu lösen?
Wenn Sie kein Problem haben, brauchen Sie kein neues Werkzeug. Punkt. Sie müssen nicht nach einer Lösung suchen und dann auf ein Problem stoßen. Sofern Sie nicht vor einem Problem stehen, das die neue Technologie nicht wesentlich besser löst als Ihre bestehende Technologie, gibt es hier nichts zu besprechen. Wenn Sie erwägen, diese Technologie zu verwenden, weil Sie gesehen haben, dass andere sie verwenden, denken Sie über die Probleme nach, die diese haben, und fragen Sie, ob Sie diese Probleme haben. Es ist einfach, die Technologie zu akzeptieren, weil andere sie nutzen. Die Schwierigkeit besteht darin, zu wissen, ob Sie mit den gleichen Problemen konfrontiert sind.
Frage 2: Was fehlt mir?
Dies ist sicherlich eine schwierigere Frage, da man sowohl die alte als auch die neue Technologie gut verstehen und verstehen muss. Manchmal kann man etwas Neues erst wirklich verstehen, wenn man etwas daraus aufgebaut hat oder einen Kollegen mit dieser Erfahrung hat.
Wenn Sie beides nicht haben, ist es sinnvoll, über die minimal mögliche Investition nachzudenken, um den Wert dieses Instruments zu ermitteln. Und wenn Sie eine Investition tätigen, wie schwierig wird es sein, die Entscheidung rückgängig zu machen?
Menschen ruinieren immer alles
Wenn Sie versuchen, diese Fragen so unparteiisch wie möglich zu beantworten, denken Sie an eines: Sie müssen die menschliche Natur bekämpfen. Es gibt eine Reihe kognitiver Vorurteile, die überwunden werden müssen, um Technologie effektiv bewerten zu können. Hier sind nur einige davon:
- Jeder kennt ihn, aber es ist immer noch schwer, gegen ihn zu kämpfen. Stellen Sie einfach sicher, dass die Technologie wirklich Ihren tatsächlichen Anforderungen entspricht.
- Viele Entwickler neigen dazu, Technologien, mit denen sie schon lange arbeiten, zu unterschätzen und die Vorteile einer neuen Technologie zu überschätzen. Nicht nur Programmierer, sondern jeder unterliegt dieser kognitiven Verzerrung.
- Wir neigen dazu, zu sehen, was ist, und das, was nicht ist, aus den Augen zu verlieren. Dies kann zusammen mit dem Neuheitseffekt zu Chaos führen, da Sie die neue Technologie nicht nur von Natur aus überbewerten, sondern auch ihre Mängel ignorieren..
Eine objektive Beurteilung ist nicht einfach, aber das Verständnis der zugrunde liegenden kognitiven Verzerrungen wird Ihnen helfen, rationalere Entscheidungen zu treffen.
Zusammenfassung
Wenn eine Innovation entsteht, müssen zwei Fragen mit großer Sorgfalt beantwortet werden:
- Löst dieses Tool ein echtes Problem?
- Sind wir gut darin, Kompromisse zu verstehen?
Wenn Sie diese beiden Fragen nicht sicher beantworten können, gehen Sie einen Schritt zurück und denken Sie nach.
War La MongoDB also grundsätzlich die richtige Wahl? Ja natürlich; Wie bei den meisten technischen Technologien hängt es von vielen Faktoren ab. Viele von denen, die diese beiden Fragen beantwortet haben, haben von MongoDB profitiert und tun dies auch weiterhin. Für diejenigen unter Ihnen, die das noch nicht getan haben, hoffe ich, dass Sie eine wertvolle und nicht allzu schmerzhafte Lektion darüber gelernt haben, wie man den Hype-Zyklus durchläuft.
Haftungsausschluss
Ich möchte klarstellen, dass ich MongoDB weder liebe noch hasse. Wir hatten einfach nicht die Art von Problemen, für deren Lösung MongoDB am besten geeignet ist. Ich kenne 10gen/MongoDB Inc. Anfangs handelte es sehr mutig, indem es unsichere Standardeinstellungen festlegte und MongoDB überall (besonders bei Hackathons) als Komplettlösung für die Arbeit mit beliebigen Daten bewarb. Es war wahrscheinlich eine schlechte Entscheidung. Aber es bestätigt den hier beschriebenen Ansatz: Diese Probleme konnten auch bei oberflächlicher Betrachtung der Technik sehr schnell erkannt werden.
Source: habr.com