#common #highload
Сегодня три небольшие статьи. Без докладов. Будем считать это небольшим отдыхом для вас, т.к. скоро хочу накидать чего-то более крупного.
0. [article] Taking a Look at Compression Algorithms.
Чувак рассказывает базу про сжатие, иногда с некоторыми техническими деталями. Если вы, как и я, не шарите, статья зайдёт.
1. [article] SQL as API.
Чувак рассказывает, как правильно юзать SQL в вашем API, чтобы не было никаких рисков и возможностей помереть. Кейс специфичный конечно и требует чуть больше вложений, чем может показаться, но вроде выглядит адекватно.
2. [article] Don't make these feature flag mistakes.
Автор рассказывает про потенциальные проблемы, связанные с использованием feature flag'ов, и их решения. Среди прочего есть маленькая история про то, как компания чуть не обанкротилась из-за проблем с этим инструментом. Но, что важно, в конце напоминает, что полностью отказываться от этого инструмента нельзя, т.к. он всё же жутко полезный.
Сегодня три небольшие статьи. Без докладов. Будем считать это небольшим отдыхом для вас, т.к. скоро хочу накидать чего-то более крупного.
0. [article] Taking a Look at Compression Algorithms.
Чувак рассказывает базу про сжатие, иногда с некоторыми техническими деталями. Если вы, как и я, не шарите, статья зайдёт.
1. [article] SQL as API.
Чувак рассказывает, как правильно юзать SQL в вашем API, чтобы не было никаких рисков и возможностей помереть. Кейс специфичный конечно и требует чуть больше вложений, чем может показаться, но вроде выглядит адекватно.
2. [article] Don't make these feature flag mistakes.
Автор рассказывает про потенциальные проблемы, связанные с использованием feature flag'ов, и их решения. Среди прочего есть маленькая история про то, как компания чуть не обанкротилась из-за проблем с этим инструментом. Но, что важно, в конце напоминает, что полностью отказываться от этого инструмента нельзя, т.к. он всё же жутко полезный.
👍8❤2
#common #highload
Иногда я замахиваюсь на что-то, что не могу скушать за один присест. Как сейчас. Я хотел просто написать небольшой постик про базу CRDT, а когда пошёл вникать, понял, что базово не получится. Получится скорее душно; придётся потратить больше времени, чем я готов; а чтобы нормально разобраться и объяснить, по-хорошему бы что-нибудь сесть покодить. Потому вместо готового текста сегодня сборка материалов по одной теме (я видел у людей, так делают).
Что впитать по CRDT.
На всякий случай я дам вам критерий, который поможет вам отсеять душные тексты от дворового контента (если вы любитель читать формальные статьи, то скипайте этот абзац): если в статье про CRDT вы встречаете слово "полурешётка", то закрывайте её. Вероятно это очередная статья на хабре, в которой формализм есть только для потешения эго автора. Всё, что нам нужно помнить про требования к свойствам операций для CRDT, -- это идемпотентность и коммутативность. Из них следует, что если у вас есть одинаковые множества операций над объектами (в любом порядке), то и стейты объектов будут одинаковыми. Больше пацанам и дамам ничего знать не надо.
А теперь ссылочки.
[*articles] Можно начать с нескольких статей Matthew Weidner:
- Introduction
- Semantic Techniques
- Algorithmic Techniques
- Further Topics
Они немного душноватые, но если посидеть и подумать, а не смотреть тикток параллельно с чтением, можно что-нибудь понять.
[*articles] Если у вас много-много времени, то можно почитать 12 статей от Bartosz Sypytkowski. Каждая из них поменьше, так что может пойдёт легче.
Если прочитаете и то, и это, будете совсем большими молодцами и, много всего поймёте.
[*talk] Или может вам больше нравится видеоформат, так что можете послушать ликбез по основным структурам данных в CRDT концепции: CRDT: Datatype for the Apocalypse. Правда сумейте вовремя остановиться, а то с какого-то момента начинаются Elixir-специфичные вещи, а мы всё-таки с вами на C++ пишем.
[talk] Теперь слушаем рассказал Martin Kleppman: CRDTs and the Quest for Distributed Consistency. Тут он рассказывает и про Operational Transformation (OT), и про CRDT, и про очень важный в этой сфере Automerge. Есть много примеров, которые сильно качают понималку.
[*talk] Дальше можно посмотреть старенький доклад про зачатки Google Docs и увидеть (если внимательно присмотреться) некоторые проблемы OT. Примерно так гуглодоки сейчас и реализованы.
[*article] Ну и тут вы можете почитать про то, как потенциально могут работать Google Sheets: Conflict-free Replicated Spread Sheets.
Дальше можно посмотреть отличный доклад того же Martin Kleppman: CRDTs: The Hard Parts. Тут вы узнаете, почему из "Hello Alice!" и "Hello Charlie!" может получится "Hello Al Ciharcliee!", про [открытые] проблемы перемещения элементов/символов/поддеревьев.
[*article] Интересно, что в докладе выше Kleppman говорит, что у LSeq есть проблемы, т.к. этот подход interleaving. А вот Bartosz Sypytkowski писал про non-interleaving версию. Что-то там проапдейтил, лис.
[*article] Опять же в докладе Kleppman рассказывал про проблемы оверхеда CRDT. И это то, из-за чего CRDT иногда недолюбливают. Тут статья оптимизацию частных случаев: Making CRDTs 98% More Efficient.
[*article] Тут есть очень прикольная (и жирная) статья про то, как в каком-то Loro реализовывали свой очереднярский CRDT алгоритм для текста. Понравилось, потому что в начале есть интерактивная штука потыкаться и очень много букав. Прям фундаментально тему осветили.
[talk] Ещё есть вот такой несложный докладик про то, как работает delta -- коллаборативный сервис для ведения заметок в Яндексе. Я вот им прям каждый день пользуюсь и очень довольный.
[*site] И если вдруг вам не хватило контента, идите на crdt.tech. Там ещё тыща тыща постов, докладов и настоящих статей.
Что-то люди напридумали себе проблем и сидят их решают. Коллаборативное редактирование какое-то. Консенсус. Раньше вот угольком по очереди на камне мамонтов рисовали и всё норм было. Чего завелись.
Иногда я замахиваюсь на что-то, что не могу скушать за один присест. Как сейчас. Я хотел просто написать небольшой постик про базу CRDT, а когда пошёл вникать, понял, что базово не получится. Получится скорее душно; придётся потратить больше времени, чем я готов; а чтобы нормально разобраться и объяснить, по-хорошему бы что-нибудь сесть покодить. Потому вместо готового текста сегодня сборка материалов по одной теме (я видел у людей, так делают).
Материалы, помеченные звёздочками, скипабельны, но могут помочь в более глубоком понимании.
Что впитать по CRDT.
На всякий случай я дам вам критерий, который поможет вам отсеять душные тексты от дворового контента (если вы любитель читать формальные статьи, то скипайте этот абзац): если в статье про CRDT вы встречаете слово "полурешётка", то закрывайте её. Вероятно это очередная статья на хабре, в которой формализм есть только для потешения эго автора. Всё, что нам нужно помнить про требования к свойствам операций для CRDT, -- это идемпотентность и коммутативность. Из них следует, что если у вас есть одинаковые множества операций над объектами (в любом порядке), то и стейты объектов будут одинаковыми. Больше пацанам и дамам ничего знать не надо.
А теперь ссылочки.
[*articles] Можно начать с нескольких статей Matthew Weidner:
- Introduction
- Semantic Techniques
- Algorithmic Techniques
- Further Topics
Они немного душноватые, но если посидеть и подумать, а не смотреть тикток параллельно с чтением, можно что-нибудь понять.
[*articles] Если у вас много-много времени, то можно почитать 12 статей от Bartosz Sypytkowski. Каждая из них поменьше, так что может пойдёт легче.
Если прочитаете и то, и это, будете совсем большими молодцами и, много всего поймёте.
[*talk] Или может вам больше нравится видеоформат, так что можете послушать ликбез по основным структурам данных в CRDT концепции: CRDT: Datatype for the Apocalypse. Правда сумейте вовремя остановиться, а то с какого-то момента начинаются Elixir-специфичные вещи, а мы всё-таки с вами на C++ пишем.
[talk] Теперь слушаем рассказал Martin Kleppman: CRDTs and the Quest for Distributed Consistency. Тут он рассказывает и про Operational Transformation (OT), и про CRDT, и про очень важный в этой сфере Automerge. Есть много примеров, которые сильно качают понималку.
[*talk] Дальше можно посмотреть старенький доклад про зачатки Google Docs и увидеть (если внимательно присмотреться) некоторые проблемы OT. Примерно так гуглодоки сейчас и реализованы.
[*article] Ну и тут вы можете почитать про то, как потенциально могут работать Google Sheets: Conflict-free Replicated Spread Sheets.
Дальше можно посмотреть отличный доклад того же Martin Kleppman: CRDTs: The Hard Parts. Тут вы узнаете, почему из "Hello Alice!" и "Hello Charlie!" может получится "Hello Al Ciharcliee!", про [открытые] проблемы перемещения элементов/символов/поддеревьев.
[*article] Интересно, что в докладе выше Kleppman говорит, что у LSeq есть проблемы, т.к. этот подход interleaving. А вот Bartosz Sypytkowski писал про non-interleaving версию. Что-то там проапдейтил, лис.
[*article] Опять же в докладе Kleppman рассказывал про проблемы оверхеда CRDT. И это то, из-за чего CRDT иногда недолюбливают. Тут статья оптимизацию частных случаев: Making CRDTs 98% More Efficient.
[*article] Тут есть очень прикольная (и жирная) статья про то, как в каком-то Loro реализовывали свой очереднярский CRDT алгоритм для текста. Понравилось, потому что в начале есть интерактивная штука потыкаться и очень много букав. Прям фундаментально тему осветили.
[talk] Ещё есть вот такой несложный докладик про то, как работает delta -- коллаборативный сервис для ведения заметок в Яндексе. Я вот им прям каждый день пользуюсь и очень довольный.
[*site] И если вдруг вам не хватило контента, идите на crdt.tech. Там ещё тыща тыща постов, докладов и настоящих статей.
Что-то люди напридумали себе проблем и сидят их решают. Коллаборативное редактирование какое-то. Консенсус. Раньше вот угольком по очереди на камне мамонтов рисовали и всё норм было. Чего завелись.
👍10🔥5❤3
#highload #cpp #common
0. У меня на днях встретилась абсолютно простая задача (прям как на собесе, а вы говорите, что не нужны эти алгоритмы в жизни): в векторе чисел переместить все нули в конец. Недолго думая я делаю
И для примера
получаю
Где-то есть баг.
Очевидно, что баг был в моей интерпретации алгоритма. Вот как выглядит стандартное использование
В голове я строю последовательность происходящего:
- все нули ушли в конец
- получаю итератор на первый нуль
- удаляю все нули.
И в первом пункте уже ошибка. Ведь нули не ушли в конец. Наоборот, в начало ушли все не нули. Что там в конце, меняебать
То есть мы имеем на текущий C++20-й момент:
- удаляем элементы мы с
- если я хочу все нули в конец, то мне нужен
-
1. [talk] Как развивалось прогнозирование в Яндекс Погоде.
Коллега год назад рассказывал про то, как в Погоде предсказывают, неожиданно, погоду. Не то чтобы сложный технически доклад, но интересный с точки зрения незнакомого продукта и базовых деталей.
2. [article] Accelerating LinkedIn’s My Network tab by reducing latency and improving UX.
Суть статьи в названии.
У нас есть какая-то похожая задача, потому было интересно почитать. Жаль только, что они всё же различаются достаточно, чтобы не суметь перенять подход.
3. [article] Your business value.
Очень хорошая статья, которая в каждом предложении напоминает про то, зачем профессия программиста существует. Она, так сказать, постоянно cycle on a subject о вашей личной полезности для бизнеса и разбирает кейсы роста/увольнений в зависимости от разных факторов.
Будьте профитными.
0. У меня на днях встретилась абсолютно простая задача (прям как на собесе, а вы говорите, что не нужны эти алгоритмы в жизни): в векторе чисел переместить все нули в конец. Недолго думая я делаю
std::remove(vec.begin(), vec.end(), 0);
И для примера
vec = {1, 4, 0, 2, 0, 0}
получаю
{1, 4, 2, 2, 0, 0}
Где-то есть баг.
Очевидно, что баг был в моей интерпретации алгоритма. Вот как выглядит стандартное использование
std::remove до C++20:
vec.erase(std::remove(vec.begin(), vec.end(), 0), v.end());
В голове я строю последовательность происходящего:
- все нули ушли в конец
- получаю итератор на первый нуль
- удаляю все нули.
И в первом пункте уже ошибка. Ведь нули не ушли в конец. Наоборот, в начало ушли все не нули. Что там в конце, меня
То есть мы имеем на текущий C++20-й момент:
- удаляем элементы мы с
std::erase/std::erase_if- если я хочу все нули в конец, то мне нужен
std::partition-
std::remove/std::remove_if нужен только ради обратной совместимости, т.к. никакой уникальной задачи он уже не решает. Жаль братка. 1. [talk] Как развивалось прогнозирование в Яндекс Погоде.
Коллега год назад рассказывал про то, как в Погоде предсказывают, неожиданно, погоду. Не то чтобы сложный технически доклад, но интересный с точки зрения незнакомого продукта и базовых деталей.
2. [article] Accelerating LinkedIn’s My Network tab by reducing latency and improving UX.
Суть статьи в названии.
У нас есть какая-то похожая задача, потому было интересно почитать. Жаль только, что они всё же различаются достаточно, чтобы не суметь перенять подход.
3. [article] Your business value.
Очень хорошая статья, которая в каждом предложении напоминает про то, зачем профессия программиста существует. Она, так сказать, постоянно cycle on a subject о вашей личной полезности для бизнеса и разбирает кейсы роста/увольнений в зависимости от разных факторов.
Будьте профитными.
❤12👍3🔥1🤔1
#cpp #highload #common
0. [talk] The Beman Project: Bringing C++ Standard Libraries to the Next Level.
Докладчик рассказывает про bemanproject, который должен помочь во внедрении предложений в стандарт через получение раннего фидбека о потенциальной имплементации пейперов. Если точнее, то сначала про мотивацию, потом про принципы работы и в конце накидывает примерчиков. В конце участники проекта коллективно отвечают на вопросы о проекте.
Имхо очень естественное и красивое дополнение к процессу принятия пейперов. Выглядит ну очень вкусно. Интересно только, кто осмелится затаскивать к себе либу, чтобы тестить потенциальные новинки пораньше и репортить фидбек, ведь это тянет за собой постоянное обновление либы, ресурс на переход на стандартные средства и потенциальное выпиливание outdated кода, который принят не был.
Хочется посмотреть на это через пару лет.
1. [article] The billion docs JSON Challenge: ClickHouse vs. MongoDB, Elasticsearch, and more.
Чуваки из ClickHouse сделали бенчмарк, в котором обрабатывали 5 агрегационных запросов на датасете из 1 млрд реальных JSON. Сравнение было с MongoDB, Elasticsearch, DuckDB и PostgreSQL (думаю, вы уже поняли, кто показал себя лучше всего).
Во-первых, имхо очень хороший пример того, как надо бенчмарки описывать. Во-вторых, я не прям уверен, что сравнение всё-таки корректное, т.к. все рассматриваемые бдшки (кроме DuckDB, это хз что такое) концентрируются на не совсем тех же задачах (в моей голове), так что могут спокойно на конкретных сценариях проигрывать. И это нормально.
В-третьих, тем удивительнее, что эластик не пальцем деланый и результаты по перфу на этой задаче у него уходят недалеко. Новое открытие для меня.
2. [article] My DOs and DON’Ts of Software Architecture.
Вот вроде почитаешь статью и подумаешь, что всё очевидно. И непонятно зачем на это время тратил(-а).
На практике, правда, всё не так clear, и иногда распознать базовые случаи, в которые стоит поступить ровно так, как написано, сложно. Или иногда сложно понять, а как правильно сейчас поступить.
В моей голове эти пунктики очень хороши для вашего роста, если вы хотите расти быстро. Но ещё важно не забывать, что иногда надо не расти, а учиться. И что эти вещи не всегда в моменте совместимы. Вдолгую да, но не всегда сейчас.
0. [talk] The Beman Project: Bringing C++ Standard Libraries to the Next Level.
Докладчик рассказывает про bemanproject, который должен помочь во внедрении предложений в стандарт через получение раннего фидбека о потенциальной имплементации пейперов. Если точнее, то сначала про мотивацию, потом про принципы работы и в конце накидывает примерчиков. В конце участники проекта коллективно отвечают на вопросы о проекте.
Имхо очень естественное и красивое дополнение к процессу принятия пейперов. Выглядит ну очень вкусно. Интересно только, кто осмелится затаскивать к себе либу, чтобы тестить потенциальные новинки пораньше и репортить фидбек, ведь это тянет за собой постоянное обновление либы, ресурс на переход на стандартные средства и потенциальное выпиливание outdated кода, который принят не был.
Хочется посмотреть на это через пару лет.
1. [article] The billion docs JSON Challenge: ClickHouse vs. MongoDB, Elasticsearch, and more.
Чуваки из ClickHouse сделали бенчмарк, в котором обрабатывали 5 агрегационных запросов на датасете из 1 млрд реальных JSON. Сравнение было с MongoDB, Elasticsearch, DuckDB и PostgreSQL (думаю, вы уже поняли, кто показал себя лучше всего).
Во-первых, имхо очень хороший пример того, как надо бенчмарки описывать. Во-вторых, я не прям уверен, что сравнение всё-таки корректное, т.к. все рассматриваемые бдшки (кроме DuckDB, это хз что такое) концентрируются на не совсем тех же задачах (в моей голове), так что могут спокойно на конкретных сценариях проигрывать. И это нормально.
В-третьих, тем удивительнее, что эластик не пальцем деланый и результаты по перфу на этой задаче у него уходят недалеко. Новое открытие для меня.
2. [article] My DOs and DON’Ts of Software Architecture.
Вот вроде почитаешь статью и подумаешь, что всё очевидно. И непонятно зачем на это время тратил(-а).
На практике, правда, всё не так clear, и иногда распознать базовые случаи, в которые стоит поступить ровно так, как написано, сложно. Или иногда сложно понять, а как правильно сейчас поступить.
В моей голове эти пунктики очень хороши для вашего роста, если вы хотите расти быстро. Но ещё важно не забывать, что иногда надо не расти, а учиться. И что эти вещи не всегда в моменте совместимы. Вдолгую да, но не всегда сейчас.
🤔6👍3
#cpp #python #highload
0. [fact] В С++ можно брать указатели на goto метки.
godbolt.
ChatGpt говорит, что это только у GCC, но с Clang тоже компилится.
Можно, но не нужно❌
1. [talk] Why Is My C++ Build So Slow? Compilation Profiling and Visualization.
Samuel Приветт рассказывает про проблему медленной компиляции, как её детектить и что с ней делать.
Интересно как-нибудь потыкаться, насколько сложно упомянутые им инструменты притягиваются в большие промышленные проекты вроде нашего. Может получится пост!
2. [article] Python's new t-strings.
Одной из (насколько я понял) крутейших фичей в python 3.14 являются t-strings. В статье кратко про то, что это такое и зачем может быть нужно.
Я пока не прям въехал с точки зрения недомашних примеров. Верю, что опыт всё порешает. Если вам ждать не хочется, вот репозиторий из статьи с большим кол-вом примеров.
Рядышком докину статью про то, какие фичи в новом питоне появляются. Или можете официальную документацию посмотреть.
3. [article] Improving Pinterest Search Relevance Using Large Language Models.
Чувак из Pinterest рассказывают про то, как применяют LLM для улучшения качества поиска. Если кратко, то
- на основе разметки выдачи на релевантность людьми учат огромную тяжёлую LLM предсказывать релевантность выдачи
- на основе тяжёлой LLM учат student LLM, чтобы использовать её в онлайне (т.к. она легче и инфересится быстрее)
Ну и всё. Там они ещё порассказывали, какие LLM использовали и какие результаты получились в их экспериментах.
Я не поклонник LLM во всех дырах. И потому статья местами воспринимается как что-то, что написали, потому что надо было показать, какие все передовые. Но может я скептик.
0. [fact] В С++ можно брать указатели на goto метки.
void computed_goto_example(int state) {
static void* dispatch[] = { &&State0, &&State1, &&State2 };
goto *dispatch[state];
State0:
//
return;
State1:
//
return;
State2:
//
return;
}
godbolt.
ChatGpt говорит, что это только у GCC, но с Clang тоже компилится.
Можно, но не нужно
1. [talk] Why Is My C++ Build So Slow? Compilation Profiling and Visualization.
Samuel Приветт рассказывает про проблему медленной компиляции, как её детектить и что с ней делать.
Интересно как-нибудь потыкаться, насколько сложно упомянутые им инструменты притягиваются в большие промышленные проекты вроде нашего. Может получится пост!
2. [article] Python's new t-strings.
Одной из (насколько я понял) крутейших фичей в python 3.14 являются t-strings. В статье кратко про то, что это такое и зачем может быть нужно.
Я пока не прям въехал с точки зрения недомашних примеров. Верю, что опыт всё порешает. Если вам ждать не хочется, вот репозиторий из статьи с большим кол-вом примеров.
Рядышком докину статью про то, какие фичи в новом питоне появляются. Или можете официальную документацию посмотреть.
Если вы посмотрите в официальную доку, найдёте секцию под названием And now for something completely different. В ней есть какой-то факт про число pi. Ссылка, которую я вам оставил, является последней актуальной версией это странички и заканчивается на a7. Можно посмотреть предыдущие версии страницы, подекрементив чиселко и почитать другие факты про pi. Прикольно.
3. [article] Improving Pinterest Search Relevance Using Large Language Models.
Чувак из Pinterest рассказывают про то, как применяют LLM для улучшения качества поиска. Если кратко, то
- на основе разметки выдачи на релевантность людьми учат огромную тяжёлую LLM предсказывать релевантность выдачи
- на основе тяжёлой LLM учат student LLM, чтобы использовать её в онлайне (т.к. она легче и инфересится быстрее)
Ну и всё. Там они ещё порассказывали, какие LLM использовали и какие результаты получились в их экспериментах.
Я не поклонник LLM во всех дырах. И потому статья местами воспринимается как что-то, что написали, потому что надо было показать, какие все передовые. Но может я скептик.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🤯5🔥2
#books #highload
Женя иногда пишет обзоры на книги. Хочу быть как Женя. Правда для этого книги надо читать. Но я смирился.
Искусство планирования мощностей. Джон Оллспоу. (2011 г.)
Хотелось мне как-то почитать чего-то такого, что бы мне рассказало, как думать про большие объёмы нагрузок (больше, чем у меня есть). Как учитывать неявный рост ресурсов при развитии продукта. Где взять бабки на всё это и как сэкономить, чтобы не отдавать абстрактному Amazon половину прибыли. Нашёл вот такую книгу от одного из работников Flickr (на тот момент) про планирование мощностей.
Главы в книге примерно такие:
1️⃣ Цели, проблемы и процессы планирования мощностей.
Тут рассматриваются базовые вопросы, связанные с темой: зачем думать про планирование мощностей, какие сложности возникают в процессе, почему это должен быть постоянный, а не разовый процесс. Своего рода глава-предисловаие.
2️⃣ Определение целей.
Во второй главе обсуждаются разные точки зрения на вашу систему: со стороны разработчика, бизнеса или юзера. И как планирование мощностей влияет на сервисоощущение каждой из сторон. Тобишь зачем вообще это всё надо всем, а не только кому-то одному. Между делом упоминаются концепции девяток и базово рассказывается про масштабирование.
3️⃣ Сбор данных: как измеряются мощности.
Это глава освещает вопрос сбора метрик. Призывает подумать о максимально широком сборе данных о вашей системе, дабы вы могли понимать её состояние как можно более чётко. Заодно задевает некоторые конкретные инструменты мониторинга (судя по всему, уже не очень живые, т.к. я встретил их впервые в этой книге). Далее нам подсказывают, что надо найти зависимость от нагрузки на использование ресурсов и так определить, сколько ещё мы можем держать. Приправлена несколькими историями из практики автора во Flickr.
4️⃣ Прогнозирование.
Далее обсуждается вопрос прогнозирования потребления ресурсов, исходя из исторических данных. Предлагается это делать довольно просто: собрать набор исторических данных за какой-то период и построить аппроксимацию в Excel. Заодно поясняют, почему данных не должно быть мало. Ну и пруфают это ещё одним кейсом из практики.
5️⃣ Развертывание.
В последней главе рассказывают про то, как деплоить ваши сервисы. В целом ничего такого.
🅰️ Приложения.
В целом книга скорее оставила ощущение потраченного времени. Нет, не прям плохо. Истории из практики были довольно интересными. Местами поучительными. В голове закрепился очевидный, но важный принцип: "Планировать ресурсы, не надеясь на потенциальную оптимизацию". В Приложении Б есть пару страничек про жутко интересную сейчас для меня тему функциональной деградации. Но возможно я просто ожидал чего-то более масштабного, чтобы про планирование на 2 года, а не 3 недели. Чтобы про миллионы долларов, а не отсутствие экономических факторов. Чтобы не про Excel.
Возможно, поработать пару лет в похожей ситуации будет гораздо полезнее. Но если опыта такого у вас нет, книга может дать базовые понятия.
500 RPS из 1000.
Женя иногда пишет обзоры на книги. Хочу быть как Женя. Правда для этого книги надо читать. Но я смирился.
Искусство планирования мощностей. Джон Оллспоу. (2011 г.)
Хотелось мне как-то почитать чего-то такого, что бы мне рассказало, как думать про большие объёмы нагрузок (больше, чем у меня есть). Как учитывать неявный рост ресурсов при развитии продукта. Где взять бабки на всё это и как сэкономить, чтобы не отдавать абстрактному Amazon половину прибыли. Нашёл вот такую книгу от одного из работников Flickr (на тот момент) про планирование мощностей.
Главы в книге примерно такие:
1️⃣ Цели, проблемы и процессы планирования мощностей.
Тут рассматриваются базовые вопросы, связанные с темой: зачем думать про планирование мощностей, какие сложности возникают в процессе, почему это должен быть постоянный, а не разовый процесс. Своего рода глава-предисловаие.
2️⃣ Определение целей.
Во второй главе обсуждаются разные точки зрения на вашу систему: со стороны разработчика, бизнеса или юзера. И как планирование мощностей влияет на сервисоощущение каждой из сторон. Тобишь зачем вообще это всё надо всем, а не только кому-то одному. Между делом упоминаются концепции девяток и базово рассказывается про масштабирование.
3️⃣ Сбор данных: как измеряются мощности.
Это глава освещает вопрос сбора метрик. Призывает подумать о максимально широком сборе данных о вашей системе, дабы вы могли понимать её состояние как можно более чётко. Заодно задевает некоторые конкретные инструменты мониторинга (судя по всему, уже не очень живые, т.к. я встретил их впервые в этой книге). Далее нам подсказывают, что надо найти зависимость от нагрузки на использование ресурсов и так определить, сколько ещё мы можем держать. Приправлена несколькими историями из практики автора во Flickr.
4️⃣ Прогнозирование.
Далее обсуждается вопрос прогнозирования потребления ресурсов, исходя из исторических данных. Предлагается это делать довольно просто: собрать набор исторических данных за какой-то период и построить аппроксимацию в Excel. Заодно поясняют, почему данных не должно быть мало. Ну и пруфают это ещё одним кейсом из практики.
5️⃣ Развертывание.
В последней главе рассказывают про то, как деплоить ваши сервисы. В целом ничего такого.
🅰️ Приложения.
В целом книга скорее оставила ощущение потраченного времени. Нет, не прям плохо. Истории из практики были довольно интересными. Местами поучительными. В голове закрепился очевидный, но важный принцип: "Планировать ресурсы, не надеясь на потенциальную оптимизацию". В Приложении Б есть пару страничек про жутко интересную сейчас для меня тему функциональной деградации. Но возможно я просто ожидал чего-то более масштабного, чтобы про планирование на 2 года, а не 3 недели. Чтобы про миллионы долларов, а не отсутствие экономических факторов. Чтобы не про Excel.
Возможно, поработать пару лет в похожей ситуации будет гораздо полезнее. Но если опыта такого у вас нет, книга может дать базовые понятия.
500 RPS из 1000.
👍8
#highload
Я звал вас на Яндекс Day&Night, А теперь предлагаю посмотреть замечательные доклады.
1. [talk] Не «Кафкой» единой. Серёжа Бунатян.
Коллега из техплатформы Городских сервисов рассказывает про то, что такое STQ. Порядок примерно такой:
- мотивация
- некоторые дизайн решения
- почему это очень удобно для обычного разработчика (мой коммент: видя, как часто STQ пользуются для самых разных задач, даже иногда там, где не надо, просто потому что это очень удобно и просто, сложно с этим утверждением не согласиться).
2. [talk] Где бы заказать? Ищем доступные рестораны в Яндекс Еде. Серёжа Синягин.
В прошлом году я писал про геоиндексинг, а тут коллега из Еды рассказывает про то, как устроен поиск доступных ресторанов. Практический кейс! План примерно такой:
- постановка задача
- геохеш
- Uber H3
- R-Tree и его применение к решению задачи.
3. [talk] Вы неправильно делаете нагрузочное тестирование. Андрей Матвеев.
Коллега из Такси рассказывает про то, что не так с "базовым" нагрузочным тестированием, как делать его правильно и какие положительные артефакты можно от этого получить.
4. [talk] Платформа для разработчика как продукт. Рома Елизаров.
Ещё один коллега из техплатформы (да, тот самый) рассказывает процессно-менеджерский доклад про то, как работать над инфрой как над продуктом.
5. [talk] Поиск в Яндекс Маркете: как делать всё и сразу. Даня Яковлев.
Коллега из Маркета рассказывает про то, как в поиске пытаются сделать счастливыми и пользователей, и продавцов, и инфру. По пути задевая базовую базу поиска, поясняя, как все задачи сводятся к одной и той же задаче, и сверху добивая историей про шардирование поиска.
Красота блин!
Я звал вас на Яндекс Day&Night, А теперь предлагаю посмотреть замечательные доклады.
1. [talk] Не «Кафкой» единой. Серёжа Бунатян.
Коллега из техплатформы Городских сервисов рассказывает про то, что такое STQ. Порядок примерно такой:
- мотивация
- некоторые дизайн решения
- почему это очень удобно для обычного разработчика (мой коммент: видя, как часто STQ пользуются для самых разных задач, даже иногда там, где не надо, просто потому что это очень удобно и просто, сложно с этим утверждением не согласиться).
2. [talk] Где бы заказать? Ищем доступные рестораны в Яндекс Еде. Серёжа Синягин.
В прошлом году я писал про геоиндексинг, а тут коллега из Еды рассказывает про то, как устроен поиск доступных ресторанов. Практический кейс! План примерно такой:
- постановка задача
- геохеш
- Uber H3
- R-Tree и его применение к решению задачи.
3. [talk] Вы неправильно делаете нагрузочное тестирование. Андрей Матвеев.
Коллега из Такси рассказывает про то, что не так с "базовым" нагрузочным тестированием, как делать его правильно и какие положительные артефакты можно от этого получить.
4. [talk] Платформа для разработчика как продукт. Рома Елизаров.
Ещё один коллега из техплатформы (да, тот самый) рассказывает процессно-менеджерский доклад про то, как работать над инфрой как над продуктом.
5. [talk] Поиск в Яндекс Маркете: как делать всё и сразу. Даня Яковлев.
Коллега из Маркета рассказывает про то, как в поиске пытаются сделать счастливыми и пользователей, и продавцов, и инфру. По пути задевая базовую базу поиска, поясняя, как все задачи сводятся к одной и той же задаче, и сверху добивая историей про шардирование поиска.
Красота блин!
👍13
#highload
Балансируем трафик.
https://telegra.ph/Balansiruem-trafik-06-10
Ещё бы как-то жизнь забалансировать...
Балансируем трафик.
https://telegra.ph/Balansiruem-trafik-06-10
Ещё бы как-то жизнь забалансировать...
Telegraph
Балансируем трафик
Зачем балансировать трафик растекаться не буду. Все понимают важность масштабирования. А где масштабирование, там надо и учить систему работать в новой парадигме. Задача балансировки трафика в идеальном случае решается так: берём имеющееся у нас знание про…
🔥23👍7❤4👎4
#highload
Часть 1/2.
Недавно выложили доклады с Highload++ 2024. Я так понимаю, в его рамках ещё проходил Golang Conf 2024 и PHP Russia 2024. На первом я хотел послушать пару докладов по интересным сверху темам, но их качество не зашло, а в пхп я в целом не интересуюсь.
Вот список докладов, которые меня зацепили названием, я смог досмотреть до конца и в итоге остался доволен (в случайном порядке). В этот раз решил попробовать разбить по темам.
### Поиск и рекомендации
1. Гибридный поиск на базе OpenSearch и Qdrant. Егор Прохоренко.
Докладчик из жёлтого банка рассказывает про то, как делали гибридный поиск: в случае ребят это когда есть полнотекстовый поиск (OpenSearch) и векторный (Qdrant) для некоторых документов, и хочется уметь матчить выдачу их двух флоу. Точнее про внедрение векторного поиска к основному и как их матчили.
Задача в общем случае прикольная. Таска мержа выдачи не самая тривиальная, если делать её адекватно. У движков разные релевантности, и подгонять под одну шкалу можно, но сложно. И модель-мержилка должна как-то учитывать релевантности от источников, а не просто по своему какому-то признаку отранжировать кандидатов. Надо думать короче.
Хотя доклад больше бэкендерский и архитектурный, чем мльный.
2. Поиск в видеоконтенте при помощи AI. Александр Соколов.
Очень прикольная задача у ребят: искать фрагменты видео по произвольным запросам "в кадре два человека", "вид с высоты птичьего полёта", Александр Пушной, "кулебяка". Такой универсальный источник материалов для контентмейкеров.
Тут чувак тоже упоминает задачу мержа выдач из нескольких источников. Прям из полнотекстового движка и из векторного. Если прошлый докладчик не углублялся в проблему, этот да.
3. Ускорение индекса в поиске по VK-видео. Федор Петряйкин.
Интересная история про ускорение поиска в VK видео.
Там примерно математика и какой-то новый алгоритм из какой-то там статьи. Понравилось.
4. Как мы сделали рекомендации, отказались от подрядчика и заработали денег. Данила Федюкин.
Прикольный доклад про то, как ребята в X5 делали свои базовые рекомендации вместо накидывать бабосики внешнему подрядчику. Там даже не то чтобы жоская млька. Базовая математика и классический мль для начала. Получилось интересно.
### Инфраструктура
1. Как на самом деле работает Apache Iceberg. Владимир Озеров.
Я знал слова вроде Data Lake, но концепция не была уложена. После этого доклада осознал чуть больше, появилась картинка в голове. И название Apache Iceberg получило какой-то смысл.
2. Почтовые приключения с PostgreSQL: как приручить 650+ шардов и выжить. Кирилл Григорьев.
История про шардирование постгри. Задача важная и нужная. Решение интересное. Впитал.
3. AppHost: как Яндекс организует взаимодействие сотен микросервисов. Константин Вуколов.
Я руками AppHost никогда не трогал, но со стороны и из отзывов коллег выглядит прикольно. Доклад раскрывает детали, что же это такое.
Если кратко -- штука, которая позволяет управлять графами походов между сервисами.
4. Динтаблицы YTsaurus — и ещё одна СУБД от Яндекса. Руслан Савченко.
YTsaurus это крута. Динтаблицы в нём ещё круче. Руслан Савченко -- прекрасный докладчик.
5. Как объединять данные из разных СУБД и делать это эффективно. Виталий Исаев.
Я не оч шарю за федеративные СУБД. Тут не рассказывается про их базу, но какие-то вещи осознал. Плюс саму задачу про объединение раскрыли.
Часть 1/2.
Недавно выложили доклады с Highload++ 2024. Я так понимаю, в его рамках ещё проходил Golang Conf 2024 и PHP Russia 2024. На первом я хотел послушать пару докладов по интересным сверху темам, но их качество не зашло, а в пхп я в целом не интересуюсь.
Вот список докладов, которые меня зацепили названием, я смог досмотреть до конца и в итоге остался доволен (в случайном порядке). В этот раз решил попробовать разбить по темам.
### Поиск и рекомендации
1. Гибридный поиск на базе OpenSearch и Qdrant. Егор Прохоренко.
Докладчик из жёлтого банка рассказывает про то, как делали гибридный поиск: в случае ребят это когда есть полнотекстовый поиск (OpenSearch) и векторный (Qdrant) для некоторых документов, и хочется уметь матчить выдачу их двух флоу. Точнее про внедрение векторного поиска к основному и как их матчили.
Задача в общем случае прикольная. Таска мержа выдачи не самая тривиальная, если делать её адекватно. У движков разные релевантности, и подгонять под одну шкалу можно, но сложно. И модель-мержилка должна как-то учитывать релевантности от источников, а не просто по своему какому-то признаку отранжировать кандидатов. Надо думать короче.
Хотя доклад больше бэкендерский и архитектурный, чем мльный.
2. Поиск в видеоконтенте при помощи AI. Александр Соколов.
Очень прикольная задача у ребят: искать фрагменты видео по произвольным запросам "в кадре два человека", "вид с высоты птичьего полёта", Александр Пушной, "кулебяка". Такой универсальный источник материалов для контентмейкеров.
Тут чувак тоже упоминает задачу мержа выдач из нескольких источников. Прям из полнотекстового движка и из векторного. Если прошлый докладчик не углублялся в проблему, этот да.
3. Ускорение индекса в поиске по VK-видео. Федор Петряйкин.
Интересная история про ускорение поиска в VK видео.
Там примерно математика и какой-то новый алгоритм из какой-то там статьи. Понравилось.
4. Как мы сделали рекомендации, отказались от подрядчика и заработали денег. Данила Федюкин.
Прикольный доклад про то, как ребята в X5 делали свои базовые рекомендации вместо накидывать бабосики внешнему подрядчику. Там даже не то чтобы жоская млька. Базовая математика и классический мль для начала. Получилось интересно.
### Инфраструктура
1. Как на самом деле работает Apache Iceberg. Владимир Озеров.
Я знал слова вроде Data Lake, но концепция не была уложена. После этого доклада осознал чуть больше, появилась картинка в голове. И название Apache Iceberg получило какой-то смысл.
2. Почтовые приключения с PostgreSQL: как приручить 650+ шардов и выжить. Кирилл Григорьев.
История про шардирование постгри. Задача важная и нужная. Решение интересное. Впитал.
3. AppHost: как Яндекс организует взаимодействие сотен микросервисов. Константин Вуколов.
Я руками AppHost никогда не трогал, но со стороны и из отзывов коллег выглядит прикольно. Доклад раскрывает детали, что же это такое.
Если кратко -- штука, которая позволяет управлять графами походов между сервисами.
4. Динтаблицы YTsaurus — и ещё одна СУБД от Яндекса. Руслан Савченко.
YTsaurus это крута. Динтаблицы в нём ещё круче. Руслан Савченко -- прекрасный докладчик.
5. Как объединять данные из разных СУБД и делать это эффективно. Виталий Исаев.
Я не оч шарю за федеративные СУБД. Тут не рассказывается про их базу, но какие-то вещи осознал. Плюс саму задачу про объединение раскрыли.
👍12❤7
#highload
Есть такой паттерн speculative execution (для любителей нативного русского💪💪💪 C2 -- спекулятивное исполнение ). Паттерн заключается в том, чтобы делать префетч данных ещё до того, как пользователь захочет что-то увидеть, чтобы в момент, когда он всё-таки это захочет, показать ему готовый результат.
Идея довольно простая и логичная. Ниже пару примеров.
💪 В instagram мне когда-то давно-давно попадался reels, в котором один из топов того же instagram рассказывал, что в какой-то момент они стали предзагружать фотографии с устройства к себе на сервер, если пользователь зашёл в таббаре во вкладку про выкладывание фотографий. Таким образом, пока юзер сделает подпись и отметит кого-нибудь, у вас уже загружена фотка и пост создаётся почти мгновенно. Юзер в шоке.
👉 Трейдоф: сколько фотографий с локального устройства загружать. Понятно, что чем больше, тем дороже это обходится по ресурсам, но тем вероятнее юзер впечатлится.
💪 Хороший продукт умеет угадывать, что дальше будет делать юзер.
Например, если пользователь листает ленту в вашей социальной сети, то почти наверняка он и продолжит её листать. Потому можно предзагрузить следующие 10 постов, чтобы отобразить их мгновенно и юзер не успел подумать, что хватит сидеть в тиктоке.
Или, например, сидит ваш юзер и смотрит на красивый товар. И из поведения пользователей вы знаете, что с этим товаром часто смотрят похожие/аксессуары к нему/товары того же бренда. Можно предзагрузить эти товары заранее.
👉 Количество запросов конечно же растёт.
💪 Представим, что вы хотите ускорить ваше приложение, но в самом начале какой-нибудь важной ручки торчит синхронный поход в другой сервис, без которого ну никак нельзя. Пусть это будет поход в антифрод, который говорит вам, надо вообще этому юзеру отдавать контент или заблокировать его нафек. Или может контент так и так отдать надо, но в разном виде: со скидками или без них.
Делаем поход в антифрод асинхронным и запускаем две ветки в коде: которая считает, что наш юзер лапочка, и которая считает, что он злодей и его надо наказать. Когда ответ от антифрода готов, отбрасываем ненужную таску/результат и оставляем нужное.
👉 Можно знатно нагрузить и себя, и другие сервисы, от которых зависит ваша логика.
💪 Может у вас есть какие-то фильтры в приложении. Например, как в любых картах "Заведение открыто", "Заведение близко", "Заведение с пивом". Можно предпосчитать результаты для самых популярных комбинаций фильтров, чтобы отобразить их юзеру мгновенно.
👉Тратим ресурсики на то, что может и не понадобится.
💪 Делаете вы поиск. Взяли да посчитали выдачу для самых популярных запросов. Да положили её в кеш. Теперь на самые крутые топовые запросы вы отдаёте ответ жоска мгновенно.
Или вводит пользователь запрос, а мы у себя его уже продолжили и для топ-5 саджестов уже и выдачу подгрузили, чтобы при клике побыстрее её отобразить.
👉Разменялись на память/ресурсы.
💪 Делаем дашборд, который пересчитывается раз в какое-то время, а не на каждое открытие.
👉Экономим ресурсы, но жертвуем актуальностью данных. Хотя в таком случае иногда актуальные данные и не нужны.
Примеров можем насобирать ещё тыщу, но суть вы уже поняли.
Главное применять аккуратно, т.к. можно легко сделать х2 самых тяжёлых запросов в сервисе и получить огромную кушалку железа, которая не окупается за счёт полученного ускорения (надо заранее понимать, что ускорение вообще вам что-то даёт, желательно деньги).
И сперва стоит сначала попробовать честно пооптимизировать. А то может у вас там валенки какие базовые. Лишние походы по сети или копируете что-нибудь жирное, а тут начнёте трейдофы трейдофить. Да код станет сложнее поддерживать.
Есть такой паттерн speculative execution (
Идея довольно простая и логичная. Ниже пару примеров.
💪 В instagram мне когда-то давно-давно попадался reels, в котором один из топов того же instagram рассказывал, что в какой-то момент они стали предзагружать фотографии с устройства к себе на сервер, если пользователь зашёл в таббаре во вкладку про выкладывание фотографий. Таким образом, пока юзер сделает подпись и отметит кого-нибудь, у вас уже загружена фотка и пост создаётся почти мгновенно. Юзер в шоке.
👉 Трейдоф: сколько фотографий с локального устройства загружать. Понятно, что чем больше, тем дороже это обходится по ресурсам, но тем вероятнее юзер впечатлится.
💪 Хороший продукт умеет угадывать, что дальше будет делать юзер.
Например, если пользователь листает ленту в вашей социальной сети, то почти наверняка он и продолжит её листать. Потому можно предзагрузить следующие 10 постов, чтобы отобразить их мгновенно и юзер не успел подумать, что хватит сидеть в тиктоке.
Или, например, сидит ваш юзер и смотрит на красивый товар. И из поведения пользователей вы знаете, что с этим товаром часто смотрят похожие/аксессуары к нему/товары того же бренда. Можно предзагрузить эти товары заранее.
👉 Количество запросов конечно же растёт.
💪 Представим, что вы хотите ускорить ваше приложение, но в самом начале какой-нибудь важной ручки торчит синхронный поход в другой сервис, без которого ну никак нельзя. Пусть это будет поход в антифрод, который говорит вам, надо вообще этому юзеру отдавать контент или заблокировать его нафек. Или может контент так и так отдать надо, но в разном виде: со скидками или без них.
Делаем поход в антифрод асинхронным и запускаем две ветки в коде: которая считает, что наш юзер лапочка, и которая считает, что он злодей и его надо наказать. Когда ответ от антифрода готов, отбрасываем ненужную таску/результат и оставляем нужное.
👉 Можно знатно нагрузить и себя, и другие сервисы, от которых зависит ваша логика.
💪 Может у вас есть какие-то фильтры в приложении. Например, как в любых картах "Заведение открыто", "Заведение близко", "Заведение с пивом". Можно предпосчитать результаты для самых популярных комбинаций фильтров, чтобы отобразить их юзеру мгновенно.
👉Тратим ресурсики на то, что может и не понадобится.
💪 Делаете вы поиск. Взяли да посчитали выдачу для самых популярных запросов. Да положили её в кеш. Теперь на самые крутые топовые запросы вы отдаёте ответ жоска мгновенно.
Или вводит пользователь запрос, а мы у себя его уже продолжили и для топ-5 саджестов уже и выдачу подгрузили, чтобы при клике побыстрее её отобразить.
👉Разменялись на память/ресурсы.
💪 Делаем дашборд, который пересчитывается раз в какое-то время, а не на каждое открытие.
👉Экономим ресурсы, но жертвуем актуальностью данных. Хотя в таком случае иногда актуальные данные и не нужны.
Примеров можем насобирать ещё тыщу, но суть вы уже поняли.
Главное применять аккуратно, т.к. можно легко сделать х2 самых тяжёлых запросов в сервисе и получить огромную кушалку железа, которая не окупается за счёт полученного ускорения (надо заранее понимать, что ускорение вообще вам что-то даёт, желательно деньги).
И сперва стоит сначала попробовать честно пооптимизировать. А то может у вас там валенки какие базовые. Лишние походы по сети или копируете что-нибудь жирное, а тут начнёте трейдофы трейдофить. Да код станет сложнее поддерживать.
1❤25👍14🤮1
#highload
Хочу сказать пару слов про деструктивный паттерн, который можно обнаружить в книжках о подготовке к сисдизу. В большей степени этим страдает Grokking the system design interview, в меньшей System design interview by Alex Xu. Уверен, ещё и много других (несколько случайных скринов для пруфов).
Одна из проблем таких книг в том, что они концентрируются на "сделать, чтобы работало". И для прохождения собеседования на middle этого будет часто достаточно. Но если ваша секция на роли посерьёзнее, "просто работает" не катит. Надо детальнее объяснять выбор технологий, иногда посчитать бабки и (!!!) как решение будет поддерживаться.
А поддерживать вашу систему, когда 2 разных сервиса общаются с одной базой, сложно.
Перед описанием проблемы, кратко посмотрим на то, почему shared database подход вообще может возникнуть:
1️⃣ Если вы молодой стартап и торопитесь сделать хоть что-то работающее, то не заморачиваться с поднятием отдельной БД может быть сильным срезанием в сроках.
В т.ч. не нужно делать API и учиться в него ходить.
2️⃣ Если вы в процессе распила монолита (strangler паттерн), это может быть естественным шагом развития вашей системы.
3️⃣ Если у вас уже есть одна фулл настроенная БД, то иметь желание сократить ресурс на администрирование второй вполне естественно (актуально для команд с небольшой экспертизой и слабой инфрой). Также можно экономить на лицензиях и железе в целом.
Это всё конечно хорошо, но скорее от бедности. Понятно, что какое-то время жить с таким решением ок и даже необходимо. Но если вы крепкая уверенная компания, которая беспокоится о своей доступности, то надо не ковыряться в носу и идти править. Потому что
1️⃣ У сервисов с общей БД связность (или coupling) мгновенно возрастает до небес.
- Хотите изменить схему? На здоровье. Делаем это в сервисе А. Забываем в сервисе Б. Получаем отвалившийся Б, не готовый к подобным изменениям.
Здорово, если Б не является критическим для ваших пользователей сервиса. Всего-то фича какая-нибудь сломается. Но бабки вы можете потерять.
- Не забыли сделать изменения и во втором сервисе? Молодцы! Но потратили время на эти изменения -> ТТМ задач выше возможного. Так что тут ещё посчитать надо, больше ли мы экономим, чем тратим.
- Забыть поддержать изменения в другом сервисе всё-таки довольно просто. Часто это какое-то тайное знание. Про которое не знает любой новый разработчик. Если ему(ей) не скажут, то он(а) узнает только на опыте. Первые пару раз можно и не вспомнить, даже если знаешь. Можно забыть кому-то подсказать в моменты рабочей душноты. В CI особо такое не проверишь.
Всё против вас.
2️⃣ Нарушаем инкапсуляцию.
Если в сервисе А набагали (а это eventually произойдёт), данные для двух сервисов могут быть битыми. А если ещё и А не критичен, а Б критичен, то вот вам неприятный инцидент и потеря денюжек.
И ответственность размывается. Надо помнить, чья это БД на самом деле, а кто просто рядом стоит. Чтобы случайно не сделать удаление данных в Б, хотя за все остальные операции отвечает А.
3️⃣ Масштабироваться сложно.
У сервисов могут быть разные паттерны работы с данными. Например А обрабатывает онлайн запросы пользователей, а Б -- аналитические запросы аналитиков. Тяжёлый аналитический запрос со сложной агрегацией и большой read нагрузкой может просто приложить вам БД или хотя бы просадить перф -> вы проиграли в деньги.
Было бы здорово иметь отдельные инсталляции, которые можно масштабировать отдельно под задачу, в т.ч. выбирая подходящие технологии для конкретного типа нагрузки.
Отдельно ещё отмечу про картинку 2, где существует отдельный сервис для очистки данных (cleanup). Он тут абсолютно не нужен по причинам выше. Можно смело сделать отдельную компоненту в изначальном Key generation сервисе, которая раз в какое-то время (может по ночам) будет чистить БД от лишних данных. Это даже и разрабатывать проще. А если на собесе хочется показать, что вы про это не забыли, так напишите рядом в ответственности сервиса с бизнес-логикой, что он будет делать. И не делите на сервисы без необходимости. Чем меньше квадратиков вы нарисуете, тем проще будет.
Хочу сказать пару слов про деструктивный паттерн, который можно обнаружить в книжках о подготовке к сисдизу. В большей степени этим страдает Grokking the system design interview, в меньшей System design interview by Alex Xu. Уверен, ещё и много других (несколько случайных скринов для пруфов).
Одна из проблем таких книг в том, что они концентрируются на "сделать, чтобы работало". И для прохождения собеседования на middle этого будет часто достаточно. Но если ваша секция на роли посерьёзнее, "просто работает" не катит. Надо детальнее объяснять выбор технологий, иногда посчитать бабки и (!!!) как решение будет поддерживаться.
А поддерживать вашу систему, когда 2 разных сервиса общаются с одной базой, сложно.
Перед описанием проблемы, кратко посмотрим на то, почему shared database подход вообще может возникнуть:
В т.ч. не нужно делать API и учиться в него ходить.
Это всё конечно хорошо, но скорее от бедности. Понятно, что какое-то время жить с таким решением ок и даже необходимо. Но если вы крепкая уверенная компания, которая беспокоится о своей доступности, то надо не ковыряться в носу и идти править. Потому что
- Хотите изменить схему? На здоровье. Делаем это в сервисе А. Забываем в сервисе Б. Получаем отвалившийся Б, не готовый к подобным изменениям.
Здорово, если Б не является критическим для ваших пользователей сервиса. Всего-то фича какая-нибудь сломается. Но бабки вы можете потерять.
- Не забыли сделать изменения и во втором сервисе? Молодцы! Но потратили время на эти изменения -> ТТМ задач выше возможного. Так что тут ещё посчитать надо, больше ли мы экономим, чем тратим.
- Забыть поддержать изменения в другом сервисе всё-таки довольно просто. Часто это какое-то тайное знание. Про которое не знает любой новый разработчик. Если ему(ей) не скажут, то он(а) узнает только на опыте. Первые пару раз можно и не вспомнить, даже если знаешь. Можно забыть кому-то подсказать в моменты рабочей душноты. В CI особо такое не проверишь.
Всё против вас.
Если в сервисе А набагали (а это eventually произойдёт), данные для двух сервисов могут быть битыми. А если ещё и А не критичен, а Б критичен, то вот вам неприятный инцидент и потеря денюжек.
И ответственность размывается. Надо помнить, чья это БД на самом деле, а кто просто рядом стоит. Чтобы случайно не сделать удаление данных в Б, хотя за все остальные операции отвечает А.
У сервисов могут быть разные паттерны работы с данными. Например А обрабатывает онлайн запросы пользователей, а Б -- аналитические запросы аналитиков. Тяжёлый аналитический запрос со сложной агрегацией и большой read нагрузкой может просто приложить вам БД или хотя бы просадить перф -> вы проиграли в деньги.
Было бы здорово иметь отдельные инсталляции, которые можно масштабировать отдельно под задачу, в т.ч. выбирая подходящие технологии для конкретного типа нагрузки.
Отдельно ещё отмечу про картинку 2, где существует отдельный сервис для очистки данных (cleanup). Он тут абсолютно не нужен по причинам выше. Можно смело сделать отдельную компоненту в изначальном Key generation сервисе, которая раз в какое-то время (может по ночам) будет чистить БД от лишних данных. Это даже и разрабатывать проще. А если на собесе хочется показать, что вы про это не забыли, так напишите рядом в ответственности сервиса с бизнес-логикой, что он будет делать. И не делите на сервисы без необходимости. Чем меньше квадратиков вы нарисуете, тем проще будет.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18👍18
#highload
Старожилы канала могли заметить, что фокус потихоньку сместился с C++ на бэкенд и архитектуру. Это логично: я профессионально расту, больше вещей меня увлекают, интересы становятся шире и глубже. Ограничивать себя только плюсами уже не хочется. Хочется писать про что угодно.Может через год это будет каналом про PHP. Я не знаю. Вряд ли конечно. Но запрещать себе такое я не буду.
Раз я начал рассказывать про людей и то, что они делают (это не последний раз, я планирую это регулярно повторять), то двигаемся дальше.
Где-то далеко в дереве моих коллег есть Саша Федькин. Он руководит сектором клиентского бэкенда в Crowd. У нас уже в этом месте матчится рабочая зона ответственности, а отсюда вытекают знакомые проблемы, задачи и специфика.
Лично я с Сашей не знаком, но за его активностью уже некоторое время слежу. Активничает он у себя на канале: @MicroservicesThoughts.
Пишет про архитектуру, бэкенд и всё что рядом. Вот вам несколько из множества постов, которые мне зашли:
- про circuit breaker
- tail latency и hedged запросы
- прикольная загадка про postgres
- snapshot isolation
- про bloat в postgres
По контенту вы быстро поймёте, что это не очереднярские гпт посты. Текст приятный. Для осознания иногда надо напрягаться -> я расту.
Побольше бы такого.
Старожилы канала могли заметить, что фокус потихоньку сместился с C++ на бэкенд и архитектуру. Это логично: я профессионально расту, больше вещей меня увлекают, интересы становятся шире и глубже. Ограничивать себя только плюсами уже не хочется. Хочется писать про что угодно.
Раз я начал рассказывать про людей и то, что они делают (это не последний раз, я планирую это регулярно повторять), то двигаемся дальше.
Где-то далеко в дереве моих коллег есть Саша Федькин. Он руководит сектором клиентского бэкенда в Crowd. У нас уже в этом месте матчится рабочая зона ответственности, а отсюда вытекают знакомые проблемы, задачи и специфика.
Лично я с Сашей не знаком, но за его активностью уже некоторое время слежу. Активничает он у себя на канале: @MicroservicesThoughts.
Пишет про архитектуру, бэкенд и всё что рядом. Вот вам несколько из множества постов, которые мне зашли:
- про circuit breaker
- tail latency и hedged запросы
- прикольная загадка про postgres
- snapshot isolation
- про bloat в postgres
По контенту вы быстро поймёте, что это не очереднярские гпт посты. Текст приятный. Для осознания иногда надо напрягаться -> я расту.
Побольше бы такого.
1❤27👍17🔥7🥴4
#highload
Принёс отдельные доклады с Яндекс Tech Tour (в прошлом году это был foodtech tour, на котором я выступал в Минске).
1️⃣ Как мы переосмыслили поиск лекарств в Яндекс Еде. Сергей Синягин.
Когда вы открываете Еду, ищутся все доступные вам заведения. И бывает, что вам доступны несколько заведений одного бренда. Тогда заведения дедуплицируются и остаётся какое-то одно. Проблема в том, что в этом заведении может не быть нужного вам товара (например конкретных таблеток в конкретной аптеке), а в отброшенным они были!
Серёжа рассказывает, как меняли архитектуру, чтобы уметь чаще удовлетворять пользовательские запросы.
2️⃣ Как мы пересобрали инфраструктуру Маркета и не сломали всё вокруг. Егор Быховцев.
Егор рассказывает про изменение концепции оркестрации в бэкенде Маркета.
Буквально недавно меня убедили, что такое крута. Я верю. После доклада Егора убедился ещё больше.
Внутри и снаружи решение называется apphost. Глядишь, выкатят в опенсорс скоро.
3️⃣ LLM Cache в поиске Лавки. Алексей Щекалев.
Лёша рассказывает тлдр про развитие поиска в Лавке.
Раз у нас ассортимент небольшой, то можно сделать кеш ответов на самые популярные запросы. Вот ребята это и сделали.
Имхо решение бомба. Наикрасивейше. Это не только про качество, но и про тайминги.
Ещё круто, что ребята затащили это в т.ч. в Еду. Круто, когда внутри экосистемы один сервис чуть ли не бесплатно помогает другому крутыми технологиями.
4️⃣ Event-Driven архитектура в Цикле Заказа Яндекс Лавки. Миша Горбушин.
Миша рассказывает про ЦЗ Лавки, зачем его делали event-driven, собсна как это делали. И про разные проблемы по пути.
5️⃣ Как разрабатывают и улучшают алгоритмы логистики в Яндекс Еде. Дима Ефимов.
Дима рассказывает про процесс улучшения алгоритмов доставки в Еде. В целом из чего доставка состоит. На какие метрики смотрят. Про разные уникальности доставки и местные АБ.
Принёс отдельные доклады с Яндекс Tech Tour (в прошлом году это был foodtech tour, на котором я выступал в Минске).
Когда вы открываете Еду, ищутся все доступные вам заведения. И бывает, что вам доступны несколько заведений одного бренда. Тогда заведения дедуплицируются и остаётся какое-то одно. Проблема в том, что в этом заведении может не быть нужного вам товара (например конкретных таблеток в конкретной аптеке), а в отброшенным они были!
Серёжа рассказывает, как меняли архитектуру, чтобы уметь чаще удовлетворять пользовательские запросы.
Егор рассказывает про изменение концепции оркестрации в бэкенде Маркета.
Буквально недавно меня убедили, что такое крута. Я верю. После доклада Егора убедился ещё больше.
Внутри и снаружи решение называется apphost. Глядишь, выкатят в опенсорс скоро.
Лёша рассказывает тлдр про развитие поиска в Лавке.
Раз у нас ассортимент небольшой, то можно сделать кеш ответов на самые популярные запросы. Вот ребята это и сделали.
Имхо решение бомба. Наикрасивейше. Это не только про качество, но и про тайминги.
Ещё круто, что ребята затащили это в т.ч. в Еду. Круто, когда внутри экосистемы один сервис чуть ли не бесплатно помогает другому крутыми технологиями.
Миша рассказывает про ЦЗ Лавки, зачем его делали event-driven, собсна как это делали. И про разные проблемы по пути.
Дима рассказывает про процесс улучшения алгоритмов доставки в Еде. В целом из чего доставка состоит. На какие метрики смотрят. Про разные уникальности доставки и местные АБ.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤮7🔥6🗿2❤1👍1
#highload
Инциденты Ч.1.
Если вы работаете над системами, которые делают что-то для пользователя вот прямо сейчас, вы так или иначе хотите видеть эту самую систему в стабильном работающем состоянии.
Сколько бы девяток вы не имели, две или пять, рано или поздно вы упадёте. Возможно, упадёте сильно.
Сегодня тлдр нескольких жирных инцидентов, которые произошли по абсолютно базовичковым причинам.
Knight Capital 2012
Когда-то это была одна из крупнейших трейдинговых фирм на американском рынке.
Что случилось:
- реализовали новую фичу под флагом (флаг взяли от старой фичи, а не сделали новый)
- раскатка нового бинарника происходила руками. На один из 8 подов сервиса забыли положить новый бинарник
- включили фичу
- с началом торгового дня заработала новая логика на 7/8 подов. На восьмом включилась старая логика (на самом деле даже не старая, а частично отпиленная старая).
Из-за того, что старая логика была частичной, её действия свелись к покупке некоторых активов в бесконечном цикле.
У чуваков не было адекватного обсервабилити, процесса дебага и инцидент-менеджмента.
Через 45 минут проблему починили, но за это время всадили >400kk$, что фактически обанкротило компанию.
Понятно, что проблема не в коде конкретного разработчика, и не в руках человека, отвечающего за деплой. Проблема скорее в общей инженерной культуре компании, которая, очевидно, идёт с самого верха к низу.
Но всё-таки прикиньте, каково быть тем самым/теми самыми разработчиками, действия которых привели к такому крупному инциденту. Пипяу.
Link: https://specbranch.com/posts/knight-capital/
British Airways 2017
Проблема британской авиакомпании -- подрядчик неаккуратно отключил питание в основном ДЦ.
Вообще-то был второй. Но он был запасным. На нём не было постоянной нагрузки. На него надо процессно переключаться при наличии проблем. Этого сделано не было, из-за чего авиакомпания осталась без возможности обслуживать фактически все пользовательские запросы.
Последствия: 75k пассажиров не улетели куда планировали, 1000 рейсов отменены.
Восстановление было довольно сложным, т.к. не было произведено аккуратного переключения на второй ДЦ, из-за чего много данных фактически стали битыми.
Link: https://www.theguardian.com/business/2017/jun/05/ba-inquiry-it-meltdown-airline-willie-walsh-passengers
Azure 2012
В посте про время я уже писал про один инцидент, связанный со временем (Cloudfare и не монотонность часов), но там это хотя бы что-то нетривиальное.
А вот в Azure ребята рофланули мощнейше.
Создавали они значит где-то в коде у себя какие-то сертификаты на доступность. Код был примерно таким:
Конечно же сертификаты, созданные 29ого февраля получали
Это ж надо было такую либу написать, которая +1 год делает буквально +1 год.
Потрясающе ещё, что фактически этот код мог не меняться годами и стрельнуть только в этот самый отличный день. Не зря на собесах вас просят крайние случаи проговорить.
Link: https://www.wired.com/2012/03/azure-leap-year-bug/
Следующая порция когда-нибудь!
Ещё позже расскажу про мои любимые инциденты из личного опыта.
Инциденты Ч.1.
Если вы работаете над системами, которые делают что-то для пользователя вот прямо сейчас, вы так или иначе хотите видеть эту самую систему в стабильном работающем состоянии.
Сколько бы девяток вы не имели, две или пять, рано или поздно вы упадёте. Возможно, упадёте сильно.
Сегодня тлдр нескольких жирных инцидентов, которые произошли по абсолютно базовичковым причинам.
Knight Capital 2012
Когда-то это была одна из крупнейших трейдинговых фирм на американском рынке.
Что случилось:
- реализовали новую фичу под флагом (флаг взяли от старой фичи, а не сделали новый)
- раскатка нового бинарника происходила руками. На один из 8 подов сервиса забыли положить новый бинарник
- включили фичу
- с началом торгового дня заработала новая логика на 7/8 подов. На восьмом включилась старая логика (на самом деле даже не старая, а частично отпиленная старая).
Из-за того, что старая логика была частичной, её действия свелись к покупке некоторых активов в бесконечном цикле.
У чуваков не было адекватного обсервабилити, процесса дебага и инцидент-менеджмента.
Через 45 минут проблему починили, но за это время всадили >400kk$, что фактически обанкротило компанию.
Понятно, что проблема не в коде конкретного разработчика, и не в руках человека, отвечающего за деплой. Проблема скорее в общей инженерной культуре компании, которая, очевидно, идёт с самого верха к низу.
Но всё-таки прикиньте, каково быть тем самым/теми самыми разработчиками, действия которых привели к такому крупному инциденту. Пипяу.
Link: https://specbranch.com/posts/knight-capital/
British Airways 2017
Проблема британской авиакомпании -- подрядчик неаккуратно отключил питание в основном ДЦ.
Вообще-то был второй. Но он был запасным. На нём не было постоянной нагрузки. На него надо процессно переключаться при наличии проблем. Этого сделано не было, из-за чего авиакомпания осталась без возможности обслуживать фактически все пользовательские запросы.
Последствия: 75k пассажиров не улетели куда планировали, 1000 рейсов отменены.
Восстановление было довольно сложным, т.к. не было произведено аккуратного переключения на второй ДЦ, из-за чего много данных фактически стали битыми.
Link: https://www.theguardian.com/business/2017/jun/05/ba-inquiry-it-meltdown-airline-willie-walsh-passengers
Azure 2012
В посте про время я уже писал про один инцидент, связанный со временем (Cloudfare и не монотонность часов), но там это хотя бы что-то нетривиальное.
А вот в Azure ребята рофланули мощнейше.
Создавали они значит где-то в коде у себя какие-то сертификаты на доступность. Код был примерно таким:
DateTime issuedAt = DateTime.UtcNow;
DateTime expiresAt = issuedAt.AddYears(1);
Конечно же сертификаты, созданные 29ого февраля получали
expiresAt значение 29.02.2013, что не является валидной датой. В связи с особенностями архитектуры, ошибка привела к большому outage в нескольких регионах, т.к. с точки зрения системы очень много железа было неисправно.Это ж надо было такую либу написать, которая +1 год делает буквально +1 год.
Потрясающе ещё, что фактически этот код мог не меняться годами и стрельнуть только в этот самый отличный день. Не зря на собесах вас просят крайние случаи проговорить.
Link: https://www.wired.com/2012/03/azure-leap-year-bug/
Следующая порция когда-нибудь!
Ещё позже расскажу про мои любимые инциденты из личного опыта.
🔥62❤16👍11
#books #highload
Масштабирование систем. Ian Gorton.
Ещё одна книжка про то, как делать бэкенд. Причём такой бэкенд. Крепкий. Устойчивый.
Содержание:
1️⃣ глава рассказывает про скорость масштабирования систем сегодня и насколько мы можем недооценивать темпы роста. В основном на основе исторических данных вида "а вот эти челы выросли очень быстро, никто даже не ожидал".
И даётся обещание рассматривать до конца книги две основные концепции: увеличение ресурсов и оптимизацию их использования.
Это в целом разумно, но в этот момент я не понимал, как растянуть это всё на фулл книгу.
2️⃣ разбирает базовые концепции: горизонтальное/вертикальное масштабирование, кеширование для уменьшения нагрузки на БД и другие подходы. Про нам известные metastable failures и даунсайды глубоко не говориться, хотя я в последнее время всё чаще думаю про подобные проблемы и про то, как мало внимания им уделяется.
В3️⃣ начинается разбор всего вокруг: база про сети, grpc, частичные отказы, консенсус, время.
С этого момента я начал что-то подозревать о контенте книги.
4️⃣ пытается рассказать про конкурентность (???).
Имхо пытаться обсудить concurrency в одной главе книги опасно. Причём там не то чтобы база, а по верхам с попыткой залезть чуть глубже базовых понятий.
5️⃣ рассказывает про основы бэкенда, API, балансировку нагрузки.
6️⃣ про распределённое кеширование.
7️⃣ — асинхронный обмен сообщениями.
8️⃣ про serverless. Честно говоря, единственная полезная для меня глава, т.к. я в теме не шарю и тут были какие-то интересные поинты для хоть какого-то понимания. Но мне всё равно не хватило.
Отдельно понравилось, что обсуждается тема денег в рамках парадигмы и то, как реконфигурация может денюжку сэкономить. Очень жаль, что контента про экономику в программировании не прям много. Мне кажется это интересным.
9️⃣ Микросервисы, переход к ним от монолита. Почему-то ещё про функциональную деградацию и некоторые паттерны. Имхо в тему зашли, но сказано почти ничего.
1️⃣ 0 — про масштабирование БД.
1️⃣ 1️⃣ про согласованность в конечном счёте.
1️⃣ 2️⃣ про high consistency.
1️⃣ 3️⃣ — разные имплементации БД. В частности тут про Redis, MongoDB и Amazon DynamoDB.
1️⃣ 4️⃣ аналогичная глава про Kafka.
В1️⃣ 5️⃣ про Apache Flink как систему потоковой обработки данных.
И в последней1️⃣ 6️⃣ несколько отдельных тем: автоматизация, observability, data lakes.
В общем я ждал книгу про масштабирование и hard parts, а получил ещё один учебник про базовые понятия с другой стороны. Если вы уже читали что-то по теме, вам будет неинтересно и скорее всего неполезно. Если вы работали в среде, тоже.
Может часть про отдельные технологии может быть интересной, но опять же книга не целенаправленно рассказывает про них, а мимоходом. Так что почти наверняка лучше погуглить конкретный источник. Более полный/интерактивный/точный.
Почитайте лучше кабанчика. Тем более второе издание как раз вышло.
На эту лучше тратить не стоит. Я уже это сделал за вас.
3 окуня из 10.
Масштабирование систем. Ian Gorton.
Ещё одна книжка про то, как делать бэкенд. Причём такой бэкенд. Крепкий. Устойчивый.
Содержание:
И даётся обещание рассматривать до конца книги две основные концепции: увеличение ресурсов и оптимизацию их использования.
Это в целом разумно, но в этот момент я не понимал, как растянуть это всё на фулл книгу.
В
С этого момента я начал что-то подозревать о контенте книги.
Имхо пытаться обсудить concurrency в одной главе книги опасно. Причём там не то чтобы база, а по верхам с попыткой залезть чуть глубже базовых понятий.
Отдельно понравилось, что обсуждается тема денег в рамках парадигмы и то, как реконфигурация может денюжку сэкономить. Очень жаль, что контента про экономику в программировании не прям много. Мне кажется это интересным.
В
И в последней
В общем я ждал книгу про масштабирование и hard parts, а получил ещё один учебник про базовые понятия с другой стороны. Если вы уже читали что-то по теме, вам будет неинтересно и скорее всего неполезно. Если вы работали в среде, тоже.
Может часть про отдельные технологии может быть интересной, но опять же книга не целенаправленно рассказывает про них, а мимоходом. Так что почти наверняка лучше погуглить конкретный источник. Более полный/интерактивный/точный.
Почитайте лучше кабанчика. Тем более второе издание как раз вышло.
На эту лучше тратить не стоит. Я уже это сделал за вас.
3 окуня из 10.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18❤9👍6🤝2😢1
#highload
Redis license stuff.
https://github.com/dasfex/articles/blob/trunk/redis_license_stuff.md
Спасибо Artyom Garkavy и niki4smirn.
Patreon, Boosty.
Redis license stuff.
https://github.com/dasfex/articles/blob/trunk/redis_license_stuff.md
Спасибо Artyom Garkavy и niki4smirn.
Patreon, Boosty.
GitHub
articles/redis_license_stuff.md at trunk · dasfex/articles
My articles which I don't want to store on telegra.ph, cause its kinda shitty. - dasfex/articles
👍12🤔2🔥1
#highload
Я не очень понял, как это работает. Видосы на самом канале так и не появились, хотя прошло уже больше года с конференции. Плейлист со всеми докладами доступен, и видео выложили год назад. Доступ к ним явно есть. Но просмотров нет. То есть как-то никто и не в курсе, что их можно смотреть.
Доклады с Saint HighLoad++ 2025.
0. Эволюция векторного поиска в YDB. Александр Зевайкин.
Есть ещё в тексте (правда не уверен, что контент 1 в 1).
1. Технологии распределенной карты для автономного транспорта. Гоша Лутидзе.
Прикольное введение в кусок вот этих самоездящих штук.
2. 20 лет на граблях: ошибки, отказы и выводы. Александр Стерлигов.
Несколько кайфовых историй про разные инциденты. Я тоже такое сделаю когда-нибудь.
3. Взгляд за кулисы Яндекс Карт: от сырых спутниковых данных до четких изображений. Игорь Орпанен.
4. Четыре девятки хватит всем? Разбираемся с доступностью дата-центров. Алексей Учакин.
Доклад про датацентры, как они устроены с точки зрения пользователя, что вам обещают и (не)гарантирует.
5. Почему в космосе (пока) нет дата-центров. Александр Токарев.
Ещё один доклад про датацентры, но в космосе. Приятный научпоп.
6. Про избыточность WAL в Postgres. Андрей Бородин.
Интересное для понимания устройства WAL в pg. Не то, чтобы я запомнил что-то, но удовольствие получил.
Факт, который понравился: в pg есть лагающая реплика. Вы можете сделать реплику, в которой всё применяется с задержкой в час, и при факапе остановить её обновление + переключиться на неё.
У меня коллеги когда-то делали похожую штуку, но на уровне приложения. Фиксировали набор табличек, которым нужно делать снапшоты (раз в час и сутки, например). И если источник данных накатил что-то неправильное, из-за чего не получается клиентам отдать данные, мы (как промежуточное звено) могли руками включить чтение из подходяшего снапшота.
Пару раз помогло восстановиться на инцидентах за минуты.
Я не очень понял, как это работает. Видосы на самом канале так и не появились, хотя прошло уже больше года с конференции. Плейлист со всеми докладами доступен, и видео выложили год назад. Доступ к ним явно есть. Но просмотров нет. То есть как-то никто и не в курсе, что их можно смотреть.
Доклады с Saint HighLoad++ 2025.
0. Эволюция векторного поиска в YDB. Александр Зевайкин.
Есть ещё в тексте (правда не уверен, что контент 1 в 1).
1. Технологии распределенной карты для автономного транспорта. Гоша Лутидзе.
Прикольное введение в кусок вот этих самоездящих штук.
2. 20 лет на граблях: ошибки, отказы и выводы. Александр Стерлигов.
Несколько кайфовых историй про разные инциденты. Я тоже такое сделаю когда-нибудь.
3. Взгляд за кулисы Яндекс Карт: от сырых спутниковых данных до четких изображений. Игорь Орпанен.
4. Четыре девятки хватит всем? Разбираемся с доступностью дата-центров. Алексей Учакин.
Доклад про датацентры, как они устроены с точки зрения пользователя, что вам обещают и (не)гарантирует.
5. Почему в космосе (пока) нет дата-центров. Александр Токарев.
Ещё один доклад про датацентры, но в космосе. Приятный научпоп.
6. Про избыточность WAL в Postgres. Андрей Бородин.
Интересное для понимания устройства WAL в pg. Не то, чтобы я запомнил что-то, но удовольствие получил.
Факт, который понравился: в pg есть лагающая реплика. Вы можете сделать реплику, в которой всё применяется с задержкой в час, и при факапе остановить её обновление + переключиться на неё.
У меня коллеги когда-то делали похожую штуку, но на уровне приложения. Фиксировали набор табличек, которым нужно делать снапшоты (раз в час и сутки, например). И если источник данных накатил что-то неправильное, из-за чего не получается клиентам отдать данные, мы (как промежуточное звено) могли руками включить чтение из подходяшего снапшота.
Пару раз помогло восстановиться на инцидентах за минуты.
👍10🔥6❤4
#highload
Давайте представим, что у вас есть пару датацентров и по какой-то причине вы потеряли некоторые. Чуть ли не все. Что делать?
Конечно, не дай бог кому-то попасть в такой кризис.
Но план выживания примерно такой:
• определить критический функционал и операции, которые необходимо поддержать любой ценой. Сфокусироваться на этой части ваших сервисов. Остальные выключить для максимальной экономии ресурсов. В идеале, вы должны знать критическую цепь в любой момент жизни продукта.
• увести нагрузку (если есть что уводить) на работающее и доступное железо
• активно позабирать ресурсы там, где они используются неэффективно, и отдать туда, где их критически не хватает (в идеале это всегда должно выполняться, но достичь этого сложно). Восстанавливать сервисы надо по приоритетам, а не наобум.
В такой ситуации (как и во многих других) жизненно необходимо уметь правильно функционально деградировать. Вспомним пост от начала года: https://t.iss.one/thisnotes/399
Год назад примерно в окрестности этого времени я активно исследовал, что нужно сделать, чтобы иметь инструмент вида «по кнопке отключить всё кроме самого важного». К сожалению, бизнес устроен так, что такими долгосрочными вещами заниматься почти наверняка нельзя. Это всегда nice to have. До тех пор, пока попа не отвалится (конечно, и я мог бы лучше продавать проекты, но как есть). Прийти к чему-то материальному и полезному не получилось.
Ну что ж.
@thisnotes. Patreon (сюда можно донатить, чтобы мои дц жили вечно), newsletter.
Спасибо Artyom Garkavy и niki4smirn.
Давайте представим, что у вас есть пару датацентров и по какой-то причине вы потеряли некоторые. Чуть ли не все. Что делать?
Конечно, не дай бог кому-то попасть в такой кризис.
Но план выживания примерно такой:
• определить критический функционал и операции, которые необходимо поддержать любой ценой. Сфокусироваться на этой части ваших сервисов. Остальные выключить для максимальной экономии ресурсов. В идеале, вы должны знать критическую цепь в любой момент жизни продукта.
• увести нагрузку (если есть что уводить) на работающее и доступное железо
• активно позабирать ресурсы там, где они используются неэффективно, и отдать туда, где их критически не хватает (в идеале это всегда должно выполняться, но достичь этого сложно). Восстанавливать сервисы надо по приоритетам, а не наобум.
В такой ситуации (как и во многих других) жизненно необходимо уметь правильно функционально деградировать. Вспомним пост от начала года: https://t.iss.one/thisnotes/399
Год назад примерно в окрестности этого времени я активно исследовал, что нужно сделать, чтобы иметь инструмент вида «по кнопке отключить всё кроме самого важного». К сожалению, бизнес устроен так, что такими долгосрочными вещами заниматься почти наверняка нельзя. Это всегда nice to have. До тех пор, пока попа не отвалится (конечно, и я мог бы лучше продавать проекты, но как есть). Прийти к чему-то материальному и полезному не получилось.
Ну что ж.
@thisnotes. Patreon (сюда можно донатить, чтобы мои дц жили вечно), newsletter.
Спасибо Artyom Garkavy и niki4smirn.
😁27👍6❤4😢3🥴1🫡1
#highload
Sharding 101.
Давайте быстро пробежимся и зафиксируем концепции, которые важно помнить при шардировании. Хотелось бы, чтобы этот пост был заметкой с ключевыми словами, которые вы поклодите при необходимости.
Задача шардирования: разбить данные на куски, если одна машинка не справляется держать всё (потому что данных слишком много или нагрузка очень большая).
Чтобы шардировать, надо выбрать ключ: по нему вы будете сначала раскладывать данные по шардам, а потом понимать, где данные искать. Ключ нужен нормальный. timestamp — плохой ключ: шард для новых данных всегда мега горячий.
Шардировать можно:
• по значениям ключей.
Очень просто: берёте все значения (или их префиксы, например по первому символу в uuid) и для последовательных ренджей выделяете по шарду ([a-c] -> shard 1, [d-g] -> shard 2, ...). Проблема в том, что нужно выбрать такие ренджи, чтобы шарды были примерно одинаковыми. Если паттерн наличия данных/нагрузки приводит к hot шардам, проблема. Шарды всегда можно сплитить на побольше и поменьше. Можно автоматически. По ключам хорошо, если вам важно иметь рядом данные, ключи которых тоже рядом. Но это не всегда так. Можно
• по хешам от ключей.
Посчитали хеш и взяли остаток от деления на кол-во шардов. Правда решардинг (+/-1 шард) приводит к полному решардингу данных. Можно делать много виртуальных шардов для маленького кол-ва реальных хостов (Count(virtual) — большое составное число, произведение большого кол-ва первых простых числе в идеале, так проще).
Лучше разбивать хеши на ренджи. Отсюда растёт consistent hashing: организовываете всё пространство хешей в логическое кольцо, расставляете на нём шарды. Найти ближайший шард для ключа == взять следующий по часовой стрелке. Так вы сокращаете кол-во перераспределений данных при появлении/пропаже шардов. Тут есть разные варианты реализации (rendezvous hashing, jump consistent hashing, etc).
Это всё было stateless sharding. Но иногда вам нужна чуть более сложная логика. И хранить информацию о том, что где хранится, нужно в отдельной БД. Пару примеров, когда это оправдано:
• динамический шардинг.
Вы пишете систему, которая по каким-то вам известным правилам умеет делить/мержить шарды.
• может у вас мессенджер.
Хранить чаты можно частями по блокам (для очень больших чатов это м.б. выгодно). Новые блоки можно начинать писать на новые шарды, когда на старых места уже нет.
• гео-шардинг.
Причём со сложной конфигурацией для большого кол-ва регионов и клиентов в них.
В общем случае всегда, когда у вас есть какая-то метадата.
Про вот этот второй вариант stateful шардирования с какой-то application логикой часто забывают на system design собеседованиях. Потому что про них редко говорят в туториалах и разборах. А зря. Там есть много полезных и красивых вариантов.
Важно только не забыть, что сервис с метаданными, — доп точка отказа.
А может вы вообще можете забить на это всё, ведь паттерны работы с данными простые. Возьмите тогда Amazon DynamoDB, которая умеет шардироваться автоматически (и по объёму, и по нагрузке) и не думайте про это.
Только посчитайте, сколько это будет стоить.
@thisnotes. Patreon, newsletter.
Спасибо Artyom Garkavy и niki4smirn.
Sharding 101.
Давайте быстро пробежимся и зафиксируем концепции, которые важно помнить при шардировании. Хотелось бы, чтобы этот пост был заметкой с ключевыми словами, которые вы поклодите при необходимости.
Задача шардирования: разбить данные на куски, если одна машинка не справляется держать всё (потому что данных слишком много или нагрузка очень большая).
Чтобы шардировать, надо выбрать ключ: по нему вы будете сначала раскладывать данные по шардам, а потом понимать, где данные искать. Ключ нужен нормальный. timestamp — плохой ключ: шард для новых данных всегда мега горячий.
Шардировать можно:
• по значениям ключей.
Очень просто: берёте все значения (или их префиксы, например по первому символу в uuid) и для последовательных ренджей выделяете по шарду ([a-c] -> shard 1, [d-g] -> shard 2, ...). Проблема в том, что нужно выбрать такие ренджи, чтобы шарды были примерно одинаковыми. Если паттерн наличия данных/нагрузки приводит к hot шардам, проблема. Шарды всегда можно сплитить на побольше и поменьше. Можно автоматически. По ключам хорошо, если вам важно иметь рядом данные, ключи которых тоже рядом. Но это не всегда так. Можно
• по хешам от ключей.
Посчитали хеш и взяли остаток от деления на кол-во шардов. Правда решардинг (+/-1 шард) приводит к полному решардингу данных. Можно делать много виртуальных шардов для маленького кол-ва реальных хостов (Count(virtual) — большое составное число, произведение большого кол-ва первых простых числе в идеале, так проще).
Лучше разбивать хеши на ренджи. Отсюда растёт consistent hashing: организовываете всё пространство хешей в логическое кольцо, расставляете на нём шарды. Найти ближайший шард для ключа == взять следующий по часовой стрелке. Так вы сокращаете кол-во перераспределений данных при появлении/пропаже шардов. Тут есть разные варианты реализации (rendezvous hashing, jump consistent hashing, etc).
Это всё было stateless sharding. Но иногда вам нужна чуть более сложная логика. И хранить информацию о том, что где хранится, нужно в отдельной БД. Пару примеров, когда это оправдано:
• динамический шардинг.
Вы пишете систему, которая по каким-то вам известным правилам умеет делить/мержить шарды.
• может у вас мессенджер.
Хранить чаты можно частями по блокам (для очень больших чатов это м.б. выгодно). Новые блоки можно начинать писать на новые шарды, когда на старых места уже нет.
• гео-шардинг.
Причём со сложной конфигурацией для большого кол-ва регионов и клиентов в них.
В общем случае всегда, когда у вас есть какая-то метадата.
Про вот этот второй вариант stateful шардирования с какой-то application логикой часто забывают на system design собеседованиях. Потому что про них редко говорят в туториалах и разборах. А зря. Там есть много полезных и красивых вариантов.
Важно только не забыть, что сервис с метаданными, — доп точка отказа.
А может вы вообще можете забить на это всё, ведь паттерны работы с данными простые. Возьмите тогда Amazon DynamoDB, которая умеет шардироваться автоматически (и по объёму, и по нагрузке) и не думайте про это.
Только посчитайте, сколько это будет стоить.
@thisnotes. Patreon, newsletter.
Спасибо Artyom Garkavy и niki4smirn.
❤15👎2🥴2