Warum ist die Verwendung von MySQL für eine Wörterbuch-Website eine schlechte Idee?

Ich plane, eine Datenbank zu entwerfen und einzurichten, in der Wörterbucheinträge (normalerweise einzelne Wörter) und ihre Bedeutung in einer anderen Sprache gespeichert werden. So zum Beispiel die Tabelle Glossar muss Eintrag und Definition und jede Tabelle Datensatz einen Verweis auf die hat ID einen Datensatz in gespeichert Tag(Jeder Eintrag muss einen Tag oder eine Kategorie hat).

Da meine Daten eine Struktur haben, dachte ich, dass die Verwendung einer SQL-Datenbank (wie MySQL) keine schlechte Idee ist. Aber die Leute sagen, MongoDB ist viel besser für die Leistung.

Auf der Clientseite muss die Anwendung in der Lage sein, ein Suchfeld mit Autocomplete bereitzustellen, das eine vom Backend bereitgestellte REST-API verwendet. Ist es in einem solchen Szenario sicher, mit MySQL zu arbeiten? oder sollte ich MongoDB oder ElasticSearch einer anderen Lösung dafür verwenden? Hunderttausende von Datensätzen sollen auf diese Weise gespeichert und abgerufen werden.

Ich kann dir nicht sagen, warum es eine schlechte Idee ist. Ich kann Ihnen eine Reihe von Gründen nennen, warum eine relationale Datenbank eine gute Idee ist.

1. Denken Sie daran, dass nicht jeder ein Wörterbuch nach einer Definition durchsucht. Mehrmals wird ein Wörterbuch verwendet, um die richtige Schreibweise zu finden. Das heißt, Sie finden nicht nur eine Nadel im Heuhaufen , sondern Sie suchen im Heuhaufen nach Nadeln, die der vom Benutzer beschriebenen ähnlich sind (wenn ich ein Idiom verwenden darf).

   Sie werden nicht nur nach Primärschlüsseln suchen. Sie führen eine Stichwortsuche durch

2. Wörter können entweder in der Bedeutung oder in der Schreibweise verwandt sein ( Lesen, Lesen , Rot und Schilf )

   Wann immer Sie das Wort "related" sehen, denken Sie an "Relational Database".

3. Wenn Sie Geschwindigkeit benötigen, müssen Sie die relationale Datenbank zwischenspeichern, nicht ein defektes relationales Datenmodell

4. Eine ordnungsgemäß normalisierte Datenbank beschleunigt das Nachschlagen und Durchsuchen von Primärschlüsseln, da einfach weniger Bits zum Durchsuchen vorhanden sind.

5. Die Leute, die sagen, dass normalisierte Datenbanken langsamer sind, beziehen sich auf 0,1% der Fälle, in denen dies zutrifft. In dem anderen 99,9% der Fälle haben sie nicht wirklich mit einer wirklich normalisierten Datenbank gearbeitet , um die Leistung aus erster Hand zu sehen, so dass sie ignorieren. Ich habe mit einer normalisierten Datenbank gearbeitet. Liebe es. Ich will nicht zurück gehen. Und ich bin kein Datenbank-Typ. Ich bin ein C # / JavaScript / HTML / Ruby-Typ.

6. Worte haben einen Ursprung. Tatsächlich können viele Wörter in derselben Sprache denselben Ursprung haben, was ein anderes Wort in einer anderen Sprache ist. Zum Beispiel ist der Lebenslauf (das, was wir auf die Webseiten der Personalvermittler hochladen, damit wir für die nächsten 7 Jahre ununterbrochen Anrufe und E-Mails erhalten) ein französisches Wort.

7. Ein Wörterbuch definiert auch, um welche Art von Wort es sich handelt (Nomen, Verb, Adjektiv ect). Dies ist nicht nur ein Stück Text: "Nomen" hat auch Bedeutung. Außerdem können Sie mit einer relationalen Datenbank Dinge wie "Gib mir alle Nomen für die englische Sprache" sagen. Da eine normalisierte Datenbank Fremdschlüssel verwendet und Fremdschlüssel Indizes haben (oder haben sollten), ist die Suche ein Kinderspiel.

8. Denken Sie daran, wie Wörter ausgesprochen werden. Insbesondere im Englischen haben viele Wörter die gleiche Aussprache (siehe mein Beispiel oben mit read and reed oder read and red).

   Die Aussprache eines Wortes ist selbst ein anderes Wort. In einer relationalen Datenbank können Sie Fremdschlüssel für Aussprachen verwenden. Diese Informationen werden nicht in einer relationalen Datenbank dupliziert. Es wird wie verrückt in einer No-SQL-Datenbank dupliziert.

9. Und jetzt sprechen wir über pluralistische und singuläre Versionen von Wörtern. :) Denken Sie "Boot" und "Boote". Oder die Tatsache, dass ein Wort "Singular" oder "Plural" ist.

10. Oh! Und jetzt reden wir über Vergangenheitsform, Gegenwartsform, Zukunftsform und Partizip Präsens (um ehrlich zu sein, ich weiß nicht, was der Mist "Partizip Präsens" ist. Ich denke, es hat etwas mit Wörtern zu tun, die auf "ing" enden Englisch oder so).

    Schauen Sie nach "run" und Sie sollten die anderen Zeiten sehen: ran, running, running

    In der Tat ist "angespannt" eine andere Beziehung an sich.

11. Englisch macht das nicht so oft, aber Geschlecht ist eine andere Sache, die ein Wort definiert. Sprachen wie Spanisch haben Suffixe, die definieren, ob das Subjekt des Substantivs männlich oder weiblich ist. Wenn Sie die Lücken eines Satzes ausfüllen müssen, ist das Geschlecht in vielen Sprachen äußerst wichtig.

    Da Sie sich bei der Bestimmung des Geschlechts nicht immer auf Sprachkonventionen verlassen können (auf Spanisch sind Wörter mit der Endung "o" männlich / männlich, dies gilt jedoch nicht für alle Wörter), benötigen Sie einen identifizierenden Wert: männlich oder weiblich. Dies ist eine weitere Beziehung, die eine normalisierte Datenbank auch bei Millionen von Datensätzen ordnungsgemäß verarbeitet.

Bei all den verdrehten Regeln und Beziehungen zwischen Wörtern und sogar verschiedenen Sprachen fällt es mir schwer, mir diesen Datenspeicher als "Dokumentenspeicher" vorzustellen, wie ihn eine No-SQL-Lösung bietet. Es gibt so viele und so unterschiedliche Beziehungen zwischen Wörtern und ihren Bestandteilen, dass eine relationale Datenbank die einzig sinnvolle Lösung ist.

Wenn Sie sich für den Schlüsselwertspeicher entscheiden (der Ihnen ein verarmteres Programmiermodell bietet) und sich herausstellt, dass Sie mehr Struktur benötigen (in Ihrem Fall beispielsweise das Hinzufügen einer dritten Sprache) oder komplexere Abfragen mit Verknüpfungen durchführen müssen verbringen Sie eine Menge Zeit damit, Ihre Schlüssel zu reorganisieren, Ihre Daten zu denormalisieren und / oder alle Daten zu durchlaufen, um das zu finden, was Sie benötigen.

Wenn Sie mit einer relationalen Datenbank beginnen, können Sie das Design und den Code Ihrer Anwendung durcharbeiten und versuchen, sich mehr auf das natürliche Datenmodell für Ihre Anwendung zu konzentrieren, als es in das Schlüsselwertformular einzufügen.

Sobald sich die Anwendung beruhigt hat, können Sie die Leistung durch Messen verschiedener Optionen verbessern. In SQL müssen einige Leistungstricks ausgeführt werden, bevor die Technologie gewechselt werden muss. Sie haben viel über Ihre Anwendung gelernt und können viel besser entscheiden, ob die relationale Beziehung Sie verletzt und ob der Schlüsselwert für Ihr Datenmodell funktioniert.

Wenn sich herausstellt, dass der Schlüsselwert genau den Anforderungen Ihrer Anwendung entspricht, können Sie wechseln, ohne erhebliche Investitionen in das relationale Modell getätigt zu haben. In umgekehrter Richtung wird möglicherweise Zeit dafür verschwendet, dass das Schlüsselwertmodell die erforderlichen Aktionen ausführt trivial im relationalen Modell.

Betrachten Sie die relationale Datenbank als Beschleuniger, um Ihre Anwendung angesichts sich ständig ändernder Anforderungen so zu gestalten, zu schreiben und in Betrieb zu nehmen, dass Sie mehr über Ihre Domäne und Benutzer erfahren.

Wenn Sie Millionen von Benutzern haben, müssen Sie das Design mit ziemlicher Sicherheit ohnehin umgestalten, selbst wenn Sie sich für einen Schlüsselwert entschieden haben.

Für eine so kleine Datenbank wird es wahrscheinlich keinen großen Unterschied für die Leistung machen. Ein Standard-RDBMS ist hier keine schreckliche Idee, da es vermutlich weit mehr Lese- als Schreibvorgänge für einen bestimmten Eintrag geben sollte. Die Leistung scheint dafür nicht der Haupttreiber zu sein. Das Cachen in der Anwendungsschicht mildert auch solche Bedenken.

Die andere Überlegung ist die Replikation und Ausfallsicherheit. Relationale Datenbanken werden in der Regel um eine einzelne Instanz herum entworfen. Lesen Sie sich den CAP-Satz durch und überlegen Sie, worauf es Ihnen am meisten ankommt.

Diese NoSQL-Datenbanken klingen zu Beginn immer nach einer guten Idee, aber Sie werden garantiert auf Probleme stoßen, wenn Sie anfangen, sich mit Randfällen zu befassen (z. B. wenn Schlüsselwörter anhand ihres Werts (oder eines Teils davon) nachgeschlagen werden müssen).

Es wäre sicherer, zu Beginn eine relationale Datenbank zu verwenden und diese später zu denormalisieren. MySQL ist für diese Art von Zweck hervorragend geeignet (einfache relationale Datenbanken mit textbasierter Suche). Es gibt nicht allzu viele Anwendungsfälle, in denen es mit dieser Art von Daten zu kämpfen hat. Vergewissern Sie sich nur, dass Ihre Indizes korrekt eingerichtet sind, und stellen Sie sicher, dass sie eine Leistung aufweisen, die mit einer NoSQL-Datenbank vergleichbar ist (oder besser ist, wenn Sie eine Textsuche durchführen), und dass Sie die Flexibilität haben, Ihre Anwendungslogik zu ändern, ohne dies zu tun an eine konkrete Datenstruktur gebunden.

Wenn Sie feststellen, dass Ihre Daten am häufigsten verwendet werden (und wenn Sie jemals feststellen, dass sie nicht Ihren Leistungsanforderungen entsprechen), können Sie die Daten durch Ausgabe in ein festgelegtes Format de-normalisieren, das geladen (und abgerufen) werden kann. ein NoSQL-Schema.