Desarrollar un almacén de datos masivo y distribuido que pueda atender solicitudes con un rendimiento extremadamente alto es algo en lo que nos hemos enfocado en Google. Creamos algo llamado BigTable que subyace el almacén de datos en App Engine. El diseño para BigTable se enfocó en la escalabilidad a través de un sistema distribuido para que pueda funcionar un poco diferente a las bases de datos con las que has trabajado antes, como no soportar combinaciones. Esto no es un accidente, cuando se desarrolla un sistema que puede escalar al tamaño de BigTable no hay forma de hacer una combinación con un objetivo general en los conjuntos de datos de ese tamaño y que aún tengan alto rendimiento.
Google no es el único en ofrecer un almacén de datos no relacional para permitir el escalamiento. Por ejemplo, Amazon tiene SimpleDB: base de datos relacional agrupada tradicional requiere de un desembolso inicial de capital considerable, es complejo para diseñar y generalmente requiere de un administrador de bases de datos para darle mantenimiento y administrarla. Amazon SimpleDB es evidentemente más simple, no requiere de ningún esquema, indexa automáticamente sus datos y proporciona una API simple para su almacenamiento y acceso.
También tienes a tu disposición una gama de almacenes de datos no relacionales de código abierto, como CouchDB y Hypertable. Ésos sólo son dos ejemplos, aquí hay muchos más.
Aunque podrías pensar que todo esto es nuevo, realmente es un poco regresar al pasado. Como ves, hubo una época en la que el "RDBMS" no siempre era la respuesta independientemente de la pregunta que fuera. Cuando Codd publicó su estudio titulado "A Relational Model of Data for Large Shared Data Banks (Un modelo relacional de datos para grandes bancos de datos compartidos)", había muchos enfoques diferentes para los almacenes de datos. Fue tan sólo en los 80 que las bases de datos relacionales ganaron la mayor parte de la captación. Al haberse establecido en una sola metáfora, la industria ha desarrollado muchas herramientas y técnicas para facilitar el desarrollo de una base de datos relacional.
Desafortunadamente esa mayor parte de la captación también es un problema porque mientras los RDBMS son útiles en muchas situaciones, no lo son en todas las situaciones. Su dominio en la captación significa que no se usan las alternativas útiles y grandes cantidades de tiempo y dinero se pueden desperdiciar en tratar de forzar problemas no relacionales en un modelo relacional.
Nos encontramos en medio de un renacimiento en el almacenamiento de datos con la aplicación de muchas ideas y técnicas nuevas; existe un gran potencial para tener un pensamiento innovador acerca del almacenamiento de datos solamente de una forma. Michael Stonebraker señaló en su estudio, "One Size Fits All": An Idea Whose Time Has Come and Gone (Talla única: una idea cuya época ha ido y venido), que existen casos de uso comunes de almacenes de datos, como el almacenamiento de datos y el procesamiento por flujos que no funcionan bien para los RDBMS de objetivo general y que abandonar los RDBMS de objetivo general puedan brindarle un aumento de rendimiento en uno o dos tipos de magnitud.
Es un momento emocionante y lo más importante aquí no es abandonar la base de datos relacional, que es una tecnología muy madura que funciona excelente en su dominio, sino estar dispuestos a ver fuera de los RDBMS para buscar soluciones de almacenamiento.
