Soy nuevo en NoSQL y estoy tratando de descubrir la mejor manera de modelar mi base de datos. Usaré ArangoDB en el proyecto, pero creo que esta pregunta también es válida si uso MongoDB.
La base de datos almacenará 12 categorías de productos. Se espera que cada categoría contenga cientos o miles de productos. Los productos también se agregarán / eliminarán constantemente.
Habrá una serie de campos comunes en todos los productos, pero cada categoría también tendrá campos únicos/diferentes restricciones a los datos.
Tenga en cuenta que hay instancias en las que necesitaría consultar todas las categorías al mismo tiempo, por ejemplo, para buscar un producto en todas las categorías, y otras instancias en las que solo necesitaré consultar una categoría.
¿Debo crear una sola colección "Producto" y usar un campo para indicar la categoría, o crear una colección separada para cada categoría?
He leído muchas preguntas relacionadas con esta idea (1 colección frente a muchas) pero no he podido llegar a una conclusión, aparte de "depende".
Entonces, mi pregunta es: en este caso de uso específico, ¿qué opción sería la más óptima, colecciones múltiples versus colección única + fragmentación, en términos de rendimiento y velocidad?
Cualquier ayuda sería apreciada.
Como mencionó, debe jugar con sus datos y su caso de uso. Tendrás una mejor imagen.
Algunas decisiones requeridas como se indica a continuación.
Decida la cantidad de documentos que tendrá en un futuro próximo. Si tendrá 1 millón de documentos en un año, intente con al menos 3 millones de datos
Decida el número de índices necesarios.
Decide el número de escrituras, lecturas por segundo.
Decide el tamaño de los documentos por categoría.
Decidir el patrón de consulta.
Algunas entradas basadas en los requisitos.
Si tiene más escrituras con más índices, la recopilación monolítica única será más lenta, ya que es necesario actualizar varios índices.
Como tiene un conjunto diferente de campos por categoría, puede probar con varias colecciones. Existe $unionWith para combinar datos de múltiples colecciones. Pero verifique el rendimiento, depende puramente de las decisiones anteriores. Tenga en cuenta este problema abierto también.
Si decide optar por la recopilación monolítica, posponga la fragmentación. Implemente esto una vez que haya descubierto que las consultas son más lentas.
Si tiene más escrituras en el mismo documento, las escrituras se ejecutarán secuencialmente. También ralentizará su lectura.
Piense en recuperar el espacio en disco cuando se borren más datos de las colecciones. Múltiples colecciones hacen bien aquí.
El punto que me obliga a sugerir colecciones monolíticas es que I'd need to query all the categories at the same time . Es posible que deba agregar más categorías, pero combinarlas todas en una sola respuesta no sería mejor en términos de rendimiento.
Como realmente no tiene un caso de uso de unión como en RDBMS, puede optar por una colección monolítica única desde el punto de vista del modelo. Dudo que puedas tener una clave de unión.
Si alguno de mis puntos es incorrecto, por favor hágamelo saber.
Creo que antes de implementar esto en NoSQL, debería preguntarse por qué lo está haciendo. Me gusta bastante NoSQL, pero algunos datos definitivamente se ajustan mejor a ese modelo que otros.
Los datos que está describiendo son un caso clásico para una base de datos SQL relacional. Está bien si se trata de un proyecto de pasatiempo y desea probar NoSQL, pero si se trata de un entorno de producción o un cliente, es probable que les haga la situación más difícil.
Mencionas campos comunes en todos los productos. Si desea actualizar estos campos y que esas actualizaciones se reflejen en todos los productos, entonces tiene datos relacionales.
Puede valer la pena leer el artículo de Sarah Mei de 2013 sobre esto . Pase a la sección "Cómo MongoDB almacena datos" y lea desde allí. Advertencia: el artículo se llama "Por qué nunca debería usar MongoDB" y (quizás intencionalmente) está algo sesgado en contra de Mongo, por lo que es importante leerlo desde el punto de vista correcto. El mensaje que debe recibir de este artículo es que MongoDB no es una buena opción para todos los tipos de datos.
Estos son factores importantes a considerar al decidir qué base de datos usar y cómo modelar sus datos
He usado MongoDB, ArangoDB y Neo4j.