aws - DynamoDB vs MongoDB NoSQL
mongodb atlas (7)
Estoy tratando de averiguar qué puedo usar para un proyecto futuro, tenemos previsto almacenar aproximadamente 500k registros por mes en el primer año y tal vez más en los próximos años, esta es una aplicación vertical, por lo que no es necesario utilizar 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 nuevo producto que ofrece un servicio administrado de alto 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 mayor preocupación es sobre la estructura de consultas, no he examinado las capacidades de consulta dynamoDB todavía, 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 mover un proyecto de mongoDB a DynamoDB, cualquier consejo será totalmente apreciado.
Con 500k documentos, no hay razón para escalar en absoluto. Una computadora portátil típica con un SSD y 8 GB de memoria RAM puede fácilmente hacer 10s de millones de registros, por lo que si está tratando de elegir debido a la escala de su elección en realidad no importa. Le sugiero que elija lo que más le guste, y quizás dónde pueda encontrar el soporte más en línea.
Elegimos una combinación de Mongo / Dynamo para un producto de atención médica. Básicamente mongo permite una mejor búsqueda, pero el Dynamo alojado es excelente porque cumple con HIPAA sin ningún trabajo adicional. Así que alojamos la porción de mongo sin datos personales en una configuración estándar y le permitimos a Amazon tratar con la parte de HIPAA en términos de infraestructura. Podemos consultar ciertos elementos de mongo que muestran documentos con punteros (ID) del documento Dynamo identificable.
La razón principal por la que elegimos hacer esto usando mongo en lugar de alojar toda la aplicación en dínamo fue por 2 razones. En primer lugar, necesitábamos realizar búsquedas basadas en la ubicación en las que Mongo es excelente y, en ese momento, Dynamo no, pero ahora sí 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 "form" de la siguiente manera: {"username": "user1", " correo electrónico ":" [email protected] "}. Y otro usuario coloca 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, podría hacer esto, pero tendría que hacer un índice cada vez que se agregara un nuevo campo que deseaba buscar. Entonces, si nunca antes ha tenido un campo de teléfono en su documento de Dynamo y luego, de repente, alguien lo agrega, es completamente indescifrable.
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 usará el sistema que creó durante más de 10 años. Ir con una solución SaaS / IaaS que sea lo suficientemente buena 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 fan de ambos.
Pero debe comprender cuándo usar qué y con qué fin.
No creo que sea una buena idea mover toda su base de datos a DynamoDB, por lo que la consulta es difícil, excepto en las claves primarias y secundarias. La indexación es limitada y escanear en DynamoDB es doloroso.
Me gustaría ir a un tipo híbrido de DB, donde los datos exhaustivos consultables deberían estar allí es MongoDB, con todas sus características que nunca se sentiría obligado a proporcionar mejoras o modificaciones.
DynamoDB es muy 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évalo a otra mesa.
Entonces supongamos que tiene artículos o feeds. Es más probable que las personas busquen las cosas de la semana pasada o las de este mes. es muy raro que las personas visiten datos de dos años. Para estos fines, DynamoDB prefiere tener datos almacenados por mes o años en tablas diferentes.
DynamoDB es aparentemente escalable, algo que tendrás que hacer manualmente en MongoDB. Sin embargo, usted perdería el rendimiento de DynamoDB si no comprende la partición de rendimiento y cómo funciona el escalado detrás de la escena.
DynamoDB debe usarse donde la velocidad es crítica, MongoDB por otro lado tiene demasiadas manos y características, algo que DynamoDB no tiene.
por ejemplo, puede tener un conjunto de réplicas de MongoDB de tal manera que una de las réplicas tenga una instancia de datos de 8 (o lo que sea) horas de antigüedad. Realmente útil, si cometió un error grave en su base de datos y desea obtener los datos como antes.
Esa es mi opinión sin embargo.
Para una comparación general rápida, 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 / si es 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 tullido cuando se trata de algo más que las consultas de clave / valor más básicas. Me encanta lo básico, 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 hash y de rango, y puede tener múltiples índices globales secundarios. Estoy haciendo consultas en una sola tabla con 4 posibles parámetros de filtro y clasificando los resultados, esto es soportado (apenas) mediante el uso de los índices secundarios globales con expresiones de filtro. El problema aparece cuando intenta obtener los resultados totales que coinciden con el filtro, no puede simplemente buscar los primeros 10 elementos que coinciden con el filtro, sino que comprueba 10 elementos y puede obtener 0 resultados válidos que lo obligan a mantener el escanear desde la tecla Continuar - dolor en el cuello y consume demasiado de su cuota de lectura de 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 ):
In a response, DynamoDB returns all the matching results within the scope of the Limit value. For example, if you issue a Query or a Scan request with a Limit value of 6 and without a filter expression, the operation returns the first six items in the table that match the request parameters. If you also supply a FilterExpression, the operation returns the items within the first six items in the table that match the filter requirements.
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ía o la totalidad de su tabla que consume demasiadas unidades de lectura DynamoDB. Una vez que use demasiadas unidades de lectura, recibirá una aceleración y verá un bajo rendimiento.
Opinión de expertos: En la cumbre de AWS del 9 de abril de 2015 Brett Hollman, gerente de Solutions Architecture, AWS en su charla sobre cómo escalar para sus primeros 10 millones de usuarios aboga por comenzar con una base de datos SQL y luego usar NoSQL solo cuando y si tiene sentido. Porque tarde o temprano probablemente necesites un servidor SQL en algún lugar de tu pila. Sus diapositivas están aquí: http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users Vea la diapositiva 28.
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 características, no es así. 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 dijo en su comentario: es fácil. No tiene que ocuparse de ningún servidor. Cuando comienzas a configurar una solución de Mongo sharded, se complica. Puedes ir a una de las compañías 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 es hora de actualizar Dynamo, ya está hecho para ti. Eso es todo un montón de estrés y tiempo precioso no gastado. Si no tienes personas dedicadas a operaciones, Dynamo es excelente.
Así que ahora vamos a Dynamo por defecto. Mongo, tal vez, si la estructura de datos es lo suficientemente complicada como para garantizarlo, pero luego probablemente regresemos a una base de datos SQL. Dynamo es obtuso, realmente necesitas pensar cómo vas a construirlo, y es probable que uses Redis en Elasticcache para que funcione para cosas complejas. Pero seguro es bueno no tener que ocuparse de eso. Usted codifica. Eso es.
Tenga en cuenta que solo he experimentado con MongoDB ...
Según 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ásicos con capacidades de almacenamiento y consultas extremadamente limitadas. Desde entonces, ha crecido y ahora admite tamaños de documentos más grandes + compatibilidad con 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 amplían here .
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, es decir, que es simple, de bajo mantenimiento y, a menudo, de bajo costo. Otra discusión aquí sobre las elecciones de bases de datos fue interesante de leer, aunque un poco antigua.
Mi punto a punto: si está haciendo consultas serias a la base de datos o trabajando en idiomas no compatibles con DynamoDB, use MongoDB. De lo contrario, quédese con DynamoDB.