== Катаем гусей ==
'''Павел Левдик (Yandex Infrastructure) - — Внутри S3'''
Mover чанки ханки splitter s3meta s3db pgmeta счётчикиДоклад про Яндексовую реализацию S3. Глобально всё просто — взят уже готовый надёжный распределённый сторадж для данных, взят шардированный и реплицированный PostgreSQL, одно скрещено с другим и вот вам, пожалуйста, S3.
Неприятный паттерн возрастающие ключи листингиШардирование раньше было только в виде чанков — диапазонов имён объектов в бакете. Чтобы таскать чанки с шарда на шард — мувер, чтобы порождать новые чанки почкованием — сплиттер. И то, и то — через двухфазный коммит. Но была проблема, что в такой схеме определённые паттерны нагрузки не размазывались по всему кластеру БД. Например, если юзер всегда писал новые объекты в конец бакета — эти вставки всегда попадали в один чанк и, соответственно, шард. Или, например, если юзер сначала делал алфавитный листинг всех объектов, а потом последовательно читал их — такая нагрузка тоже в каждый момент времени попадала только в один шард БД.
Доклад про Яндексовую реализацию S3Поэтому сделали хеш-чанки (диапазоны хешей имён объектов) и такая нагрузка тоже стала размазываться. На самом делеБыл даже график, не очень хардкорно получилосьна котором это было видно наглядно — до переключения на ханки нагрузка шла постоянно то в 1 шард, про какието во 2, то в 3 и т. п., а после — равномерно во все три. То есть, все три покрашенные разными цветами линии нагрузки в разные шарды сошлись на одном уровне. Кто-то внутренние хитрости Паша особенно из зала не рассказывал. Самоепонял, наверноечто на графике изображены не листинги, интересное а обычная нагрузка (для конкурентов :Dто ли GET, то ли PUT) , и спросил, так это что же, теперь листинги грузят все шарды? По факту с этим проблем нет, так как, во-первых, запрос листинга в докладе S3 ограничен 1000 записей, во- это цифры. 120k rpsвторых, и до перехода на ханки запросы листинга часто попадали в несколько шардов — в тех случаях, когда нельзя точно сказать, что 1000 записей можно вернуть из 1 шарда, а в-третьих, с ханками число шардов, на которые размазан каждый бакет, тоже регулируется, просто оно увеличивается сразу в 2 экзабайта данныхраза.
Ещё было про счётчики и то, что они считаются через очередь. Ну ещё из интересного (для конкурентов :D) — цифры, например, 120к rps в облаке (2x за год), типичный крупный клиент > 1 ПБ и > 1 млрд объектов, и > 1000 rps. Кстати, ещё Паша не затронул тот моментупоминал, что там в PostgreSQL есть хранимки и они весьма неплохо работают. Но про это есть старый пост на хабре про реализацию самой БД: https://habr.com/ru/companies/yandex/articles/417241/
== Неудачный опенсорс от бодишопа ==