Pull to refresh

Comments 9

Хм. Прям чем-то знакомым повеяло…

Лет 6–7 назад мне в составе команды одного крупного американо-белорусского аутсорсера довелось делать сетевое файлохранилище для некоего очень большого зелёного банка. Метаданные в базе, файловое хранилище отдельно, классический CRUD с блобами по ключу. Не в стиле S3, но близко. К счастью, масштаб был не на дофигаллиарды блобов, а всего лишь на миллионы, так что БД, по условиям заказчика — DB2 (та ещё гадость) — как-то без шардирования справлялась. Oracle на тестах вела себя получше, конечно, но не разрешили…

С другой стороны, метаданные тоже бывают всякие, в том проекте помимо имени требовалось прицеплять к каждому блобу аж произвольный словарь оных, и обеспечивать поиск блоба по значению любого из полей метаданных, или даже по более сложному запросу. Не помню уж, что конкретно мы там мутили с индексами, но проблемы были.

Где-то у меня даже лекция-постмортем валяется о том, как подобные файлохранилища проектируются, — взгляд с чуточку более высокого уровня, чем данная статья, — могу попробовать раскопать, если кому-то это покажется интересным.
Обязательно раскопать!
Ок, попробую оформить в статью. Но быстро не обещаю, ближайшие несколько выходных у меня заняты.
Интереснейшая статья неумехи с высш(ейш)им образованием.

Что называется, диплом этому парню дали за милые глаза. Вполне возможно, подведенные косметикой.

Для затравки ( дальше, чую серцем, будет ишшо теплее ) — цитата — Как происходит удаление? Прокси при удалении напрямую со storage не работает, так как тут трудно координировать базу и storage, поэтому он просто идет в БД, говорит ей, что этот объект удален, там объект перемещается в очередь на удаление, и потом в фоновом режиме специально обученный профессионал-робот забирает эти ключи, удаляет их из storage и из базы. Тут все тоже достаточно просто.
— конец цитаты — А теперь, дети, кто откроет руководство по формату файлов средненькой СУБД.

Итак, Ванечка, что там говорится сначала
— Ванечка — Сначала была системная страница, разграничивающая системные ячейки зарезервированного блока запоминающего устройства ( размером в 8192 байта, из которых 16 отданы для адреса следующей странички, а ещё 16 отданы для адреса самой себя, поскольку это якорь ).
— Петечка, а что дальше?
— Петечка — ( немного бодрее ) дальше идет блок системных страниц, разграничивающих уже странички запоминающие текст ( цифровое карго ) данных
— Гришенька, а что ещё дальше
— Гришенька — как что, Яков Исаевич, вы же нам вчера только все уши прожужжали, что дальше идет целый суперблок этих самых страничек текста?! Вы что, риторические вопросы задаете.
— и тут детей прорвало.

И здесь, к унынию Яндекса и его незадачливых выпускников МГУ и прочих ВУЗ-ов, которые по праву считаются источником неисчерпаемого богатства знаний приходит понимание, что вместо того, чтобы построить свою собственную базу, они построили, с огромными издержками в ЗВР ( поскольку быстрые запоминающие устройства продаются только за валюту ) каталог СУБД сверху каталога СУБД, то есть затраты на его хранение и содержание выше чем нормальной СУБД, которую четыре нормальных студента ПТУ пишут за пол — года, по экспоненте выше.

Вы что господа, нарочно профессионалов провоцируете громить Ваши статьи?

Ну да… про то самое удаление. Оно во всех многопользовательских СУБД выполняется отдельной службой, после того как запись помечается в системных страничках, как удаленная. Но без затрат на выполнение SQL запроса, языка бизнес запросов, каждый и которых изменяется единицами или больше в валютных эквивалентах.

Так ведь, ребята, можно вообще, провода лаборатории через Луну закрутить, и сказать, что это в память о великих космонавтах страны, где на своих не скупятся.

На самом деле "многофазное" удаление это очень хорошая практика в любой системе хранения. Основной её плюс в том, что она позволяет легко "откатить" состояние базы данных на уровне приложения без танцев с бинлогами/бекапами/снапшотами/логамибубном.


Двухшаговое удаление ещё упрощает написание verifier'ов которые следят за нарушениями соглашений "модели данных", например о том что данные которые были "удалены" в одной базе всё ещё имеют живые ссылки в какой-либо другой базе. У нас так регулярно находятся проблемы в процедуре подчистки базы от старых ревизий файлов, не потому что она бажная, а потому что мир вокруг неё меняется.


ПС. Вау! У кого-то серьёзный батхёрт на тему высшего образования. Ну и уровней абстракций походу тоже.

За деревьями леса не увидел. Батхерт по поводу неоправданных и необратимых / неокупаемых затрат, на устройства, которые принесли 0 инноваций в копилку ПО страны.

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

Весьма практическая статья, спасибо.


Я не фанат SQL, поэтому если бы я проектировал эту систему, то спрятал бы S3DB за API и сделал бы всю коммуникацию RPC-based (у нас внутри gRPC, у FB Thrift) ala services.
Meta бы делал на Zookeeper/etcd, чтобы Proxy могли подписываться на изменения "топологии". S3DB "сервис" бы в случае ошибки маршрутизации просто бы говорил, что proxy ошиблась и ей нужно получить новую таблицу у Meta. Что же использует S3DB для хранения не так важно, это может быть Postgres/MySQL/RocksDB/etc.


Ну и да, если бы это делалось в Dropbox, то полный S3 API мы бы наверное не поддерживали, а в замен сделали бы свой S3-подобный API. Описали бы протобафы, а код для клиентов под все языки сгенерился бы автоматом (aka codegen).


Disclaimer: в своё время я работал над Elliptics: делал из eblob LSM и писал первые версии dnet_recovery.

Хотелось бы чуть больше информации по эксплуатации этой системы.


По структурной целостности:


  • Как бекапите метаданные Андрей Бородин рассказывал в лекции "Разгоняем бэкап". Было бы интересно услышать больше про то как эти бекапы верифицируются. В QnA секции прошлись по этому немного, но только с точки зрения физической структуры (checksum'ы и index'ы), а не логической — то что бекап действительно является репликой существующей базы и способен подключиться к кластеру как слейв.
  • Какие verifier'ы вы запускаете на данных, например, как вы проверяете что реплики не разошлись, что данные что были записаны всё ещё доступны и тд и тп? Shameless plug: у нас кажется верификаций больше чем кода самого приложения.

По доступности:


  • Что за система отвечает за замену умерающих/мёртвых машин. Особенно интересен случай мееедленно умирающей машины, который очень сложно отличить от перегрева шарда.
  • Как боритесь с горячими шардами по IOPS/QPS?

Ну и около-админские вещи: как вы безопасно деплоите код/ОС/прошивки/железо на кластер, как мониторите всю систему, итд итп

Sign up to leave a comment.