sql - tablas - Recursos para la división de datos y particionamiento
sql server partition table (4)
10 millones de filas realmente no son grandes en términos de DBMS y estaría buscando primero en mis planes de indexación y consulta antes de comenzar a planificar una distribución física de datos con fragmentos o particiones, que en realidad no deberían ser necesarios hasta que su tabla haya crecido. par de órdenes de magnitud
Todo en mi humilde opinión, por supuesto.
Estoy trabajando con un esquema de base de datos que se ejecuta en problemas de escalabilidad. Una de las tablas en el esquema ha crecido a alrededor de 10 millones de filas, y estoy explorando las opciones de fragmentación y división para permitir que este esquema se escale a conjuntos de datos mucho más grandes (digamos, 1 mil millones a 100 mil millones de filas). Nuestra aplicación también debe poder implementarse en varios productos de bases de datos, incluidos, entre otros, Oracle, MS SQL Server y MySQL.
Este es un gran problema en general, y me gustaría leer sobre las opciones disponibles. ¿Qué recursos hay disponibles (libros, libros blancos, sitios web) para fragmentación de bases de datos y estrategias de partición?
Estoy de acuerdo con la observación de Mike Woodhouse de que el tamaño actual no debería ser un problema, y el que pregunta está de acuerdo.
La mayoría de los DBMS comerciales brindan soporte para tablas fragmentadas en una u otra forma, bajo un nombre o varios más. Una de las preguntas clave es si existe una forma sensata de dividir los datos en fragmentos. Una forma común es hacerlo en función de una fecha, por lo que todos los valores para, por ejemplo, noviembre de 2008 van en un fragmento, los de octubre de 2008 en otro, y así sucesivamente. Esto tiene ventajas cuando llega el momento de eliminar los datos antiguos. Probablemente pueda eliminar el fragmento que contiene datos de octubre de 2001 (siete años de retención de datos) sin afectar los otros fragmentos. Este tipo de fragmentación también puede ayudar con la ''eliminación de fragmentos''; si la consulta claramente no puede necesitar leer los datos de un fragmento dado, entonces no se leerá, lo que puede brindarle un magnífico beneficio de rendimiento. (Por ejemplo, si el optimizador sabe que la consulta tiene una fecha en octubre de 2008, ignorará todos los fragmentos excepto el que contiene los datos de octubre de 2008).
Existen otras técnicas de fragmentación: round robin distribuye la carga entre múltiples discos, pero significa que no puede beneficiarse de la eliminación de fragmentos.
En mi experiencia, las tablas grandes siempre te golpean en el lado de I / O. La solución más económica es agregar suficientes índices de varias columnas para que todas sus consultas puedan obtener los datos directamente del índice, sin tener que cargar las páginas de datos principales. Esto hace que sus inserciones y actualizaciones sean más intensivas en E / S, pero esto puede estar bien. La siguiente opción fácil es maximizar la memoria RAM en su servidor. No hay razón para tener menos de 32 GB si su base de datos es grande. Pero al final todavía se encontrará obligado a E / S, y estará buscando comprar una gran cantidad de discos duros y mantener un esquema de partición complejo, que cuesta una fortuna entre el hardware y la mano de obra. Espero que haya una mejor alternativa en estos días: mover la base de datos de discos duros giratorios a unidades de estado sólido SLC; esto debería hacer que sus lecturas y escrituras sean cien veces más rápidas que las unidades SAS de la parte superior de la línea, y eliminar las E / S embotellamiento. Las SSD comienzan en $ 10 por gigabyte, por lo que vas a gastar unos pocos pero aún es mucho más barato que las SAN, etc.
Estoy de acuerdo con las otras respuestas de que debe ver su esquema e índices antes de recurrir a la fragmentación. 10 millones de filas están dentro de las capacidades de cualquiera de los principales motores de base de datos.
Sin embargo, si desea obtener algunos recursos para aprender sobre el tema de la fragmentación, intente estos: