Ist MongoDB in meinem Fall die richtige Wahl? [geschlossen]

Ich werde mein erstes echtes Projekt in Rails erstellen, das aus einer Web-App besteht, die aus drei Hauptteilen besteht:

• Der statische Teil, in dem keine Datenbank verwendet wird
• Der Benutzerregistrierungsteil, für den eine Datenbank erforderlich ist, und ich können MySQL verwenden, da die Zeilen jedes Benutzers dieselben Felder haben
• Die "App", in der Benutzer Elemente in Sammlungen erstellen, organisieren, bearbeiten und für andere Benutzer freigeben können

Es wird mehrere Elementtypen geben und jeder hat unterschiedliche Optionen, zum Beispiel kann ich "Video" -Elemente mit den folgenden Optionen haben:

• Ich würde
• Benutzeridentifikation
• collection_id
• Titel
• Plattform (falls eingebettet)
• URL (falls eingebettet)
• Dateiname (falls auf meiner App gehostet)
• Dateigröße (ID in meiner App gehostet)

und "Karten" -Elemente:

• Ich würde
• Benutzeridentifikation
• collection_id
• Titel
• Plattform (Google Maps, Bing Maps ...)
• Ort
• URL
• Kartengröße

Wie Sie können, während ich für Benutzer MySQL für Elemente verwenden kann, kann die Flexibilität von MongoDB nützlich sein, da jedes Element möglicherweise andere Optionen als ein anderes Element benötigt

Bisher habe ich immer PHP und MySQL verwendet (immer auf Shared Hosting für kleine Projekte) und Skalierbarkeit ist für mich ein völlig neues Wort.

Ich habe Zeit zu lernen, aber ich möchte in etwas wie 1 Monat etwas Konkretes tun können.

Ich habe viel über MongoDB und NoSQL im Vergleich zu RDMS und MySQL gelesen und nachdem ich es ausprobiert habe, muss ich sagen, dass mir die Funktionsweise von MongoDB gefällt: keine Tabellen, keine Zeilen und ihre Dokumente JSON wie folgt:

• Was würden Sie in meiner Situation empfehlen? Warum?
• Über Skalierbarkeit kann es Probleme mit MongoDB geben? Wenn ja, wann (in Bezug auf die DB-Größe) und können diese Probleme meine App erheblich verlangsamen?

Bearbeiten: wie die App funktioniert

Da viele gefragt haben, wie die App funktionieren soll:

1. Ein Benutzer meldet sich an
2. Er ist eingeloggt
3. Er kreiert seine erste Sammlung iside, mit der er unendlich viele Gegenstände kreieren kann
4. Es gibt verschiedene Arten von Elementen, und für jeden Typ müssen unterschiedliche Daten in der Datenbank gespeichert werden. Die Art der Elemente kann hinzugefügt oder geändert werden

Benutzer können andere Sammlungen und Elemente darin erstellen.

Wir haben also CRUD für Sammlungen und Elemente in ihnen und jede Sammlung / jedes Element wird an einen bestimmten Benutzer verwiesen

Das Hauptproblem bei MySQL ist, dass es kein flexibles Schema gibt. Gibt es eine Möglichkeit, dies zu lösen (eine Problemumgehung?).

Wenn ich an NoSQL denke, besteht der einzige Zweifel, den ich habe, in der Verknüpfung. Beispielsweise möchte ich bei einer bestimmten Spalte Daten abrufen, die sich auf den Benutzer mit dem Feld id = user_id in der Sammlung beziehen

EDIT: Idee, MySQL weiter zu verwenden

Erstellen Sie ein Feld in der Tabelle "Elemente" mit optionalen Einstellungen, wobei jede Einstellung durch ein | geteilt wird oder ein anderes Symbol.

Dann werde ich irgendwo eine Struktur der optionalen Einstellungen jedes Elements speichern, zum Beispiel benötigt der Elementtyp "Notizen" zwei optionale Einstellungen "Farbe" und "seltsame_Einstellung". Wenn ich die Daten von MySQL erhalte, teile ich das Feld für optionale Einstellungen in ein Array mit dem Wissen, dass das erste Element im Array für "Farbe" usw. steht.

Was denkst du? Gibt es ein Problem mit dieser Lösung? hast du andere ideen

Wir können Ihnen möglicherweise erst helfen, wenn Sie uns mitteilen, was Sie mit der App tun möchten. Relationale Datenbanken sind für bestimmte Dinge gut, und NoSQL-Datenbanken sind für andere gut.

Wie mir hier auf SO mal jemand gesagt hat:

Der relationale Teil einer relationalen Datenbank ist weitaus optimierter als einige andere Teile

Dies bedeutet, dass Sie eine relationale Datenbank auch dann verwenden können, wenn dies zu Ihren Anwendungsfällen passt. Machen Sie nicht einfach mit MongoDB weiter, weil es flexibel und skalierbar ist. Dies ist die erste Zeile über MongoDB auf Wikipedia:

MongoDB (von "humongous") ist ein dokumentenorientiertes Open-Source-NoSQL-Datenbanksystem.

Beabsichtigen Sie wirklich, eine dokumentenorientierte Datenbank zu verwenden? Wenn Ihre Anwendungsfälle eine gewisse Grafik aufweisen, können Sie sich sehr gut für eine Grafikdatenbank wie Neo4j entscheiden. Oder Sie können das Beste aus SQL und NoSQL sehr gut zusammen verwenden, wie es manche Leute tun.

Übrigens mache ich auch ein Projekt, in dem ich die besten Teile von SQL und NoSQL verwende.

EDIT: Ich sage noch einmal:

Lesen Sie den Abschnitt Neo4j vs Hadoop zu diesem Artikel. Es sagt:

Grundsätzlich befassen sich Hadoop und andere Key-Value-Speicher hauptsächlich mit relativ flachen Datenstrukturen . Das heißt, sie sind extrem schnell und skalierbar beim Abrufen einfacher Objekte wie Werte, Dokumente oder sogar Objekte.

Benötigen Sie unter Bezugnahme auf denselben Artikel wirklich eine flache Datenstruktur, für die Sie sich für MongoDB entscheiden? Dies hängt letztendlich von Ihren detaillierten Anwendungsfällen ab, wie die Schritte 3 und 4 ausgeführt werden.

Darüber hinaus möchten Sie möglicherweise folgende Fragen stellen:

/programming/2124274/mongodb-what-to-know-before-using

/programming/1476295/when-to-use-mongodb-or-other-document-oriented-database-systems

( Schauen Sie sich die oberste / ausgewählte Antwort der zweiten Frage sicher an. Sie befinden sich in dem Dilemma, das dies möglicherweise gerade löst. )

Ich denke, diese Fragen haben alle Informationen, die Sie wissen wollten. Am Ende müssen Sie selbst entscheiden, ob es sich um MongoDb oder etwas anderes handelt. Wir können es nur empfehlen. Die einzigen Personen, die Ihre detaillierten Anwendungsfälle kennen, sind Sie und Ihr Team.

WIEDER BEARBEITEN (für den MySQL-Teil): Wie ich es verstanden habe, planen Sie, etwas in der Datenbank zu speichern und durch ein Trennzeichen zu trennen. Dies wirft 2 Probleme auf:

1. Sie müssen zusätzlich alle Eingaben verarbeiten, die das Trennzeichen haben.
2. Der relationale Speicherteil einer relationalen Datenbank ist weitaus optimierter als der String-Matching-Teil. Ich würde mich nicht für ein Schema entscheiden, bei dem ich einen String-Abgleich in einer Datenbank durchführen muss, um ein bestimmtes Ergebnis zu erhalten. Wieder betone ich:

   Der relationale Teil einer relationalen Datenbank ist weitaus optimierter als einige andere Teile (z. B. String-Matching).

3. Verwenden Sie keine mehrwertigen Attribute. Die Leute fürchten sie im Allgemeinen.

Ich sehe diese Frage sehr oft. Es scheint immer als entweder / oder gedacht zu sein. MongoDB ist ein großartiges neues Tool. Es scheint auch manchmal das glänzende Werkzeug für alles zu sein, und das kann meiner Erfahrung nach eine schlechte Wahl sein.

Ich denke, die beste Kombination ist definitiv BEIDE und ich möchte Sie für Ihren Ansatz loben, mylsql für einige Teile, wie z. B. Benutzer, zu verwenden, aber MongoDB für andere Teile zu verwenden, da ich der Meinung bin, dass Authentifizierung und Autorisierung am besten mit mySQL durchgeführt werden und es gibt Eine Menge Beispiele und Module, die das wirklich gut machen.

Für das Stück "Große Anzahl von Elementen" sollten Sie die Verwendung von mongoDB in Betracht ziehen, wenn Ihr Volumen hoch ist und / oder es sich hauptsächlich um gelesene und / oder unstrukturierte Daten handelt.

Ich würde raten, Ihre Entscheidung nicht auf Mongos schemalose Flexibilität zu stützen. SQL- und SQL-Schemata entstanden aus der Notwendigkeit, strukturierte Daten zu haben und Berechnungen und Transformationen durchführen zu können, die nur mit einer solchen Struktur möglich sind. Ich habe dies aus 5 Jahren Arbeit in einer Data Warehouse-Rolle gelernt. Ich würde mich nur wegen des Leistungsproblems an MongoBD wenden. Wenn Sie eine große Anzahl von Benutzern und Anfragen erwarten oder erwarten, z. B. 100.000 Benutzer und 20 Anfragen pro Sekunde, würde ich mongoDB verwenden, andernfalls würde ich versuchen, bei SQL zu bleiben. In vielen Fällen würde ich mySQL für geringes Volumen verwenden und dann, da Volumen, Einkommen und Infrastruktur dies unterstützen, zu Oracle wechseln, bevor ich mongoDB einmische. Ich bin damit einverstanden, dass Sie nicht versuchen sollten, Volumenprobleme zu lösen, bevor Sie sie bemerken, aber wenn Sie eine gute Vorstellung davon haben, wohin Sie gehen und nicht. Um die Dinge auf halbem Weg neu zu schreiben, ist es sehr sinnvoll, gleich zu Beginn die richtigen Technologien auszuwählen. Denken Sie daran, dass es auf allen Ebenen des Stapels eine Vielzahl von Optionen und Technologien gibt, die Sie verwenden möchten, wenn Sie wirklich über ein so hohes Volumen verfügen.

Locker strukturierte Daten haben Nachteile. Ich benutze hier die Parkplatzanalogie. Keine Trennlinien sind großartig für die ersten 3 Autos, die einfahren, aber wenn mehr Autos einfahren, kommt es zu einer Menge Desorganisation und der Versuch, geparkt zu werden oder Autos leicht zu zählen und die Fahrspuren frei zu halten, wird zum Albtraum. Die Organisation erfordert Arbeit im Voraus - das Markieren von Linien und Trennwänden, Verkehrsströmen usw., aber es zahlt sich aus. Manchmal ändern sich die Dinge natürlich (Autos werden größer) und Sie müssen einige Änderungen vornehmen - Linien neu streichen. Plus nur Standard-Ausfallzeit für jährliche Neulackierungen und Wartung.

Der Aspekt des Schemadesigns wird wahrscheinlich die größte Hürde für traditionelle MySQL-Benutzer sein. Ich denke, die MongoDb-Seite zum Schema-Design hilft dabei. Mein letzter Punkt ist, dass jede Technologie, die Sie dem Mix hinzufügen, die Komplexität erhöht. Es gibt oft große Befürworter für ein bestimmtes Stück, die sagen, dass Sie es "verwenden" müssen, aber ich habe festgestellt, dass ein wirklich großer Faktor darin besteht, wie viele Stücke es gibt. Dies impliziert mehr mögliche Fehlerquellen und vor allem eine Wissensbasis, die jeder andere wissen muss, um daran arbeiten zu können.

fyi Rick Obsorne hat ein ziemlich erstaunliches Vergleichsdiagramm , das ziemlich einzigartig ist!

Ich sehe hier viele gültige Argumente für NoSQL vs MySQL. Ein fehlendes Glied betrifft jedoch die Skalierung: Wenn Sie wirklich skalieren und dies mit einer internen Datenbank tun möchten, benötigen Sie eine Menge Wissen über Datenbanken. Es gibt zu viele Horrorgeschichten, in denen Menschen nicht versucht haben, ein System zu implementieren, das unendlich skalierbar ist.

Wenn Sie sich wirklich für die NoSQL-Route entscheiden (und bereit sind, die damit verbundenen Kosten zu tragen - wie keine Joins), sollten Sie AWS DynamoDB (http://aws.amazon.com/dynamodb/) in Betracht ziehen. Hier können Sie den gesamten Teil der Datenbankskalierung vergessen und sich auf Ihre Anwendung konzentrieren. Viel Glück.

Haftungsausschluss: Ich bin Entwickler im AWS DynamoDB-Team, glaube aber fest an unser Produkt. Probieren Sie es aus :)

Ihr Design kann also zwei verschiedene Arten von Objekten in Ihrer Datenbank speichern:

• Benutzerobjekt (das immer die Felder hat).
• Apps-Objekte (die unterschiedliche Felder haben können). Eine App gehört nur einem Benutzer.

Eine Sammlung könnte oder könnte nicht als anderes Objekt erstellt werden, da es sich nur um ein Tag zum Gruppieren verschiedener Apps handelt. Nehmen wir zum Zwecke der Argumentation an, es gibt keine Sammlungen und Benutzer haben nur eine Liste von Anwendungen.

Während ich denke, dass dies unter MySQL möglich ist, haben Sie in MongoDB eine größere Flexibilität in Bezug auf die Struktur von App-Objekten, und wahrscheinlich wird Ihre Darstellung natürlicher in die Datenbank abgebildet, wodurch der Code einfacher wird.

In MySQL haben Sie Probleme mit unterschiedlichen Formaten für unterschiedliche Apps, aber es ist möglich. Einige Ideen:

• Sie können eine Zwischentabelle mit allen gemeinsamen Informationen zwischen allen Objekten (ID, Benutzer-ID, Titel usw.) und dann dem Typ erstellen, sodass Sie in einer anderen Tabelle nur mit den nicht gemeinsamen Feldern für dieses Format danach suchen können (z Dateiname und Dateigröße für Dateien). Sie müssen für jedes Format eine andere Tabelle erstellen. Wenn beide Tabellen mit app_id (Primärschlüssel) indiziert sind, ist dies schnell genug, da der Zugriff auf eine Tabelle über einen indizierten Wert schnell ist.
• Sie können die Daten in einem bestimmten Format codieren und standardisiert speichern. Codieren Sie beispielsweise die nicht allgemeinen Daten in JSON als Zeichenfolge und speichern Sie sie in einem VARCHAR-Feld. Seien Sie vorsichtig mit der Größe dieses Feldes, damit Ihnen nicht der Platz ausgeht. Das Format kann komplex (JSON) oder einfach sein (nur durch Kommas getrennte Werte).
• Sie können verschiedene "generische" Felder erstellen, z. B. int1, int2, str1, str2, und definieren, dass str1 für einen App-Typ "Dateiname" ist, während für einen anderen Typ "Speicherort" sein kann.

In MongoDB kann es so einfach sein, nur zwei MongoDB-Sammlungen zu verwenden, eine für die Benutzer und eine für die Apps. Unter der Annahme einer Art von Grenze (was nicht der Fall ist, wie Sie beschrieben haben, sondern nur um es zu sagen), könnten Sie die Apps sogar als Liste im Benutzerobjekt speichern. Das Speichern und Abrufen der Daten ist natürlicher, da Sie jede Art von Objekt speichern können, unabhängig von den Feldern. Sie können nach user_id suchen, um alle Apps abzurufen, die einem Benutzer gehören. In MongoDB verlieren Sie sowieso die Möglichkeit, Join-Abfragen durchzuführen, aber in diesem Fall denke ich, dass die grundlegenden Abfragen darin bestehen, den Benutzer und die mit dem Benutzer verbundenen Apps abzurufen. Wenn Sie vorhaben, eine Menge Dinge wie "Geben Sie mir die Benutzer, die mehr als zwei Sammlungen mit jeweils drei oder weniger Anwendungen haben" auszuführen, müssen Sie diese nicht als Join-Abfrage generieren. Dies ist jedoch ein Prozess im Code und weniger natürlich als in einer relationalen Datenbank. Die Verarbeitung kann länger dauern. Wenn Sie nach Parametern suchen möchten (z. B. geben Sie mir alle Apps, die einem bestimmten Benutzer gehören; geben Sie mir alle Apps vom Typ X), ist dies für MongoDB recht einfach und Sie müssen keine Joins verwenden.

Ich bin mir nicht sicher, ob MongoDB on Rails unterstützt wird. Ich habe es in Python und JavaScript verwendet.

BEARBEITEN: Kommentar zur Zeit beim Zugriff auf zwei Tabellen und eine weitere MySQL-Option hinzugefügt

Ich würde sagen, verwenden Sie die Technologie, die Sie am besten kennen, insbesondere wenn es sich um ein echtes Projekt handelt und Sie es schnell veröffentlichen möchten. Die Verwendung von MySQL und Mongo bringt sowohl Vorteile als auch Kopfschmerzen mit sich. Nachdem ich mit beiden gearbeitet habe, möchte ich auch hinzufügen, dass es nicht sehr schwierig ist, von MySQL nach Mongo zu migrieren, wenn Sie guten Designprinzipien folgen.

Ein guter Grund, sich in Ihrem Fall für MongoDB zu entscheiden, sind Ihre Daten. Wie Sie bereits erwähnt haben, haben Sie verschiedene Arten von Einträgen für Ihre Sammlungen: Karte, Video usw. Wenn Sie dies mit RDBMS implementieren, haben Sie drei Ansätze:

• Tabelle pro Typ: Jede Tabelle enthält Spalten, die für jeden Objekttyp spezifisch sind

  Nachteile : N Abfrage zur Suche über alle Datentypen.

  Vorteile : gutes OO-Design, leicht zu warten

• Einzeltabelle: Eine große Tabelle mit allen möglichen Attributen für alle Typen, von denen die meisten für einen bestimmten Eintrag null sind

  Nachteile : Das Ändern eines Objekts erfordert das Ändern der Tabelle. Dies ist schmerzhaft, sobald die Tabelle groß wird. Schwer zu pflegen.

  Vorteile : Einfach zu implementieren.

• Kerntabelle mit Metadaten: Sie haben eine einzelne Tabelle mit den Kernattributen, z. B. Titel, Datum, und eine Metadatentabelle mit Schlüssel-Wert-Paaren für zusätzliche Attribute

  Nachteile : Zwei Abfragen, um alle Daten für ein einzelnes Objekt abzurufen.

  Vorteile : Extrem flexibel, nicht sehr schwer zu implementieren.

Ich habe jeden dieser Ansätze schon einmal verwendet, und ich kann sagen, dass keiner so selbstverständlich ist, mit Mongo zu arbeiten. Ihre Daten werden wahrscheinlich ungefähr so ​​aussehen:

{_id:"collection1",
 name:"My first Collection",
 owner: "user123243342",
 entries: [
    {type:"video",
     url: "http://www.youtube.com/234324",
     tags: ["roadtrip", "fun", "camera"]
     },
    {type:"map",
     coordinates: [LOC: [38, –102], LOC: [43, –33], LOC: [228, –102]],
     description: "Road trip to nowhere",
 ]
}

Sie müssen sich jedoch nicht wirklich um das Schema-Design kümmern, da Ihre Domänenobjekte direkt als solche beibehalten werden können. MongoDB ist im Wesentlichen Ihr Objektspeicher, gegen den Sie abfragen können.

Ich habe festgestellt, dass ich keine Diskussion über den Leistungsvergleich zwischen MySql und Mongodb ausgelassen habe. Während Sie immer die Leistung im Auge behalten sollten, können Sie nur dann effektiv Entscheidungen treffen, wenn Sie das Datenzugriffsmuster kennen. Jedes gute Projekt wird wahrscheinlich einige Iterationen des Refactorings durchlaufen, wenn es wächst und neue Herausforderungen auftauchen. Sorgen Sie sich nicht vorzeitig um die Leistung und wählen Sie das Tool aus, das Sie am besten kennen, und beginnen Sie mit dem Codieren.

Bearbeiten

Um auf Ihre spezielle Frage zur Verwendung von MySQL zu antworten und Attribute mit "|" im selben Feld zu belassen. Tu das nicht. Dieser Ansatz gibt Ihnen mehr Probleme als er löst. Erstens können Sie mit MySql keine einzelnen Attribute abfragen. Zweitens erhöht dies die Komplexität Ihrer Datenzugriffsschicht. Verwenden Sie stattdessen entweder den Typ-pro-Tabelle- oder den Metadaten-Ansatz. Wenn Sie zuvor mit WordPress gearbeitet haben, wird der Metadatenansatz verwendet:

• Benutzertabelle + Usemeta für Benutzer
• post table + postmeta table post

Dies macht die Datenstruktur äußerst flexibel und dennoch mit angemessener Geschwindigkeit abfragbar.

Der folgende Artikel bietet gute Ergebnisse beim Vergleich von MySQL und MongoDB hinsichtlich Auswählen, Abrufen und Einfügen unter Berücksichtigung der Datenmenge in der Datenbank und der Menge der abgerufenen Daten. Die Ergebnisse zeigen eine große Leistung für MongoDB in Bezug auf die "Inserts", aber in den anderen Fällen gewinnt MySQL. Siehe unten:

http://www.moredevs.ro/mysql-vs-mongodb-performance-benchmark/

Ich hatte die Erfahrung mit MongoDB, dass ich denke, dass es eine gute Lösung war. Ich habe damit jeden Tag Tausende von Sammlungen eingefügt. In Kombination mit der Solr-Lösung (Cache-Lösung, einmal täglich aktualisiert) kann ich die MongoDB-Daten bei Bedarf anhand der Erfassungs-ID abrufen, sodass ich keine Auswahl im laufenden Betrieb benötige. Wenn man bedenkt, dass man sich mit vielen Beilagen befassen muss und sich nicht um das Auswählen und Abrufen kümmern muss, könnte MongoDB eine großartige Idee sein, es hängt von jedem Fall ab und führt eine gute Analyse durch.