mongodb - tipo - Datos referenciales NoSql
qué tipo de base de datos mongodb es (6)
Descargo de responsabilidad: por datos referenciales, no me refiero a la integridad referencial
Estoy aprendiendo nosql y me gustaría entender cómo deberían modelarse los datos. En una base de datos relacional típica para una aplicación CMS, por ejemplo, puede tener dos tablas: artículo y autor, donde el artículo tiene una referencia al autor.
En el sistema nosql, puede crear un documento de artículo de esta manera ya que son solo un gráfico de objeto disfrazado
{
title: "Learn nosql in 5 minutes",
slug: "nosql_is_easy",
author: {firstName: "Smarty"
lastName: "Pants"
}
{
title: "Death to RDBMS",
slug: "rdbms_sucks",
author: {firstName: "Smarty"
lastName: "Pants"
}
y así...
Digamos que un día el Sr. Smarty Pants decidió cambiar su nombre a Regular Joe porque nosql se ha vuelto omnipresente. En tal caso de usos, cada artículo debería ser escaneado y el nombre del autor actualizado.
Así que mi pregunta es, ¿cómo se deben modelar los datos en nosql para que se ajusten a los casos de usos básicos para un CMS de modo que el rendimiento sea a la par o más rápido que RDBMS ? mongodb , por ejemplo, afirma CMS como un caso de uso ...
Editar :
Pocas personas ya han sugerido normalizar los datos como:
article
{
title: "Death to RDBMS",
slug: "rdbms_sucks",
author: {id: "10000001"}
}
author
{
name: "Big Brother",
id: "10000001"
}
Sin embargo, dado que nosql, por diseño, carece de combinaciones, tendría que usar funciones de tipo mapreduce para reunir los datos. Si esta es su sugerencia, por favor coméntenos sobre el desempeño de dicha operación.
Editar 2:
Si cree que nosql no es la solución adecuada para ningún tipo de datos que requiera datos referenciales, explique por qué. Esto parece hacer que el caso de uso para nosql sea bastante limitado, ya que cualquier aplicación razonable contendría datos relacionales.
Editar 3:
Esta publicación ha estado aquí por un tiempo, pero pensé que señalaría otro método para manejar "uniones" y referencias de documentos cruzados con CouchDB. Este es un método que empleo en el CMS. Estoy (re) escribiendo para usar CouchDB (anteriormente fue escrito para MySQL).
El CMS se llama BlueInk y se puede encontrar en Github en http://github.com/BigBlueHat/BlueInk. En la actualidad, la reescritura se centra en el diseño del documento y en la parte del "motor de renderizado", por lo que no hay UI de la que hablar. tiene que crear todo el JSON a mano. Eso es algo que espero solucionar pronto, pero ya hay suficiente en el repositorio (una vez instalado en CouchDB) para darle una idea de cómo se realizan las "uniones".
En BlueInk, una página hace referencia a elementos de contenido que pueden incluirse en una o más páginas (o en la misma página varias veces). La página hace referencia a los elementos de la página a través de su ID (como en su segundo ejemplo de JSON). Cuando se ejecuta a través de la vista "page_and_items" generará resultados que se pueden usar con el parámetro ?include_docs=true CouchDB para obtener el contenido completo de las referencias de elementos de contenido dentro del documento de página.
El resultado de la vista se pasa a través de una función _list y se formatea a través de una plantilla de bigote y se _list como una página HTML, todo en una única solicitud GET.
Este mismo patrón de uso de ID referenciados con ?include_docs=true se puede utilizar en su caso de uso anterior. El uso de una función _list es completamente "cosmético", pero puede ser útil para reestructurar la vista de salida JSON o crear plantillas y generar HTML, CSV, XML, etc.
Permítanme decir que no soy un experto con NoSQL de ninguna manera. En cambio, mi conocimiento es principalmente teórico.
Dicho esto, soy un firme creyente de que la implementación de un sistema de tipo CMS como este en NoSQL probablemente no sea la mejor manera de hacer las cosas, ya que los datos son principalmente relacionales.
Mi opinión sobre este problema se basa en la presunción de que el sistema NoSQL que está utilizando permite cargar registros a través de una estructura de tipo "clave primaria". Creo que la mayoría lo hace, pero estoy seguro de que hay algunos que no lo hacen.
Dicho esto, sugeriría almacenar los datos de la siguiente manera.
Para el autor:
{
_KEY: $AUTHOR_GUID,
firstName: "Smarty",
lastName: "Pants",
}
Y para la publicación en sí:
{
title: "Learn nosql in 5 minutes",
slug: "nosql_is_easy",
author: $AUTHOR_GUID,
}
Tenga en cuenta que en lo anterior, uso _KEY para representar que este es el valor de tipo "clave principal".
Después de cargar la publicación, puede cargar el autor por su GUID.
Puede modelar sus datos muy bien con playOrm Y hacer combinaciones en una tienda noSQL. playOrm tiene S-SQL (Scalable SQL) que es un giro en SQL en el que se especifican las particiones que está consultando. De esta forma, puede pasar de DBMS a noSQL y seguir teniendo las mismas herramientas familiares que utilizó.
Supongo que CouchDB es una base de datos NoSQL, si tú lo dices.
Pero realmente, tenemos lenguajes de programación de propósito general y lenguajes específicos de dominio . Del mismo modo, CouchDB es una base de datos específica de dominio .
Utilizo mucho CouchDB, pero realmente no me importa si usa SQL o NoSQL. CouchDB es valioso (para mí) porque la API es 100% HTTP, JSON y Javascript. Puede construir aplicaciones web con el navegador obteniendo HTML de CouchDB y luego consultando los datos a través de AJAX. ¡Decir que esto es "no SQL" es una subestimación!
De todos modos, de vuelta a Smarty Pants y Regular Joe. Tal vez él tiene 100,000 documentos. ¿Qué pasa si simplemente los actualizamos todos, de la manera difícil? Bueno, esa es una cantidad muy pequeña de Javascript.
$.getJSON(''/db/_design/cms/_view/by_user?key=Smarty+Pants'', {
success: function(result) {
// Change the name right here, in the result objects.
var docs = result.rows.map(function(row) {
row.value.firstName = "Regular";
row.value.lastName = "Joe";
return row.value;
})
// Store it!
$.post(''/db/_bulk_docs'', {"docs":docs}, function() {
console.log("Done! Renamed Smarty Pants in " + docs.length + " documents!");
})
}
})
Sí, esta técnica te daría una F en la clase de informática. Sin embargo, me gusta. Escribiría este código en Firebug. En mi navegador El cambio de nombre no es atómico y no tiene integridad referencial. Por otro lado, probablemente se completaría en un par de segundos y a nadie le importaría.
Se podría decir que CouchDB falla en las palabras de moda y en los puntos de referencia, pero provoca problemas en la escuela.
PD La vista by_user está construida desde map-reduce. En CouchDB, map-reduce es incremental, lo que significa que funciona como la mayoría de los índices SQL. Todas las consultas terminan en un tiempo corto, predecible (logarítmico).
Sus datos son claramente relacionales: un artículo tiene un autor. Puedes modelar tus datos en una tienda NOSQL como MongoDB de la misma manera que lo harías en una tienda relacional, PERO porque no hay uniones en la base de datos tienes que hacer dos llamadas a la base de datos para que no hayas ganado nada.
PERO ... lo que PUEDE hacer con una tienda NOSQL es desnormalizar los datos un tanto para obtener un mejor rendimiento (un solo viaje de ida y vuelta para obtener todo lo que necesita para mostrar el artículo) PERO a expensas de la consistencia inmediata: intercambiando siempre autor preciso nombres para nombres de autores eventualmente precisos.
Por ejemplo, puede usar esto en su artículo:
author: {firstName: "Smarty", lastName: "Pants", _id:DE342624EF }
Ahora puede mostrar el artículo muy rápido y, cuando alguien cambie su nombre, puede iniciar una tarea en segundo plano para actualizar todos los artículos existentes o puede esperar un barrido de coherencia periódico para solucionarlo.
Muchos sitios web importantes ya no le dan consistencia inmediata. Hay cambios que usted hace que eventualmente solo los otros usuarios vean en el sitio.
para su caso específico, use el patrón Flyweight , almacene el id del objeto en lugar de la entidad del objeto.
article
{
title: "Death to RDBMS",
slug: "rdbms_sucks",
author: {id: "10000001"}
}
author
{
name: "Big Brother",
id: "10000001"
}
para la sugerencia general del diseño del esquema de mongodb, lea los documentos oficiales