¿Qué es una base de datos de la tienda Key / Value?

He estado buscando en la página de Wikipedia para NoSQL y enumera varias variaciones en la base de datos de la tienda Key / Value, pero no puedo encontrar ningún detalle sobre lo que significa la tienda Key / Value en este contexto. ¿Podría alguien explicarme o vincularme una explicación? Además, ¿cuándo usaría tal base de datos?

¿Conoces el concepto de un par clave / valor? Suponiendo que esté familiarizado con Java o C #, esto está en el lenguaje como map / hash / datatable / KeyValuePair (el último es en el caso de C #)

La forma en que funciona se demuestra en este pequeño gráfico de muestra:

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

Donde tenga una clave (izquierda) y un valor (derecha) ... observe que puede ser una cadena, int o similar. La mayoría de los objetos KVP le permiten almacenar cualquier objeto a la derecha, porque es solo un valor.

Dado que siempre tendrá una clave única para un objeto en particular que desea devolver, solo puede consultar la base de datos para esa clave única y obtener los resultados de cualquier nodo que tenga el objeto (es por eso que es bueno para sistemas distribuidos, ya que hay otras cosas involucradas como sondear los primeros n nodos para devolver un valor que coincida con otros nodos devuelve).

Ahora mi ejemplo anterior es muy simple, así que aquí hay una versión ligeramente mejor del KVP

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

Como puede ver, la generación de claves simple es poner "usuario" el número único de usuario, un guión bajo y el objeto. Una vez más, esta es una variación simple, pero creo que comenzamos a entender que siempre que podamos definir la parte de la izquierda y tener un formato consistente, podemos extraer el valor.

Tenga en cuenta que no hay restricción en el valor de la clave (ok, puede haber algunas limitaciones, como solo texto) o en la propiedad del valor (puede haber una restricción de tamaño), pero hasta ahora no he tenido sistemas realmente complejos. Probemos y avancemos un poco más:

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

Se entiende la idea ... todos estos se almacenarían en una "tabla" masiva en los nodos distribuidos (hay matemática detrás de todo) y simplemente le pediría al sistema distribuido el valor que necesita por nombre.

Por lo menos, esa es mi comprensión de cómo funciona todo. Puedo tener algunas cosas mal, pero eso es lo básico.

enlace obligatorio de wikipedia http://en.wikipedia.org/wiki/Associative_array

En términos de SQL, una base de datos NoSQL es una sola tabla con dos columnas: una es la Clave (Primaria) y la otra es el Valor. Y eso es todo, esa es toda la magia NoSQL.

Usaría NoSQL por una razón principal: escalabilidad.

Si su aplicación necesita manejar millones de consultas por segundo, la única forma de lograrlo es agregar más servidores. Eso es muy barato y fácil con NoSQL. En contraste, escalar una base de datos SQL tradicional es mucho más complicado.

Solo los sitios web más grandes están aprovechando todo el potencial de NoSQL, es decir, Facebook, que tiene miles de servidores con Cassandra .

Recomiendo leer esta publicación de blog, comparando SQL, NoSQL y ORM:

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

Supongo que tiene una comprensión básica del movimiento NoSQL y modelos de bases de datos no relacionales.

Key Value store es uno de los modelos de bases de datos sin relación, como gráficos, modelos de bases de datos orientados a documentos.

Tiendas de valor clave y el movimiento NoSQL

En general, SQL logró manejar datos especialmente estructurados y permitió consultas altamente dinámicas de acuerdo con las necesidades del departamento en cuestión.

Si bien todavía no hay competidores reales para SQL en este campo específico, el caso de uso en las aplicaciones web cotidianas es diferente. No encontrará un rango altamente dinámico de consultas llenas de uniones externas e internas, uniones y cálculos complejos sobre tablas grandes. Por lo general, encontrará una forma de pensar muy orientada a objetos. Especialmente con la adopción de patrones como MVC, los datos en el back-end generalmente no se modelan para una base de datos, sino para una integridad lógica que también ayuda a las personas a ser capaces de comprender grandes infraestructuras de software. Lo que se está haciendo para poner estos modelos orientados a objetos en bases de datos relacionales es una gran cantidad de normalización que conduce a jerarquías complejas de tablas y se opone completamente a la idea principal detrás de la programación orientada a objetos.

El hecho de que SQL permita consultas dinámicas arbitrarias para conjuntos complejos de datos se vuelve inútil mediante el uso de una base de datos SQL solo para el almacenamiento persistente de datos orientados a objetos, que es lo que básicamente hacen la mayoría de las aplicaciones en estos días.

Aquí es donde entran en juego las tiendas Key Value. 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. Los datos en sí suelen ser algún tipo de primitivo del lenguaje de programación (una cadena, un entero, una matriz) o un objeto que los enlaces de los lenguajes de programación están ordenando al almacén de valores clave. Esto reemplaza la necesidad de un modelo de datos fijos y hace que el requisito de datos con formato adecuado sea menos estricto.

They all allow storage of arbitrary data which is being indexed using a single key to allow retrieval. La mayor diferencia para las tiendas "más simples" es la forma en que puede (o no) autenticar o acceder a diferentes tiendas (si es posible). Si bien las ventajas de velocidad en el almacenamiento y la recuperación de datos podrían ser una razón para considerarlo sobre las bases de datos SQL comunes, otra gran ventaja que surge cuando se usan almacenes de valores clave es que el código resultante tiende a verse limpio y simple en comparación con las cadenas SQL incorporadas en tu lenguaje de programación Esto es algo que las personas tienden a combatir con marcos de mapeo relacional de objetos como Hibernate o Active Record. Tener un mapeador relacional de objetos básicamente parece emular un almacén de valores clave al agregar una gran cantidad de código realmente complejo entre una base de datos SQL y un lenguaje de programación orientado a objetos.

Toda una comunidad de personas se reúne bajo la etiqueta " NoSQL " y discute estas ventajas y desventajas de usar alternativas a los sistemas de gestión de bases de datos relacionales. leer más
Este es un artículo un poco viejo, pero me pareció muy útil.

when would I use such a database? Could someone explain or link an explanation to me?
Es más una decisión arquitectónica y discutible ... Debe considerar muchos factores como la escalabilidad, el rendimiento, etc.

Vea las diapositivas / artículos a continuación y obtendrá una idea de cuándo, por qué y por qué no usar el almacén de valores clave :)

• Bases de datos no relacionales y almacenes de clave / valor
• Tiendas de valores clave: ¿la clave para escalar?
• http://highscalability.com/blog/category/key-value-store [debe leer]
• http://ayende.com/Blog/archive/2010/03/29/that-no-sql-thing-keyvalue-stores.aspx

Otros han explicado esto, pero voy a hacer una puñalada de todos modos.

Una base de datos de clave / valor almacena datos por una clave primaria. Esto nos permite identificar de forma única un registro en un depósito. Como todos los valores son únicos, las búsquedas son increíblemente rápidas: siempre es una simple búsqueda de disco.

El valor es cualquier tipo de valor. La forma en que se almacenan los datos es opaca a la base de datos en sí. Cuando almacena datos en un almacén de clave / valor, la base de datos no sabe ni le importa si es XML, JSON, texto o una imagen. En efecto, lo que estamos haciendo en un almacén de clave / valor es trasladar la responsabilidad de comprender cómo se almacenan los datos fuera de la base de datos en las aplicaciones que recuperan nuestros datos. Dado que solo tiene que preocuparse por un único rango de claves por cubo, es muy fácil distribuir las claves en muchos servidores y usar técnicas de programación distribuida para que sea posible acceder a estos datos rápidamente (cada servidor almacena un rango de datos) .

Un inconveniente de este enfoque de los datos es que la búsqueda es una tarea muy difícil. Debe leer todos los registros en su depósito de datos o, de lo contrario, debe crear índices secundarios usted mismo.

Hay algunas razones por las que es posible que desee utilizar una base de datos de clave / valor:

• Cuando el rendimiento de escritura es su máxima prioridad. Mozilla Test Pilot utiliza una base de datos de clave / valor para registrar datos rápidamente.
• Cuando se garantiza que las lecturas solo se producen por PK.
• Cuando trabaja con un modelo de datos planos.
• Cuando trabaja con un modelo de datos complejo y rico que no se puede modelar en un RDBMS.

Hay tantas razones para usar una base de datos de clave / valor como para usar un RDBMS y hay tantos argumentos para justificar uno sobre el otro. Es importante observar cómo está consultando sus datos y comprender cómo ese patrón de acceso a datos guía cómo va a insertar y almacenar datos.

Solo recuerde que una base de datos clave / valor es solo un tipo de base de datos NoSQL.

Si tiene una base de datos relacional, puede experimentar fácilmente con esto:

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

Así solían ser todas las bases de datos, con Berkeley DBM como un buen ejemplo, desde 1979. Desde entonces, las cosas han avanzado (puede tener muchos valores por clave en cualquier RDBMS). Para muchas aplicaciones, un almacén de valores clave es suficiente (por ejemplo, así es como sendmail almacena sus alias). Pero si se encuentra preprocesando el valor en su propio código (o concatenando cadenas para hacer su "clave"), tal vez dividiendo el valor en un delimitador o analizándolo, antes de que pueda usarlo, probablemente estará mejor con un RDBMS y en realidad lo almacena de esa manera.