No puedo responder la pregunta de cuándo usar un almacén de datos clave-valor (en este caso kv), pero puedo mostrarte algunos de los ejemplos y responder a tu ejemplo de stackoverflow.
Con acceso a la base de datos, la mayor parte de lo que necesita es una tienda kv. Por ejemplo, un usuario inicia sesión con el nombre de usuario "joe". Entonces busca "usuario: joe" en su base de datos y recupera su contraseña (hash por supuesto). O tal vez tenga su contraseña en "user: pass: joe", realmente no importa. Si era un desbordamiento de pila y estaba representando la página http://stackoverflow.com/questions/6935566/when-to-use-a-key-value-store-for-web-development, buscaría "pregunta: 6935566" y usaría eso. Es simple ver cómo las tiendas kv pueden resolver la mayoría de sus problemas.
Me gustaría decir que una tienda kv es un subconjunto de funcionalidad proporcionada por un RDMS tradicional. Esto se debe a que el diseño del RDMS tradicional proporciona muchos problemas de escalado y generalmente pierde funciones a medida que escala. Las tiendas kv no vienen con estas características, por lo que no te limitan. Sin embargo, estas características a menudo se pueden crear de todos modos, diseñadas desde el núcleo para ser escalables (porque se vuelve inmediatamente obvio si no lo son).
Sin embargo, eso no significa que haya cosas que no se pueden hacer. Por ejemplo, mencionas consultas.Este es un escollo de muchas tiendas de kv, ya que generalmente son independientes del valor (no siempre cierto, ejemplo, redis y más) y no tienen forma de encontrar lo que está buscando. Peor aún, no están diseñados para hacerlo rápidamente, solo buscan la clave rápidamente.
Una solución a este problema es ordenar las claves lexicográficamente y permitir las consultas de rango. Esto es esencialmente "dame todo entre la pregunta: 1 y la pregunta: 5". Ahora ese ejemplo es bastante inútil, pero hay muchos usos de consultas de rango.
Dijiste que quieres todas las casas más de $ 100 000. Si quisieras poder hacer esto, crearías un índice de casas por precio. Digamos que tienes las siguientes casas.
house:0 -> {"color":"blue","sold":false,"city":"Stackoverville","price":500000}
house:1 -> {"color":"red","sold":true,"city":"Toronto","price":150000}
house:2 -> {"color":"beige","sold":false,"city":"Toronto","price":40000}
house:3 -> {"color":"blue","sold":false,"city":"The Blogosphere","price":110000}
En SQL se almacenaría cada campo en una columna en lugar de tenerlo todo en uno (en este caso JSON) documento. Y podría SELECT * FROM houses WHERE price > 100000. Esto parece muy bueno pero, si no hay un índice creado, esto requiere mirar cada casa en su mesa y verificar su precio, que si tiene un par de millones de casas, podría ser lento. Entonces, en una tienda de kv necesitas un índice también. La principal diferencia es que la base de datos SQL silenciosamente haría lo lento, donde la tienda kv no podría.
Si no tiene consultas de rango, debería pegar su índice en un solo documento, lo que hace que actualizarlo de forma segura suponga un dolor y deba descargar todo el índice para cada consulta, limitando la escalabilidad .
house:index:price -> [{"price":500000,"id":"0"},{"price":150000,"id":"1"},{"price":110000,"id":"3"},{"price":40000,"id":"2"}]
Pero si tiene consultas de rango (a menudo llamadas keyscans) puede crear un índice de esta manera:
house:index:price:040000 -> 2
house:index:price:110000 -> 3
house:index:price:150000 -> 1
house:index:price:500000 -> 0
Y entonces se podría solicitar las llaves entre house:index:price:100000 y house:index:price:: (la ':' carácter es el personaje después de '9') y obtendrá [3,1,0], que es todas las casas más caras que $ 100 000 (también son útiles en orden). Otra cosa buena de esto es que probablemente estarán en una "partición" de su clúster, por lo que esta consulta tomará aproximadamente el mismo tiempo que un simple (más la pequeña sobrecarga de transferencia extra) o dos si su rango pasa por alto un límite del servidor (¡pero estos se pueden hacer en paralelo!).
Así que eso muestra cómo hacer consultas en una tienda de kv. Puede consultar todo lo que se puede pedir como una cadena (casi cualquier cosa) y buscarlo muy rápidamente. Si no tiene consultas de rango, necesitará almacenar todo su índice bajo una clave que apesta, pero si tiene consultas de rango, es muy agradable y muy rápido. Aquí hay un ejemplo más complejo.
Quiero casas sin vender en Toronto que sean menos de $ 100 000. Simplemente tengo que diseñar mi índice. (Agregué en un par de casas para que sea más significativo) Al principio pensé que podría construir otro índice para cada propiedad, pero pronto se dará cuenta de que eso significa que debe seleccionar cada casa sin vender y descargarla de la base de datos. (Esto es lo que quise decir cuando dije que los problemas de escalado son inmediatamente obvios). La solución es usar un multi-índice. Una vez construido, puede seleccionar exactamente los valores que desea.
house:index:sold:city:price:f~Fooville~000010:5 -> ""
house:index:sold:city:price:f~Toronto~040000:2 -> ""
house:index:sold:city:price:f~Toronto~140000:4 -> ""
house:index:sold:city:price:t~Stackoverville~500000:0 -> ""
house:index:sold:city:price:t~The Blogosphere~110000:3 -> ""
house:index:sold:city:price:t~Toronto~150000:1 -> ""
Ahora, a diferencia del último ejemplo, coloque la identificación en la clave. Esto permite que dos casas tengan las mismas propiedades. Pude haberlas combinado en el valor pero luego agregar un índice de eliminación se vuelve más difícil. También elegí separar mis datos con un ~. Esto se debe a que es lexicográficamente después de todas las letras, asegurando que el nombre completo será ordenado y no tengo que rellenar todas las ciudades con la misma longitud. En un sistema de producción, probablemente usaría el byte 255 o 0.
Ahora el rango house:index:sold:city:price:f~Toronto~100000 - house:index:sold:city:price:f~Toronto~~ seleccionará todas las casas que coincidan con la consulta. Y lo importante a tener en cuenta es que la consulta escala linealmente con el número de resultados. Esto significa que debe compilar un índice para cada conjunto de propiedades que desea indexar (aunque el índice de nuestro ejemplo también funciona para consultas vendidas y vendidas en la ciudad). Esto puede parecer mucho trabajo, pero al final se da cuenta de que es solo que lo está haciendo, no su base de datos. Estoy seguro de que vamos a empezar a ver las bibliotecas para este tipo de cosas que saldrá pronto: D
Después de estirar un poco el tema, he mostrado:
- Algunos usos de una tienda kv.
- Cómo realizar consultas en una tienda de kv.
Creo que encontrará que los kv-stores son suficientes para muchas aplicaciones y que a menudo pueden proporcionar un mejor rendimiento y disponibilidad que los RDMS tradicionales. Dicho esto, cada aplicación es diferente y, por lo tanto, es imposible responder a la pregunta original.
Seguro que podría hacer filtros en las tiendas clave-valor si quisiera, depende en parte de la implementación de la tienda y tal vez de su propio ingenio. –