Estamos estudiando la posibilidad de migrar nuestra aplicación a una base de datos multiinquilino. Actualmente, la aplicación se ejecuta con una base de datos por inquilino. Actualmente hay alrededor de 400 inquilinos. Cuando se combinan, la tabla más grande tendría alrededor de mil millones de filas y crecería a medida que se agregaran inquilinos. El tamaño por inquilino varía enormemente, con un solo inquilino que tiene 180 millones de registros en esa tabla, algunos con menos de un millón. Hay algunas otras mesas en los cientos de millones, la mayoría de las mesas tendrían mucho menos. Mis principales preocupaciones giran en torno a la planificación de la escalabilidad de las tablas grandes y me centraré en la más grande. Los parámetros para ello son que es una tabla de enlace/muchos a muchos con campos de auditoría básicos para creado por y fecha de creación (aunque me pregunto si son necesarios para este). La fecha/hora no es relevante para esto, esta es una tabla de asignaciones y se aplica en todo momento. Los registros pueden eliminarse o insertarse, no actualizarse, algunas veces de forma masiva, probablemente no con frecuencia, pero puede ocurrir en cualquier momento. Creo que la cardinalidad de los datos sería relativamente alta en ambas claves externas, aunque no estoy seguro de qué constituye una cardinalidad alta como proporción del número total de registros. Desde cierta perspectiva, el inquilino con 180 millones de registros tiene alrededor de 100 000 registros distintos para una clave externa y 165 000 para la otra. Mientras tanto, otro cliente tiene alrededor de 180 000 registros, con 500 valores distintos en un campo y 5000 en el otro. Entonces, como dije, mucha variabilidad.

¿Sería el tipo de tabla que describí anteriormente (miles de millones de filas, alta cardinalidad de datos, no basada en el tiempo, segmentada por inquilinos, inserción/eliminación masiva en cualquier momento) en el tipo de escenario que describí (más de 400 inquilinos con cantidades variables de datos) sería un buen candidato para la partición? La razón por la que estoy preocupado por esto ahora es que he leído en varios lugares que la partición es algo que puede ser mucho menos doloroso de manejar si lo planifica con anticipación en lugar de intentar dividir más tarde después de la mesa. es enorme y más difícil de trabajar sin requerir tiempo de inactividad o saltar a través de aros. En este punto, mi principal preocupación no es tanto consultar los datos, probé con una tabla con mil millones de registros y con una selección de índice adecuada, las consultas se ejecutan muy rápido. Estoy más preocupado por la concurrencia con la lectura/escritura/eliminación, el bloqueo debido a bloqueos, etc. Si se justifica la partición, ¿cuál sería una buena estrategia? Partición por inquilino? ¿Simplemente divida los grandes y mantenga los más pequeños agrupados?