¿Qué necesito saber acerca de trabajar con grandes bases de datos?

Question

Quiero saber cuáles son los problemas específicos / soluciones / consejos / mejores prácticas [no me castigan por la palabra] están surgiendo mientras se trabaja con grandes bases de datos.

bajo enormes bases de datos que quiero decir, que tienen tablas con millones de filas y / o bases de datos con petabytes de datos.

respuestas orientadas a la Plataforma será grande también.

Answer 1

Algunas ideas

• Aprende los detalles del motor de base de datos específica, cómo funciona

• Como consultas Optimizar (consejos, planes de ejecución)

• Cómo afinar la base de datos (no sólo los índices, pero el almacenamiento físico y la representación, la integración del sistema operativo).

• Consulta "trucos" como tablas temporales para almacenar resultados temporales que pueden ser reutilizados,

• ¿Cómo evaluar la necesidad de desnormalización para la mejora del rendimiento

• ¿Cómo utilizar las herramientas de perfilado de la base de datos, para identificar los cuellos de botella.

Answer 2

Un par de piezas de asesoramiento de un DBA producción (mi experiencia es MS SQL, pero éstos debe aplicarse a otras plataformas):

• El mantenimiento se convierte en un significativos de problemas (copias de seguridad nocturnas, DBCCs, trabajos reindex semanal / optimización, etc). Muy fácil de empezar superior a una ventana de mantenimiento de la noche o el fin de semana razonable. Esto no es sólo un techical tema, también es un negocio tema ( "¿qué quiere decir, que va a tomar 4 horas para restaurar la base de datos desde la última copia de seguridad buena ? ")

• Los desarrolladores tienen que entender que es posible que deban funcionar de forma diferente. "¿Quiere decir que no se puede simplemente DELETE (500m rows) FROM MassiveTable y esperar que funcione?

estoy seguro me ocurrirá más ...

Answer 3

Mi primer consejo sería contratar a alguien que sabe lo que están haciendo y no depender de SO, de lo contrario podría estar en algunos errores muy costosos. La segunda sería elegir el hardware y el software plataforma adecuada. Los detalles dependerán en gran medida de las necesidades.

Answer 4

Altamente recomendamos leer esta presentación sobre antipatterns SQL http://www.slideshare.net/billkarwin/sql-antipatterns-strike- volver

La ayuda presentación (sí, me ha ayudado mucho) a encontrar una solución a la situación aparentemente estancado.

Answer 5

Cualquier RDBMS puede sufrir de bajo rendimiento si se hace muy grande, especialmente cuando se unen a las condiciones complejas están en uso. esquemas de bases deben ser diseñados a escala para grandes cantidades de tráfico, también. La mayoría de los sistemas son bastante buenos para la manipulación de cargas, pero también puede que tenga problemas cuando se tiene una base de datos que necesita ser distribuidos a través de múltiples máquinas.

Una gran cantidad de nuevas herramientas están apareciendo para hacer frente a la escalabilidad de base de datos. Uno de los más prometedores es MemCached, que almacena una gran cantidad de datos en la memoria, lo que permite el acceso mucho más rápido y ayuda a la sincronización entre varios servidores de bases de datos. Algunas de las soluciones NoSQL, que aumentan los sistemas tradicionales SQL con arquitecturas que no apliquen esquemas.

Algunos ejemplos de tecnologías NoSQL son Cassandra, CouchDB, Google BigTable, MongoDB. Algunas personas juran que estos sistemas serán cruciales en la gestión de "la venida explosión de datos".

Answer 6

Hay dos aspectos de una base de datos que son más importantes que el tamaño, por lo que el diseño y la gestión va.

La primera es la complejidad. ¿Cuántas tablas de usuario hay? El número de columnas en las tablas? Una base de datos con varios cientos de tablas de usuario en el esquema y más de un millar de columnas en las tablas es muy complejo. Una base de datos con una media docena de mesas no es muy complejo, incluso si contiene petabytes de datos.

El segundo es alcance de intercambio de datos. Si una base de datos está diseñado para compartir datos entre seis o más aplicaciones, desarrolladas por equipos de programación separados, debe diseñar y gestionar de manera muy diferente de lo que sería una base de datos que está incrustado en una sola aplicación.

La mayoría de las preguntas formuladas en la base de datos SO pertenecen a las bases de datos de una sola aplicación.

Aquí hay algunas cosas que aprender, además de lo que ya se ha mencionado.

Saber la diferencia entre la tabla de particiones y la descomposición mesa. Algunas personas se descomponen tablas en varias tablas todos con las mismas columnas, cuando la partición serviría mejor.

Saber la diferencia real entre el modelo gráfico de los datos y el modelo relacional de datos. Algunas personas diseñan bases de datos como si las claves externas eran esencialmente los mismos que los punteros. Lo que terminan con un sistema que captura toda la lentitud de un sistema relacional y todo el descontrol de un sistema gráfico.

. (Nota: el modelo gráfico a menudo se llama el modelo hiearachical o red)

El diseño de una base de datos relacional real es mucho más sutil, y mucho más la pena, que el diseño de una base de datos que pretende ser modelados relacional, pero en realidad es un gráfico modelados.