No puedo enfatizar esto lo suficiente: obtenga algo que funcione bien con las herramientas de informes disponibles.
20 mil millones de filas al mes te colocan en el territorio VLDB, por lo que necesitas particionar. Las dimensiones de cardinalidad baja también sugieren que los índices de mapa de bits serían una ganancia de rendimiento.
Olvídese de los sistemas en la nube ( Hive ,
Hbase ) hasta que tengan soporte SQL maduro. Para una aplicación de depósito de datos, usted quiere algo que funcione con las herramientas de informes convencionales. De lo contrario, se encontrará perpetuamente empantanado escribiendo y manteniendo programas de informes ad-hoc.
Los volúmenes de datos son manejables con un sistema de gestión de bases de datos ( DBMS) más convencional como Oracle: conozco una importante compañía de telecomunicaciones europea que carga 600 GB por día en una base de datos Oracle . En igualdad de condiciones, son dos órdenes de magnitud más grandes que sus volúmenes de datos, por lo que las arquitecturas de discos compartidos aún tienen espacio libre para usted. Es
probable que una arquitectura compartida como
Netezza o Teradata sea aún más rápida, pero estos volúmenes no se encuentran en un nivel que esté más allá de un sistema de disco compartido convencional. Tenga en cuenta, sin embargo, que estos sistemas son bastante caros.
También tenga en cuenta que MapReduce no es un algoritmo de selección de consulta eficiente . Es fundamentalmente un mecanismo para distribuir cálculos de fuerza bruta. Greenplum tiene un back-end de MapReduce, pero un motor de nada compartido especialmente diseñado será mucho más eficiente y hará más trabajo por menos hardware.
Mi opinión sobre esto es que Teradata o Netezza probablemente serían la herramienta ideal para el trabajo, pero sin duda la más cara.
Oracle , Sybase IQ o incluso SQL Server también manejarían los volúmenes de datos implicados, pero serán más lentos: son arquitecturas de disco compartidas pero aún pueden administrar este tipo de volumen de datos. Vea esta publicación para un resumen de las características relacionadas con VLDB en Oracle y SQL Server, y tenga en cuenta que Oracle acaba de presentar también la plataforma de almacenamiento Exadata .
Mi plan de capacidad de back-of-a-fag-pack sugiere quizás 3-5 TB más o menos por mes, incluyendo índices para Oracle o SQL Server. Probablemente menos en Oracle con índices de mapa de bits, aunque una hoja de índice tiene un ROWID de 16 bytes en Oracle versus una referencia de página de 6 bytes en SQL Server.
Sybase IQ hace un uso extensivo de los índices de mapas de bits y está optimizado para las consultas del almacén de datos. Aunque es una arquitectura de disco compartido, es muy eficiente para este tipo de consulta (IIRC era la arquitectura original orientada a columnas). Esto probablemente sería mejor que Oracle o SQL Server, ya que está especializado para este tipo de trabajo.
Greenplum podría ser una opción más económica, pero nunca la he usado, así que no puedo comentar qué tan bien funciona en la práctica.
Si tiene 10 dimensiones con solo unos pocos cientos de filas, considere fusionarlas en una única dimensión basura que adelgace su tabla de hechos al fusionar las diez claves en una sola. Todavía puede implementar jerarquías en una dimensión de basura y esto eliminaría 1/2 o más del tamaño de su tabla de hechos y eliminaría una gran cantidad de uso de disco por índices.
Recomiendo encarecidamente que vaya con algo que funciona bien con una sección transversal razonable de herramientas de informes. Esto significa una interfaz de SQL. Los sistemas comerciales, como Crystal Reports, permiten que los informes y análisis sean realizados por personas con un conjunto de habilidades de SQL más fáciles de obtener. El mundo de código abierto también ha generado BIRT , Jasper Reports y Pentaho. . Hive o HBase te ponen en el negocio de crear un front-end personalizado, que realmente no deseas a menos que estés feliz de pasar los próximos 5 años escribiendo formateadores de informes personalizados en Python.
Finalmente, ubíquelo en algún lugar donde pueda obtener fácilmente un feed de datos rápido de sus sistemas de producción. Esto probablemente significa su propio hardware en su propio centro de datos. Este sistema estará vinculado a E / S; está haciendo un procesamiento simple en grandes volúmenes de datos. Esto significa que necesitará máquinas con subsistemas de discos rápidos. Los proveedores de la nube tienden a no admitir este tipo de hardware, ya que es un orden de magnitud más caro que el tipo de caja desechable de 1U que tradicionalmente usan estos conjuntos. Fast Disk I / O no es una fortaleza de las arquitecturas en la nube.
