Получается в архитектуре Амазона есть ограничения на префикс, которые физически лежат на одном "шарде"?
В AWS S3 префикс по сути это и есть шард. Там так же есть split шардов, то же самое, что и у вас: если RPS сильно большой, то шард (префикс) разделяется на несколько под-префиксов. В вырожденном случае шард будет состоять из одного ключа. Отсюда можно понять максимальные лимиты на запросы к одному ключу.
Та сложность, о которой вы говорите, вероятно связана с необходимостью формировать событие очереди notifications в той же транзакции, что и само действие (например, object created)?
В какой-то степени да, но там все немного сложнее. Система сама по себе распределенная и нет однозначного мастера. Запись происходит через кворум. Соответственно для реализации событий там свой велосипед с логом транзакций и его обработкой :)
Очень рад такому контакту с зарубежным коллегой :)
Взаимно, интересно как похожая система устроена в других компаниях :)
Над сервисом-оракулом думали, но пока не выявили явной необходимости в нем.
Как раз, если понадобится сделать кеш консистентным, то оракул будет полезным :)
Конкретные цифры лимитов RPS на шард не могу озвучить.
В AWS S3 ограничения такие: 3,500 PUT/COPY/POST/DELETE или 5,500 GET/HEAD (источник). Еще сложности добавляет необходимость поддерживать AWS S3 Event Notifications с учетом требования доставки 100% событий. Есть ли в вашем хранилище похожая функциональность?
Да, в AWS S3 такой есть (сам работаю как раз в AWS S3 Index ?).
Дополнительный вопрос, есть ли у вас какой-то кеш метаданных над postgres? Чтобы лишний раз не нагружать базу для чтения. Тут как раз сервис-оракул может сильно помочь, чтобы подобное реализовать. Какие у вас лимиты RPS на запись/чтение для шарда?
Как у вас работает режим консистентности? Есть ли какой-то дополнительный сервис-оракул, который знает, какая транзакция для конкретного ключа последняя?
Если представить ситуацию, что у вас есть два параллельных запроса: один на запись, другой на чтение. И запись уже произошла, но не все реплики обновили метаданные. Здесь запрос на чтение должен как-то понять, что реплика, с которой читаются данные, имеет последние метаданные.
Ну и особенности архитектуры s3 возможно могут неприятно удивить автора - в будующем. Например в определенныъ случаях после того как значение было "обновлено" (перезаписано в смысле), другой процесс который будет пытатться получить это значение будет получать старое, необновленное значение, в течение некоторого времени.
Знаю людей, кто после такого обмена восстанавливал права в РФ по причине утери и в итоге оказывался с двумя правами. Не знаю на сколько такое законно.
В AWS S3 префикс по сути это и есть шард. Там так же есть split шардов, то же самое, что и у вас: если RPS сильно большой, то шард (префикс) разделяется на несколько под-префиксов. В вырожденном случае шард будет состоять из одного ключа. Отсюда можно понять максимальные лимиты на запросы к одному ключу.
В какой-то степени да, но там все немного сложнее. Система сама по себе распределенная и нет однозначного мастера. Запись происходит через кворум. Соответственно для реализации событий там свой велосипед с логом транзакций и его обработкой :)
Взаимно, интересно как похожая система устроена в других компаниях :)
Как раз, если понадобится сделать кеш консистентным, то оракул будет полезным :)
В AWS S3 ограничения такие: 3,500 PUT/COPY/POST/DELETE или 5,500 GET/HEAD (источник). Еще сложности добавляет необходимость поддерживать AWS S3 Event Notifications с учетом требования доставки 100% событий. Есть ли в вашем хранилище похожая функциональность?
Да, в AWS S3 такой есть (сам работаю как раз в AWS S3 Index ?).
Дополнительный вопрос, есть ли у вас какой-то кеш метаданных над postgres? Чтобы лишний раз не нагружать базу для чтения. Тут как раз сервис-оракул может сильно помочь, чтобы подобное реализовать. Какие у вас лимиты RPS на запись/чтение для шарда?
Как у вас работает режим консистентности? Есть ли какой-то дополнительный сервис-оракул, который знает, какая транзакция для конкретного ключа последняя?
Если представить ситуацию, что у вас есть два параллельных запроса: один на запись, другой на чтение. И запись уже произошла, но не все реплики обновили метаданные. Здесь запрос на чтение должен как-то понять, что реплика, с которой читаются данные, имеет последние метаданные.
Здесь не верно. Amazon S3 уже давно strong consistent.