Производительность от S3 до EC2 для извлечения большого количества небольших файлов

У меня есть большая коллекция фрагментов данных размером 1 КБ (порядка нескольких сотен миллионов), и мне нужен способ хранения и запроса этих фрагментов данных. Фрагменты данных добавляются, но никогда не удаляются и не обновляются. Наш сервис развернут на платформе S3, EC2.

Я знаю, что Amazon SimpleDB существует, но мне нужно решение, не зависящее от платформы (например, на тот случай, если нам понадобится отказаться от AWS).

Итак, мой вопрос: каковы плюсы и минусы этих двух вариантов хранения и извлечения фрагментов данных. Как сравнить производительность?

  • Храните фрагменты данных в виде файлов на S3 и ПОЛУЧАЙТЕ их при необходимости.
  • Храните фрагменты данных в кластере MySQL Server.

Будет ли такая большая разница в производительности?


amazon-web-services amazon-ec2 amazon-s3
person The Unknown    schedule 29.04.2009    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вам нужно предоставить доступ к этим фрагментам данных непосредственно пользователям вашего приложения? Если нет, то запросы S3 и HTTP GET являются излишними. Принимая также во внимание, что S3 является защищенным сервисом, накладные расходы для каждого запроса GET (всего для 1 КБ данных) будут значительно большими.

Кластер серверов MySQL был бы лучшей идеей, но для работы в EC2 вам необходимо использовать Elastic Block Storage. Наконец, не исключайте SimpleDB. Возможно, это лучшее решение вашей проблемы. Тщательно проектируйте свою систему, и вы сможете легко мигрировать в другие системы баз данных (распределенные или реляционные) в будущем.

person kgiannakakis    schedule 29.04.2009

arrow_upward
2
arrow_downward

Я попытался использовать S3 в качестве своего рода «базы данных», используя крошечные XML-файлы для хранения моих объектов структурированных данных и полагаясь на «ключи» S3 для поиска этих объектов.

Производительность была неприемлемой даже для EC2 — слишком велика задержка для S3.

Запуск MySQL на устройстве EBS будет на порядок быстрее, даже с таким количеством записей.

person Nick Farina    schedule 14.05.2009