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.
Suchergebnisse für „MongoDB“
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.
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.
Sonntag Nachmittag, ein ruhiges Wochenende neigt sich dem Ende zu, als die erste Katastrophennachricht eintrifft. Binnen 4 Stunden folgen mehr als genug weitere.
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.
