Zoe sieht beim Abendessen mein T-Shirt: "Was heißt denn Schpark Punkt Punkt Punkt Punkt Punkt fünf?" Sie lernt lesen und alles was Buchstaben hat, ist derzeit interessant. Zufällig war es ein Firmen T-Shirt von der letzten Weihnachtsfeier - und da steht nunmal "Spark5" drauf. Der richtige Anlass, endlich einen Blog-Post über unsere freien Stellen zu schreiben.
Suchergebnisse mit Tag „mysql“
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.
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.
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.
Baumstrukturen sind weit verbereitet in der EDV. Jedes aktuelle Betriebssystem kennt "Verzeichnisse" oder "Ordner" die beliebig verschachtelt werden können und auch viele moderne Applikationen beschränken sich nicht mehr auf eine feste Anzahl von Ebenen. Aber wie legt man so einen Baum in einer (SQL-)Datenbank ab?
Some errors are really hard to find: They appear only sometimes or only on live systems or within complex source that can't run manually using a debugger. Adding debug output might help, but might also be confusing as the DBI error code 4 "statement contains no result" does.
Zur richtigen Nutzung von MySQL-Indices habe ich bereits früher schon gebloggt, aber nicht alle Problemstellungen lassen sich so einfach beantworten. Im konkreten Fall ging es um zwei WHERE-Bedingungen: email LIKE '%@somedomain.de' im Vergleich zu SUBSTRING_INDEX(email, '\@', -1) = 'somedomain.de'. Das Ergebnis hat mich ein wenig überrascht.
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.
SQL wird gerne als Artbezeichnung für Datenbanken verwendet, dabei ist es nur eine genormte Sprache, in der mit Datenbanken kommuniziert werden kann. Zutreffender wäre eigentlich die weitaus weniger verbreitete Bezeichnung RDBMS für Relational Database Management System.
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.
Von Zeit zu Zeit brauche ich Herausforderungen. Gerade steht wieder eine an und zwar ein High-Performance-System, das mit großen Datenmengen arbeiten soll. Einer der Knackpunkte ist die Gruppierung von zur Verarbeitung anstehenden Datensätzen einer MySQL-Datenbank, doch ich wünschte, es wäre eine MongoDB, die nativ Arrays und MapReduce unterstützt.
Here are three SQL queries and one simple challenge: Order them by speed assuming that city has an index.
1. SELECT city, SUM(inhabitants) FROM population GROUP BY city
2. SELECT city, SUM(inhabitants) FROM population GROUP BY city ORDER BY city
3. SELECT city, SUM(inhabitants) FROM population GROUP BY city ORDER BY city DESC
Eines habe ich in den letzten Jahren, in denen ich jobbedingt zwangsweise mySQL-Anwender wurde, gelernt: mySQL ist immer für eine Überraschung gut und man sollte nichts, aber auch rein gar nichts "annehmen" oder "voraussetzen", schon gar kein "das ist ja logisch, das wird bestimmt so sein".
mySQL macht selten was man erwartet, einige Sonderfälle scheinen absolut willkürlich zu sein. Dazu gehört die Verwendung von NOW() oder CURRENT_TIMESTAMP in DEFAULT-Werten einer Tabelle.
Look at the title and you're done. No need to add a text to this post if everything is said in the title. Not really? France is too small to hold half of the world's population? No way! My computer told me that 4.294.967.296 people live in France - and computers don't fail, you know?
Heute wurde mir eine kurze Frage gestellt:
Wir wollen in Richtung DB Slaves gehen, um die Hauptdatenbank zu entlasten. Ich würde gerne aus Deiner Sicht erfahren, wo Probleme auftauchen können.
