¿Cuál es el punto de usar Amazon SimpleDB?

Question

Pensé que podía usar SimpleDB para ocuparme del área más desafiante de mi aplicación (en lo que respecta al escalado) - comentarios similares a Twitter, pero con la ubicación en la parte superior - hasta el punto en que me senté para comenzar realmente implementándolo con SDB.

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

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

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

¿Me estoy perdiendo algo sobre SDB? ¿Es 10GB realmente una gran base de datos para superar todas las limitaciones de SDB? Honestamente, me entusiasmó aprovechar SDB, ya que ya uso S3 y EC2, pero ahora simplemente no veo un caso de uso.

Answer 1

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 uniones entre dominios, 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 uniones de dominios cruzados.

La limitación de 1000 bytes por atributo también fue 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. Mientras lo trasladaba a SDB, me encontré con esta limitación. Terminé almacenando las publicaciones y comentarios como archivos en S3, y lo leí en mi código. Dado que 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 volver a leerlos con la garantía de que se le devolverán los datos recién escritos. Finalmente, los datos se actualizarán.

Todo esto dicho, todavía me encanta SDB. No me arrepiento de haberlo cambiado. 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 predefinir el esquema es increíble. Con una capa de caché fuerte y robusta en su código, es fácil hacer que SDB sea más flexible.

Answer 2

Tengo alrededor de 50 GB en SimpleDB, dividido en 30 dominios. Lo uso 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, etc., pero no es el conjunto de características adecuado 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 la base de datos es solo un almacén de valores clave, y la agregación debe manejarse mediante un proceso de agregación que escriba los resultados en el almacén de valores clave. Esto es exactamente lo que se necesita para algunas aplicaciones.

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

Answer 3

Vale la pena agregar que si bien tener que escribir su propia lógica de particionamiento entre dominios no es lo ideal, lo es en términos de rendimiento. Si, por ejemplo, necesita buscar en 100 gb de datos, es mejor pedirle a 20 máquinas con 5 gb cada una que realicen 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 esto abstraído del uso normal y tener algo como "pistas". en la API si quieres obtener un nivel inferior. Entonces, si almacena 100 gb 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 tabla es tan simple como eso, y BigTable hace el trabajo de averiguar en qué parte de la tableta o millones de tabletas vive.

Por otra parte, BigTable requiere que escribas llamadas de MapReduce para realizar una consulta, mientras que SimpleDB se indexa dinámicamente por ti, por lo que ganas algo, pierdes algo.

Answer 4

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 5

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 de SimpleDB como un puntero / clave para un elemento en S3. De esta forma puede ejecutar consultas (lento contra SimpleDB para obtener listas de resultados o puede presionar directamente S3 con una tecla (rápido) para extraer el objeto cuando necesite recuperar o modificar registros uno por uno.

Answer 6

Los límites parecen aplicarse a la versión actual de Beta . Supongo que permitirán bases de datos más grandes en el futuro, después de descubrir cómo pueden satisfacer económicamente la demanda. Incluso con los límites, una base de datos de 10 GB que admita 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 superficial , mientras crece el volumen de datos o el volumen de solicitudes. No significa necesariamente un rendimiento óptimo ni un almacenamiento de datos de muy alta capacidad.

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

Answer 7

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

• Partición transparente de datos
• Pseudo transaccionalidad
• Extensión transparente de atributos a 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 (algunas agregadas al sistema central y otras en las bibliotecas de códigos).

La biblioteca .NET es Simple Savant .

Answer 8

No compro toda la publicidad sobre SimpleDB y, según las siguientes limitaciones, no puedo ver una razón por la que debería usarse (entiendo que ahora puedes construir casi cualquier cosa con casi cualquier tecnología, pero esta no es la razón para seleccione uno).

Entonces, las limitaciones que he visto:

• solo se puede ejecutar en Amazon AWS, también debe pagar por un montón de personal
• el tamaño máximo del dominio (tabla) es de 10 GB
• la longitud del valor del atributo (tamaño del campo) es 1024 bytes
• elementos máximos en 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 todos los limitaciones aquí
• tiene controladores solo para algunos idiomas (java, php, python, ruby, .net)
• no permite la búsqueda entre mayúsculas y minúsculas. Debe introducir una lógica adicional de campo / aplicación en minúsculas.
• la clasificación solo se puede realizar en un campo
• debido a 5s timelimit el recuento puede comportarse de forma extraña . Si pasaron 5 segundos y la consulta no ha terminado, terminas con un número parcial y un token que te permite continuar 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 Es un fastidio trabajar con valores que no son cadenas (como números, fechas).
La ordenación
• se comporta de forma extraña para los números (debido al hecho de que todo es una cadena). Entonces ahora tienes que hacer un danza chamánica con relleno
• ambos no tienen transacciones y se unen
• sin índices compuestos, geostáticos, de múltiples columnas, sin claves foráneas

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

Entonces, la funcionalidad no es realmente 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 sin documentos y 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 último, no se olvide del bloqueo del proveedor . Si en un par de años Azure (o alguna otra cosa que apareciera) proporcionara un alojamiento en la nube 5 veces más barato que AWS, sería muy difícil cambiarlo.