Antipatrones
Hay modelos de datos que funcionan mal en TeselaDB; para cada uno, qué hacer.
Algunos modelos de datos funcionan mal en cualquier base documental. Otros solo fallan en una base que reparte los datos por rangos, como TeselaDB. Esta lista dice cuáles son y qué hacer en su lugar.
Cómo funciona
Cada caso dice qué falla y qué hacer en su lugar. Los primeros valen para cualquier base documental, porque tratan del tamaño de los documentos y del coste de los índices, y el último es propio de una base que reparte cada colección en rangos entre los nodos.
Arrays sin límite
Un array que crece con cada evento acaba en un documento enorme. Guarda cada evento como un documento.
Muchísimas colecciones
Una colección por cliente multiplica índices y rangos. Usa una colección con un campo de cliente o inquilinos.
Índices que no se usan
Cada índice se escribe en cada inserción. Mira $indexStats y borra los que nadie usa.
Documentos inflados
Traer campos que la consulta no necesita cuesta red y memoria. Usa proyecciones.
$lookup en cada lectura
Si siempre unes dos colecciones para leer, cada consulta paga la unión aunque los datos casi nunca cambien por separado, así que incrusta en un mismo documento lo que lees junto.
Clave que siempre crece en una colección con muchas escrituras
Concentra la carga en un rango. Lee Claves y puntos calientes.
Qué implica para tu aplicación
Revisa tu modelo con estos casos antes de llevarlo a producción. Empieza por las consultas que tocan más rangos o leen
más documentos de los que devuelven, que son las que te señalan explain y el perfilador.
Límites
Ningún antipatrón rompe la aplicación al principio. Los problemas aparecen cuando crecen los datos y el tráfico, y para entonces cambiar el modelo obliga a reescribir documentos que ya están en producción.