¿De qué sirve usar Amazon SimpleDB?

Question

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

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

Entonces, el tamaño máximo de 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 está faltando 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.

Answer 1

Uso SDB en un par de aplicaciones grandes. 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 piense 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.

La limitación 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, aún me encantan los 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.

Answer 2

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.

Answer 3

Amazon intenta hacer 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 forma 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 uno.

Answer 4

Los límites parecen aplicarse a la versión actual Beta. 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 la fiabilidad 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 que el volumen de datos o el volumen de las solicitudes f crecen. No significa necesariamente un rendimiento óptimo, ni tampoco significa un almacenamiento de datos de muy alta capacidad.

Amazon SimpleDB también ofrece un servicio gratuito de nivel, por lo que puede almacenar hasta 1 GB, transferir hasta 1 GB/mes, utilizando 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.

Answer 5

Estoy construyendo una aplicación commericial .NET que utilizará SimpleDB como su almacén de datos primario. 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 de mi plan de trabajo están relacionados con los temas que usted ha mencionado:

• partición transparente de los datos
• Pseudo transaccionalidad
• Spanning transparente de atributos a superar el límite de 1.000 bytes

SimpleDB aún está 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.

Answer 6

Tengo alrededor de 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í es a description of how I pinch pennies using SimpleDB

Answer 7

Vale la pena añadiendo que aunque tener que escribir su propia lógica sharding a través de dominios no es lo 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, me gustaría ver que esto se abstraiga del uso normal y tenga algo así como "sugerencias" en la API si desea 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 requiere que escriba las llamadas de MapReduce para realizar una consulta, mientras que SimpleDB se indexa de forma dinámica para usted, por lo que gana algo, pierde algo.

Answer 8

No compre todo el bombo alrededor de SimpleDB y de acuerdo con 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 uno).

lo que las limitaciones que han visto:

• sólo se puede ejecutar en Amazon AWS, también debe pay for a whole bunch of staff
• tamaño máximo de dominio (tabla) es de 10 GB
• longitud valor de 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 Seleccionar (la cantidad máxima de datos que puede devolverle) - 1Mb, en realidad puede consultar l la limitations here
• tiene controladores únicamente para a few languages (Java, PHP, Python, Ruby, .NET)
• no permite búsqueda que ignore. Debe introducir una lógica adicional de campo/aplicación en minúsculas.
• clasificación se puede hacer solo on one field
• debido a 5s timelimit count in can behave strange. 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.
• everything is a UTF-8 string, lo que hace que sea un fastidio trabajar con valores que no sean cadenas (como números, fechas).
• clasificación se comporta extraño para los números (debido a que todo es una cadena). Así que ahora usted tiene que hacer un shamanic dance with padding
• tanto no tienen las transacciones y se une a
• ningún compuesto, los índices de columna geostático, múltiples, no hay claves externas

Si esto no es suficiente, entonces también tiene que olvidarse de las cosas básicas como group by, sumaverage, distinct, así como la 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 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, por fin, no se olvide de vendor locking. 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.