Pro de bases de datos como BigTable, SimpleDB

Question

Los nuevos paradigmas del almacén de datos de la escuela, como Google BigTable y Amazon SimpleDB, están diseñados específicamente para la escalabilidad, entre otras cosas. Básicamente, la anulación de uniones y la desnormalización son las formas en que esto se está logrando.

En este tema , sin embargo, el consenso parece ser que se une en general las tablas no necesariamente tienen que ser demasiado caras y la desnormalización está "sobrevalorada" hasta cierto punto ¿Por qué, entonces, estos sistemas mencionados anteriormente no permiten la unión y obligan a todo a unirse en una sola tabla para lograr la escalabilidad? ¿Es el gran volumen de datos que se necesita almacenar en estos sistemas (muchos terabytes)?
¿Las reglas generales para las bases de datos simplemente no se aplican a estas escalas? ¿Es porque estos tipos de base de datos están diseñados específicamente para almacenar muchos objetos similares?
¿O me falta una foto más grande?

Answer 1

Las bases de datos distribuidas no son tan ingenuas como implica Orion; Se ha realizado bastante trabajo en la optimización de consultas completamente relacionales sobre conjuntos de datos distribuidos. Es posible que desee ver qué hacen las empresas como Teradata, Netezza, Greenplum, Vertica, AsterData, etc. (Oracle también se incorporó al juego, finalmente, con su reciente anuncio; Microsoft compró su solución en nombre de la empresa que solía llamarse DataAllegro).

Dicho esto, cuando los datos se escalan en terabytes, estos problemas se vuelven muy triviales. Si no necesita la estricta transaccionalidad y las garantías de coherencia que puede obtener de las RDBM, a menudo es mucho más fácil desnormalizar y no hacer uniones. Especialmente si no necesitas hacer una referencia cruzada mucho. Especialmente si no está haciendo análisis ad-hoc, pero requiere acceso programático con transformaciones arbitrarias.

La desnormalización está sobrevalorada. Solo porque eso es lo que sucede cuando se trata de un 100 Tera, no significa que este hecho deba ser usado por todos los desarrolladores que nunca se molestaron en aprender sobre bases de datos y tienen problemas para consultar un millón o dos filas debido a una mala planificación de esquemas y optimización de consultas. .

Pero si estás en el rango de 100 Tera, por supuesto ...

Oh, la otra razón por la que estas tecnologías están recibiendo el alboroto: la gente está descubriendo que algunas cosas nunca pertenecieron a la base de datos en primer lugar, y se están dando cuenta de que no están tratando con las relaciones en sus campos particulares, sino con Pares clave clave-valor. Para las cosas que no deberían haber estado en una base de datos, es totalmente posible que el marco Map-Reduce, o algún sistema de almacenamiento persistente y eventualmente consistente, sea lo correcto.

En una escala menos global, recomiendo altamente BerkeleyDB para ese tipo de problemas.

Answer 2

No estoy muy familiarizado con ellos (solo he leído el mismo blog / noticias / ejemplos que todos los demás), pero mi opinión es que decidieron sacrificar muchas de las funciones de DB relacionales normales en el nombre de la escalabilidad - lo intentaré explicar.

Imagina que tienes 200 filas en tu tabla de datos.

En el centro de datos de Google, 50 de estas filas se almacenan en el servidor A, 50 en B y 100 en el servidor C. Además, el servidor D contiene copias redundantes de datos del servidor A y B, y el servidor E contiene copias redundantes de datos en servidor C.

(En la vida real no tengo idea de cuántos servidores se usarían, pero está configurado para hacer frente a muchos millones de filas, así que me imagino que bastantes).

Para " seleccionar * donde nombre = 'orion' " ;, la infraestructura puede disparar esa consulta a todos los servidores, y agregar los resultados que regresan. Esto les permite escalar de forma bastante lineal a través de tantos servidores como quieran (para su información, esto es más o menos lo que mapreduce)

Sin embargo, esto significa que necesitas algunas compensaciones.

Si necesita hacer una unión relacional en algunos datos, donde se distribuyó en unos 5 servidores, cada uno de esos servidores tendría que extraer datos de para cada fila . Intenta hacer eso cuando tienes 2 millones de filas repartidas en 10 servidores.

Esto lleva a la compensación # 1 - No hay combinaciones.

Además, dependiendo de la latencia de la red, la carga del servidor, etc., es posible que algunos de sus datos se guarden instantáneamente, pero algunos pueden demorar un segundo o dos. Una vez más, cuando tiene docenas de servidores, esto se alarga más y más. el enfoque normal de "todos esperan hasta que el hombre más lento haya terminado" ya no se vuelve aceptable.

Esto lleva a un compromiso # 2: es posible que sus datos no siempre sean visibles inmediatamente después de que se escriben.

No estoy seguro de qué otras compensaciones hay, pero desde el principio, estas son las 2 principales.

Answer 3

Entonces, lo que estoy obteniendo es que todo " no normaliza, no se une " La filosofía existe, no porque las uniones no se escalan en grandes sistemas, sino porque son prácticamente imposibles de implementar en bases de datos distribuidas.

Esto parece bastante razonable cuando se almacenan datos en gran medida invariantes de un solo tipo (como lo hace Google). ¿Estoy en el camino correcto aquí?

Answer 4

Si está hablando de datos que son prácticamente de solo lectura, las reglas cambian. La desnormalización es más difícil en situaciones donde los datos cambian porque el trabajo requerido aumenta y hay más problemas con el bloqueo. Si los datos apenas cambian, la desnormalización no es tanto un problema.

Answer 5

Novaday Es necesario encontrar más entornos interoperacionales para las bases de datos. Con más frecuencia, no solo necesita una base de datos relacional, como MySQL o MS SQL, sino también granjas de Big Data como Hadoop o bases de datos no relacionales como MongoDB. En algunos casos, todos esos DB se utilizarán en una solución, por lo que su rendimiento debe ser lo más equitativo posible en la escala macro. Significa que no podrá usar, digamos, Azure SQL como DB relacional y una VM con 2 núcleos y 3GB de RAM para MongoDB. Debe escalar su solución y usar DB como un servicio cuando sea posible (si no es posible, cree su propio clúster en una nube).