¿Existen limitaciones conocidas de la escala S3? ¿Alguien alguna vez tuvo tantas lecturas o escrituras simultáneas que un cubo comenzó a devolver errores? Estoy un poco más interesado en escribir que leer porque es probable que S3 esté optimizado para lecturas.¿Alguien ha alcanzado alguna vez un límite superior de lectura o escritura para un cubo de Amazon S3?
comentario de Eric lo resume ya en un nivel conceptual, como se abordó en el FAQ What happens if traffic from my application suddenly spikes? así:
Amazon S3 fue diseñado desde cero para manejar el tráfico para cualquier aplicación Internet. [...] La escala masiva de Amazon S3 nos permite repartir la carga de manera uniforme, por lo que ninguna aplicación individual se ve afectada por picos de tráfico .
Por supuesto, usted todavía tiene que dar cuenta de posibles problemas y Tune [su] Solicitud de errores desaceleración repetidas (véase Amazon S3 Error Best Practices):
Como con cualquier sistema distribuido, S3 tiene Los mecanismos de protección detectan el consumo excesivo o no intencional de recursos y reaccionan en consecuencia. Los errores SlowDown pueden ocurrir cuando una alta tasa de solicitud activa uno de estos mecanismos. Al reducir su tasa de solicitud, disminuirá o eliminará los errores de este tipo. En general, la mayoría de los usuarios de no experimentarán estos errores regularmente; Sin embargo, si desea más información o está experimentando errores altas o inesperadas desaceleración, por favor publique en nuestro foro de desarrolladores de Amazon S3 http://developer.amazonwebservices.com/connect/forum.jspa?forumID=24 o se inscribe para AWS Soporte Premium http://aws.amazon.com/premiumsupport/. [el énfasis es mío]
Aunque es poco común, estas ralentizaciones qué suceden por supuesto - aquí es un AWS team response que ilustra el tema (bastante antiguo, sin embargo):
Amazon S3 devolverá este error cuando el la tasa de solicitud es lo suficientemente alta como que el servicio de las solicitudes causaría la degradación del servicio para otros clientes . Este error rara vez se activa. Si recibe , debe retroceder exponencialmente. Si se produce este error, los recursos del sistema se reequilibrarán/asignarán de forma reactiva para admitir mejor una tasa de solicitud más alta de . Como resultado, el período de tiempo durante el cual se lanzará este error debería ser relativamente corto. [el énfasis es mío]
Su suposición acerca de leer frente a la optimización de escritura se confirma allí también:
El umbral en el que este error se trigged varía y dependerá, en parte, de la tipo y patrón de solicitud. En general, podrá obtener rps más altos con puts contra puts y con lotes de get para un pequeño número de teclas frente a lotes de get para un gran número de claves. Al calcular o colocar un gran número de claves, podrá obtener rps más altos si las teclas están en orden alfanumérico contra orden aleatorio/hash .
Amazon S3 procesa cientos de miles de solicitudes por segundo (http://aws.typepad.com/aws/amazon_s3/). No hay límite en la cantidad de objetos por segmento, por lo que dudo que existan límites de concurrencia en el nivel de depósito. –
FYI, acabo de cargar más de 10 millones de archivos en menos de 15 días, con 30 subprocesos concurrentes. No encontré ningún límite/problema. – Benjamin