¿Por qué las bases de datos relacionales no pueden cumplir con las escalas de Big Data?

A menudo se repite que el problema de Big Data es que las bases de datos relacionales no pueden escalar para procesar los volúmenes masivos de datos que ahora se están creando.

Pero, ¿cuáles son estas limitaciones de escalabilidad a las que no están vinculadas las soluciones de Big Data como Hadoop? ¿Por qué Oracle RAC o MySQL sharding o MPP RDBMS como Teradata (etc.) no logran estas hazañas?

Estoy interesado en las limitaciones técnicas: soy consciente de que los costos financieros de la agrupación de RDBMS pueden ser prohibitivos.

MS acaba de tener una charla tecnológica en los Países Bajos donde discutieron algunas de estas cosas. Comienza lentamente, pero se mete en la carne de Hadoop alrededor de los 20 minutos.

La esencia de esto es que "depende". Si tiene un conjunto de datos sensiblemente organizado (al menos algo) fácil de particionar que (al menos algo) es homogéneo, debería ser bastante fácil escalar a esos altos volúmenes de datos con un RDBMS, dependiendo de lo que esté haciendo .

Hadoop y MR parecen estar más orientados a situaciones en las que se ve obligado a realizar grandes escaneos de datos distribuidos, especialmente cuando esos datos no son necesariamente tan homogéneos o estructurados como lo que encontramos en el mundo RDBMS.

¿A qué limitaciones no están vinculadas las soluciones de Big Data? Para mí, la mayor limitación a la que no están obligados es tener que hacer un esquema rígido antes de tiempo. Con las soluciones de Big Data, inserta cantidades masivas de datos en la "caja" ahora y agrega lógica a sus consultas más adelante para abordar la falta de homogeneidad de los datos. Desde la perspectiva del desarrollador, la compensación es la facilidad de implementación y la flexibilidad en la parte frontal del proyecto, frente a la complejidad en las consultas y la consistencia de datos menos inmediata.

El pionero e investigador de bases de datos Michael Stonebraker co-escribió un artículo que discute las limitaciones de las arquitecturas de bases de datos tradicionales. En general, se amplían con hardware más costoso, pero tienen dificultades para escalar con más hardware básico en paralelo, y están limitados por la arquitectura de software heredada diseñada para una era anterior. Sostiene que la era BigData requiere múltiples arquitecturas de bases de datos nuevas que aprovechan la infraestructura moderna y se optimizan para una carga de trabajo particular. Ejemplos de esto son el proyecto C-store, que condujo a la base de datos comercial Vertica Systems, y el proyecto H-store que llevó a VoltDB, una base de datos SQL OLTP en memoria diseñada para cargas de trabajo BigData de alta velocidad. (Divulgación completa, trabajo para VoltDB).

Puede encontrar este seminario web interesante sobre este tema. Responde a algunos de los mitos que han surgido con el éxito de las bases de datos NoSQL. Básicamente, sostiene que SQL no era el problema, no debería ser necesario renunciar a las características tradicionales de la base de datos, como la consistencia, para obtener rendimiento.

No es del todo cierto que RDBMS no pueda escalar. Sin embargo, la verdad parcial en la declaración depende de la arquitectura. En la lista que proporcionó, Oracle RAC es diferente del resto (MySQL y Teradata fragmentados). La principal diferencia es el disco compartido frente a las arquitecturas de nada compartido.

Las arquitecturas de disco compartidas como Oracle RAC sufren escalas porque en algún momento u otro todas las máquinas en ejecución deberían sincronizarse en alguna parte de los datos. Por ejemplo, el administrador de bloqueo global es un asesino. Puede seguir ajustándolo hasta cierto punto, pero finalmente golpeará una pared. Si no puede agregar máquinas fácilmente, debería tener menos máquinas, pero súper potentes, que pueden quemar su bolsillo. En caso de que no se compartan arquitecturas (o datos fragmentados), cada máquina se apropia de algunos datos. No necesita sincronizarse con otras máquinas si quiere actualizar algunos datos.

Luego viene la raza de bases de datos NoSQL. Les trataría un subconjunto de bases de datos RDBMS tradicionales. No todas las aplicaciones en este mundo necesitarán toda la funcionalidad que ofrece RDBMS. Si quiero usar la base de datos como caché, no me importaría la durabilidad. Puede ser que en algunos casos tampoco me importe la coherencia. Si toda mi búsqueda de datos se basa en una clave, no necesito soporte para consultas de rango. Es posible que no necesite índices secundarios. No necesito toda la capa de procesamiento de consultas / optimización de consultas que tienen todas las bases de datos tradicionales.