Erläuterung der Verwendungsszenarien von SQL und verschiedenen NoSQL-Datenbanken

SQL ist der Hauptstamm. Warum ich das so verstehe:

Aus technischer Sicht

• Relationales Raster spiegelt die Realität des Geschäfts vollständig wider
• Aufgrund der Betonung von Daten in Transaktionen, Auditing, Flash-Speicher usw. müssen einige besonders wichtige Daten in SQL platziert werden. Zumindest Benutzerinformationen sind wichtige Daten in einem System.
• Daher muss SQL vorhanden sein und das Rückgrat der Datenspeicherung

Wann sollte NoSQL eingeführt werden?

Sehen wir uns zunächst den Prozess von SQL -> SQL + NoSQL an.

https://www.jb51.net/article/79236.htm Warum NoSQL verwenden?

Diese NoSQL?

Für die Sprache Java:

• redis: für Caching – extrem schnelle Lesegeschwindigkeit (im Speicher)
• mongoDb – Lese- und Schreibtransaktionen sind ausgeglichen. json entwickelt von node.js
• Neo4j – .java ähnelt eher SQL, aber die Abfrage ist schneller, die erweiterten Funktionen sind jedoch kostenpflichtig … – Social (Bilddatenbank)
• Cassandra – schreibt Daten schneller als sie liest. – Wird zur Protokollspeicherung verwendet.
• HBase Offline-Analyse

Meine Idee:

In Bezug auf die Java-Sprache:

• - Redis wird zum Caching (Werte werden in Javabeans gespeichert) und für Hot Data verwendet, die nicht gespeichert werden müssen
• - mongoDb wird für weniger wichtige, aber notwendige Speicherung verwendet.
• - Cassandra wird für die Protokollverwaltung dringend empfohlen (legen Sie das Protokoll in die Datenbank ein).
• - HBASE Offline-Analyse, Big Data
• - Solr, ES – Innerhalb der Site suchen und SQL usw. ersetzen.
• - Oder verwenden Sie neo4j anstelle einer SQL-Datenbank. Wenn eine Transaktion erforderlich ist, starten Sie einen separaten Thread mit Priorität 2 und speichern Sie ihn in SQL.

Die NoSQL-Ära

Es gibt bereits viele NoSQL-Datenbanken, wie MongoDB, Redis, Riak, HBase, Cassandra usw. Jeder von ihnen hat eine der folgenden Eigenschaften:

• SQL wird nicht mehr verwendet, MongoDB und Cassandra haben beispielsweise ihre eigenen Abfragesprachen
• Normalerweise Open Source-Projekte
• Geboren für den Clusterbetrieb
• Schwache Struktur - schränkt den Datenstrukturtyp nicht streng ein

Anwendbare Szenarien

Speichern Sie Benutzerinformationen wie Sitzungen, Profile, Parameter, Einkaufswagen usw. Diese Informationen sind normalerweise mit einer ID (Schlüssel) verknüpft und in diesem Szenario ist eine Schlüssel-Wert-Datenbank eine gute Wahl.

Nicht anwendbare Szenarien

1) Führen Sie die Abfrage nicht nach Schlüssel, sondern nach Wert durch. Es gibt keine Möglichkeit, in der Schlüssel-Wert-Datenbank nach Wert abzufragen.

2) Die Beziehung zwischen Daten muss gespeichert werden. In einer Schlüssel-Wert-Datenbank können Daten nicht durch zwei oder mehr Schlüssel verknüpft werden.

3) Transaktionsunterstützung. Ein Rollback ist nicht möglich, wenn in der Key-Value-Datenbank ein Fehler auftritt.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM. Wenn Sie mehr darüber erfahren möchten, schauen Sie sich bitte die folgenden Links an