Im ersten Anlauf schienen mir die Ergebnisse wenig aussagekräftig, also habe ich neue Testdaten generiert. Dieses Mal steht die dreifache Menge Datensätze zur Verfügung, die Suchkriterien bleiben die gleichen.
Suchergebnisse mit Tag „mongodb“
mySQL, ElasticSearch und MongoDB sind installiert und mit Testdaten befüllt - Zeit für den Geschwindigkeitsvergleich. Zur Erinnerung: Es geht um die Performance bei der parallelen Ausführung unterschiedlicher komplexer Suchanfragen einer existierenden Applikation, die mySQL regelmäßig an seine Grenzen bringt. ElasticSearch hat seinen Ruf als hochperformante Suchmaschine zu verteidigen und MongoDB soll zeigen, wie eine andere Datenbank im Vergleich abschneidet.
Um ElasticSearch mit den beiden Datenbanken vergleichen zu können, müssen alle drei natürlich die gleiche Aufgabe lösen. Dazu muss eine bestehende SQL-Abfrage in die Query-Sprachen von ElasticSearch und MongoDB übersetzt werden.
mySQL, ElasticSearch und MongoDB müssen sich einem echten Anwendungsfall stellen. Bei der Installation der Clients und Server war mySQL außen vor und das gleiche gilt für den Import der Testdaten: Diese liegen in einer mySQL-Datenbank mit einem praxistauglichen Normalisierungsgrad vor und müssen für einen echten Vergleich jetzt in beide NoSQL-Lösungen übernommen werden.
Ein kleiner Vergleichstest soll zeigen, wie sich mySQL, ElasticSearch oder MongoDB im Praxisumfeld einer echten Applikation bei komplexen Suchanfragen schlagen. Doch bevor alle drei abgefragt werden können, müssen sie erstmal installiert werden.
Anfang des Jahres habe ich mySQL und MongoDB aus Sicht der Daten verglichen, jetzt geht es um Leistung. Neu im Bunde ist dieses Mal ElasticSearch, eine nicht-Datenbank, die sich vor allem mit schneller Volltextsuche rühmt, aber kann sie auch im Praxiseinsatz mithalten?
JOIN ist ein mächtiges Werkzeug, das allerdings auf einen Datenbankserver* beschränkt ist. Wenn dann noch SQL und NoSQL verknüpft werden müssen, steigt der Aufwand schnell in unsinnige Dimensionen. Am Beispiel von MySQL und MongoDB möchte ich zeigen, dass es auch anders geht.
Error messages should be simple, clear and easy to understand. But there are differences: A developer writing some sourcecode will think of something different as "easy to understand" than a user who doesn't know the source or internals. MongoDB reports a "DBClientCursor::init call() failed" on connect errors. Do you know what this message means?
Jede neue Datenbank erfordert einen neuen Lernschritt: Befehle und teilweise auch die Syntax sind trotz aller Standartisierung von SQL über ein klein wenig anders, aber im Allgemeinen findet man sich schnell zurecht - zumindest, wenn der Umstieg von einer SQL-Datenbank auf eine andere erfolgt. Bei NoSQL reicht es dagegen nicht aus, einfach ein paar neue Befehle zu lernen.
Es gibt einen ganz sicheren Weg, die ersten NoSQL-Versuche in einem Fiasko enden zu lassen: MongoDB als 1:1 Ersatz für MySQL verwenden. Der Wechsel zu einer NoSQL-Datenbank ist nicht einfach nur ein Wechsel des Datenspeichers, sondern erfordert auch eine grundlegend neue Arbeits- und Denkweise.
Mit MySQL und MongoDB stehen sich die wohl jeweils am weitesten verbreiteten Vertreter ihrer Datenbankgattung gegenüber. Beide stehen für jeweils ein komplett gegensätzliches Datenhaltungskonzept und haben trotzdem überraschend viele Gemeinsamkeiten.
NoSQL ist eine ebenso irreführende Bezeichnung für ein Datenbankkonzept, wie SQL. Mit ein wenig Hilfe von Postgres kann MongoDB sogar mit SQL-Befehlen angesprochen werden. Tatsächlich bezieht sich das NoSQL-Konzept eher auf die Art der Datenhaltung: Die von RDBMS bekannten Datensätze existieren nach wie vor, folgen aber keiner festen Form mehr. Statt dessen beinhaltet jeder Datensatz ein komplettes Dokument.
Vor rund zwei Jahren habe ich mir die Frage gestellt, ob eine der neumodischen NoSQL Datenbanken wirklich schon ein praxistauglicher Ersatz für die mit jeweils ganz eigenen Problemen behafteten bekannten SQL-Datenbanken sein kann. Heute kann ich diese Frage ganz klar mit JA beantworten und möchte mit dieser Mini-Serie einen Weg zum Umstieg aufzeigen.
I recently started my first Dancer & MongoDB project. MongoDB is my preferred database (at the moment) and Dancer is a great framework, but something is missing: I really prefer using an ORM and didn't find anything for MongoDB which fits my needs.
There are few better ways for taking a SQL server down than SELECT ... JOIN statements. Don't get me wrong - a good JOIN could really fast, but huge JOIN blocks adding 10 or more foreign tables maybe even without using indexes could easily slow down the biggest SQL server. MongoDB has MapReduce to do the job with much less server impact - but more developer brain usage.
Perl doesn't care about numbers, integer or float - at least on the script level - but MongoDB does. The driver's default number detection algorithm treats floats as strings and MongoDB doesn't like to compare strings with less-than or greater-than operations.
Ich nutze MongoDB schon seit über einem Jahr, bisher aber nur für kleinere Sachen - und ohne MapReduce. Dabei ist es genau diese Funktion, die viel zur Macht dieser ungewöhnlichen Datenbank beiträgt.
I recently decided to prefer MongoDB for new projects and it turned out that I still need to learn a lot of things about it. One of them is MapReduce which is more powerful than (most) SQL SELECT options.
Früher war die Sache einfach: Eine Textdatei oder später ein tie-Call und die Daten waren gespeichert. Heute kämpfen verschiedene Datenbanken um die Vorherrschaft - aber eine wirklich gute Option scheint es nicht zu geben, man kann nur das kleinste Übel wählen.
The YAWF framework is available from CPAN, but it still needs a Webserver and some environment for working at it's best. This tutorial shows everything needed to set up a new OpenVZ VE (VServer) with MongoDB and YAWF framework on an existing OpenVZ host.
