web-applications - una - valor bases de datos
¿Cuándo usar un almacén de clave-valor para el desarrollo web? (6)
Hay dos casos de uso viables generales para noSQL:
- Desarrollo rápido de aplicaciones
- Sistemas masivamente escalables
El hecho de que la mayoría de las soluciones no SQL son efectivamente sin esquema; requiere mucha menos ceremonia para operar; son livianos (en términos de API); y proporcionan ganancias de rendimiento significativas en contraste con los sistemas de persistencia relacional más canónicos que informan su idoneidad para los 2 casos de uso anteriores (en el sentido general).
Siendo cínico - o quizás práctico en el sentido comercial - uno puede proponer un tercer caso de uso general para los sistemas no SQL (aún informados por el conjunto de características / características anteriores):
Es más fácil compactarse y cualquier geek nadador sin experiencia (pero no cerebralmente muerto) puede atraparlo en un abrir y cerrar de ojos. Esa es una característica muy poderosa. (Pruébalo con Oracle ...)
Por lo tanto, los casos de uso de los sistemas no SQL, que en general pueden caracterizarse como sistemas relajados y persistentes , están informados de manera óptima por consideraciones prácticas .
No cabe duda, fuera de sistemas enormemente escalables, de que los sistemas RDBMS son sistemas formalmente perfectos diseñados para asegurar la integridad de los datos.
Soy un poco novato, así que aquí voy ...
¿Cuándo alguien usaría un almacén de clave-valor (Redis, Memcache, etc.) para el desarrollo web? Un caso de uso real sería de gran ayuda.
Mi confusión es que una base de datos simple parece mucho más funcional porque, a mi entender, puede hacer todo lo que un almacén de valores clave puede hacer ADEMÁS, también le permite hacer filtraciones / consultas. Lo que significa, a mi entender, NO se puede hacer un filtro como: select * homes where price > 100000 con un almacén de valores-clave.
ACTUALIZAR :
Hagamos este ejemplo más real. Imaginemos que StackOverflow usa un almacén de clave-valor (memcache, redis, etc.).
¿Cómo ayudaría una tienda de valores clave a las necesidades de alojamiento de Stackoverflow?
Los almacenes de valores clave generalmente son muy rápidos, por lo que es bueno tenerlos como un caché para los datos a los que se accede en gran medida y rara vez se actualizan para reducir la carga en sus bases de datos.
Como ha dicho, generalmente tiene consultas limitadas (aunque MongoDB las maneja bastante bien), pero las tiendas de valores clave están principalmente destinadas a acceder a datos precisos: perfil del usuario X, información de la sesión X, etc.
Una base de datos "tradicional" probablemente sea más que suficiente para un sitio web promedio, pero si experimenta altas cargas, las tiendas de valor clave realmente pueden ayudarlo en sus tiempos de carga.
EDITAR: Y por "altas cargas", quiero decir cargas realmente altas. Las tiendas de valores clave rara vez son necesarias.
No confunda una base de datos de tipo NoSQL con algo como memcached (que no está destinado a almacenar datos de forma permanente).
El uso típico de memcached es almacenar algunos resultados de consulta a los que puede acceder un clúster de servidores web, es decir. un caché compartido P.ej. En esta página hay una lista de publicaciones relacionadas y es probable que haya un poco de trabajo para que la base de datos haga la lista. Si lo haces cada vez que alguien carga la página, crearás mucho trabajo para la base de datos. En cambio, los resultados una vez recuperados por primera vez podrían almacenarse en un servidor memcached con la clave siendo la identificación de la página. Cualquiera de los servidores web en el clúster puede obtener esa información muy rápidamente sin tener que golpear constantemente la base de datos. Después de un tiempo, la memoria caché se purgará mediante memcached para que los resultados de los artículos antiguos no agoten el espacio. [Descargo de responsabilidad: no tengo idea si hace esto en realidad].
Una base de datos "NoSQL" por otro lado es para almacenar información de forma permanente. Si su esquema de datos es bastante simple y también lo son sus consultas, entonces puede ser más rápido que una base de datos SQL estándar. Muchas aplicaciones web no necesitan bases de datos enormemente complejas, por lo que las bases de datos NoSQL pueden ser una buena opción.
No puedo responder la pregunta de cuándo usar un almacén de datos clave-valor (en este caso kv), pero puedo mostrar algunos de los ejemplos y responder a su ejemplo de .
Con el 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 se tratara de desbordamiento de pila y estuvieras renderizando la página http://.com/questions/6935566/when-to-use-a-key-value-store-for-web-development , buscarías "pregunta: 6935566 "y usa 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 puedes 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ás 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 sus claves lexicográficamente y permitir 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 querías 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, debe almacenar cada campo en una columna en lugar de tenerlo todo en uno (en este caso, JSON). 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, tendrá que insertar su índice en un solo documento, lo que hace que actualizarlo de forma segura sea una molestia y significa que tendrá que descargar todo el índice para cada consulta, lo que también limita 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 keyscan) puede crear un índice como este:
house:index:price:040000 -> 2
house:index:price:110000 -> 3
house:index:price:150000 -> 1
house:index:price:500000 -> 0
Y luego podría solicitar las claves entre la house:index:price:100000 y house:index:price:: (el carácter '':'' es el personaje después de ''9'') y obtendría [3,1,0] que es todas las casas cuestan más de $ 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!).
Entonces eso muestra cómo hacer consultas en una tienda 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, coloco el id 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 la house:index:sold:city:price:f~Toronto~100000 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 comenzaremos a ver bibliotecas para este tipo de cosas que saldrán pronto: D
Después de estirar el tema un poco, he mostrado:
- Algunos usos de una tienda kv.
- Cómo hacer consultas en una tienda kv.
Creo que encontrará que las kv-stores son suficientes para muchas aplicaciones y, 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.
Simplemente agregando a la respuesta de bstrawson, "mem- caché -d" es un mecanismo de caché mientras que Redis es un almacenamiento permanente, pero ambos almacenan datos como pares clave-valor.
Busque en un almacenamiento de clave-valor (algo así como Redis o Membase) más como buscar todo el valor en una base de datos relacional, demasiado lento. Si desea hacer algunas consultas, es posible que deba pasar a un tipo de DB NoSQL orientado a documentos, como MongoDB o CouchDB, que puede hacer una parte de consulta.
En un futuro cercano, podrás manejar el servidor 6.0 de couchbase, que resolverá todos tus problemas de grabación con la consulta de datos NoSQL con los nuevos códigos Unlik y el almacenamiento en caché (derivado directamente del código fuente de Memcached)
utiliza efectivamente Redis, y ampliamente. Respuesta detallada a su pregunta, con como ejemplo, en un par de buenas publicaciones de blog de @Mark Gravell. Mark es el autor de la excelente biblioteca de enlaces .NET Redis completamente asíncrona de Booksleeve .