Ich habe kürzlich herausgefunden, dass Red Hat die MongoDB-Unterstützung von Satellite entfernt (sie sagen aufgrund von Lizenzänderungen). Ich dachte, dass ich in den letzten Jahren eine Reihe von Artikeln gesehen habe, wie schrecklich MongoDB ist und dass niemand es jemals benutzen sollte. In dieser Zeit ist MongoDB jedoch ein viel ausgereifteres Produkt geworden. Was ist passiert? Ist der ganze Hass wirklich auf Fehler zu Beginn der Vermarktung eines neuen DBMS zurückzuführen? Oder verwenden die Leute MongoDB einfach an einem falschen Ort?

Wenn Sie plötzlich das Gefühl haben, MongoDB zu schützen, lesen Sie bitte den Haftungsausschluss am Ende des Artikels.

Neuer Trend

Ich arbeite seit mehr als Jahren in der Softwareindustrie, um anständig zu sprechen, aber trotzdem war nur ein kleiner Teil der Trends, die unsere Branche getroffen haben, für mich verantwortlich. Ich habe das Wachstum von 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain gesehen ... die Liste ist endlos. Jedes Jahr tauchen neue Trends auf. Einige verschwinden schnell, während andere die Art und Weise, wie Software entwickelt wird, grundlegend verändern.

Bei jedem neuen Trend entsteht eine gewisse allgemeine Aufregung: Die Leute springen entweder ins Boot oder sehen den Lärm anderer - und folgen der Menge. Dieser Prozess wird von Gartner in einem Hype-Zyklus kodifiziert. Obwohl umstritten, beschreibt diese Grafik grob, was mit den Technologien passiert, bevor sie schließlich verwendbar werden.

Aber von Zeit zu Zeit erscheint eine neue Innovation (oder kommt wie in diesem Fall eine zweite), die von nur einer bestimmten Implementierung angetrieben wird. Im Fall von NoSQL war der Hype stark vom Aufkommen und dem raschen Aufstieg von MongoDB getrieben. MongoDB hat diesen Trend nicht ausgelöst: Tatsächlich hatten große Internetunternehmen Probleme, große Datenmengen zu verarbeiten, was zur Rückgabe nicht relationaler Datenbanken führte. Die allgemeine Bewegung begann mit Projekten wie Bigtable von Google und Cassandra von Facebook, aber es war MongoDB, die zur bekanntesten und kostengünstigsten Implementierung der NoSQL-Datenbank wurde, auf die die meisten Entwickler Zugriff hatten.

Hinweis: Sie könnten denken, dass ich Dokumentendatenbanken mit Spaltendatenbanken, Schlüssel- / Wertspeichern oder einer der vielen anderen Arten von Datenspeichern mische, die unter die allgemeine Definition von NoSQL fallen. Und du hast recht. Aber zu dieser Zeit herrschte Chaos. Jeder war von NoSQL besessen, jeder brauchte es unbedingt , obwohl viele die Unterschiede in den verschiedenen Technologien nicht sahen. Für viele ist MongoDB zum Synonym für NoSQL geworden.

Und die Entwickler haben sie angegriffen. Es war eine ziemlich verlockende Idee, eine Datenbank ohne ein Schema zu haben, das sich magisch skalieren lässt, um jedes Problem zu lösen. Um 2014 schien es, dass überall dort, wo vor einem Jahr eine relationale Datenbank verwendet wurde, wie MySQL, Postgres oder SQL Server, MongoDB-Datenbanken bereitgestellt wurden. Auf die Frage, warum, könnten Sie eine Antwort vom banalen "Dies ist die Skala des Webs" auf die nachdenklichere "Meine Daten sind sehr schlecht strukturiert und passen ohne Schema gut in die Datenbank" erhalten.

Es ist wichtig zu bedenken, dass MongoDB- und Dokumentendatenbanken im Allgemeinen eine Reihe von Problemen mit herkömmlichen relationalen Datenbanken lösen:

Strenges Schema : Wenn Sie in einer relationalen Datenbank dynamisch generierte Daten haben, müssen Sie entweder eine Reihe zufälliger „unterschiedlicher“ Datenspalten erstellen, Datenblobs dort verschieben oder die EAV- Konfiguration verwenden ... all dies hat erhebliche Nachteile.
Die Schwierigkeit der Skalierung : Wenn so viele Daten vorhanden sind, dass sie nicht auf einen einzelnen Server passen, hat MongoDB Mechanismen vorgeschlagen, um sie auf mehreren Computern zu skalieren.
Anspruchsvolle Schaltungsänderungen : keine Migrationen! In einer relationalen Datenbank kann das Ändern der Struktur der Datenbank ein großes Problem sein (insbesondere wenn viele Daten vorhanden sind). MongoDB konnte den Prozess erheblich vereinfachen. Und es machte es so einfach, dass Sie die Schaltung einfach unterwegs aktualisieren und sehr schnell weitermachen können.
Aufnahmeleistung : Die MongoDB-Leistung war gut, insbesondere bei richtiger Abstimmung. Sogar die sofort einsatzbereite MongoDB-Konfiguration, für die sie häufig kritisiert wurde, zeigte einige beeindruckende Leistungskennzahlen.

Alle Risiken liegen bei Ihnen.

Die potenziellen Vorteile von MongoDB waren enorm, insbesondere für bestimmte 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 genannten Vorteile mit einer Reihe von Vorbehalten einhergingen, von denen einige nachstehend aufgeführt sind.

Fairerweise niemand bei 10gen / MongoDB Inc. Er wird nicht sagen, dass das Folgende nicht stimmt, es ist nur ein Kompromiss.

Verlust von Transaktionen : Transaktionen sind ein Hauptmerkmal vieler relationaler Datenbanken (nicht alle, aber die meisten). Transaktion bedeutet, dass Sie mehrere Vorgänge atomar ausführen und sicherstellen können, dass die Daten konsistent bleiben. Bei einer NoSQL-Datenbank kann sich die Transaktionsfähigkeit natürlich innerhalb desselben Dokuments befinden, oder Sie können zweiphasige Commits verwenden, um die Transaktionssemantik abzurufen. Sie müssen diese Funktionalität jedoch selbst implementieren. Dies kann eine komplexe und zeitaufwändige Aufgabe sein. Oft sind Sie sich des Problems erst bewusst, wenn Sie feststellen, dass die Daten in der Datenbank in inakzeptable Zustände geraten, da die Atomizität von Operationen nicht garantiert werden kann. Hinweis: Viele sagten mir, dass Transaktionen im letzten Jahr in MongoDB 4.0 erschienen sind, jedoch mit einer Reihe von Einschränkungen. Die Schlussfolgerung aus dem Artikel bleibt dieselbe: Bewerten Sie, wie die Technologie Ihren Anforderungen entspricht.
Verlust der relationalen Integrität (Fremdschlüssel) : Wenn Ihre Daten eine Beziehung enthalten, müssen Sie diese in der Anwendung anwenden. Wenn Sie eine Datenbank haben, die diesen Beziehungen entspricht, wird ein erheblicher Teil der Arbeit aus der Anwendung und damit aus Ihren Programmierern entfernt.
Mangelnde Fähigkeit, Datenstruktur anzuwenden : Strenge Schemata werden manchmal zu einem großen Problem, aber es ist auch ein leistungsfähiger Mechanismus für eine gute Datenstrukturierung, wenn es richtig verwendet wird. Dokumentendatenbanken wie MongoDB bieten eine unglaubliche Schemaflexibilität, aber diese Flexibilität beseitigt die Verantwortung, Daten sauber zu halten. Wenn Sie sich nicht um sie kümmern, müssen Sie am Ende viel Code in die Anwendung schreiben, um Daten zu berücksichtigen, die nicht in der von Ihnen erwarteten Form gespeichert sind. Wie unser Unternehmen oft sagt, wird Simple Thread ... eines Tages die Anwendung neu geschrieben und die Daten werden für immer leben. Hinweis: MongoDB unterstützt die Schemaüberprüfung: Es ist nützlich, bietet jedoch nicht die gleichen Garantien wie in einer relationalen Datenbank. Erstens wirkt sich das Hinzufügen oder Ändern einer Schemaüberprüfung nicht auf vorhandene Daten in der Sammlung aus. Sie müssen selbst sicherstellen, dass Sie die Daten gemäß dem neuen Schema aktualisieren. Entscheiden Sie selbst, ob dies für Ihre Bedürfnisse ausreicht.
Native Abfragesprache / Verlust des Ökosystems der Tools : Das Aufkommen von SQL ist zu einer absoluten Revolution geworden, 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 entwerfen, die aus JSON-Fragmenten besteht, wird von Personen, die Erfahrung mit SQL haben, als großer Rückschritt angesehen. Es gibt ein ganzes Universum von Tools, die mit SQL-Datenbanken interagieren: von der IDE bis zu den Berichterstellungstools. Wenn Sie zu einer Datenbank wechseln, die SQL nicht unterstützt, können Sie die meisten dieser Tools nicht verwenden oder müssen die Daten in SQL konvertieren, um sie zu verwenden. Dies kann schwieriger sein als Sie denken.

Viele Entwickler, die sich an MongoDB gewandt haben, haben die Kompromisse nicht wirklich verstanden und sind oft kopfüber getaucht und haben es als primären Datenspeicher eingerichtet. Danach war es oft unglaublich schwierig, zurück zu gehen.

Was hätte anders gemacht werden können?

Nicht jeder sprang mit dem Kopf voran und traf den Boden. Aber viele Projekte haben die MongoDB-Basis dort installiert, wo sie einfach nicht passte - und sie werden noch viele Jahre damit leben müssen. Wenn diese Organisationen einige Zeit damit verbracht hätten, die Wahl der Technologien methodisch zu prüfen, hätten viele eine andere Wahl getroffen.

Wie wählt man die richtige Technologie? Es gab mehrere Versuche, einen systematischen Rahmen für die Bewertung von Technologien zu schaffen, wie z. B. "Rahmen für die Einführung von Technologien in Softwareorganisationen" und "Rahmen für die Bewertung von Softwaretechnologien" , aber es scheint mir, dass dies unnötige Komplexität ist.

Viele Technologien können angemessen bewertet werden, indem nur zwei grundlegende Fragen gestellt werden. Das Problem besteht darin, Menschen zu finden, die verantwortungsbewusst auf sie reagieren können, Zeit damit verbringen, nach Antworten zu suchen und ohne Vorurteile.

Wenn Sie auf kein Problem stoßen, benötigen Sie kein neues Tool. Der Punkt.

Frage 1: Welche Probleme versuche ich zu lösen?

Wenn Sie auf kein Problem stoßen, benötigen Sie kein neues Tool. Der Punkt. Sie müssen nicht nach einer Lösung suchen und dann ein Problem finden. Wenn Sie nicht auf ein Problem gestoßen sind, das eine neue Technologie nicht viel besser löst als Ihre vorhandene Technologie, gibt es nichts zu besprechen. Wenn Sie überlegen, diese Technologie zu verwenden, weil Sie gesehen haben, wie andere sie verwenden, überlegen Sie, mit welchen Problemen sie konfrontiert sind, und fragen Sie, ob Sie solche Probleme haben. Es ist einfach, die Technologie zu akzeptieren, da andere sie verwenden. Die Schwierigkeit besteht darin, zu verstehen, ob Sie mit denselben Problemen konfrontiert sind.

Frage 2: Was verliere ich?

Dies ist sicherlich eine schwierigere Frage, da Sie sowohl alte als auch neue Technologien gut verstehen müssen. Manchmal kann man ein neues nicht wirklich verstehen, bis man etwas damit baut oder einen Mitarbeiter mit solcher Erfahrung hat.

Wenn Sie weder das eine noch das andere haben, ist es sinnvoll, über die minimal mögliche Investition nachzudenken, um den Wert dieses Tools zu bestimmen. Und wenn Sie eine Investition tätigen, wie schwierig wird es sein, die Entscheidung rückgängig zu machen?

Die Leute verderben immer alles

Wenn Sie versuchen, diese Fragen so unparteiisch wie möglich zu beantworten, denken Sie an eines: Sie müssen mit der menschlichen Natur kämpfen. Es gibt eine Reihe von kognitiven Verzerrungen, die überwunden werden müssen, um die Technologie effektiv bewerten zu können. Hier nur einige:

Der Effekt des Beitritts zur Mehrheit - jeder weiß davon, aber es ist immer noch schwierig, damit zu kämpfen. Stellen Sie einfach sicher, dass die Technologie wirklich Ihren tatsächlichen Anforderungen entspricht.
Der Effekt der Neuheit - Viele Entwickler neigen dazu, die Technologien, mit denen sie seit langem arbeiten, zu unterschätzen und die Vorteile der neuen Technologie zu überschätzen. Nicht nur Programmierer, sondern jeder ist dieser kognitiven Tendenz ausgesetzt.
Die Wirkung positiver Eigenschaften - wir neigen dazu zu sehen, was ist, und verlieren aus den Augen, was fehlt. Dies kann in Kombination mit dem Neuheitseffekt zu Chaos führen, da Sie die neue Technologie nicht nur überschätzen, sondern auch ihre Mängel ignorieren .

Eine objektive Beurteilung ist nicht einfach, aber das Verständnis grundlegender kognitiver Vorurteile hilft, rationalere Entscheidungen zu treffen.

Zusammenfassung

Wenn eine bestimmte Innovation auftritt, müssen zwei Fragen mit großer Sorgfalt beantwortet werden:

Löst dieses Tool ein echtes Problem?
Verstehen wir Kompromisse gut?

Wenn Sie diese beiden Fragen nicht sicher beantworten können, treten Sie ein paar Schritte zurück und überlegen Sie.

War MongoDB im Allgemeinen die richtige Wahl? Ja natürlich; Wie bei den meisten technischen Technologien hängt dies von vielen Faktoren ab. Unter denjenigen, die diese beiden Fragen beantwortet haben, haben viele von MongoDB profitiert und profitieren weiterhin davon. Wer dies nicht getan hat, ich hoffe, sie haben eine wertvolle und nicht zu schmerzhafte Lektion über Bewegung entlang des Hype-Zyklus erhalten.

Haftungsausschluss

Ich möchte klarstellen, dass ich MongoDB weder liebe noch hasse. Es ist nur so, dass wir keine Probleme hatten, für die MongoDB am besten geeignet ist. Ich weiß, dass 10gen / MongoDB Inc. Zunächst handelte sie sehr kühn, setzte unsichere Standardwerte und bewarb MongoDB überall (insbesondere bei Hackathons) als universelle Lösung für die Arbeit mit Daten. Dies war wahrscheinlich eine schlechte Entscheidung. Dies bestätigt jedoch den hier beschriebenen Ansatz: Diese Probleme konnten auch bei einer oberflächlichen Bewertung der Technologie sehr schnell erkannt werden.

War MongoDB überhaupt die richtige Wahl?