Son estas tablas demasiado grandes para SQL Server u Oracle

Question

No soy mucho gurú de una base de datos, así que me gustaría obtener algunos consejos.

Antecedentes

Tenemos 4 mesas que están almacenados actualmente en Sybase IQ. Actualmente no tenemos otra opción sobre esto, básicamente estamos atrapados con lo que otra persona decidió para nosotros. Sybase IQ es una base de datos orientada a columnas que es perfecta para un almacén de datos. Desafortunadamente, mi proyecto necesita hacer muchas actualizaciones transaccionales (somos más una base de datos operacional), así que estoy buscando más alternativas convencionales.

Pregunta

1. Dadas las dimensiones de estas mesas, alguien consideran SQL Server u Oracle a ser una alternativa viable?

   • Tabla 1: 172 columnas * 32 millones de filas
   • Tabla 2: 453 columnas * 7 millones de filas
   • Tabla 3: 112 columnas * 13 millones de filas
   • Tabla 4: 147 columnas * 2,5 millones filas

2. Dado el tamaño de los datos, ¿cuáles son las cosas que me deberían preocupar en términos de elección de bases de datos, configuración del servidor, memoria, plataforma, etc.?

Answer 1

Sí, ambos deberían ser capaces de manejar sus tablas (si su servidor es adecuado para ello). Pero, consideraría rediseñar su base de datos un poco. Incluso en un datawarehouse donde desnormaliza sus datos, una tabla con 453 columnas no es normal.

Answer 2

Con el hardware de tamaño adecuado y el subsistema de E/S para satisfacer sus demandas ambos son bastante adecuada - Wihlst usted tiene una gran cantidad de columnas los recuentos de filas son realmente muy bajo - que regularmente utilizan conjuntos de datos que se expresan en mil millones, no millones (Simplemente no lo intente en SQL 2000 :))

Si conoce sus usos y requisitos de E/S, la mayoría de los proveedores de E/S lo traducirán en especificaciones de hardware para usted. La memoria, los procesadores, etc. de nuevo dependen de las cargas de trabajo que solo usted puede modelar.

Answer 3

Oracle 11g no tiene problemas con dichos datos y estructura.

Más información en: http://neworacledba.blogspot.com/2008/05/database-limits.html

Saludos.

Answer 4

Realmente depende de lo que hay en las columnas. Si hay muchas columnas grandes de VARCHAR, y con frecuencia se llenan casi hasta la capacidad, entonces podría tener algunos problemas. Si se trata de datos enteros, entonces deberías estar bien.

453 * 4 = 1812  # columns are 4 byte integers, row size is ~1.8k 
453 * 255 = 115,515 # columns are VARCHAR(255), theoretical row size is ~112k 

La regla de oro es que el tamaño de la fila no debe exceder el tamaño de bloque de disco, que es generalmente 8k. Como puede ver, su tabla grande no es un problema en este sentido si está compuesta enteramente por enteros de 4 bytes, pero si consta de columnas VARCHAR de 255 caracteres, entonces podría exceder sustancialmente el límite. Este límite de 8k solía ser un límite estricto en SQL Server, pero creo que en estos días es solo un límite suave y una guía de rendimiento.

Tenga en cuenta que las columnas VARCHAR no necesariamente consumen memoria de forma proporcional al tamaño que especifique para ellas. Ese es el tamaño máximo, pero solo consumen todo lo que necesitan. Si los datos reales en las columnas VARCHAR siempre tienen entre 3 y 4 caracteres, el tamaño será similar al de las columnas enteras, independientemente de si las creó como VARCHAR (4) o VARCHAR (255).

La regla general es que desea que el tamaño de fila sea pequeño para que haya muchas filas por bloque de disco, esto reduce el número de lecturas de disco necesarias para escanear la tabla. Una vez que tienes más de 8k tienes dos lecturas por fila.

Oracle tiene otro problema potencial que es que las uniones ANSI tienen un límite estricto en el número total de columnas en todas las tablas de la unión. Puede evitar esto evitando la sintaxis de unión ANSI de Oracle. (Hay equivalentes que no sufren este error). No recuerdo cuál es el límite ni a qué versiones se aplica (no creo que se haya solucionado todavía).

La cantidad de filas de las que está hablando no debe ser un problema en absoluto, suponiendo que tiene el hardware adecuado.

Answer 5

Oracle limitations

SQL Server limitations

Quizás se estrecha en SQL Server, dependiendo de qué tipo de datos que tiene en esa mesa 453 de columna (tenga en cuenta los bytes por fila limitación, sino también leer la nota al pie). Sé que dijiste que esto está normalizado, pero sugiero mirar tu flujo de trabajo y considerar formas de reducir el conteo de columnas.

Además, estas tablas son lo suficientemente grandes como para que las consideraciones de hardware sean un problema importante con el rendimiento. Necesitará un DBA experimentado para ayudarlo a configurar y configurar el servidor con RDBMS. La configuración adecuada de su subsistema de disco será vital. Probablemente también quiera considerar la partición de tablas, entre otras cosas, para ayudar con el rendimiento, pero todo depende de cómo se usen exactamente los datos.

Answer 6

¿Están todas las columnas en todas esas tablas actualizadas por su aplicación?

Podría considerar tener almacenes de datos (AKA operacionales o almacén de datos en línea) que se actualizan durante el día, y luego los nuevos registros se migran al almacén principal por la noche? Digo esto porque las filas con cantidades masivas de columnas van a ser más lentas de insertar y actualizar, por lo que es posible que desee considerar adaptar su arquitectura específica en línea a los requisitos de actualización de su aplicación.

Answer 7

Pedir un DB para que funcione como un sistema operativo y de depósito al mismo tiempo sigue siendo un poco difícil. Consideraría usar SQL server u Oracle para el sistema operativo y tener un DW separado para informes y análisis, probablemente manteniendo el sistema que tiene.

Espere que se realice un rediseño y una normalización de la tabla en el lado operativo para adaptarse a las limitaciones de una fila por página del almacenamiento basado en filas.

Si necesita tener actualizaciones rápidas del DW, puede considerar EP for ETL enfoque, a diferencia del ETL estándar (programado).

teniendo en cuenta que se encuentra en la etapa temprana de esto, echar un vistazo a Microsoft project Madison, que es DW aparato de auto-escalable hasta 100s TB. Ya han enviado algunas instalaciones.

Answer 8

Consideraría muy cuidadosamente cambiar de una base de datos orientada a columnas a una relacional. Las bases de datos orientadas a columnas son de hecho inadecuadas para el trabajo operativo, ya que las actualizaciones son muy lentas, pero son más que adecuadas para informes y soporte de inteligencia empresarial.

La mayoría de las veces tiene que dividir el trabajo operativo en una base de datos OLTP que contiene la actividad actual necesaria para las operaciones (cuentas, inventario, etc.) y usar un proceso ETL para llenar el almacén de datos (historial, tendencias). Un DW orientado a columnas vencerá sin problemas uno relacional en casi cualquier circunstancia, por lo que no abandonaría el Sybase IQ tan fácilmente. Quizás pueda diseñar su sistema para tener un lado OLTP operacional utilizando su producto relacional de su elección (elegiría SQL Server, pero estoy sesgado) y mantener la parte OLAP que tiene ahora.

Answer 9

Sobre la base de sus comentarios en las otras respuestas Creo que lo que me gustaría recomendar es:

1) Aislar los datos que se actualiza en realidad frente a la cual está más o menos leer datos sólo (o con poca frecuencia) 2) Mueva los datos actualizados a tablas separadas unidas en una identificación a las tablas más grandes (borre esas columnas de las tablas grandes) 3) Realice sus transacciones OLTP contra las tablas más pequeñas y más relacionales 4) Use combinaciones internas para volver a conectarlas al grandes tablas para recuperar datos cuando sea necesario.

Como otros han notado, intenta hacer que la base de datos haga tanto OLTP como OLAP al mismo tiempo y eso es difícil. La configuración del servidor necesita ser ajustada de manera diferente para cada escenario.

Cualquiera de los servidores SQL u Oracle debería funcionar. También uso datos del censo y mi tabla de giganto tiene más de 300 columnas. Utilizo SQL Server 2005 y se queja de que si todas las columnas se llenaran a su capacidad, excederían ese máximo tamaño posible para un registro. Usamos nuestros datos del censo de manera OLAP, por lo que no es tan importante tener tantas columnas.

Answer 10

Sybase tiene un producto llamado RAP que combina IQ con una instancia en memoria de ASE (su base de datos relacional) que está diseñada para ayudar en situaciones como esta.

Sus datos no son tan amplios que no podría considerar cambiarse a una base de datos orientada a filas pero, dependiendo de la estructura de los datos, podría terminar usando considerablemente más espacio en disco y ralentizando muchos tipos de consultas .

Descargo de responsabilidad: Trabajo para Sybase, pero actualmente no en ASE/IQ/RAP.