Rendimiento de S3 a EC2 para obtener grandes cantidades de archivos pequeños

Question

Tengo una gran colección de fragmentos de datos con un tamaño de 1kB (del orden de varios cientos de millones), y necesito una forma de almacenar y consultar estos fragmentos de datos. Los fragmentos de datos se agregan, pero nunca se eliminan o actualizan. Nuestro servicio se implementa en la plataforma S3, EC2.

Sé que Amazon SimpleDB existe, pero quiero una solución que sea independiente de la plataforma (en caso de que necesitemos salir de AWS, por ejemplo).

Entonces mi pregunta es, ¿cuáles son las ventajas y desventajas de estas dos opciones para almacenar y recuperar fragmentos de datos? ¿Cómo se compararía el rendimiento?

• Almacene los fragmentos de datos como archivos en S3 y OBTENGA cuando sea necesario
• Almacene los fragmentos de datos en un clúster de Servidor MySQL

¿Habría tanta diferencia de rendimiento?

Answer 1

¿Necesita proporcionar acceso a estos fragmentos de datos directamente a los usuarios de su aplicación? De lo contrario, las solicitudes S3 y HTTP GET son excesivas. Teniendo también en cuenta que S3 es un servicio seguro, la sobrecarga para cada solicitud GET (por solo 1 KB de datos) será considerablemente grande.

El clúster de servidores MySQL sería una mejor idea, pero para ejecutar en EC2 necesita emplear Elastic Block Storage. Finalmente, no descarte SimpleDB. Es quizás la mejor solución para su problema. Diseñe su sistema con cuidado y podrá migrar fácilmente en otros sistemas de bases de datos (distribuidos o relacionales) en el futuro.

Answer 2

Intenté usar S3 como una especie de "base de datos" usando pequeños archivos XML para contener mis objetos de datos estructurados y confiando en las teclas S3 '' para buscar estos objetos.

El rendimiento era inaceptable, incluso desde EC2: la latencia a S3 es demasiado alta.

Ejecutar MySQL en un dispositivo EBS será un orden de magnitud más rápido, incluso con tantos registros.