Cómo estructurar una tabla extremadamente grande

Question

Esto es más una pregunta conceptual. Está inspirado en el uso de una tabla extremadamente grande donde incluso una simple consulta lleva mucho tiempo (correctamente indexada). Me preguntaba si hay una mejor estructura que dejar que la mesa crezca, continuamente.

En general me refiero a más de 10,000,000 de registros que crecen todos los días en algo así como 10,000/día. Una mesa como esa alcanzaría 10,000,000 de registros adicionales cada 2,7 años. Digamos que los registros más recientes son los accesos más, pero los más antiguos deben permanecer disponibles. Tengo dos ideas conceptuales para acelerarlo.

1) Mantenga una tabla maestra que contenga todos los datos, indexados por fecha en orden inverso. Cree una vista separada para cada año que contenga solo los datos de ese año. Luego, cuando consultemos, y digamos que se espera que la consulta extraiga solo unos pocos registros de un lapso de tres años, podría usar una unión para combinar las tres vistas y seleccionarlas.

2) La otra opción sería crear una tabla por separado para cada año. Luego, una vez más usando una unión para combinarlos al consultar.

¿Alguien más tiene alguna otra idea o concepto? Sé que este es un problema que Facebook ha enfrentado, entonces, ¿cómo crees que lo manejaron? Dudo que tengan una sola tabla (status_updates) que contenga 100,000,000,000 de registros.

Answer 1

Los principales proveedores de RDBMS todos tienen conceptos similares en términos de tablas con particiones y puntos de vista con particiones (así como combinaciones de los dos)

hay un beneficio inmediato, en el que los datos se divide ahora a través de múltiples tablas conceptuales , por lo que cualquier consulta que incluya la clave de partición dentro de la consulta puede ignorar automáticamente cualquier partición en la que no esté la clave.

Desde una perspectiva de administración RDBMS, tener los datos divididos en particiones separadas permite que las operaciones se realicen en una partición nivel, copia de seguridad/restauración/indexación, etc. Esto ayuda a reducir los tiempos de inactividad y permite un archivado mucho más rápido simplemente eliminando una partición a la vez.

También existen mecanismos de almacenamiento no relacionales como nosql, map reductor, etc., pero finalmente cómo se usa, se carga y se archivan los datos se convierte en un factor determinante en la decisión de la estructura a utilizar.

10 millones de filas no es tan grande en la escala de sistemas grandes, los sistemas particionados pueden contener miles de millones de filas.

Answer 2

A menudo, el mejor plan es tener una tabla y luego utilizar la partición de la base de datos.

O puede archivar datos y crear una vista para los datos archivados y combinados y mantener solo los datos activos en la tabla a la que hacen referencia la mayoría de las funciones. Sin embargo, tendrá que tener una buena estrategia de archivo (que es automática) o puede perder datos o no hacer las cosas de manera eficiente al moverlos. Esto es típicamente más difícil de mantener.

Answer 3

Su segunda idea parece particionar.

no sé qué tan bien funciona, pero no hay soporte para partición en MySQL - véase, en su manual: Chapter 17. Partitioning

Answer 4

Lo que estamos hablando es de partición horizontal o sharding.

Answer 5

Hay un buen enfoque de escalabilidad para estas tablas. La unión es correcta, pero hay una mejor manera.

Si su motor de base de datos admite "partición semántica", puede dividir una tabla en particiones. Cada partición cubrirá algunos subrangos (digamos 1 partición por año). No afectará nada en la sintaxis SQL, excepto DDL. Y el motor ejecutará de forma transparente lógica de unión oculta y escaneos de índices particionados con todo el hardware paralelo que tenga (CPU, E/S, almacenamiento).

Por ejemplo, Sybase permite hasta 255 particiones, ya que es el límite de unión. Pero nunca necesitará la palabra clave "unión" en las consultas.