database - signin - aws simpledb vs dynamodb

¿De qué sirve usar Amazon SimpleDB? (8)

Amazon está tratando de lograr que implemente una base de datos de objetos simple. Esto es principalmente por razones de velocidad. Piense en los registros SimpleDB como un puntero / clave para un elemento en S3. De esta manera puede ejecutar consultas (desacelere contra SimpleDB para obtener listas de resultados o puede presionar S3 directamente con una tecla (rápida) para extraer el objeto cuando necesite recuperar o modificar registros uno a la vez.

Pensé que podría usar SimpleDB para ocuparme del área más desafiante de mi aplicación (en lo que se refiere al escalado) - comentarios tipo twitter, pero con ubicación en la parte superior - hasta el momento en que me senté para comenzar a implementarlo con SDB.

En primer lugar, SDB tiene una limitación de 1000 bytes por valor de atributo, que no es suficiente incluso para los comentarios (probablemente deba descomponer los valores más largos en múltiples atributos).

Entonces, el tamaño máximo del dominio es 10GB. La promesa fue que podría escalar sin preocuparse por la acumulación de datos de la base de datos, etc., ya que SDB no se degradará con el aumento de la carga de datos. Pero si lo entiendo correctamente, con los dominios tendría exactamente el mismo problema que con la fragmentación, es decir. en algún momento, es necesario implementar la distribución de registros de datos y las consultas entre los dominios en el nivel de la aplicación.

Incluso para los objetos más simples que tengo en toda la aplicación, es decir. calificaciones de usuarios atómicos, SDB no es una opción, porque no puede calcular un promedio dentro de la consulta (todo está basado en cadenas). Entonces, para calcular la calificación promedio de un usuario, tendría que cargar todos los registros, 250 a la vez, y calcularlos en el nivel de la aplicación.

¿Me estoy perdiendo algo sobre SDB? ¿Realmente 10 GB es una base de datos para superar todas las limitaciones de SDB? Honestamente, me entusiasmé con tomar ventaja de SDB, ya que uso S3 y EC2, pero ahora simplemente no veo un caso de uso.

Estoy construyendo una aplicación commericial .NET que utilizará SimpleDB como su almacén de datos principal. Todavía no estoy en producción, pero también he estado creando una biblioteca de código abierto que resuelve algunos de los problemas con el uso de SimpleDB frente a un RDBS. Algunas de las características en mi hoja de ruta están relacionadas con los problemas que ha mencionado:

Partición transparente de datos
Pseudo transaccionalidad
Transparición transparente de atributos para superar el límite de 1000 bytes

SimpleDB aún se encuentra en desarrollo activo y seguramente terminará con muchas características que no tiene hoy en día (algunas agregadas al sistema central y otras en las bibliotecas de códigos).

La biblioteca .NET es Simple Savant .

Los límites parecen aplicarse a la versión beta actual. Supongo que permitirán bases de datos más grandes en el futuro, una vez que descubran cómo pueden satisfacer económicamente la demanda. Incluso con los límites, una base de datos de 10 GB que admite alta escalabilidad y confiabilidad es un recurso útil y rentable.

Tenga en cuenta que la escalabilidad se refiere a la capacidad de mantener una curva de rendimiento estable y poco profunda , mientras crece el volumen de datos o el volumen de solicitudes. No significa necesariamente un rendimiento óptimo, ni tampoco significa un almacenamiento de datos de muy alta capacidad.

Amazon SimpleDB también ofrece un nivel de servicio gratuito , por lo que puede almacenar hasta 1GB, transferir hasta 1GB / mes, usando hasta 25 horas de tiempo de la máquina. Si bien este límite parece muy bajo, el hecho de que sea gratuito permite a algunos clientes de baja escala utilizar la tecnología, sin invertir en una gran granja de servidores.

No compre todo el bombo en torno a SimpleDB y en base a las siguientes limitaciones no puedo ver una razón por la que deba usarse (entiendo que ahora puedes construir casi cualquier cosa con casi cualquier tecnología, pero esta no es la razón para seleccionar una) .

Entonces las limitaciones que he visto:

solo se puede ejecutar en Amazon AWS, también debe pagar todo un personal
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 la respuesta de selección - 2500
tamaño máximo de respuesta para Select (la cantidad máxima de datos que puede devolverle) - 1Mb, en realidad puede verificar todas las limitaciones aquí
tiene controladores solo para algunos idiomas (java, php, python, ruby, .net)
no permite búsquedas insensibles a mayúsculas y minúsculas Debe introducir una lógica adicional de campo / aplicación en minúsculas.
la clasificación se puede hacer solo en un campo
debido a 5s timelimit count en puede comportarse extraño . 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 cadenas (como números, fechas).
la clasificación se comporta de forma extraña para los números (debido a que todo es una cadena). Entonces ahora tienes que hacer una danza chamánica con relleno
ambos no tienen transacciones y se une
sin índices compuestos, geostáticos, de columnas múltiples, sin claves externas

Si esto no es suficiente, entonces también debe olvidarse de las cosas básicas como group by , sum average , distinct así como manipulación de datos. En general, el lenguaje de consulta es bastante rudimentario y recuerda a un pequeño subconjunto de lo que SQL puede hacer.

Por lo tanto, la funcionalidad no es mucho más rica que Redis / Memcached, pero dudo mucho que funcione tan bien como estos dos dbs para sus casos de uso.

SimpleDB se posiciona como una base de datos nosql basada en documentos sin esquema pero la sintaxis de consulta de MongoDB / CounchDB es mucho más expresiva y sus limitaciones son mucho más razonables.

Y finalmente, no te olvides del bloqueo de proveedores . Si en un par de años Azure (o alguna otra cosa que pareciera) proporcionará una nube alojada 5 veces más barata que AWS, sería muy difícil cambiarla.

Si el problema es el tamaño de almacenamiento por atributo, puede usar S3 para almacenar datos más grandes y almacenar los enlaces a los objetos s3 en SDB. S3 no es solo para archivos, es una solución de almacenamiento genérica.

Tengo aproximadamente 50 GB en SimpleDB, fragmentado en 30 dominios. Utilizo esto para permitir múltiples claves en objetos almacenados en S3, y también para reducir mis costos de S3. No he jugado con SimpleDB para la búsqueda de texto completo, pero no lo intentaría.

SimpleDB funciona, es fácil, y así sucesivamente, pero no es el conjunto de funciones correcto para cada situación. En su caso, si necesita agregación, SimpleDB no es la solución correcta. Se basa en la escuela de pensamiento de que el DB es solo un almacén de valores clave, y la agregación debe ser manejada por un proceso de agregación que escribe los resultados en el almacén de valores clave. Esto es exactamente lo que se necesita para algunas aplicaciones.

Aquí hay una descripción de cómo pellizco centavos usando SimpleDB

Vale la pena agregar que, si bien tener que escribir su propia lógica de fusión entre dominios no es ideal, es en términos de rendimiento. Si, por ejemplo, necesita buscar 100 gb de datos, es mejor pedir 20 máquinas con 5 gb cada una para realizar la misma búsqueda en la parte de la que son responsables, en lugar de que una máquina tenga que realizar toda la tarea. Si su objetivo es terminar con una lista ordenada, puede obtener los mejores resultados devueltos de las 20 consultas simultáneas y cotejarlas en la máquina que inicia la solicitud.

Dicho esto, preferiría ver que esto se abstraiga del uso normal y tener algo así como "sugerencias" en la API si quieres obtener un nivel inferior. Entonces, si almacena 100gb de datos, deje que Amazon decida si está dividido en 20 máquinas o 10 o 40, y distribuya el trabajo. Por ejemplo, en el diseño BigTable de Google, a medida que una tabla crece, se divide continuamente en tabletas de 400MB. Pedir una fila de una mesa es tan simple como eso, y BigTable hace el trabajo de averiguar dónde vive una tableta o millones de tabletas.

Por otra parte, BigTable le exige que escriba las llamadas de MapReduce para realizar una consulta, mientras que SimpleDB se indexa a sí mismo de forma dinámica, por lo que gana algo, pierde algo.

Yo uso SDB en un par de aplicaciones de gran tamaño. El límite de 10 GB por dominio me preocupa, pero estamos apostando en Amazon permitiendo que esto se extienda si lo necesitamos. Tienen un formulario de solicitud en su sitio si desea más espacio.

En cuanto a las combinaciones de dominios cruzados, no pienses en SDB como una base de datos tradicional. Durante la migración de mis datos a SDB, tuve que desnormalizar algunos de ellos para poder hacer manualmente las combinaciones de dominios cruzados.

El límite de 1000 bytes por atributo también era difícil de solucionar. Una de las aplicaciones que tengo es un servicio de blog que almacena publicaciones y comentarios en la base de datos. Al transferirlo a SDB, encontré esta limitación. Terminé almacenando las publicaciones y comentarios como archivos en S3, y lo leí en mi código. Como este servidor está en EC2, el tráfico a S3 no cuesta nada extra.

Quizás uno de los otros problemas a tener en cuenta es el modelo de coherencia eventual en SDB. No puede escribir datos y luego leerlos con la garantía de que le devolverán los datos recién escritos. Eventualmente los datos serán actualizados.

Dicho todo esto, todavía amo SDB. No me arrepiento de cambiar a eso. Me mudé de un servidor SQL 2005. Creo que tenía mucho más control con SQL, pero una vez que renuncié a ese control, tengo más flexibilidad. No es necesario pre-definir el esquema es increíble. Con una capa de caché sólida y robusta en su código, es fácil hacer que los SDB sean más flexibles.