mongodb - que - ¿Cuáles son los pros y los contras de DynamoDB con respecto a otras bases de datos NoSQL?
mongodb español (8)
Amazon DynamoDB parece una solución NoSQL bastante decente. Es rápido, y es bastante fácil de usar. Aparte de tener una cuenta de AWS, realmente no se requiere ninguna configuración o mantenimiento. El conjunto de características y la API son bastante pequeñas en este momento en comparación con MongoDB / CouchDB / Cassandra, pero probablemente esperaría que crezcan con el tiempo a medida que se reciban los comentarios de la comunidad de desarrolladores. En este momento, todos los SDK oficiales de AWS incluyen un cliente DynamoDB.
Usamos el complemento de la base de datos MongoDB en Heroku para nuestro producto SaaS. Ahora que Amazon lanzó DynamoDB, un servicio de base de datos en la nube, me preguntaba cómo eso cambia el panorama de las ofertas de NoSQL.
Específicamente para servicios basados en la nube o proveedores de SaaS, ¿cómo será mejor o peor el uso de DynamoDB en comparación con MongoDB? ¿Hay algún beneficio de costo, rendimiento, escalabilidad, confiabilidad, controladores, comunidad, etc. de usar uno frente al otro?
Creo que la diferencia clave a considerar es que MongoDB es un software que puede instalar en cualquier lugar (incluso en AWS o en otro servicio en la nube o en la propia empresa) mientras que DynamoDB es un SaaS disponible exclusivamente como servicio alojado de Amazon (AWS). Si desea conservar la opción de hospedar su aplicación internamente, DynamoDB no es una opción. Si hospedarse fuera de AWS no es una consideración, entonces, DynamoDB debe ser su opción predeterminada a menos que las características muy específicas sean de mayor consideración.
Creo que una de las principales diferencias entre DynamoDB y otras ofertas de NoSQL es el rendimiento aprovisionado: usted paga por un nivel de rendimiento específico en una tabla y, siempre que mantenga sus datos bien particionados, siempre puede esperar que se cumpla con el rendimiento. Así que a medida que crece la carga de su aplicación puede escalar y mantener su rendimiento más o menos constante.
Hay una tabla en el siguiente enlace que resume los atributos de DynamoDB y Cassandra:
http://www.datastax.com/dev/blog/amazon-dynamodb
Algo que necesita mejoras en DynamoDB para ser más útil es la posibilidad de indexar columnas que no sean la clave principal.
ACTUALIZACIÓN 1 (04/06/2013)
El 18/04/2013, Amazon anunció su apoyo a los Índices Secundarios Locales, lo que hizo que DynamoDB se divirtiera mucho:
Para empezar, estará completamente administrado por el equipo experto de Amazon, por lo que puede apostar que se escalará muy bien sin prácticamente ninguna entrada del usuario final (desarrollador).
Además, desde su creación y administración por parte de Amazon, puede suponer que lo han diseñado para funcionar muy bien con su infraestructura, por lo que puede asumir que el rendimiento será de primera clase. Además de estar diseñados específicamente para su infraestructura, han elegido usar SSD como almacenamiento, por lo que, desde el comienzo, el rendimiento del disco será significativamente más alto que en otras tiendas de datos en AWS respaldadas por HDD.
Aún no he visto ningún controlador y creo que es demasiado pronto para decir cómo reaccionará la comunidad ante esto, pero sospecho que Amazon tendrá controladores para todos los idiomas más populares y es probable que la comunidad lo reciba bien y, a su vez, cree controladores y herramientas adicionales.
Pros
- Lightning Fast (utiliza SSD internamente)
- Realmente (realmente) confiable. (las posibilidades de errores de escritura son más bajas)
- Escala sin problemas (no es necesario hacer sharding manual)
- Funciona como servicios web (sin servidor, sin configuración, sin instalación)
- Se integra fácilmente con otras características de AWS (puede almacenar toda la tabla en S3 o usar EMR, etc.)
- La replicación se administra internamente, por lo que las posibilidades de pérdida accidental de datos son insignificantes.
Contras
- Consulta muy (muy) limitada.
- El escaneo es doloroso (recuerdo que una vez que un escaneo a través de Java se ejecutó durante 6 horas)
- rendimiento predefinido, lo que significa que se acelerará el aumento repentino más allá del rendimiento establecido.
- el rendimiento se divide en particiones a medida que la tabla se fragmenta internamente. (lo que significa que si tiene un rendimiento de 1000 y está dividido en dos y si solo está leyendo los datos más recientes (de una parte), entonces su rendimiento de lectura es de 500)
- Sin uniones, se permite la indexación limitada (básicamente 2).
- Sin vistas, activadores, scripts o procedimientos almacenados.
Es realmente bueno como alternativa al almacenamiento de sesiones en aplicaciones escalables. Otro buen uso sería el registro / auditoría en un sistema extenso. NO es preferible para una aplicación rica en funciones con mejoras frecuentes o cambios.
Tengo que ser honesto; Estaba muy emocionado cuando escuché acerca del nuevo DynamoDB y asistí al seminario web de ayer. Sin embargo, es muy difícil tomar una decisión en este momento ya que todo lo que dijeron era todavía muy vago; No tengo idea de las funciones que se permitirán o usarán a través de su servicio.
Lo único que sé es que la escala se maneja automáticamente; lo cual es bastante asombroso, sin embargo, todavía hay tantas incógnitas que es difícil hacer realmente un gran análisis hasta que todos los hechos se encuentren y podamos comenzar a usarlo.
Hasta ahora, todavía veo a mongo trabajando mucho mejor para mí (personalmente) en la tarea de proyecto en la que he estado trabajando.
Al igual que la mayoría de las decisiones de DB, realmente se reducirá a un proyecto por decisión del proyecto de lo que sea mejor para su necesidad.
Espero ansiosamente más información sobre el producto, aunque por el momento está en versión beta y no me lanzaría a adoptar el más reciente y mejor solo para ser un probador :)
Usar MongoDB a través de un complemento para Heroku efectivamente convierte a MongoDB en un producto SaaS también.
En realidad, uno compararía cualquier servicio que tenga un proveedor elegido en comparación con lo que Amazon puede ofrecer en lugar de comparar una solución de persistencia con otra.
Esto es muy difícil de hacer. Cada proveedor tendrá diferentes niveles de servicio en diferentes puntos de precio y uno podría considerar la opción de ejecutarlo en su propio hardware a nivel local con fines de desarrollo, una opción bienvenida.