In NoSQL:Wenn es nur so einfach wäre , schreibt der Autor über MongoDB:
MongoDB ist kein Key/Value Store, es ist einiges mehr. Es ist definitiv auch kein RDBMS. Ich habe MongoDB nicht in der Produktion verwendet, aber ich habe es ein wenig zum Erstellen einer Test-App verwendet, und es ist ein sehr cooles Teil des Kits. Es scheint sehr leistungsfähig zu sein und hat entweder Fehlertoleranz und Auto-Sharding (auch bekannt als Skalierung). Ich denke, Mongo könnte einem RDBMS-Ersatz, den ich bisher gesehen habe, am nächsten kommen. Es funktioniert nicht für alle Datensätze und Zugriffsmuster, aber es wurde für Ihre typischen CRUD-Sachen entwickelt. Die meisten Menschen verwenden eine relationale Datenbank, um etwas zu speichern, was im Wesentlichen ein riesiger Hash ist, und in der Lage zu sein, einen dieser Schlüssel auszuwählen. Wenn Ihre DB 3NF ist und Sie keine Verknüpfungen vornehmen (Sie wählen nur eine Reihe von Tabellen aus und fügen alle Objekte zusammen, auch bekannt als das, was die meisten Leute in einer Webanwendung tun), wäre MongoDB wahrscheinlich der Hammer dafür du.
Dann im Schluss:
Die wahre Sache, auf die Sie hinweisen sollten, ist, dass Sie etwas falsch machen, wenn Sie daran gehindert werden, etwas supertolles zu machen, weil Sie keine Datenbank auswählen können. Wenn Sie MySQL kennen, verwenden Sie es einfach. Optimieren Sie, wenn Sie es wirklich brauchen. Verwenden Sie es wie einen K/V-Store, verwenden Sie es wie ein RDBMS, aber bauen Sie um Himmels willen Ihre Killer-App! Nichts davon spielt für die meisten Apps eine Rolle. Facebook verwendet immer noch sehr viel MySQL. Wikipedia verwendet sehr viel MySQL. FriendFeed verwendet sehr viel MySQL. NoSQL ist ein großartiges Tool, aber es wird sicherlich nicht Ihr Wettbewerbsvorteil sein, es wird Ihre App nicht heiß machen, und vor allem wird es Ihren Benutzern egal sein.
Worauf werde ich meine nächste App aufbauen? Vermutlich Postgres. Werde ich NoSQL verwenden? Vielleicht. Ich könnte auch Hadoop und Hive verwenden. Ich könnte alles in flachen Dateien aufbewahren. Vielleicht fange ich an, Maglev zu hacken. Ich verwende das, was für den Job am besten geeignet ist. Wenn ich Berichte benötige, verwende ich kein NoSQL. Wenn ich Caching brauche, werde ich wahrscheinlich Tokyo Tyrant verwenden. Wenn ich ACIDity brauche, verwende ich NoSQL nicht. Wenn ich eine Menge Zähler brauche, verwende ich Redis. Wenn ich Transaktionen benötige, verwende ich Postgres. Wenn ich viele Dokumente eines einzigen Typs habe, verwende ich wahrscheinlich Mongo. Wenn ich 1 Milliarde Objekte pro Tag schreiben muss, würde ich wahrscheinlich Voldemort verwenden. Wenn ich eine Volltextsuche benötige, würde ich wahrscheinlich Solr verwenden. Wenn ich eine Volltextsuche nach flüchtigen Daten benötige, würde ich wahrscheinlich Sphinx verwenden.
Ich mag diesen Artikel, ich finde ihn sehr informativ, er gibt einen guten Überblick über die NoSQL-Landschaft und den Hype. Aber, und das ist das Wichtigste, es hilft wirklich, sich die richtigen Fragen zu stellen, wenn es um die Wahl zwischen RDBMS und NoSQL geht. IMHO lesenswert.
