Параллелизм в Amazon S3

Question

В настоящее время я создаю систему, в которой S3 будет использоваться в качестве постоянного хеш-набора (URL S3 выводится из данных) многими компьютерами в Интернете. Если два узла хранят одни и те же данные, они будут сохранены с использованием одного и того же ключа и, следовательно, не будут сохранены дважды. Когда объект удален, мне нужно знать, использует ли какой-либо другой узел (ы) эти данные. В этом случае я не буду удалять его.

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

1. Считать объект из S3.
2. Десериализация объекта.
3. Добавить идентификатор нового узла в список узлов хранения.
4. Сериализация нового объекта (данные для хранения и список узлов).
5. Записать сериализованные данные в S3.

Это создает форму идемпотентного подсчета ссылок. Поскольку запросы через Интернет могут быть весьма ненадежными, я не хочу просто считать количество узлов хранения. Вот почему я храню список вместо счетчика (в случае, если узел отправляет один и тот же запрос> 1 раз).

Этот подход работает до тех пор, пока два узла не пишут одновременно. S3 (насколько я знаю) не предоставляет никакого способа блокировки объекта, чтобы все эти 5 шагов стали атомарными.

Как бы вы решили эту проблему параллелизма? Я рассматриваю возможность реализации некоторой формы оптимистичного параллелизма. Как мне это сделать для S3? Должен ли я использовать совершенно другой подход?

Answer 1

Попробуйте сначала отделить список блокировок от ваших (защищенных) данных.Создайте отдельную корзину, соответствующую вашим данным, чтобы она содержала список блокировок (имя корзины должно быть производной от имени вашего объекта данных).Используйте отдельные файлы во втором сегменте (по одному на узел, имя объекта получено из имени узла).Узлы добавляют новый объект во второе хранилище перед доступом к защищенным данным, узлы удаляют свой объект из второго хранилища, когда они завершают.

Это позволяет вам перечислить второе хранилище, чтобы определить, заблокированы ли ваши данные,И позволяет двум узлам обновлять список блокировок одновременно без конфликтов.

Answer 2

В дополнение к тому, что сказал amadeus, если ваши потребности не являются реляционными, вы можете даже использовать AWS SimpleDB, значительно дешевле.

Answer 3

Я не работал с Amazon S3, но вот мое постоянное невежественное предложение.

1. Можете ли вы использовать сегрегацию командных запросов?Будет хорошо отделить операции чтения от команд, так как эта проверка будет выполняться только для команды (УДАЛИТЬ), и она вам не понадобится для операций чтения (если я правильно понял).

2. Если для такой синхронизации нет встроенной поддержки, то ваше собственное свернутое решение может оказаться узким местом с точки зрения высокой нагрузки (что может быть решено с помощью [3] и [4]).Все ваши DELETE должны проходить через центральное место - очередь запросов.

3. Я бы сделал выделенный сервис (например, WCF) с параллельной очередью запросов.Каждый раз, когда вам нужно УДАЛИТЬ объект, вы ставите его в очередь.Служба, в своем собственном темпе, исключит предмет из очереди и выполнит все ваши 5 шагов за одну транзакцию.Это может привести к некоторым задержкам, которые, однако, могут быть не видны, если система слишком интенсивно для чтения.

4. Если система перегружена записью, вам может потребоваться добавить рабочих, которые помогают удалить из очередизапрос из очереди [3]

Answer 4

Вы можете реализовать свой собственный механизм блокировки в качестве службы на вашем ec2 и использовать его для синхронизации доступа к S3. В этом случае вы можете сохранить количество мониторов в вашем S3 (отдельно или нет)

Answer 5

Может быть хорошей идеей отделить ссылки от ресурса.

Вы можете построить параллелизм поверх версий S3. Или пусть каждый реферер / узел создает и удаляет свой собственный ресурс блокировки на S3. Или используйте сервис реляционной базы данных Amazon (RDS).