Возможный алгоритм многопоточности со списком всех ключей в большом ведре S3?

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

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

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

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


amazon-s3 rest concurrent-programming
person Johnny C    schedule 09.01.2012    source источник
comment
Так как S3 возвращает большой XML - несжатый - вы будете заполнять свое интернет-соединение всего несколькими запросами, в зависимости, конечно, от вашего соединения и скорости вашей программы.   -  person Tom Andersen    schedule 10.01.2012
comment
Я собираюсь использовать механизм здесь, перечисляя ключи на каждом уровне и спускаясь по дереву с потоками. Это может сработать и для вас. stackoverflow .com/questions/1239700/   -  person karoberts    schedule 02.05.2013
comment
@TomAndersen только что увидел это 4 года спустя. Я призываю вас насытить полосу пропускания инстанса ec2 (100 Мбит/с) требованиями списка корзин S3, лол.   -  person Johnny C    schedule 18.05.2016
comment
Я могу насытить соединение — ограничение составляет #of IOPs, что составляет 5500 операций чтения в секунду для всех клиентов для определенного префикса. Вам не нужно больше нескольких десятков агрессивных клиентов EC2, прежде чем они все получат 503, и вам придется отступить. Если вы ходите по деревьям, идите по освещенным тропинкам и рандомизируйте их, прежде чем нырять в них.   -  person stevel    schedule 16.03.2021

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

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

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

person Tom Andersen    schedule 10.01.2012
comment
Спасибо. Я не думаю, что подход бинарного поиска работает лучше, чем просто предварительное разделение теоретического пространства ключей, потому что, если ключи плотно сгруппированы, скажем, под «изображениями/», каждый пакет находится более или менее на одном и том же расстоянии от конца ключевое пространство. Конечно, запросы, сделанные из экземпляров EC2, имеют меньшую задержку/более высокую пропускную способность, но то, что я действительно ищу, — это алгоритм, который оптимизирует любой обход ключа независимо от таких факторов, не зависящих от него. Я думаю, что использование префиксов и разделителей для имитации обхода в ширину имеет многообещающие перспективы, но требует дополнительных размышлений. - person Johnny C; 16.01.2012