13 521
правка
Изменения
м
Нет описания правки
От себя добавлю, что та самая «балансировка нагрузки» и вообще распределение объектов — это один из наиболее базовых аспектов устройства любой системы хранения и именно он во многом определяет дальнейший вектор развития архитектуры системы. Вообще все стороджи можно поделить на классы… класса, наверное, на 3… в зависимости от применённого подхода к распределению данных. Так что на самом деле рассмотренный в докладе вопрос гораздо значительнее, чем может показаться на первый взгляд :-).
P.S: Вопрос Вадиму: А у вас есть автоматика, которая определяет, отвалившая реплика ушла совсем или ещё вернётся? Коллега мне на ухо: Есть, её зовут Женя…
== Жизнь перф инженера в Pg Pro ==
** Большие объекты нарезаются на части по 64 МБ, сначала пишутся части, в конце — индекс, ссылающийся на эти части.
** После заполнения бакет закрывается и в него больше не пишут, а только удаляют и потом переупаковывают. Процесс-переупаковщик бакетов называется bucketcompactor.
* Распределение объектов — перед каждой записью идём в statusservice и спрашиваем у него, в какой бакет писать. ** При этом бакет на запись блокируется. При удалении аналогично, тоже блокировка. После записи разблокируем и обновляем версию бакета в statusservice. Версией служит просто последнее смещение в бакете.** При отвале клиента — это мои фантазии, в докладе не было, но по-другому вроде никак — должен следовать отвал блокировки по таймауту, перевод бакета в readonly и его последующая синхронизация, что полностью эквивалентно Hadoop с его Lease Recovery.
* Репликация — клиентская, запись — кворумная.
** То есть, клиент (прокся) напрямую соединяется с несколькими серверами и пишет свои данные на каждый, и считает запись успешной при записи на 2 из 3 серверов. При неуспехе — повторная попытка в другой бакет.
А вот этот доклад сделал мой второй день конференции. И хоть докладчик и говорил «вёб» (через ё) и «рпц» вместо rps (ЭР ПЭ ЭС), очень приятно было послушать, что где-то ещё есть люди, которые могут сесть и БЫСТРО и ПРОСТО, без 200 микросервисов, что-то запилить. А то в последние годы уже как-то начал привыкать к тому, что разработка ПО в компаниях обычно как идеальный газ — занимает все ресурсы, которые на неё выделишь, и в итоге сидит человек 100 и все чем-то заняты, а баги исправляются по полгода. А фичи разрабатываются по 2 года.
К ним пришёл заказчик и сказал — мы тут писали ТЗ 8 месяцев, а вы нам это закодьте за 2. Причём заказчик был очень начитанный, ТЗ было очень подробное, там была прорисована архитектура, 100 микросервисов и всё такое прочее. Но, к счастью, заказчику ответили — да, это всё замечательно, но не за 2 месяца. ''/Микросервисы — г@вно!!! Парни, вы молодцы, что на это не пошли! Тупой монолит в 99.9% случаев гораздо лучше!/ — прим.вред./''
В итоге просто писали на Django, причём даже с jQuery. ''/ну да, тоже уже устаревшее г@но, но если умеешь — пиши на том, на чём умеешь — умеешь/ — прим.вред./'' И только самая нагруженная часть с самим «диктантом» была на React.
Кратко таймлайн разработки, который почему-то начинается с 11 недель — не совсем 2 месяцев до диктанта, ну да не суть:
Ну ок :-). «Сетевики пишут DNS».
[[Категория:КонференцииОтчёты о конференциях]]
