Comments 16
"Манагер" Вернер Вогельс это CTO Амазона, один из соавторов Dynamo (с которого, местами буквально, срисованы многие современные архитектуры БД И хранилищ объектов).
Вопиющее переворачивание верх-ногами причинно следственных связей -- это DynamoDB позаимствовало архитектуру со многих современников своего времени. Изначальная статья по Dynamo (не путать с DynamoDB) вполне явно упоминает Oceanstore и PAST, а также протоколы Pastry и Chord, не говоря уже о том, что школьники качали порно через Kademlia DHT и основанный на нем Mainline DHT у BitTorrent за несколько лет до формирования теоретической модели Dynamo, и тем более практической реализации, DynamoDB, которая задержалась еще на 5 лет. Ну и конечно же статья Dynamo упоминает Google FS, как ближайшего "энтерпрайзного" аналога-конкурента, выполняющего те же задачи.
Потом, когда Amazon начал продавать DynamoDB, внезапно развился хайп в духе "мама, хочу БД как у Амазона". И пошли Cassandra, Riak, и другие менее известные. Примерно как Git никому не нужен был 10 лет, а потом внезапно взлетел GitHub и все резко помешались на Git. И все резко забыли про недостатки Dynamo, которые очень серьезны, и из-за которых гугловый BigTable/FS не пошел по аналогичному пути, а именно -- проблема согласованности данных. Как переместить значение из одного ключа в другой? Как гарантировать инвартианты суммы-количества? Не говоря уже про более сложные связи.
Да куда там несколько записей -- как гарантировать для одной-единственной записи атомарность обновлений? Да, есть решение для неглобальных таблиц через условное обновление по атрибуту-версии, но для глобальных (реплицированных) оно не работает. Лучшее, что пока что смогли придумать по этой проблеме в Амазоне -- это поставить сверху дополнительный координатор транзакций с очень серьезными ограничениями на 25 элементов в транзакции, и, опять-таки, это не работает с глобальными таблицами.
Да, разрабатывать системы с распределенными БД сложно. Многие люди "влипают" в касандру не понимая, что все их данные спокойно влезут в SQLite или BerkleyDB -- у последней даже есть встроенная репликация еще с начала нулевых годов.
Почему я назвал Вернера манагером? Ну не почувствовал я в нем программиста-архитектора, извиняйте. Я увидел ученого-наперсточника, который пишет исследовательские работы, выбивает гранты, который имеет богатый опыт демонстрации сильных сторон и тщательного сокрытия слабых сторон, который, самое главное, умеет это продемонстрировать перед некомпетентным слушателем, вроде чиновников или нетехнических менеджеров. Не поймите меня неправильно -- это очень важный тип характера, именно потому Microsoft и Google сегодня руководят индусы. Но это не программист-архитектор.
Как бы там нибыло, эта штука для нас решила безумное количество задач и наши коллеги, очень активно запрашивали эти фичи на стороне aws.
Для нас это изменило подход к ETL, теперь только надо чтобы legacy вырезали, а так, у нас где-то 10 петабайт данных, где очень нужен read after write, в первую очередь на операциях update.
alluxio, apiary, waggledance и куча остального хлама, который используется в основных процессах.
Как бы там нибыло, эта штука для нас решила безумное количество задач и наши коллеги, очень активно запрашивали эти фичи на стороне aws.
Если вам это так нужно было, то почему вы сразу не перешли на B2, в котором read-after-write было из коробки как минимум с 2015 года?
Но мне кажется, что вы изначально использует не тот инструмент для не той задачи. Собственные сервера под 10 петабайт на Storage Pod 6.0 обойдутся порядка $1M, при этом на них можно крутить свои собственные приложения. Не говоря уже о том, что у меня есть сомнения, что вам на самом деле нужны эти 10 петабайт при том, что какой-нибудь Facebook хранит 300 петабайт.
Пинаете aws на тему увеличения партишенов в s3?
У нас это приводило к 5хх ошибкам, пока суппорт не отпинаешь.
> В таких условиях единственный способ узнать, где находится последняя версия объекта — собирать эту информацию на один или несколько каталогов.
Вы уверены, что не путаете (вероятно синхронную) внутреннюю репликацию в рамках бакета для обеспечения избыточности и (явно асинхронную) репликацию между бакетами, видимо для обеспечения геораспределённости?)
Вы уверены, что не путаете (вероятно синхронную) внутреннюю репликацию в рамках бакета для обеспечения избыточности и (явно асинхронную) репликацию между бакетами, видимо для обеспечения геораспределённости?)
Они обе асинхронные. Если бы репликация внутри региона была синхронная, как у B2, то проблемы read-after-write вообще бы не существовало. Проблема в том, что S3 изначально сохраняет объект из PUT-запроса не туда, где он будет хранится. То есть (тс-с-с, только между нами девочками) Amazon решает проблему, которую сам же себе и создал. Переусложненные задачи -- это вечная проблема энтерпрайза.
Ну а гарантии read-after-write и монотонных чтений-записей меж регионами и вовсе нет, так что при честном сравнении с ZooKeeper и Spanner, спроектированными для строгой согласованности по всему земному шарику, "строгая согласованность" у S3 существует только при взгляде под правильным углом и грамотном освещении, как то в новостях Амазона и блоге Вернера Вогельса (еще раз к слову о тому, почему я не считаю Вернера программистом-архитектором).
ну меня как-то это не убеждает. могут данные реплицироваться синхронно например (сразу писаться на несколько дисков), а метаданные в репликах БД доползать асинхронно :-) или например могли просто с переходом на консистентность просто поменять архитектуру, может там теперь цефоподобное нечто внутри? :-)
ну меня как-то это не убеждает. могут данные реплицироваться синхронно
например (сразу писаться на несколько дисков), а метаданные в репликах
БД доползать асинхронно
Зачем, если реплицировать метаданные проще, чем данные?
или например могли просто с переходом на консистентность просто поменять
архитектуру, может там теперь цефоподобное нечто внутри?
У Ceph есть очень и очень серьезная проблема с масштабируемостью чтений, поскольку в норме он читает из единственной реплики, за счет чего и обеспечивается строгая согласованность, а на другие реплики запросы чтения перенаправляются только после отказов.
И это не просто какая-то хотелка авторов Ceph -- это физические непреодолимые трудности: либо доступность и производительность, либо согласованность. При всех недостатках, выбранный Амазоном подход в типичных для S3 сценариях приводит к линейному масштабированию скорости записей и чтений при росте числа хранилищ без шардирования. А Ceph может масштабироваться только шардированием. Правда, я не вижу каких-то принципиально непреодолимых препятствий для того, чтобы Ceph мог начать читать объекты со всех реплик, а S3 начал делать простую синхронную репликацию без необходимости в замороченных роутерах-свидетелях.
Про чтение с primary правда, но там это не мешает, т.к. шардируется в разрезе PG, а PG дофига и на каждом OSD размещается их 100 штук примерно обычно, и для части он оказывается primary. Поэтому там и смысла нет читать с реплик, и там все диски утилизируются. Сделать чтение с реплик напрямую наверное как раз не получится, т.к. состоянием владеет primary, и как раз он знает, вообще откуда читать, если объект сейчас перемещается.
Метаданные реплицировать асинхронно т.к. это БД, чтобы не тормозить ее, те же листинги... а данные пишутся все равно относительно долго и там есть время сходить на другие реплики. Ну или да, почему нет такого варианта, что амазон тупо сделал синхронную репликацию таки и в метабазах S3, когда перешел на консистентность? И читает себе дальше с реплик, просто они теперь синхронные. Вроде никаким уликам это не противоречит, репликация между бакетами это другое :-)
Ну просто иначе надо организовывать какую то очередь асинхронной репликации данных, кэши вот эти извратные и т.п., неудобно как-то.
Не, может это и правда, что у амазона такое наделано, я свечку не держал. Но звучит довольно извратно
Про чтение с primary правда, но там это не мешает, т.к. шардируется в
разрезе PG, а PG дофига и на каждом OSD размещается их 100 штук примерно
обычно, и для части он оказывается primary. Поэтому там и смысла нет
читать с реплик, и там все диски утилизируются.
У меня софтина с десятками миллионов пользователей. В софтине выявилась бага, ее нужно срочно пропатчить. Я публикую в Ceph обновления, которые автоматически подхватываются клиентами -- это генерирует сотни тысяч запросов в секунду к одному файлу. И это еще не самая большая нагрузка, крупные игроки могут иметь миллионы загрузок одного файла в секунду.
Метаданные реплицировать асинхронно т.к. это БД, чтобы не тормозить ее,
те же листинги... а данные пишутся все равно относительно долго и там
есть время сходить на другие реплики.
Вот именно: данные пишут долго, метаданные -- быстро. Да, по поводу списков можно спорить, но недолго -- проблема у индексов только с персистентностью, в памяти их можно изменять очень быстро.
Ну или да, почему нет такого варианта, что амазон тупо сделал синхронную
репликацию таки и в метабазах S3, когда перешел на консистентность?
Остальные ограничения и неудобства S3 никуда не исчезли, а значит остальная реализация не менялась. Более того, у S3 весьма сложные замороченные уровни доступности-архивации, которые в том числе являются причиной для существования асинхронной репликации внутри региона. Тот же B2 вообще никуда не двигает файлы. он просто сохраняет их один раз на жесткие диски, и всё.
Ну просто иначе надо организовывать какую то очередь асинхронной репликации данных, кэши вот эти извратные и т.п., неудобно как-то.
Кэши и асинхронная репликация у них как раз были давно, они просто прикрутили к кэшам когерентность в пределах региона. Если делать PUT и GET на один сервер, то там read-after-write работал и так, проблема была актуальнадля GET с другого сервера в регионе и для любого LIST (списки тоже обновлялись асинхронно).
миллионы загрузок одного файла в секунду — это всё-таки не задача S3, кэшем каким-то надо накрыть, в том же омозоне тупо на запросах и трафике разоришься…
но так-то замечание верное — если какой-то гад будет долбить один и тот же ключ многократно — это в цефе не масштабируется.
с другой стороны — а масштабируется ли в амазоне? вот в чём вопрос. вот можно было бы по ним бахнуть какой-нибудь бенчилкой в один ключ, например, для интереса. хотя там небось могут запросы в секунду лимитироваться и тогда ни фига не поймёшь…
Хм-м-м, и то правда -- 5500 GET запросов в секунду на один префикс, а потом 503.
Ну или да, почему нет такого варианта, что амазон тупо сделал синхронную
репликацию таки и в метабазах S3, когда перешел на консистентность?
Не обратил внимание на "МЕТАданные". Да, по сути, подмножество метаданных обновляется синхронно -- именно об этом говорит конечная описанная мной модель S3. Правда, в число синхронных метаданных входит только расположение ключа, дата его помещения, и еще некоторые внутренние штуки, вроде индексов. Другое дело, что это в основном внутренние невидимые метаданные, а не те метаданные, которые клиент указал в PUT-запросе.
Скажите а у s3 теперь есть атомарный mv фолдера?
Amazon S3 — детективное расследование внутренней архитектуры