it-swarm-eu.dev

Praktisches Beispiel für jeden Datenbanktyp (reale Fälle)

Es gibt verschiedene Arten von Datenbanken für unterschiedliche Zwecke. Normalerweise wird MySQL jedoch für alles verwendet, da es sich um die bekannteste Datenbank handelt. Um nur ein Beispiel in meinem Unternehmen zu nennen: Eine Big-Data-Anwendung verfügt zu Beginn über eine MySQL-Datenbank, was unglaublich ist und schwerwiegende Konsequenzen für das Unternehmen mit sich bringt. Warum MySQL? Nur weil niemand weiß, wie (und wann) ein anderes DBMS verwendet werden sollte.

Meine Frage bezieht sich also nicht auf Anbieter, sondern auf Datenbanktypen. Können Sie mir ein praktisches Beispiel für bestimmte Situationen (oder Apps) für jeden Datenbanktyp geben, für den die Verwendung dringend empfohlen wird?

Beispiel:

• Ein soziales Netzwerk sollte wegen Y den Typ X verwenden.

• MongoDB oder Couch DB können keine Transaktionen unterstützen, daher eignet sich Document DB nicht für eine App für eine Bank oder eine Auktionssite.

Und so weiter...


Relational: MySQL , PostgreSQL , SQLite , Firebird , MariaDB , Oracle DB , SQL Server , IBM DB2 , IBM Informix , Teradata

Objekt: ZODB , DB4O , - Eloquera , Versant , Objectivity DB , VelocityDB

Graphdatenbanken: AllegroGraph , Neo4j , OrientDB , - InfiniteGraph , Graphbase , Sparkledb , Flockdb , BrightstarDB

Schlüsselwertspeicher: Amazon DynamoDB , Redis , Riak , Voldemort , FoundationDB , Leveldb , BangDB , KAI , hamsterdb , Tarantool , Maxtable , HyperDex , Genom , Memcachedb

Spaltenfamilie: große Tabelle , Hbase , Hypertabelle , Cassandra , Apache Accumulo

RDF-Speicher: Apache Jena , Sesam

Multimodell-Datenbanken: arangodb , Datomic , Orient DB , - FatDB , AlchemyDB

Dokument: Mongo DB , Couch DB , Rethink DB , Raven DB , terrastore , Jas DB , Raptor DB , djon DB , - EJDB , denso DB , Couchbase

XML-Datenbanken: BaseX , Sedna , eXist

Hierarchisch: InterSystems Caché , GT.M danke an @Laurent Parenteau

56
daniel__

Diese Frage ist aufgrund der Allgemeinheit kaum zu beantworten. Ich denke, Sie suchen nach einer einfachen Lösung. Das Problem ist, dass jedes "Problem" immer eindeutiger wird, wenn es zu einem Geschäft wird.

Wie nennt man ein soziales Netzwerk? Twitter? Facebook? LinkedIn? Paketüberfluss? Sie alle verwenden unterschiedliche Lösungen für unterschiedliche Teile, und es können viele Lösungen existieren, die den Polyglot-Ansatz verwenden. Twitter hat ein grafisches Konzept, aber es gibt nur 1-Grad-Verbindungen, Follower und Follower. LinkedIn hingegen lebt davon zu zeigen, wie Menschen jenseits des ersten Grades verbunden sind. Dies sind zwei unterschiedliche Verarbeitungs- und Datenbedürfnisse, aber beide sind "soziale Netzwerke".

Wenn Sie ein "soziales Netzwerk" haben, aber keine Erkennungsmechanismen ausführen, können Sie mit größter Wahrscheinlichkeit problemlos einen beliebigen Basis-Schlüsselwertspeicher verwenden. Wenn Sie eine hohe Leistung bei horizontaler Skalierung benötigen und über Sekundärindizes oder Volltextsuche verfügen, können Sie Couchbase verwenden.

Wenn Sie zusätzlich zu den erfassten Protokolldaten maschinelles Lernen durchführen, können Sie Hadoop in Hive oder Pig oder Spark/Shark integrieren. Oder Sie können eine Lambda-Architektur erstellen und mit Storm viele verschiedene Systeme verwenden.

Wenn Sie die Ermittlung über grafische Abfragen durchführen, die über Scheitelpunkte 2. Grades hinausgehen und auch nach Edge-Eigenschaften filtern, werden Sie wahrscheinlich Diagrammdatenbanken über Ihrem primären Speicher berücksichtigen. Da Diagrammdatenbanken jedoch keine gute Wahl für den Sitzungsspeicher oder als allgemeine Speicher sind, benötigen Sie eine mehrsprachige Lösung, um effizient zu sein.

Was ist die Datengeschwindigkeit? Rahmen? Wie willst du das schaffen? Welche Fachkenntnisse haben Sie in der Firma oder im Startup? Es gibt eine Reihe von Gründen, warum dies keine einfache Frage und Antwort ist.

5
scalabl3

Eine kurze nützliche Lektüre speziell für die Datenbankauswahl: Wie wähle ich eine NoSQL-Datenbank aus? . Ich werde in dieser Antwort wichtige Punkte hervorheben.

Schlüsselwert vs. dokumentenorientiert

Schlüsselwertspeicher

Wenn Sie eine klare Datenstruktur definiert haben, bei der alle Daten genau einen Schlüssel haben, wählen Sie einen Schlüsselwertspeicher. Es ist, als hätten Sie einen großen Hashtable, und die Leute verwenden ihn meistens für Cache-Speicher oder eindeutig auf Schlüsseln basierende Daten. Es wird jedoch etwas unangenehm, wenn Sie dieselben Daten auf der Basis mehrerer Schlüssel abfragen müssen!

Einige Schlüsselwertspeicher sind: zwischengespeichert , Redis , Aerospike .

Zwei wichtige Dinge beim Entwerfen Ihres Datenmodells für den Schlüsselwertspeicher sind:

  • Sie müssen alle Anwendungsfälle im Voraus kennen und können die abfragbaren Felder in Ihren Daten ohne eine Neugestaltung nicht ändern.
  • Denken Sie daran, dass, wenn Sie mehrere Schlüssel für dieselben Daten in einem Schlüsselwertspeicher verwalten, Aktualisierungen für mehrere Tabellen/Buckets/Auflistungen/Was auch immer NICHT atomar sind. Sie müssen sich selbst darum kümmern.

Dokumentorientiert

Wenn Sie sich gerade von RDBMS entfernen und Ihre Daten als Objekt und so nah wie möglich an einer tabellenähnlichen Struktur halten möchten, ist die Dokumentenstruktur der richtige Weg! Besonders nützlich, wenn Sie eine App erstellen und sich nicht frühzeitig (im Prototyping-Stadium) mit dem RDBMS-Tabellendesign befassen möchten und sich Ihr Schema im Laufe der Zeit drastisch ändern kann. Beachten Sie jedoch:

  • Sekundärindizes funktionieren möglicherweise nicht so gut.
  • Transaktionen sind nicht verfügbar.

Beliebte dokumentenorientierte Datenbanken sind: MongoDB , Couchbase .

Vergleichen von NoSQL-Datenbanken mit Schlüsselwerten

zwischengespeichert

  • In-Memory-Cache
  • Keine Ausdauer
  • TTL unterstützt
  • nur clientseitiges Clustering (Client speichert Wert auf mehreren Knoten). Durch Client horizontal skalierbar.
  • Nicht gut für große Werte/Dokumente

Redis

  • In-Memory-Cache
  • Festplatte unterstützt - Sicherung und Wiederherstellung von der Festplatte
  • TTL unterstützt
  • Superschnell (siehe Benchmarks )
  • Unterstützung der Datenstruktur zusätzlich zum Schlüsselwert
  • Die Clusterunterstützung ist noch nicht ausgereift. Vertikal skalierbar (siehe Redis Cluster Spezifikation )
  • Die horizontale Skalierung kann schwierig sein.
  • Unterstützt Sekundärindizes

Aerospike

  • Sowohl im Speicher als auch auf der Festplatte
  • Extrem schnell (könnte> 1 Million TPS auf einem einzelnen Knoten unterstützen)
  • Horizontal skalierbar. Serverseitiges Clustering. Sharded & replizierte Daten
  • Automatische Failover
  • Unterstützt Sekundärindizes
  • CAS-Operationen (Safe Read-Modify-Write), TTL Unterstützung
  • Enterprise-Klasse

Dokumentorientierte NoSQL-Datenbanken vergleichen

MongoDB

  • Schnell
  • Reif und stabil - reich an Funktionen
  • Unterstützt Failover
  • Horizontal skalierbare Lesevorgänge - von Replikat/Sekundär gelesen
  • Schreibt nicht horizontal skalierbar, es sei denn, Sie verwenden Mongo-Shards
  • Unterstützt erweiterte Abfragen
  • Unterstützt mehrere Sekundärindizes
  • Die Architektur von Shards wird schwierig und lässt sich nicht mehr über einen Punkt hinaus skalieren, an dem Sie Sekundärindizes benötigen. Für die Bereitstellung eines elementaren Shards sind mindestens 9 Knoten erforderlich.
  • Sperren auf Dokumentebene sind ein Problem, wenn Sie eine sehr hohe Schreibrate haben

Couchbase Server

  • Schnell
  • Splitterhaufen statt Master-Slave von Mongodb
  • Hot-Failover-Unterstützung
  • Horizontal skalierbar
  • Unterstützt Sekundärindizes durch Views
  • Lernkurve größer als MongoDB
  • Behauptet, schneller zu sein
1
naXa