¿Cuáles son los pros y los contras de DynamoDB con respecto a otras bases de datos NoSQL?

Question

Utilizamos 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?

Answer 1

Para empezar, estará completamente administrado por el equipo de expertos de Amazon, por lo que puede apostar que se escalará muy bien con prácticamente ninguna entrada del usuario final (desarrollador).

Además, desde que fue construido y administrado por 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.

Todavía 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 la comunidad probablemente reciba este bien: y a su vez crear controladores y herramientas adicionales.

Answer 2

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 empresa del proyecto en la que he estado trabajando.

Al igual que la mayoría de las decisiones de la base de datos, 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, ya que por el momento a pesar de que está en fase beta y no me abandonar el barco para adoptar la mejor y más nuevo sólo para ser un probador :)

Answer 3

Usando MongoDB través de un complemento -en Heroku efectivamente convierte a MongoDB en un producto SaaS.

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.

Answer 4

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 official AWS SDKs incluyen un cliente DynamoDB.

Answer 5

Hay una mesa en el siguiente enlace que resume los atributos de DynamoDB y Cassandra:

http://www.datastax.com/dev/blog/amazon-dynamodb

Algo que necesita mejorar en DynamoDB con el fin de ser más útil es la posibilidad de columnas de índice que no sea el Clave primaria.

ACTUALIZACIÓN 1 (06/04/2013)

En 18.04.2013, Amazon anunció soporte para índices secundarios locales, lo que hizo DynamoDB f *** ing grande:

http://aws.amazon.com/about-aws/whats-new/2013/04/18/amazon-dynamodb-announces-local-secondary-indexes/

Answer 6

Creo que una de las principales diferencias entre DynamoDB y otras ofertas NoSQL es el rendimiento previsto: usted paga por un nivel de rendimiento específico en una tabla y, siempre que mantenga sus datos bien particionados, siempre puede esperar ese rendimiento. Así que a medida que crece la carga de su aplicación puede escalar y mantener su rendimiento más o menos constante.

Answer 7

Creo que la diferencia clave a tener en cuenta es que MongoDB es un software que puedes instalar en cualquier lugar (incluso en AWS o en otro servicio en la nube o en casa) donde 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.

Answer 8

Pros

1. velocidad del rayo (los SSD utiliza internamente)
2. realmente (realmente) fiable. (Posibilidades de errores de escritura son más bajos)
3. escala sin fisuras (sin necesidad de hacer sharding manual)
4. Obras como servicios web (sin servidor, sin necesidad de configuración, sin instalación)
5. integrarse fácilmente con otras características de AWS (puede almacenar el toda la tabla en S3 o usar EMR, etc.)
6. La replicación se administra internamente, por lo que las posibilidades de pérdida accidental de datos son insignificantes.

Contras

1. muy (muy) limitada consulta.
2. El escaneo es doloroso (recuerdo que una vez que un escaneo a través de Java se ejecutó durante 6 horas)
3. rendimiento predefinido, lo que significa un aumento repentino más allá del rendimiento establecido se acelerará.
4. 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), su rendimiento de lectura es de 500)
5. Sin uniones, se permite la indexación limitada (básicamente 2)
6. Sin vistas, disparadores, scripts o procedimiento almacenado.

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.