Lassen Sie sich nicht vom räumlichen Maßstab (über 1000 Geräte) in Bezug auf den Rechen- und/oder Speicherumfang täuschen. Ein paar Dutzend 35-Byte-Einfügungen pro Sekunde sind eine triviale Arbeitslast für jedes Mainstream-DBMS, selbst wenn es auf Low-End-Hardware läuft. Ebenso liegen 142 Millionen Datensätze pro Monat nur in der Größenordnung von 1 bis 10 Gigabyte Speicherplatz pro Monat, ohne jegliche Komprimierung, einschließlich Indizes.
In Ihrem Fragenkommentar sagten Sie:
„Es dreht sich alles um Zuverlässigkeit, Skalierbarkeit und Geschwindigkeit. Es ist sehr wichtig, dass die Lösung leicht skalierbar ist (MongoDB-Autosharding?), indem einfach mehr Knoten hinzugefügt werden, und die Geschwindigkeit ist auch sehr wichtig.
Verlässlichkeit? Jedes Mainstream-DBMS kann dies garantieren (vorausgesetzt, Sie meinen, es wird Ihre Daten nicht beschädigen und es wird nicht abstürzen - siehe meine Diskussion des CAP-Theorems am Ende dieser Antwort). Geschwindigkeit? Selbst mit einer einzigen Maschine sollte das 10- bis 100-fache dieser Arbeitslast kein Problem darstellen. Skalierbarkeit? Bei der aktuellen Rate würden die Daten eines ganzen Jahres, unkomprimiert, sogar vollständig indiziert, problemlos in 100 Gigabyte Festplattenspeicher passen (ebenfalls haben wir bereits festgestellt, dass die Einfügungsrate kein Problem darstellt).
Daher sehe ich keinen eindeutigen Bedarf für eine exotische Lösung wie NoSQL oder gar eine verteilte Datenbank – eine einfache, alte relationale Datenbank wie MySQL wäre völlig in Ordnung. Wenn Sie sich Sorgen um Failover machen, richten Sie einfach einen Backup-Server in einer Master-Slave-Konfiguration ein. Wenn wir über das 100- oder 1000-fache der aktuellen Skalierung sprechen, partitionieren Sie einfach einige Instanzen horizontal basierend auf der ID des Datenerfassungsgeräts (d. h. {Partitionsindex} ={Geräte-ID} modulo {Anzahl der Partitionen}).
Denken Sie daran, dass das Verlassen der sicheren und bequemen Grenzen der relationalen Datenbankwelt bedeutet, sowohl ihr repräsentatives Modell aufzugeben und sein reiches Toolset . Dadurch wird Ihr "komplexes Datamining" viel schwieriger - Sie müssen Daten nicht nur in die Datenbank eingeben, sondern auch herausholen.
Abgesehen davon sind MongoDB und CouchDB ungewöhnlich einfach zu implementieren und damit zu arbeiten. Sie machen auch sehr viel Spaß und machen Sie für viele Menschen attraktiver (nicht nur für Programmierer, sondern auch für Führungskräfte!).
Die allgemeine Meinung ist, dass Cassandra von den drei von Ihnen vorgeschlagenen NoSQL-Lösungen die beste für ein hohes Einfügungsvolumen ist (relativ gesehen glaube ich natürlich nicht, dass Sie es haben hohes Insert-Volumen – dies wurde für die Verwendung durch Facebook entwickelt ); Dem wird entgegengewirkt, indem es schwieriger zu bearbeiten ist. Wenn Sie also keine seltsamen Anforderungen haben, die Sie nicht erwähnt haben, würde ich für Ihren Anwendungsfall davon abraten.
Wenn Sie positiv auf eine NoSQL-Bereitstellung eingestellt sind, sollten Sie das CAP-Theorem in Betracht ziehen. Dies wird Ihnen bei der Entscheidung zwischen MongoDB und CouchDB helfen. Hier ist ein guter Link:http://blog.nahurst.com/visual-guide-to-nosql-systems. Es läuft alles darauf hinaus, was Sie mit „Zuverlässigkeit“ meinen:MongoDB tauscht Verfügbarkeit gegen Konsistenz, während CouchDB Konsistenz gegen Verfügbarkeit eintauscht . (Cassandra ermöglicht es Ihnen, diesen Kompromiss pro Abfrage zu verfeinern, indem Sie angeben, wie viele Server geschrieben/gelesen werden müssen, damit ein Schreib-/Lesevorgang erfolgreich ist; UPDATE:Jetzt kann CouchDB das auch, mit BigCouch! Sehr aufregend ...)
Viel Glück bei Ihrem Projekt.
