¿Qué técnicas son más efectivas para manejar millones de registros?

Question

Una vez tuve una tabla de base de datos MySQL que contenía 25 millones de registros, lo que hizo que incluso una simple consulta COUNT(*) requiera un minuto para ejecutarse. Terminé haciendo particiones, separándolas en un par de tablas. Lo que estoy preguntando es, ¿hay algún patrón o técnicas de diseño para manejar este tipo de problema (gran cantidad de registros)? ¿MSSQL u Oracle es mejor para manejar muchos registros?

P.S el problema COUNT(*) mencionado anteriormente es solo un caso de ejemplo, en realidad la aplicación tiene funcionalidad crud y alguna consulta agregada (para informar), pero nada realmente complicado. Es solo que lleva bastante tiempo (minutos) ejecutar algunas de estas consultas debido al volumen de la tabla

Answer 1

Ver Why MySQL could be slow with large tables y COUNT(*) vs COUNT(col)

Asegúrese de que tiene un índice en la columna que está contando. Si su servidor tiene mucha RAM, considere aumentar el tamaño del búfer de MySQL. Asegúrese de que sus discos estén configurados correctamente: DMA habilitado, sin compartir una unidad o cable con la partición de intercambio, etc.

Answer 2

Muchos problemas de rendimiento en las tablas grandes se relacionan con problemas de indexación, o la falta de indexación. Definitivamente me aseguraré de que esté familiarizado con las técnicas de indexación y los detalles de la base de datos que planea usar.

Con respecto a su conteo lento (*) en la gran tabla, asumiría que estaba usando el tipo de tabla InnoDB en MySQL. Tengo algunas tablas con más de 100 millones de registros utilizando MyISAM en MySQL y el recuento (*) es muy rápido.

En lo que respecta a MySQL en particular, hay incluso pequeñas diferencias de indexación entre las tablas InnoDB y MyISAM, que son los dos tipos de tabla más utilizados. Vale la pena entender los pros y contras de cada uno y cómo usarlos.

Answer 3

¿Qué tipo de acceso necesita para acceder a los datos? He usado HBase (basado en BigTable de Google) cargado con una gran cantidad de datos (~ 30 millones de filas) como back-end para una aplicación que podría devolver resultados en cuestión de segundos. Sin embargo, no es realmente apropiado si necesita acceso en "tiempo real", es decir, para potenciar un sitio web. Su naturaleza orientada a columnas también es un cambio bastante radical si está acostumbrado a DBMS orientado a filas.

Answer 4

Lo que está preguntando con "SELECT COUNT (*)" no es fácil.

En MySQL, el motor no transaccional MyISAM optimiza esto al mantener un conteo de registros, por lo que SELECT COUNT (*) será muy rápido.

Sin embargo, si usted está usando un motor transaccional, SELECT COUNT (*) es básicamente diciendo:

Exactamente cuántos registros existe en esta tabla en mi transacción?

Para hacer esto, el motor necesita escanear toda la tabla; probablemente sepa aproximadamente cuántos registros existen en la tabla, pero para obtener una respuesta exacta para una transacción en particular, necesita un escaneo. Esto no va a ser rápido usando MySQL innodb, no va a ser rápido en Oracle, ni nada más. Toda la tabla DEBE ser leída (excluyendo cosas almacenadas por separado por el motor, como BLOBs)

Tener la tabla completa en ram aumentará un poco más rápido, pero aún no será rápido.

Si su aplicación se basa en recuentos frecuentes y precisos, es posible que desee crear una tabla de resumen que se actualice mediante un desencadenante u otro medio.

Si su aplicación depende de recuentos frecuentes y menos precisos, puede mantener los datos de resumen con una tarea programada (lo que puede afectar el rendimiento de otras operaciones menos).

Answer 5

¿La cuenta (*) en toda la mesa es realmente algo que haces mucho?

InnoDB tendrá que realizar un escaneo completo de la tabla para contar las filas, lo que obviamente es un problema de rendimiento importante si contar todas ellas es algo que realmente desea hacer. Pero eso no significa que otras operaciones sobre la mesa serán lentas.

Con los índices correctos, MySQL será muy rápido en la recuperación de datos de las tablas mucho más grande que eso. El problema con los índices es que pueden dañar las velocidades de inserción, especialmente en tablas grandes, ya que el rendimiento de inserción disminuye drásticamente una vez que el espacio requerido para el índice alcanza un cierto umbral, presumiblemente el tamaño que mantendrá en la memoria. Pero si solo necesitas velocidades de inserción modestas, MySQL debería hacer todo lo que necesites.

Cualquier otra base de datos tendrá compensaciones similares entre la velocidad de recuperación y la velocidad de inserción; pueden o no ser mejores para su aplicación. Pero primero buscaría los índices correctos y tal vez reescribir sus consultas antes de probar otras bases de datos. Por lo que vale, elegimos MySQL originalmente porque encontramos que funcionaba mejor.

Tenga en cuenta que las tablas MyISAM en MySQL almacenan el tamaño total de la tabla. Mantienen esto porque es útil para el optimizador en algunos casos, pero un efecto secundario es que el recuento (*) en toda la tabla es realmente rápido. Eso no significa necesariamente que sean más rápidos que InnoDB en cualquier otra cosa.

Answer 6

Respondí una pregunta similar en This Stackoverflow Posting con cierto detalle, describiendo los méritos de las arquitecturas de ambos sistemas. Hasta cierto punto, se hizo desde el punto de vista del almacenamiento de datos, pero muchas de las diferencias también importan en los sistemas transaccionales.

Sin embargo, 25 millones de filas no es un VLDB y si tiene problemas de rendimiento, debe consultar la indexación y el ajuste. No necesita ir a Oracle para soportar una base de datos de 25 millones de renglones: tiene que completar 3 órdenes de magnitud para estar realmente en el territorio de VLDB.

Answer 7

Voy a segunda @Mark Baker, y decir que usted necesita para construir índices en las tablas.

Para otras consultas que la que seleccionó, también debe tener en cuenta que el uso de construcciones como IN() es más rápido que una serie de instrucciones OR en la consulta. Hay muchos pequeños pasos que puede tomar para acelerar las consultas individuales.

Answer 8

La indexación es clave para el rendimiento con este número de registros, pero la forma de escribir las consultas puede hacer una gran diferencia también. Los métodos específicos de ajuste de rendimiento varían según la base de datos, pero en general, evite devolver más registros o campos de los que realmente necesita, asegúrese de que todos los campos de unión estén indexados (al igual que los campos cláusula where comunes), evite los cursores (aunque creo que esto es menos cierto en Oracle que SQL Server no sé sobre mySQL).

hardware también puede ser un cuello de botella, especialmente si está ejecutando cosas además de la base de datos del servidor en la misma máquina.

El ajuste del rendimiento es un tema muy técnico y en realidad no puede ser respondido bien en un formato como este. Te sugiero que obtengas un libro de ajuste de rendimiento y lo leas.Aquí hay un enlace a una para MySQL http://www.amazon.com/High-Performance-MySQL-Optimization-Replication/dp/0596101716

Answer 9

Usted está solicitando una respuesta libros por valor de y por lo tanto propongo se obtiene un buen libro en las bases de datos. Hay muchos.

Para empezar, he aquí algunos conceptos básicos de bases de datos:

En primer lugar, se necesita un gran modelo de datos basado no sólo en los datos que necesita para almacenar sino en los patrones de uso. El buen rendimiento de la base de datos comienza con un buen diseño del esquema.

En segundo lugar, coloque los indicios en las columnas según las búsquedas esperadas Y las necesidades de actualización, ya que a menudo se pasa por alto el rendimiento de las actualizaciones.

En tercer lugar, no coloque las funciones en cláusulas where si es posible.

En cuarto lugar, use un motor RDBMS que sea de diseño de calidad. Respetuosamente, quisiera decir que aunque ha mejorado mucho en el pasado reciente, mysql no califica. (Disculpe a quienes desean argumentar que finalmente ha alcanzado la calificación en los últimos tiempos). Ya no es necesario elegir entre precios altos y calidad; Postgres (también conocido como PostgreSql) está disponible en código abierto y es realmente fantástico, y tiene todos los complementos disponibles para satisfacer sus necesidades.

Finalmente, infórmese sobre lo que está pidiendo que haga un motor de base de datos: obtenga información sobre en el interior, para que pueda juzgar mejor qué tipo de cosas son caras y por qué.