Cómo estructurar las relaciones en Azure Cosmos DB?

votos
0

Tengo dos conjuntos de datos en la misma colección en el cosmos, uno son 'puestos' y el otro son 'usuarios', que están unidos por los mensajes creados por los usuarios.

Actualmente mi estructura es la siguiente;

// user document
{
id: 123,
postIds: ['id1','id2']
}

// post document
{
id: 'id1',
ownerId: 123
}
{
id: 'id2',
ownerId: 123
}

Mi principal problema con esta configuración es la naturaleza fungible de ella, código tiene que cumplir el enlace y si hay un conjunto de datos de errores muy fácilmente se pierde y no hay forma clara para recuperarlo.

También estoy preocupado por el rendimiento, si un usuario tiene 10.000 puestos de eso es de 10.000 búsquedas de que tendré que hacer para resolver todos los mensajes ..

Es este el método correcto para el modelado de relaciones de entidad?

Publicado el 19/12/2018 a las 14:09
fuente por usuario
En otros idiomas...                            


1 respuestas

votos
2

Según lo dicho por David, que es una larga discusión, pero es muy común por lo que, ya que tengo en horas o menos de tiempo "libre", estoy más que contento de tratar de responder a ella, una vez por todas, es de esperar.

¿POR Normalizar?

Lo primero que noto en su mensaje: usted está buscando un cierto nivel de integridad referencial ( https://en.wikipedia.org/wiki/Referential_integrity ), que es algo que se necesita cuando se descompone un objeto más grande en sus partes constitutivas. También se llama normalización.

Si bien esto se hace normalmente en una base de datos relacional, ahora también se está popularizando en la base de datos no relacionales, ya que ayuda mucho a evitar la duplicación de datos que por lo general crea más problemas de lo que resuelve.

https://docs.mongodb.com/manual/core/data-model-design/#normalized-data-models

Pero lo que realmente lo necesita? Puesto que usted ha optado por utilizar la base de datos de documentos JSON, debe aprovechar el hecho de que es capaz de almacenar todo el documento y luego simplemente almacenar el documento junto con todos los datos de propietario: nombre, apellidos, o todos los otros datos que tiene sobre el usuario que creó el documento. Sí, estoy diciendo que es posible que desee evaluar no tenga puesto y el usuario, pero sólo los mensajes, la información del usuario en el interior it.This puede ser realmente muy correcta, como se puede estar seguro de obtener los datos exactos para el usuario existente en el momento de la creación de correos. Digamos por ejemplo que crear un puesto y tengo biografía "X". a continuación, actualizar mi biografía en "Y" y crear una nueva entrada. Los dos post va a tener diferentes biografías de los autores y esto es justo, ya que han captado exactamente la realidad.

Por supuesto, es posible que desee mostrar también una biografía en una página de autor. En este caso, usted tiene un problema. ¿Cuál va a utilizar? Probablemente el último.

Si todos los autores, para existir en su sistema, deberá tener entrada en el blog publicado, que bien puede ser suficiente. Pero tal vez usted quiere tener un autor escribir su biografía y se aparece en su sistema, incluso antes de que escribe un blog.

En tal caso es necesario normalizar el modelo y crear un nuevo tipo de documento, sólo para autores. Si este es tu caso, entonces, también hay que encontrar la manera de handler la situación descrita antes. Cuando el autor actualizará su propia biografía, tendrá que acaba de actualizar el documento de autor, o crear una nueva? Si crea una nueva, para que pueda realizar un seguimiento de todos los cambios, tendrá también actualizar todo el post anterior para que se haga referencia al nuevo documento, o no?

Como se puede ver, la respuesta es compleja, y realmente depende de qué tipo de información que desea capturar desde el mundo real.

Así, en primer lugar, averiguar si realmente se necesita para mantener los mensajes y usuarios separados.

CONSISTENCIA

Vamos a suponer que usted realmente quiere tener mensajes y usuarios mantienen en documentos separados, y por lo tanto a normalizar su modelo. En este caso, tenga en cuenta que el equipo Cosmos DB (pero NoSQL en general) las bases de datos no cuenta con ningún tipo de soporte nativo para hacer cumplir la integridad referencial, por lo que son más o menos por su cuenta. Los índices pueden ayudar, por supuesto, por lo que es posible que desee índice de la propiedad ID_PROPIETARIO, de modo que antes de eliminar un autor, por ejemplo, se puede comprobar de manera eficiente si hay alguna entrada de blog hecho por él / ella que permanecerá huérfanos de otra manera. Otra opción es crear y mantener actualizada otro documento que, para cada autor, realiza un seguimiento de las entradas del blog que él / ella ha escrito manualmente. Con este enfoque sólo se puede mirar en este documento para entender lo que el blog puestos pertenecen a un autor. Puede tratar de mantener este documento actualiza automáticamente usando disparadores, o hacerlo en su aplicación. Hemos de tener en cuenta, que cuando a normalizar, en una base de datos NoSQL, mantener datos coherentes es su responsabilidad. Esto es exactamente lo contrario de una base de datos relacional, donde su responsabilidad es mantener datos consistentes cuando se de-normalizarla.

ACTUACIONES

El rendimiento podría ser un problema, pero que no suelen modelar con el fin de apoyar actuaciones en primer lugar. A modelar con el fin de asegurarse de que su modelo puede representar y almacenar la información que necesita del mundo real y luego optimizarlo con el fin de tener un rendimiento decente con la base de datos que tiene optó por utilizar. Como base de datos diferente tendrá diferentes restricciones, a continuación, el modelo será adaptado para hacer frente a que las limitaciones. Esto no es nada más y nada menos que el buen viejo “lógica” vs “física” discusión de modelado.

En caso Cosmos DB, que no debería tener consultas que van a través del tabique ya que son más caros.

Desafortunadamente partición es algo que eligió una vez por todas, por lo que realmente necesita tener claro en su mente cuáles son los casos de uso más común quieres apoyar en el mejor. Si la mayoría de las consultas se realizan en función de cada autor, me particionar por autor.

Ahora, si bien esto puede parecer una elección inteligente, no será más que si usted tiene un montón de autores. Si sólo tiene uno, por ejemplo, todos los datos y las consultas irán en una sola partición, lo que limita MUCHO su rendimiento. Recuerde, de hecho, que el Cosmos DB RU se divide entre todas las particiones disponibles: con 10.000 RU, por ejemplo, por lo general obtener 5 particiones, lo que significa que todos los valores se distribuyen en 5 particiones. Cada partición tendrá un límite superior de 2000 RU. Si todas sus consultas utilizan sólo una partición, su máximo rendimiento real es que 2000 y no 10.000 UR.

Realmente espero que esto ayudará a comenzar a averiguar la respuesta. Y realmente espero que esto ayuda a fomentar y hacer crecer una discusión (a modelar para una base de datos documental) que yo creo que se debe realmente y maduro ahora.

Respondida el 03/01/2019 a las 02:37
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more