Oh Justine, was hast Du da nur angerichtet. Ein Thema, zu dem mir sofort klar war, über was ich schreiben werde und eben so klar, dass es ein ganz anderer Battle-Post werden wird, als die bisherigen. Es geht nicht um Blumen, Sarkasmus oder schein-philosophische Betrachtungen, sondern um die harte, gemeine Realität.
Suchergebnisse für „Perl“
Zum dieswöchigen Blog-Battle-Thema wollte ich eigentlich schon längst mal etwas schreiben, aber es wäre ein reiner Jammerpost geworden. So habe ich jetzt eine schöne Ausrede, um ihn doch zu schreiben.
ElasticSearch is a search engine. It's made for extremly fast searching in big data volumes. But sometimes one needs to fetch some database documents with known IDs. I found five different ways to do the job. Let's see which one is the best.
...so die Unterstellung von Justine kürzlich im Blog-Tags Chat. Rein objektiv betrachtet hat sie Recht, obwohl das natürlich praktisch unmöglich ist. Trotzdem schadet eine ergebnisoffene sachliche Analyse der Fakten bestimmt nichts.
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.
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.
