DynamoDB vs MongoDB NoSQL [cerrado]

Estoy tratando de averiguar qué puedo usar para un proyecto futuro, planeamos almacenar alrededor de 500k registros por mes en el primer año y tal vez más para los próximos años, esta es una aplicación vertical, por lo que no hay necesidad de usar un base de datos para esto, esa es la razón por la que decidí elegir un almacenamiento de datos noSQL.

La primera opción que me vino a la mente fue mongo db, ya que es un producto muy maduro con mucho apoyo de la comunidad pero, por otro lado, obtuvimos un producto completamente nuevo que ofrece un servicio administrado con el máximo rendimiento, desarrollaré esto aplicación, pero no hay un plan de mantenimiento (al menos por ahora), así que creo que será una gran ventaja ya que Amazon proporciona una forma elástica de escalar.

Mi principal preocupación es sobre la estructura de consulta, todavía no he examinado las capacidades de consulta de dynamoDB, pero dado que es un almacenamiento de datos ak / v, creo que esto podría ser más limitado que mongo db.

Si alguien tuvo la experiencia de trasladar un proyecto de mongoDB a DynamoDB, cualquier consejo será totalmente apreciado.

Recientemente migré mi MongoDB a DynamoDB, y escribí 3 blogs para compartir algo de experiencia y datos sobre el rendimiento y el costo.

Migrar de MongoDB a AWS DynamoDB + SimpleDB

7 razones por las que debe usar MongoDB sobre DynamoDB

3 razones por las que debe usar DynamoDB sobre MongoDB

Sé que esto es viejo, pero aún aparece cuando buscas la comparación. Estábamos usando Mongo, nos hemos mudado casi por completo a Dynamo, que es nuestra primera opción ahora. No porque tenga más funciones, no las tiene. Mongo tiene un mejor lenguaje de consulta, puede indexar dentro de una estructura, hay muchas cosas pequeñas. La superioridad de Dynamo está en lo que el OP declaró en su comentario: es fácil. No tiene que ocuparse de ningún servidor. Cuando comienzas a configurar una solución fragmentada de Mongo, se complica. Puede ir a una de las empresas de hosting, pero tampoco es barato. Con Dynamo, si necesita más rendimiento, simplemente haga clic en un botón. Puede escribir scripts para escalar automáticamente. Cuando llegue el momento de actualizar Dynamo, ya está hecho. Eso es mucho estrés precioso y tiempo no gastado. Si no lo haces

Así que ahora vamos a Dynamo por defecto. Mongo tal vez, si la estructura de datos es lo suficientemente complicada como para justificarla, pero probablemente volveríamos a una base de datos SQL. Dynamo es obtuso, realmente necesitas pensar en cómo lo vas a construir, y es probable que uses Redis en Elasticcache para que funcione para cosas complejas. Pero seguro que es bueno no tener que cuidarlo. Usted codifica Eso es.

Con 500k documentos, no hay razón para escalar en absoluto. Una computadora portátil típica con un SSD y 8 GB de RAM puede hacer fácilmente 10 millones de registros, por lo que si está tratando de elegir debido a la escala, su elección realmente no importa. Te sugiero que elijas lo que más te gusta y, quizás, dónde puedes encontrar la mayor cantidad de soporte en línea.

Para obtener una rápida comparación general, realmente me gusta este sitio web, que tiene muchas páginas de comparación, por ejemplo, AWS DynamoDB vs MongoDB; http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB

Respuesta corta: comience con SQL y agregue NoSQL solo cuando sea necesario. (a menos que no necesite nada más que consultas muy simples)

Mi experiencia personal: no he usado MongoDB para consultas, pero a partir de abril de 2015, DynamoDB todavía está muy paralizado cuando se trata de algo más allá de las consultas más básicas de clave / valor. Me encantan las cosas básicas, pero si quieres un lenguaje de consulta, busca una solución de base de datos SQL real.

En DynamoDB puede consultar en un hash o en una clave de hash y rango, y puede tener múltiples índices globales secundarios. Estoy haciendo consultas en una sola tabla con 4 posibles parámetros de filtro y ordenando los resultados, esto es compatible (apenas) mediante el uso de índices secundarios globales con expresiones de filtro. El problema surge cuando intenta obtener los resultados totales que coinciden con el filtro, no solo puede buscar los primeros 10 elementos que coinciden con el filtro, sino que verifica 10 elementos y puede obtener 0 resultados válidos que lo obligan a mantener escaneo desde la tecla Continuar: duele el cuello y consume demasiado de la cuota de lectura de la tabla para un escenario simple.

Para ser específico sobre el problema de límite con los filtros en la consulta, esto es de los documentos ( http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ):

En respuesta, DynamoDB devuelve todos los resultados coincidentes dentro de
El alcance del valor límite. Por ejemplo, si emite una consulta
o una solicitud de escaneo con un valor límite de 6 y sin filtro
expresión, la operación devuelve los primeros seis elementos en el 
tabla que coincide con los parámetros de solicitud. Si también proporciona un
FilterExpression, la operación devuelve los elementos dentro de 
primeros seis elementos en la tabla que coinciden con los requisitos del filtro.

Mi conclusión es que las consultas que involucran FilterExpressions solo se pueden usar en muy raras ocasiones y no son escalables porque cada consulta puede leer fácilmente la mayor parte o la totalidad de su tabla, que consume demasiadas unidades de lectura DynamoDB. Una vez que use demasiadas unidades de lectura, se acelerará y verá un bajo rendimiento.

Opinión de expertos: en la cumbre de AWS el 9 de abril de 2015, Brett Hollman, Gerente de Arquitectura de Soluciones, AWS en su charla sobre la ampliación a sus primeros 10 millones de usuarios aboga por comenzar con una base de datos SQL y luego usar NoSQL solo cuando tenga sentido. Porque tarde o temprano probablemente necesitará un servidor SQL en algún lugar de su pila. Sus diapositivas están aquí: http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users Ver diapositiva 28.

Elegimos una combinación de Mongo / Dynamo para un producto sanitario. Básicamente, mongo permite una mejor búsqueda, pero el Dynamo alojado es excelente porque cumple con HIPAA sin ningún trabajo adicional. Por lo tanto, alojamos la parte de mongo sin datos personales en una configuración estándar y permitimos que Amazon se ocupe de la parte de HIPAA en términos de infraestructura. Podemos consultar ciertos elementos de mongo que muestran documentos con punteros (ID) del documento Dynamo relacionado.

La razón principal por la que elegimos hacer esto usando mongo en lugar de alojar toda la aplicación en dynamo fue por 2 razones. Primero, necesitábamos realizar búsquedas basadas en la ubicación en las que Mongo es excelente y, en ese momento, Dynamo no lo era, pero ahora tienen una opción.

En segundo lugar, algunos documentos no estaban estructurados y no sabíamos con anticipación cuáles serían los datos, así que, por ejemplo, digamos que el usuario ingresa un documento en la colección "formulario" de esta manera: {"nombre de usuario": "usuario1", " correo electrónico ":" me@me.com "}. Y otro usuario pone esto en la misma colección {"teléfono": "813-555-3333", "ubicación": [28.1234, -83.2342]}. Con mongo podemos buscar cualquiera de estos campos dinámicos y desconocidos en cualquier momento, con Dynamo, puede hacer esto, pero tendría que hacer un índice cada vez que se agrega un nuevo campo que desea buscar. Entonces, si nunca antes ha tenido un campo de teléfono en su documento de Dynamo y, de repente, alguien lo agrega, es completamente inescrutable.

Ahora esto trae a colación otro punto en el que has mencionado. A veces, elegir la solución adecuada para el trabajo no siempre significa elegir el mejor producto para el trabajo. Por ejemplo, puede tener un cliente que necesita y utilizará el sistema que creó durante más de 10 años. Optar por una solución SaaS / IaaS que sea lo suficientemente buena como para hacer el trabajo puede ser una mejor opción, ya que puede confiar en que Amazon mantendrá y mantendrá sus sistemas a largo plazo.

He trabajado en ambos y soy un fanático de ambos.

Pero debe comprender cuándo usar qué y con qué propósito.

No creo que sea una buena idea mover toda su base de datos a DynamoDB, porque realizar consultas es difícil, excepto en las claves primaria y secundaria, la indexación es limitada y el escaneo en DynamoDB es doloroso.

Optaría por un tipo de base de datos híbrida, donde deberían existir datos extensos que se puedan consultar, MongoDB, con todas sus características, nunca se sentiría obligado a proporcionar mejoras o modificaciones.

DynamoDB es extremadamente rápido (más rápido que MongoDB), por lo que DynamoDB se usa a menudo como una alternativa a las sesiones en aplicaciones escalables. Las mejores prácticas de DynamoDB también sugieren que si hay muchos datos que se usan menos, muévalos a otra tabla.

Supongamos que tiene artículos o feeds. Es más probable que las personas busquen cosas de la semana pasada o de este mes. Es muy raro que las personas visiten datos de dos años. Para estos fines, DynamoDB prefiere tener los datos almacenados por mes o años en diferentes tablas.

DynamoDB es aparentemente escalable, algo que tendrá que hacer manualmente en MongoDB. sin embargo, perdería el rendimiento de DynamoDB si no comprende la partición de rendimiento y cómo funciona el escalado detrás de escena.

DynamoDB debe usarse donde la velocidad es crítica, MongoDB, por otro lado, tiene demasiadas manos y características, algo que le falta a DynamoDB.

por ejemplo, puede tener un conjunto de réplicas de MongoDB de tal forma que una réplica contenga una instancia de datos de 8 (o lo que sea) horas de antigüedad. Realmente útil, si arruinaste algo grande en tu base de datos y quieres obtener los datos como están antes.

Sin embargo, esa es mi opinión.

Tenga en cuenta que solo he experimentado con MongoDB ...

Por lo que he leído, DynamoDB ha recorrido un largo camino en términos de características. Solía ​​ser un almacén de valores clave súper básico con capacidades de almacenamiento y consulta extremadamente limitadas. Desde entonces, ha crecido, ahora admite tamaños de documentos más grandes + soporte JSON e índices secundarios globales . La brecha entre lo que ofrece DynamoDB y MongoDB en términos de características se reduce cada mes. Las nuevas características de DynamoDB se expanden aquí .

Gran parte de las comparaciones entre MongoDB y DynamoDB están desactualizadas debido a la reciente incorporación de las características de DynamoDB. Sin embargo, esta publicación ofrece algunos otros puntos convincentes para elegir DynamoDB, a saber, que es simple, de bajo mantenimiento y, a menudo, de bajo costo. Otra discusión aquí sobre las opciones de la base de datos fue interesante de leer, aunque un poco antigua.

Mi conclusión: si está haciendo consultas serias a la base de datos o trabajando en idiomas no compatibles con DynamoDB, use MongoDB. De lo contrario, quédate con DynamoDB.