database - Pro de bases de datos como BigTable, SimpleDB
scalability amazon-simpledb (5)
Los paradigmas de nuevos almacenes de datos escolares como Google BigTable y Amazon SimpleDB están específicamente diseñados para la escalabilidad, entre otras cosas. Básicamente, no permitir las uniones y la desnormalización son las formas en que esto se logra.
En este tema, sin embargo, el consenso parece ser que las uniones en tablas grandes no necesariamente tienen que ser demasiado caras y la desnormalización está "sobreestimada" hasta cierto punto. ¿Por qué, entonces, estos sistemas antes mencionados no permiten uniones y fuerzan todo junto en una una sola tabla para lograr la escalabilidad? ¿Son los grandes volúmenes de datos que deben almacenarse 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 bases de datos están diseñados específicamente para almacenar muchos objetos similares?
¿O me estoy perdiendo una imagen más grande?
Las bases de datos distribuidas no son tan ingenuas como implica Orion; se ha realizado bastante trabajo para optimizar consultas completamente relacionales sobre conjuntos de datos distribuidos. Es posible que desee ver qué empresas como Teradata, Netezza, Greenplum, Vertica, AsterData, etc. están haciendo. (Oracle también se metió en el juego, finalmente, con su reciente anuncio; Microsoft compró su solución en nombre de la compañía que solía llamarse DataAllegro).
Dicho esto, cuando los datos se convierten en terabytes, estos problemas se vuelven muy triviales. Si no necesita las garantías estrictas de transaccionalidad y consistencia que puede obtener de los RDBM, a menudo es mucho más fácil desnormalizar y no hacer uniones. Especialmente si no necesitas hacer una referencia cruzada. Especialmente si no está haciendo un análisis ad-hoc, pero requiere acceso programático con transformaciones arbitrarias.
La desnormalización está sobrevalorada. El hecho de que eso es lo que ocurre cuando se trata de un Tera de 100, no significa que este sea utilizado por cada desarrollador que nunca se haya molestado en aprender sobre bases de datos y tenga 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 ...
Ah, la otra razón por la que estas tecnologías se están haciendo notar: la gente está descubriendo que algunas cosas nunca pertenecieron a la base de datos, y se están dando cuenta de que no están tratando con relaciones en sus campos particulares, sino con claves básicas. pares de valores Para cosas que no deberían haber sido en una base de datos, es muy posible que el marco Map-Reduce o algún sistema de almacenamiento persistente y consistente sea lo correcto.
En una escala menos global, recomiendo BerkeleyDB para ese tipo de problemas.
No estoy muy familiarizado con ellos (solo he leído el mismo blog / noticias / ejemplos como todos los demás), pero mi opinión es que optaron por sacrificar muchas de las funciones de DB relacionales normales en nombre de la escalabilidad. Voy a tratar de explicar.
Imagine que tiene 200 filas en su tabla de datos.
En el centro de datos de Google, 50 de estas filas están almacenadas 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 el servidor C.
(En la vida real no tengo idea de cuántos servidores se usarían, pero está configurado para tratar con muchos millones de filas, así que me imagino bastantes).
Para "seleccionar * donde name = ''orion''", la infraestructura puede activar esa consulta en todos los servidores y agregar los resultados que se obtienen. Esto les permite escalar de forma bastante lineal en todos los servidores que quieran (esto es más o menos lo que es mapreduce)
Sin embargo, esto significa que necesita algunos intercambios.
Si necesita realizar una unión relacional en algunos datos, donde se distribuye en, por ejemplo, 5 servidores, cada uno de esos servidores deberá extraer datos entre sí para cada fila . Intente hacer eso cuando tenga 2 millones de filas distribuidas en 10 servidores.
Esto lleva a la compensación n. ° 1: sin uniones.
Además, dependiendo de la latencia de la red, la carga del servidor, etc., algunos de sus datos pueden guardarse instantáneamente, pero algunos pueden tardar un segundo o 2. De nuevo, cuando tiene docenas de servidores, esto se hace más y más largo, y el enfoque normal de ''todo el mundo espera hasta que el tipo más lento haya terminado'' ya no se vuelve aceptable.
Esto lleva a la compensación n. ° 2: es posible que sus datos no siempre sean visibles inmediatamente después de su redacción.
No estoy seguro de qué otras compensaciones hay, pero fuera de mi cabeza esos son los principales 2.
Entonces, lo que obtengo es que existe toda la filosofía de "desnormalizar, no unir", no porque las uniones por sí mismas no se escalen en sistemas grandes, sino porque son prácticamente imposibles de implementar en bases de datos distribuidas.
Esto parece bastante razonable cuando almacena datos en gran medida invariables de un solo tipo (como Google). ¿Estoy en el camino correcto aquí?
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 un gran problema.
Novaday Necesita encontrar más entorno interoperativo para las bases de datos. Con más frecuencia, no solo necesita un DB 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 similar posible en macroescala. Significa que no podrá utilizar, digamos, Azure SQL como DB relacional y una VM con 2 núcleos y 3 GB de RAM para MongoDB. Debe escalar su solución y usar DB como servicio cuando sea posible (si no es posible, luego cree su propio clúster en una nube).