MongoDB en el servidor EC2 o AWS SimpleDB?

amazon-simpledb (3)

Ahora, 5 años después, no es difícil configurar Mongo en ningún sistema operativo. Documentation es fácil de seguir, por lo que no veo configurar a Mongo como un problema. Otras respuestas abordaron las cuestiones de escalabilidad, por lo que trataré de abordar la cuestión desde el punto de vista de un desarrollador (qué limitaciones tiene cada sistema):

Usaré S para SimpleDB y M para Mongo.

M está escrito en C ++, S está escrito en Erlang (no es el idioma más rápido)
M es de código abierto, está instalado en todas partes, S es propietario, puede ejecutarse solo en Amazon AWS. También debe pagar por un montón de personal para S
S tiene muchas limitaciones extrañas . M limitations son mucho más razonables. Las limitaciones más extrañas son:
- el tamaño máximo de dominio (tabla) es de 10 GB
- La longitud del valor del atributo (tamaño del campo) es 1024 bytes
- elementos máximos en Seleccionar respuesta - 2500
- tamaño máximo de respuesta para Select (la cantidad máxima de datos que S puede devolver) - 1Mb
S solo admite unos pocos idiomas (java, php, python, ruby, .net), M admite mucho más
ambos admiten REST
S tiene una sintaxis de consulta muy similar a SQL (pero mucho menos poderosa). Con M necesitas aprender una nueva sintaxis que se parece a json (también es sencillo aprender los conceptos básicos)
con M tienes que aprender cómo puedes diseñar tu base de datos. Debido a que muchas personas piensan que "sin esquemas" significa que puedes tirar cualquier basura en la base de datos y extraer esto con facilidad, se sorprenderán de que Junk in, Junk out maxim works. Supongo que lo mismo está en S, pero no puedo reclamarlo con certeza.
ambos no permiten la búsqueda insensible a mayúsculas y minúsculas. En M, puede usar regex de alguna manera (feo / sin índice) para superar esta limitación sin introducir la lógica adicional de campo / aplicación en minúscula.
en S la clasificación se puede hacer solo en un campo
debido a 5s timelimit count en S puede comportarse de manera extraña . Si pasaron 5 segundos y la consulta no finalizó, terminas con un número parcial y un token que te permite continuar con la consulta. La lógica de la aplicación es responsable de recopilar todos estos datos y resumirlos.
todo es una cadena UTF-8 , lo que hace que sea un fastidio trabajar con valores que no sean de cadena (como números, fechas) en S. El soporte de tipo M es mucho más rico .
ambos no tienen transacciones y se une
M admite la compression que es realmente útil para las tiendas nosql, donde el mismo nombre de campo se almacena todo de nuevo.
S admite solo un índice, M tiene funciones geoespaciales únicas, compuestas, multi-claves, etc.
ambos soportan replicación y fragmentación

Una de las cosas más importantes que debe considerar es que SimpleDB tiene un lenguaje de consulta muy rudimentario. Incluso las cosas básicas como group by , sum average , distinct así como manipulación de datos no son compatibles, por lo que la funcionalidad no es mucho más rica que Redis / Memcached. Por otro lado, Mongo admite un lenguaje de consulta enriquecido.

¿Qué escenario tiene más sentido: alojar varias instancias EC2 con MongoDB instalado, o más bien utilizar el servicio web Amazon SimpleDB?

Cuando tengo varias instancias de EC2 con MongoDB, tengo el problema de configurar la instancia por mi cuenta.

Cuando uso SimpleDB, tengo el problema de encerrarme en la estructura de datos de Amazonas ¿verdad?

¿Qué diferencias existen en cuanto al desarrollo? ¿No debería ser capaz de simplemente cambiar el DAO de mis capas de servicio, ya sea para escribir en MongoDB o AWS SimpleDB?

Creo que tienes una cuestión de tiempo y velocidad.

MongoDB / Cassandra será mucho más rápido, pero tendrás que invertir $$$ para ponerlos en marcha. Esto significa que deberá ejecutar / configurar instancias del servidor para todos ellos y descubrir cómo funcionan.

Por otro lado, no tiene que pagar directamente por un costo "por transacción", solo paga por el hardware que probablemente sea más eficiente para servicios más grandes.

En la pelea Cassandra / MongoDB esto es lo que encontrarás (basado en las pruebas con las que estoy involucrado personalmente durante los últimos días).

Cassandra:

Scaling / Redundancy es muy básico
La configuración puede ser muy intensa
Para hacer informes, necesita map-reduce, para eso necesita ejecutar una capa de hadoop. Este fue un dolor para configurar y un dolor más grande para obtener rendimiento.

MongoDB:

La configuración es relativamente fácil (incluso para el nuevo sharding, esta semana)
La redundancia todavía está "llegando"
Map-reduce está integrado y es fácil sacar datos.

Honestamente, dado el tiempo de configuración requerido para nuestros 10s de GB de datos, fuimos con MongoDB por nuestra parte. Puedo imaginarme usando SimpleDB para casos de "debo tener estos en ejecución". Pero configurar un nodo para ejecutar MongoDB es tan ridículamente simple que puede valer la pena saltar la ruta "SimpleDB".

En términos de DAO, ya hay toneladas de bibliotecas para Mongo. El marco de ahorro para Cassandra está bien respaldado. Probablemente puedas escribir alguna lógica simple para abstraer las conexiones. Pero será más difícil abstraer las cosas más complejas que el simple CRUD.

SimpleDB tiene algunas limitaciones de escalabilidad. Solo puede escalar por fragmentación y tiene una mayor latencia que mongodb o cassandra, tiene un límite de rendimiento y tiene un precio más alto que otras opciones. La escalabilidad es manual (debe fragmentar).

Si necesita opciones de consulta más amplias y tiene una tasa de lectura alta y no tiene tantos datos, mongodb es mejor. Pero para mayor durabilidad, debe usar al menos 2 instancias de servidor mongodb como maestro / esclavo. De lo contrario, puede perder el último minuto de sus datos. La escalabilidad es manual. Es mucho más rápido que simpledb. Autosharding se implementa en la versión 1.6.

Cassandra tiene opciones de consulta débiles pero es tan duradero como postgresql. Es tan rápido como mongo y más rápido en un tamaño de datos más alto. Las operaciones de escritura son más rápidas que las operaciones de lectura en cassandra. Se puede escalar automáticamente disparando instancias de ec2, pero tienes que modificar un poco los archivos de configuración (si no recuerdo mal). Si tienes terabytes de datos, Casandra es tu mejor opción. No es necesario fragmentar sus datos, fue diseñado distribuido desde el primer día. Puede tener cualquier número de copias para todos sus datos y, si algunos servidores están muertos, devolverá automáticamente los resultados de los vivos y distribuirá los datos del servidor muerto a otros. Es altamente tolerante a fallas. Puede incluir cualquier cantidad de instancias, es mucho más fácil escalar que otras opciones. Tiene fuertes opciones de cliente .net y java. Tienen agrupación de conexiones, equilibrio de carga, marcado de servidores muertos, ...

Otra opción es hadoop para Big Data, pero no es tan real como otros, puedes usar hadoop para datawarehousing. Ni cassandra ni mongo tienen transacciones, por lo que si necesitas transacciones postgresql es una mejor opción. Otra opción es Amazon RDS, pero su rendimiento es malo y el precio es alto. Si desea utilizar bases de datos o simpledb, es posible que también necesite el almacenamiento en memoria caché de datos (p. Ej .: memcached).

Para aplicaciones web, si sus datos son pequeños, recomiendo mongo, si es grande, cassandra es mejor. No necesitas una capa de almacenamiento en caché con mongo o cassandra, ya son rápidos. No recomiendo SimpleDB, también te bloquea a Amazon como dijiste.

Si está utilizando c #, java o scala, puede escribir una interfaz e implementarla para mongo, mysql, cassandra o cualquier otra cosa para la capa de acceso a datos. Es más simple en los lenguajes dinámicos (por ejemplo, frotar, python, php). Puede escribir un proveedor para dos de ellos si lo desea y puede cambiar el almacenamiento en tiempo de ejecución solo con un cambio de configuración, todos son posibles. El desarrollo con mongo, cassandra y simpledb es más fácil que una base de datos, y están libres de esquemas, también depende de la biblioteca / conector de cliente que esté utilizando. El más simple es mongo. Solo hay un índice por tabla en Casandra, por lo que debes administrar otros índices tú mismo, pero con la versión 0.7 de cassandra los índices secundarios serán posibles, como sé. También puede comenzar con cualquiera de ellos y reemplazarlo en el futuro si es necesario.