Was ist eine Key / Value Store-Datenbank?

Ich habe mir die Wikipedia-Seite für NoSQL angesehen und sie listet verschiedene Variationen der Key / Value-Store-Datenbank auf, aber ich kann keine Details dazu finden, was dies in diesem Kontext unter Key / Value-Store zu verstehen ist. Könnte mir jemand eine Erklärung erklären oder verlinken? Wann würde ich eine solche Datenbank verwenden?

Kennen Sie das Konzept eines Schlüssel / Wert-Paares? Vorausgesetzt, Sie kennen sich mit Java oder C # aus, liegt dies in der Sprache Map / Hash / Datatable / KeyValuePair vor (das letzte ist bei C # der Fall).

Die Funktionsweise wird in diesem kleinen Beispieldiagramm veranschaulicht:

Color        Red
Age          18
Size         Large
Name         Smith
Title        The Brown Dog

Wenn Sie einen Schlüssel (links) und einen Wert (rechts) haben, kann dies ein String, ein Int oder dergleichen sein. Bei den meisten KVP-Objekten können Sie jedes Objekt auf der rechten Seite speichern, da es sich nur um einen Wert handelt.

Da Sie für ein bestimmtes Objekt, das Sie zurückgeben möchten, immer einen eindeutigen Schlüssel haben, können Sie einfach die Datenbank nach diesem eindeutigen Schlüssel abfragen und die Ergebnisse von dem Knoten abrufen, auf dem sich das Objekt befindet. da es andere Dinge gibt, wie das Abfragen der ersten n Knoten, um einen Wert zurückzugeben, der mit den Rückgaben anderer Knoten übereinstimmt).

Mein Beispiel oben ist sehr einfach. Hier ist eine etwas bessere Version des KVP

user1923_color    Red
user1923_age      18
user3371_color    Blue
user4344_color    Brackish
user1923_height   6' 0"
user3371_age      34

Wie Sie sehen können, besteht die einfache Schlüsselerzeugung darin, die benutzerspezifische Nummer, einen Unterstrich und das Objekt "user" zu setzen. Auch dies ist eine einfache Variante, aber ich denke, wir beginnen zu verstehen, dass wir den Wert herausziehen können, solange wir den Teil auf der linken Seite definieren und konsistent formatieren können.

Beachten Sie, dass es keine Einschränkung für den Schlüsselwert (ok, es kann einige Einschränkungen geben, z. B. nur für Text) oder für die value-Eigenschaft (es kann eine Größenbeschränkung geben) gibt, aber ich hatte bisher keine wirklich komplexen Systeme. Lass uns versuchen, noch ein bisschen weiter zu gehen:

app_setting_width      450
user1923_color         Red
user1923_age           18
user3371_color         Blue
user4344_color         Brackish
user1923_height        6' 0"
user3371_age           34
error_msg_457          There is no file %1 here
error_message_1        There is no user with %1 name
1923_name              Jim
user1923_name          Jim Smith
user1923_lname         Smith
Application_Installed  true
log_errors             1
install_path           C:\Windows\System32\Restricted
ServerName             localhost
test                   test
test1                  test
test123                Brackish
devonly
wonderwoman
value                  key

Sie bekommen die Idee ... all diese werden in einer massiven "Tabelle" auf den verteilten Knoten gespeichert (es steckt Mathematik dahinter) und Sie fragen das verteilte System einfach nach dem Wert, den Sie mit Namen benötigen.

Zumindest verstehe ich so, wie das alles funktioniert. Ich kann ein paar Dinge falsch machen, aber das sind die Grundlagen.

obligatorischer Wikipedia-Link http://en.wikipedia.org/wiki/Associative_array

In SQL-Begriffen ist eine NoSQL-Datenbank eine einzelne Tabelle mit zwei Spalten: Eine ist der (Primär-) Schlüssel und die andere der Wert. Und das war's, das war's mit der NoSQL-Magie.

Sie würden NoSQL aus einem Hauptgrund verwenden: Skalierbarkeit.

Wenn Ihre Anwendung Millionen von Abfragen pro Sekunde verarbeiten muss, ist die einzige Möglichkeit, dies zu erreichen, das Hinzufügen weiterer Server. Das ist mit NoSQL sehr billig und einfach. Im Gegensatz dazu ist die Skalierung einer herkömmlichen SQL-Datenbank viel komplizierter.

Nur die größten Websites nutzen das volle NoSQL-Potenzial, dh Facebook, mit Tausenden von Servern, auf denen Cassandra ausgeführt wird .

Ich empfehle dringend, diesen Blog-Beitrag zu lesen und SQL, NoSQL und ORM zu vergleichen:

http://seldo.com/weblog/2010/07/12/in_defence_of_sql

Ich gehe davon aus, dass Sie grundlegende Kenntnisse über NoSQL-Movement- und nicht relationale Datenbankmodelle haben.

Der Schlüsselwertspeicher ist eines der nicht relativen Datenbankmodelle, wie z. B. grafische, dokumentorientierte Datenbankmodelle.

Schlüsselwertspeicher und die NoSQL-Bewegung

Im Allgemeinen konnte SQL mit speziell strukturierten Daten umgehen und hochdynamische Abfragen entsprechend den Anforderungen der betreffenden Abteilung durchführen.

Während es in diesem speziellen Bereich noch keine echten Konkurrenten für SQL gibt, ist der Anwendungsfall in alltäglichen Webanwendungen ein anderer. Sie werden keinen hochdynamischen Bereich von Abfragen finden, der voller äußerer und innerer Verknüpfungen, Vereinigungen und komplexer Berechnungen über große Tabellen ist. Normalerweise finden Sie eine sehr objektorientierte Denkweise. Insbesondere bei der Übernahme von Mustern wie MVC werden die Daten im Back-End normalerweise nicht für eine Datenbank modelliert, sondern für eine logische Integrität, die es den Menschen erleichtert, mit dem Verständnis riesiger Software-Infrastrukturen fertig zu werden. Was getan wird, um diese objektorientierten Modelle in relationale Datenbanken zu integrieren, ist ein hohes Maß an Normalisierung, die zu komplexen Hierarchien von Tabellen führt und sich vollständig von der Grundidee der objektorientierten Programmierung abhebt.

Die Tatsache, dass SQL willkürliche dynamische Abfragen für komplexe Datensätze zulässt, wird unbrauchbar, wenn eine SQL-Datenbank nur zum dauerhaften Speichern objektorientierter Daten verwendet wird, wie es die meisten Anwendungen heutzutage tun.

Hier kommen Key Value Stores ins Spiel. Key value stores allow the application developer to store schema-less data. This data is usually consisting of a string which represents the key and the actual data which is considered to be the value in the "key - value" relationship. Die Daten selbst sind normalerweise eine Art Grundelement der Programmiersprache (ein String, eine Ganzzahl, ein Array) oder ein Objekt, das von den Programmiersprachenbindungen an den Schlüsselwertspeicher gemarshallt wird. Dies ersetzt die Notwendigkeit eines festen Datenmodells und verringert die Anforderungen an korrekt formatierte Daten.

They all allow storage of arbitrary data which is being indexed using a single key to allow retrieval. Der größte Unterschied bei den "einfacheren" Geschäften besteht darin, wie Sie verschiedene Geschäfte authentifizieren (oder nicht authentifizieren) oder auf sie zugreifen können (falls möglich). Während die Geschwindigkeitsvorteile beim Speichern und Abrufen von Daten ein Grund sein können, sie gegenüber herkömmlichen SQL-Datenbanken in Betracht zu ziehen, besteht ein weiterer großer Vorteil bei der Verwendung von Schlüsselwertspeichern darin, dass der resultierende Code im Vergleich zu eingebetteten SQL-Zeichenfolgen in der Regel sauber und einfach aussieht Ihre Programmiersprache. Dies ist etwas, mit dem die Leute in der Regel mit objektrelationalen Mapping-Frameworks wie Hibernate oder Active Record kämpfen. Ein objektrelationaler Mapper scheint im Grunde genommen einen Schlüsselwertspeicher zu emulieren, indem sehr viel komplexer Code zwischen einer SQL-Datenbank und einer objektorientierten Programmiersprache eingefügt wird.

Unter dem Schlagwort " NoSQL " kommen eine ganze Community von Menschen zusammen, um diese Vor- und Nachteile der Verwendung von Alternativen zu relationalen Datenbankverwaltungssystemen zu diskutieren. Lesen Sie mehr
Dies ist ein etwas alter Artikel, aber ich fand sehr nützlich.

when would I use such a database? Could someone explain or link an explanation to me?
Es ist eher eine architektonische Entscheidung und eine umstrittene ... Sie müssen viele Faktoren wie Skalierbarkeit, Leistung usw. berücksichtigen.

Wenn Sie die folgenden Folien / Artikel anzeigen, erhalten Sie eine Vorstellung davon, wann, warum und warum Sie den Schlüsselwertspeicher nicht verwenden. :)

• Nicht relationale Datenbanken und Schlüssel- / Wertspeicher
• Key-Value-Stores - der Schlüssel zur Skalierung?
• http://highscalability.com/blog/category/key-value-store [muss gelesen werden]
• http://ayende.com/Blog/archive/2010/03/29/that-no-sql-thing-keyvalue-stores.aspx

Andere haben es erklärt, aber ich werde es trotzdem versuchen.

Eine Schlüssel- / Wertedatenbank speichert Daten nach einem Primärschlüssel. Auf diese Weise können wir einen Datensatz in einem Bucket eindeutig identifizieren. Da alle Werte eindeutig sind, sind Suchvorgänge unglaublich schnell: Es handelt sich immer um eine einfache Festplattensuche.

Der Wert ist nur irgendeine Art von Wert. Die Art und Weise, wie die Daten gespeichert werden, ist für die Datenbank selbst undurchsichtig. Wenn Sie Daten in einem Schlüssel- / Wertspeicher speichern, ist es der Datenbank egal, ob es sich um XML, JSON, Text oder ein Bild handelt. Tatsächlich verlagern wir in einem Schlüssel- / Wertspeicher die Verantwortung für das Verständnis, wie Daten aus der Datenbank in den Anwendungen gespeichert werden, die unsere Daten abrufen. Da Sie nur einen Schlüsselbereich pro Bucket haben, ist es sehr einfach, die Schlüssel auf viele Server zu verteilen und verteilte Programmiertechniken zu verwenden, um einen schnellen Zugriff auf diese Daten zu ermöglichen (jeder Server speichert einen Datenbereich). .

Ein Nachteil dieses Datenansatzes ist, dass das Suchen eine sehr schwierige Aufgabe ist. Sie müssen entweder jeden Datensatz in Ihrem Datenkorb lesen oder Sekundärindizes selbst erstellen .

Es gibt einige Gründe, warum Sie eine Schlüssel- / Wertedatenbank verwenden möchten:

• Wenn Schreibleistung Ihre höchste Priorität ist. Mozilla Test Pilot verwendet eine Schlüssel- / Wertedatenbank, um Daten schnell aufzuzeichnen.
• Wenn Lesevorgänge nur von PK garantiert werden.
• Wenn Sie mit einem flachen Datenmodell arbeiten.
• Wenn Sie mit einem umfangreichen, komplexen Datenmodell arbeiten, das nicht in einem RDBMS modelliert werden kann.

Es gibt ungefähr so ​​viele Gründe, eine Schlüssel- / Wertedatenbank zu verwenden wie ein RDBMS, und es gibt genau so viele Argumente, die eine über die andere rechtfertigen. Es ist wichtig, einen Blick darauf zu werfen, wie Sie Ihre Daten abfragen, und zu verstehen, wie dieses Datenzugriffsmuster das Einfügen und Speichern von Daten steuert.

Denken Sie daran, dass eine Schlüssel- / Wertedatenbank nur eine Art von NoSQL-Datenbank ist.

Wenn Sie eine relationale Datenbank haben, können Sie leicht damit experimentieren:

create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);

So waren früher alle Datenbanken, wobei Berkeley DBM ab 1979 ein gutes Beispiel war. Seitdem haben sich die Dinge weiterentwickelt (Sie können in jedem RDBMS viele Werte pro Schlüssel haben). Für viele Anwendungen ist ein Schlüsselwertspeicher ausreichend (z. B. speichert sendmail so seine Aliase). Wenn Sie jedoch feststellen, dass Sie den Wert in Ihrem eigenen Code vorverarbeiten (oder Zeichenfolgen verketten, um Ihren "Schlüssel" zu bilden), den Wert möglicherweise auf einen Begrenzer aufteilen oder ihn analysieren, bevor Sie ihn verwenden können, sind Sie wahrscheinlich besser dran ein RDBMS und speichern Sie es tatsächlich auf diese Weise.