Recursos para el particionamiento y particionamiento de bases de datos

Question

Estoy trabajando con un esquema de base de datos que tiene problemas de escalabilidad. Una de las tablas en el esquema ha crecido a alrededor de 10 millones de filas, y estoy explorando opciones de particionamiento y particionamiento para permitir que este esquema se amplíe a conjuntos de datos mucho más grandes (por ejemplo, de 1 a 100 mil millones de filas). Nuestra aplicación también debe 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 qué opciones están disponibles. ¿Qué recursos existen (libros, documentos técnicos, sitios web) para la división de bases de datos y estrategias de partición?

Answer 1

Estoy de acuerdo con las otras respuestas de que debería mirar su esquema e índices antes de recurrir al fragmentación. 10 millones de filas están dentro de las capacidades de cualquiera de los principales motores de bases de datos.

Sin embargo, si desea algunos recursos para aprender sobre el tema de fragmentación, intente estos:

• Mejores prácticas de escalabilidad: lecciones de eBay
• Randy Shoup sobre los Principios arquitectónicos de eBay - Video y presentación
• Sitio de alta escalabilidad
• Sr. Moore llega a punt en el fragmentación (cuando no hacerlo)

Answer 2

Estoy de acuerdo con la observación de Mike Woodhouse de que el tamaño actual no debería ser un problema, y ??el interlocutor está de acuerdo.

La mayoría de los DBMS comerciales brindan soporte para tablas fragmentadas en unas u otras, bajo un nombre u otros. 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 datos antiguos. Probablemente pueda soltar el fragmento que contiene datos de octubre de 2001 (retención de datos de siete años) 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, se dejará sin leer, lo que puede brindarle un magnífico beneficio de rendimiento. (Por ejemplo, si el optimizador sabe que la consulta es para 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: el round robin distribuye la carga en varios discos, pero significa que no puede beneficiarse de la eliminación de fragmentos.

Answer 3

10 millones de filas no son realmente grandes en términos de DBMS y estaría mirando primero mis planes de indexación y consulta antes de comenzar a planificar una distribución física de datos con fragmentos o particiones, lo que realmente no debería ser necesario hasta que su tabla cultivado por un par de órdenes de magnitud.

Todo en mi humilde opinión, por supuesto.

Answer 4

En mi experiencia, las tablas grandes siempre te golpean en el lado de E / S. La solución más barata 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 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 muchos discos duros y mantener un complejo esquema de partición, que cuesta una fortuna entre hardware y 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 aleatorias sean cien veces más rápidas que las unidades SAS de primera línea y elimine las E / S embotellamiento. Los SSD comienzan en $ 10 por gigabyte, por lo que gastará unos pocos grandes, pero sigue siendo mucho más barato que los SAN, etc.