Возможный алгоритм многопоточности перечисления всех ключей в большой корзине S3? - PullRequest
4 голосов
/ 09 января 2012

В блоках S3, содержащих большое количество ключей, перечисление ключей через API REST является чрезвычайно медленным процессом, поскольку

  1. Вы можете перечислять только 1000 ключей одновременно.
  2. Единственный способ определить 5001-й ключ (насколько я могу судить) состоит в том, чтобы перечислить первые 1000 ключей, перечислить следующий, основываясь на следующем маркере в ответе, а затем повторять до тех пор, пока не получите 5001.
  3. S3REST API-запросы имеют очень большую задержку, запрос на 1000 ключей обычно занимает несколько секунд.

Учитывая, что 100 одновременных запросов к списку ключей REST-запросов не должны замедлять какой-либо отдельный запрос, этот процесс в противном случае был бысозрел для оптимизации через распараллеливание.Но если мой алгоритм «глупый» и просто разбивает возможное пространство клавиш на заранее определенные маркеры (например, '', 'a', 'b', 'c', 'd', 'e' ...) на самом деле это не ускорит перечисление ключей в корзине, где каждый ключ начинается с 'images /'

Так что мне интересно, знает ли кто-нибудь действительно опытный с S3 лучший способ пройти пространство ключей корзины ИЛИесли кто-то экспериментировал с адаптивным (то есть «не глупым») алгоритмом для улучшения распечатки ключей с параллелизмом.

1 Ответ

1 голос
/ 10 января 2012

Может быть, какая-то форма алгоритма бинарного поиска поможет?Например, начинайте с префиксов '' и 'm', затем на полпути и т. Д. Я думаю, что в конечном итоге вы получите каждый ключ максимум дважды или около того - вы перестанете требовать больше, когда у вас уже есть следующий маркер.

Как выбрать, с чего начать?Я думаю, возможно, подразделить на каждом цикле: запустить '' затем, когда эти результаты возвращаются, если '' результаты указывают на большее количество ключей, затем запустить 'nextmarker' в этом поиске ПЛЮС новый поиск на полпути между 'nextmarker' и 'z',Повторение.Используйте функцию, подобную хэш-функции, чтобы хранить все ключи только один раз.

Поскольку все запросы поступают в разных потоках и т. Д., Вам потребуется блокировка для добавления всех ключей.Тогда у вас есть проблема с тем, чтобы сохранить этот замок достаточно открытым, чтобы не замедлять работу, так что это будет зависеть от того, какой язык и т. Д. Вы используете.

Возможно, вы сможете сделать это быстрее, если ваш процесс выполняется на экземпляре EC2 в том же регионе, что и файлы S3.Скажем, файлы в США «стандартные».Тогда вам повезет, вы можете использовать ruby ​​и что-то вроде Ironworker, чтобы войти туда и загрузить все ключи.После этого он может опубликовать на вашем сервере или создать файл на S3, содержащий список всех ключей или аналогичный.Для разных регионов или языков вам может потребоваться запустить собственный экземпляр EC2.

Я обнаружил, что перечисление ключей S3 намного быстрее в экземпляре EC2, поскольку существует большая пропускная способность (которую вы не платите)для EC2) для каждого запроса.S3 НЕ передает сообщения, которые являются очень пушистыми XML, поэтому полоса пропускания между вами и S3 имеет решающее значение.

...