Recursos para la creación de bases de datos y el particionamiento

Question

Estoy trabajando con un esquema de base de datos que se está ejecutando 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?

Answer 1

Estoy de acuerdo con las otras respuestas que debe consultar su esquema e índices antes de recurrir a sharding . 10 millones de filas están dentro de las capacidades de cualquiera de los principales motores de base de datos.

Sin embargo, si desea que algunos recursos para el aprendizaje sobre el tema de sharding luego tratar estas:

• Scalability Best Practices: Lessons from eBay
• Randy Shoup on eBay's Architectural Principles - Video and Presentation
• High Scalability Site
• Mr. Moore gets to punt on sharding (when not to do it)

Answer 2

10 millones de filas realmente no son grandes en términos 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 su la mesa ha crecido en un par de órdenes de magnitud.

Todo en mi humilde opinión, por supuesto.

Answer 3

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 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: round robin distribuye el cargar a través de múltiples discos, pero significa que no puede beneficiarse de la eliminación de fragmentos.

Answer 4

En mi experiencia, las tablas grandes siempre te golpean en el lado de E/S. 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 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 sus lecturas y escrituras aleatorias cientos de 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 van a gastar unos pocos pero aún son mucho más económicas que las SAN, etc.