Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Shopify Manages its Petabyte Scale MySQL Database
Очередная статья из серии «как в компании X решили проблему Y». На этот раз shopify и скейлинг петабайтных MySQL баз. Секрет строится вокруг трех направлений: балансировка шардов без даунтаймов, поддержка read консистентности через репликацию и бекапы. Статья как раз рассказывает о каждом из направлений.
В случае с балансировкой шардов рассказывается о том, что каждый шард содержит всю информацию о конкретном магазине, что помогает в управлении нагрузкой в случае распродаж или роста магазина (иногда из-за legal проблем, но об этом в статье не говорится). В случае резкого роста, магазин может мигрировать в отдельный шард. Плюс, показывается как происходит поиск шарда под запрос, балансировка, миграция в три шага.
В случае с консистентностью, рассказывается о проблеме потери актуального состояния данных во время реплицирования. В качестве решения, в компании пробовали tight и causal consistency, но в итоге остановились на monotonic read consistency (когда нельзя посмотреть старые данные). А последней части рассказывается как происходит бекап и восстановление.
#how_it_works #sql
—————————————
Testing exceptions
Кажется, что в TDD можно описать success path сценарии и жить счастливо. На деле, без failure path сценариев нельзя понять на сколько корректно обрабатываются ошибки. Автор статьи делится личным опытом тестирования failure path сценариев. Поднимается три темы:
- Как использовать мок объекты для тестирования исключений;
- Является ли эксепшен контрактом объекта;
- Как реализовать интеграционный тест для failure path;
Важно: учтите, что примеры в статье сфокусированы на xUnit и дотнете.
Русский перевод
#testing #tdd
—————————————
Don't Break the Bank: Smart Spending on Software Architecture
Принятие решений на основе цен сложная тема, при этом без бюджетов никуда. А о бюджете говорят редко в контексте разработки. Сегодняшняя статья как раз посвящена теме бюджета в компании. В начале текста рассказывается о двух видах бюджета: Tight и Flexible. Первый жесткий, когда нет времени на обучение или развитие, решение реализуется на основе того, что есть в команде, т.е. решение адаптируется под ресурсы которые находятся в распоряжении. Второй – когда бюджет решения можно подстроить под выбор новых технологий (включая обучение)
После, автор классифицирует бюджет под разные виды компаний. В собственном бизнесе без финансирования расходы будут сокращаться любыми возможными способами, в стартапах бюджет зависит от финансирования, в small-medium business (smb) бюджеты выше чем в стартапах, но отчитываться о тратах придется. А в крупных организациях бюджеты самые высокие. В конце найдете рассуждения о том, откуда могут появляться затраты (явная стоимость и не явная стоимость решения). При этом, автор советует оценивать затраты решения не абсолютным числом (напримре 100$), а процентом от текущих расходов (при расходах в 100$ еще 100$ расходов много, а при расходах в 100 000$ - капля в море)
#cost #desicion_making
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Shopify Manages its Petabyte Scale MySQL Database
Очередная статья из серии «как в компании X решили проблему Y». На этот раз shopify и скейлинг петабайтных MySQL баз. Секрет строится вокруг трех направлений: балансировка шардов без даунтаймов, поддержка read консистентности через репликацию и бекапы. Статья как раз рассказывает о каждом из направлений.
В случае с балансировкой шардов рассказывается о том, что каждый шард содержит всю информацию о конкретном магазине, что помогает в управлении нагрузкой в случае распродаж или роста магазина (иногда из-за legal проблем, но об этом в статье не говорится). В случае резкого роста, магазин может мигрировать в отдельный шард. Плюс, показывается как происходит поиск шарда под запрос, балансировка, миграция в три шага.
В случае с консистентностью, рассказывается о проблеме потери актуального состояния данных во время реплицирования. В качестве решения, в компании пробовали tight и causal consistency, но в итоге остановились на monotonic read consistency (когда нельзя посмотреть старые данные). А последней части рассказывается как происходит бекап и восстановление.
#how_it_works #sql
—————————————
Testing exceptions
Кажется, что в TDD можно описать success path сценарии и жить счастливо. На деле, без failure path сценариев нельзя понять на сколько корректно обрабатываются ошибки. Автор статьи делится личным опытом тестирования failure path сценариев. Поднимается три темы:
- Как использовать мок объекты для тестирования исключений;
- Является ли эксепшен контрактом объекта;
- Как реализовать интеграционный тест для failure path;
Важно: учтите, что примеры в статье сфокусированы на xUnit и дотнете.
Русский перевод
#testing #tdd
—————————————
Don't Break the Bank: Smart Spending on Software Architecture
Принятие решений на основе цен сложная тема, при этом без бюджетов никуда. А о бюджете говорят редко в контексте разработки. Сегодняшняя статья как раз посвящена теме бюджета в компании. В начале текста рассказывается о двух видах бюджета: Tight и Flexible. Первый жесткий, когда нет времени на обучение или развитие, решение реализуется на основе того, что есть в команде, т.е. решение адаптируется под ресурсы которые находятся в распоряжении. Второй – когда бюджет решения можно подстроить под выбор новых технологий (включая обучение)
После, автор классифицирует бюджет под разные виды компаний. В собственном бизнесе без финансирования расходы будут сокращаться любыми возможными способами, в стартапах бюджет зависит от финансирования, в small-medium business (smb) бюджеты выше чем в стартапах, но отчитываться о тратах придется. А в крупных организациях бюджеты самые высокие. В конце найдете рассуждения о том, откуда могут появляться затраты (явная стоимость и не явная стоимость решения). При этом, автор советует оценивать затраты решения не абсолютным числом (напримре 100$), а процентом от текущих расходов (при расходах в 100$ еще 100$ расходов много, а при расходах в 100 000$ - капля в море)
#cost #desicion_making
Новый ответ: как «предсказать» какой система будет в будущем
Давайте договоримся, угадать будущие требования невозможно. Но реально предположить область, в которой система будет развиваться в будущем. Один из способов предположения описал в сегодняшнем ответе. Никакой кофейной гущи, будем определять system context из системной инженерии и набор требований (больше характеристик) и ограничений, которые накладываются на систему интереса внешним миром.
Как «предсказать» какой система будет в будущем
Сразу скажу, подход не серебряная пуля и не для каждого случая. Но, надеюсь что идея поможет в принятии долгосрочных решений, либо в понимании того, куда двигать техническую систему в компании в ближайший год. Также будет интересно узнать как сами предполагаете, что с системой будет через год и на сколько точными выходят «предсказания».
Давайте договоримся, угадать будущие требования невозможно. Но реально предположить область, в которой система будет развиваться в будущем. Один из способов предположения описал в сегодняшнем ответе. Никакой кофейной гущи, будем определять system context из системной инженерии и набор требований (больше характеристик) и ограничений, которые накладываются на систему интереса внешним миром.
Как «предсказать» какой система будет в будущем
Сразу скажу, подход не серебряная пуля и не для каждого случая. Но, надеюсь что идея поможет в принятии долгосрочных решений, либо в понимании того, куда двигать техническую систему в компании в ближайший год. Также будет интересно узнать как сами предполагаете, что с системой будет через год и на сколько точными выходят «предсказания».
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
A Model for Debug Complexity
Автор статьи пытается описать математическую модель для определения сложности отладки программ. При этом, сразу предупреждает, что модель не идеальная и можно придумать лучше.
Сначала предлагается анализировать время, за которое человек изучит каждую строчку программы для поиска ошибки. Но одна строчка кода мало о чем говорит, поэтому предлагается расширить понятие на каждую переменную, находящуюся в строчке. После предлагается оптимизация: предположение, что строчка кода меняет только одну переменную и разделение программы по середине, чтобы сразу проверить корректность кода в середине флоу (а не в начале). В конце проверяется полученная модель после оптимизаций на корректность, что получается с натяжкой.
Важно: модель из статьи сложно с ходу взять «в продакшен», но как идею для дальнейшего улучшения и написания fitness functions для системы – почему бы и нет.
#debugging #math_models #fintess_functions
—————————————
Evolving from Rule-based Classifier: Machine Learning Powered Auto Remediation in Netflix Data…
В нетфликсе крутится тысячи воркфлоу и миллионы джоб которые иногда падают по разным причинам, например OOM или еще что. Что бы понять что за ошибки и автоматически каждую чинить, в компании сделали сервис, который классифицирует ошибки на основе правил. Но с ним тоже не все так радужно вышло из-за того, что при росте ошибок, классификатор не справляется с работой. Поэтому, инженеры решили написать классификатор на основе ML, который определяет что за ошибка и отдает варианты решения человеку (а иногда самостоятельно решая проблемы).
Дальше в тексте рассказывается, как работает классификатор состоящий из 3 сервисов и из каких источников собираются данные. При этом, описывается и процесс обучения модели предикшена. В конце описывается как система попадает в продакшн и какие выводы после работы были получены.
Русский перевод гугл транслейтом
#ml #errors
—————————————
How we run migrations across 2,800 microservices
Одна из проблем распределенных систем – как поддерживать актуальные версии библиотек в каждом из сервисов. Своим опытом делится компания, в которой крутится 2800+ сервисов. В компании, вместо того, чтобы перекладывать ответственность за обновления на каждую команду, в компании решили выделить одну команду, которая занималась бы миграцией на новые версии библиотек. В тексте показано, как происходил переход с OpenTracing на OpenTelemetry (учтите, что описывается мало деталей).
Процесс миграции описывается в 7 шагов:
1. Планирование и обсуждение необходимости миграции;
2. Создание абстракции-обертки для старой библиотеки;
3. Анализ функций, которые нужны для работы библиотеки;
4. Добавление новой библиотеки в обертку;
5. Деплой сервисов с новой версией библиотеки;
6. Включение «фича флага» для запуска новой библиотеки;
7. Удаление старой библиотеки;
В конце даются советы и важно отметить, что подход вряд-ли подойдет в случае миграции на новую версию одной и той же библиотеки (если в языке нельзя одновременно держать две версии библиотеки). Но, описанный подход можно модернизировать под собственные нужды.
#distributed_systems
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
A Model for Debug Complexity
Автор статьи пытается описать математическую модель для определения сложности отладки программ. При этом, сразу предупреждает, что модель не идеальная и можно придумать лучше.
Сначала предлагается анализировать время, за которое человек изучит каждую строчку программы для поиска ошибки. Но одна строчка кода мало о чем говорит, поэтому предлагается расширить понятие на каждую переменную, находящуюся в строчке. После предлагается оптимизация: предположение, что строчка кода меняет только одну переменную и разделение программы по середине, чтобы сразу проверить корректность кода в середине флоу (а не в начале). В конце проверяется полученная модель после оптимизаций на корректность, что получается с натяжкой.
Важно: модель из статьи сложно с ходу взять «в продакшен», но как идею для дальнейшего улучшения и написания fitness functions для системы – почему бы и нет.
#debugging #math_models #fintess_functions
—————————————
Evolving from Rule-based Classifier: Machine Learning Powered Auto Remediation in Netflix Data…
В нетфликсе крутится тысячи воркфлоу и миллионы джоб которые иногда падают по разным причинам, например OOM или еще что. Что бы понять что за ошибки и автоматически каждую чинить, в компании сделали сервис, который классифицирует ошибки на основе правил. Но с ним тоже не все так радужно вышло из-за того, что при росте ошибок, классификатор не справляется с работой. Поэтому, инженеры решили написать классификатор на основе ML, который определяет что за ошибка и отдает варианты решения человеку (а иногда самостоятельно решая проблемы).
Дальше в тексте рассказывается, как работает классификатор состоящий из 3 сервисов и из каких источников собираются данные. При этом, описывается и процесс обучения модели предикшена. В конце описывается как система попадает в продакшн и какие выводы после работы были получены.
Русский перевод гугл транслейтом
#ml #errors
—————————————
How we run migrations across 2,800 microservices
Одна из проблем распределенных систем – как поддерживать актуальные версии библиотек в каждом из сервисов. Своим опытом делится компания, в которой крутится 2800+ сервисов. В компании, вместо того, чтобы перекладывать ответственность за обновления на каждую команду, в компании решили выделить одну команду, которая занималась бы миграцией на новые версии библиотек. В тексте показано, как происходил переход с OpenTracing на OpenTelemetry (учтите, что описывается мало деталей).
Процесс миграции описывается в 7 шагов:
1. Планирование и обсуждение необходимости миграции;
2. Создание абстракции-обертки для старой библиотеки;
3. Анализ функций, которые нужны для работы библиотеки;
4. Добавление новой библиотеки в обертку;
5. Деплой сервисов с новой версией библиотеки;
6. Включение «фича флага» для запуска новой библиотеки;
7. Удаление старой библиотеки;
В конце даются советы и важно отметить, что подход вряд-ли подойдет в случае миграции на новую версию одной и той же библиотеки (если в языке нельзя одновременно держать две версии библиотеки). Но, описанный подход можно модернизировать под собственные нужды.
#distributed_systems
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How SQLite made Notion 30% Faster
Короткая статья о перфоманс оптимизациях в ноушене. Изначальная проблема связана с медленной работой навигации между страницами. Причем для пустых страниц код работал адекватно.
Автор статьи рассказывает как решалась проблема в компании, но в начале описывает три причины почему возникла подобная ситуация: внешние интеграции, большое количество API вызовов на клиенте и малое количество cpu у клиентов.
Для решения проблем решили воспользоваться клиентским стораджем. Но после использования sqlite на стороне дестктоп и мобильного приложений, решили, что стоит попробовать использовать базу и для фронтенда. В чем помог webAssembly и запуск бд в браузере. При этом, возникли новые проблемы:
- Web worker может быть только один для одного таба, при этом лочится открытый файл базы для записи в других табах. Решили через агалог коннекшен пулла (если правильно понял) – SharedWorker;
- Первоначальная загрузка страницы стала хуже из-за загрузки и запуска базы. Исправили заменив порядок загрузки: сначала грузим страницу, потом базу;
#performance #sqlite #web_assembly
—————————————
Why, How We Built a Primary-Replica Architecture
История компании, которая переехала с AWS Redshift на ClickHouse и получила новых проблем, решение которых описано в статье. Изначально выбрали redshift для аналитических запросов, но с ростом данных появились проблемы с ценой и перфомансом. Из-за чего и переехали на кликхаус. После чего возникли новые проблемы: скейлинг стораджа под рост данных и проблемы с дисками.
Для исправления проблем, в компании решили внедрить JuiceFS, распределенную файловую систему с высокой производительностью. Файловая система была выбрана из-за функции моментальных снимков для реализации архитектуры первичной реплики для ClickHouse. А как работает JuiceFS и создаются реплики для кликхауса можно прочитать в статье, но учтите, что статья больше об инфраструктуре, чем о работе с кликхаусом.
#clickhouse #file_systems
—————————————
Improving Application Availability: The Basics
Availability – характеристика которая часто всплывает в system design interview и в рабочих буднях. Поэтому сегодня серия статей (на текущий момент пока 3 статьи) об availability в системах.
Автор начинает с объяснения характеристики, говорит зачем и что показывает. Плюс объясняет концепцию девяток. После, связывается цена и сложность системы со значением доступности. Затем затрагивается важная тема приоритетов доступности. Так как нельзя сказать, что система целиком важна, придется выбирать какие части системы приоритетнее в плане availability. Тут рассказывается о четырех уровнях и как каждый уровень влияет на доступность.
Во второй статье затрагивается тема избыточности как на уровне ресурсов и серверов, так и данных (распределенные репликации как раз об этом). А в третьей – как Graceful Degradation и асинхронные коммуникации помогают с availability.
Статья больше обзорная. Поэтому, если плохо ориентируетесь в характеристике – статью стоит посмотреть. Если ждете хардкора, то можно пропустить.
#availability
——— одной строкой ———
- Учитывайте каждую интеграцию в системе, особенно когда нагрузка растет. Иначе будете как яндекс
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How SQLite made Notion 30% Faster
Короткая статья о перфоманс оптимизациях в ноушене. Изначальная проблема связана с медленной работой навигации между страницами. Причем для пустых страниц код работал адекватно.
Автор статьи рассказывает как решалась проблема в компании, но в начале описывает три причины почему возникла подобная ситуация: внешние интеграции, большое количество API вызовов на клиенте и малое количество cpu у клиентов.
Для решения проблем решили воспользоваться клиентским стораджем. Но после использования sqlite на стороне дестктоп и мобильного приложений, решили, что стоит попробовать использовать базу и для фронтенда. В чем помог webAssembly и запуск бд в браузере. При этом, возникли новые проблемы:
- Web worker может быть только один для одного таба, при этом лочится открытый файл базы для записи в других табах. Решили через агалог коннекшен пулла (если правильно понял) – SharedWorker;
- Первоначальная загрузка страницы стала хуже из-за загрузки и запуска базы. Исправили заменив порядок загрузки: сначала грузим страницу, потом базу;
#performance #sqlite #web_assembly
—————————————
Why, How We Built a Primary-Replica Architecture
История компании, которая переехала с AWS Redshift на ClickHouse и получила новых проблем, решение которых описано в статье. Изначально выбрали redshift для аналитических запросов, но с ростом данных появились проблемы с ценой и перфомансом. Из-за чего и переехали на кликхаус. После чего возникли новые проблемы: скейлинг стораджа под рост данных и проблемы с дисками.
Для исправления проблем, в компании решили внедрить JuiceFS, распределенную файловую систему с высокой производительностью. Файловая система была выбрана из-за функции моментальных снимков для реализации архитектуры первичной реплики для ClickHouse. А как работает JuiceFS и создаются реплики для кликхауса можно прочитать в статье, но учтите, что статья больше об инфраструктуре, чем о работе с кликхаусом.
#clickhouse #file_systems
—————————————
Improving Application Availability: The Basics
Availability – характеристика которая часто всплывает в system design interview и в рабочих буднях. Поэтому сегодня серия статей (на текущий момент пока 3 статьи) об availability в системах.
Автор начинает с объяснения характеристики, говорит зачем и что показывает. Плюс объясняет концепцию девяток. После, связывается цена и сложность системы со значением доступности. Затем затрагивается важная тема приоритетов доступности. Так как нельзя сказать, что система целиком важна, придется выбирать какие части системы приоритетнее в плане availability. Тут рассказывается о четырех уровнях и как каждый уровень влияет на доступность.
Во второй статье затрагивается тема избыточности как на уровне ресурсов и серверов, так и данных (распределенные репликации как раз об этом). А в третьей – как Graceful Degradation и асинхронные коммуникации помогают с availability.
Статья больше обзорная. Поэтому, если плохо ориентируетесь в характеристике – статью стоит посмотреть. Если ждете хардкора, то можно пропустить.
#availability
——— одной строкой ———
- Учитывайте каждую интеграцию в системе, особенно когда нагрузка растет. Иначе будете как яндекс
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Notes on Distributed Systems for Young Bloods
Статья из 2013 года с опытом автора по созданию распределенных систем. В статье нет структуры и описания того, как решить описанные проблемы. Но главная ценность текста – обозначить список проблем, которые могут встретиться в распределенной системе, что поможет людям без опыта заранее подготовиться.
Если разбить текст на темы, то получится, что автор говорит о двух вещах: проблемах, которые могут возникнуть и перечисляет советы, которые помогут в создании и поддержке распределенных систем.
В качестве проблем, описываемых автором выделю четыре:
- низкая отказоустойчивость;
- повышение стоимости создания распределенных систем;
- проблемы связанные с координацией;
- «It’s slow», как сложнейшая проблема в подобных системах;
Советов больше:
- заранее задуматься о backpressure (когда часть системы сигнализирует об отказах) и использование partially available подходов;
- сразу добавить метрики, причем желательно в персентелях;
- использование фича флагов для деплоймента;
- репликация данных поможет с partially available и reliability;
#distributed_systems
—————————————
Оптимизация хранения данных в PostgreSQL
Лонгрид о том, как оптимизировать хранение в постгресе (а еще скорость вставки и чтения). В качестве примера, автор, сделает таблицу customers с 23 столбцами (почти все number, есть и varchar) и миллионом записей. И в самом начале покажет как определить размер такой таблицы.
В тексте рассматривается четыре совета о том, как оптимизировать таблицу:
1. Определить какие данные будут использоваться и изменить таблицу под эти данные (boolean вместо number, integer вместо bigint, и так далее);
2. Самый магический совет. Связан с положением столбцов в таблице. Идея в том, чтобы в конец таблицы засунуть столбцы переменной длины, а столбцы, которые по большей части будут хранить null или значение по дефолту поставить в начало. Если таких столбцов будет много, получим ускорение чтения из таблицы (но размер станет больше на пару процентов);
3. Сгруппировать столбцы по типам. Т.е. сначала integer, потом столбцы с boolean. При этом, скорость вставки увеличивается, а размер таблицы уменьшается;
4. Использование smallint типа для небольших данных, что продолжает первый совет;
В целом, статья выглядит как оверинжиниринг и экономия на спичках, но знать что делать в ситуациях, когда все становится плохо стоит. Плюс, стоит всегда думать о нужных типах данных заранее.
#psql
—————————————
MMOG: World States and Reducing Traffic
Лонгрид о синхронизации состояния в MMO играх, а не веб приложениях. Начинается текст с двух состояний: на стороне клиента и сервера. Может показаться, что стейт лучше хранить на сервере, но подобный подход может разбиться о пропускную способность серверов. Автор сразу советует гонять между клиентом и сервером как можно меньше данных (упрощать модели персонажей, локаций, перевода игры из 3D в 2D и так далее)
После, автор добавляет еще один стейт – Publishable State, который связывает клиентский и серверный стейт и должен быть максимально сжатым. Кроме рассказа о стейте, автор также рассказывает и дает советы о том, как уменьшить Publishable State через сжатие, работу с типами и структурами. Причем, описывается четыре варианта сжатия, которые можно комбинировать.
Хоть статья выше не связана с веб приложениями, а связана с онлайн играми, но идеи и подходы можно попытаться адаптировать под другие цели (особенно идею с Publishable State и методы компрессии).
#games #state_managment
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Notes on Distributed Systems for Young Bloods
Статья из 2013 года с опытом автора по созданию распределенных систем. В статье нет структуры и описания того, как решить описанные проблемы. Но главная ценность текста – обозначить список проблем, которые могут встретиться в распределенной системе, что поможет людям без опыта заранее подготовиться.
Если разбить текст на темы, то получится, что автор говорит о двух вещах: проблемах, которые могут возникнуть и перечисляет советы, которые помогут в создании и поддержке распределенных систем.
В качестве проблем, описываемых автором выделю четыре:
- низкая отказоустойчивость;
- повышение стоимости создания распределенных систем;
- проблемы связанные с координацией;
- «It’s slow», как сложнейшая проблема в подобных системах;
Советов больше:
- заранее задуматься о backpressure (когда часть системы сигнализирует об отказах) и использование partially available подходов;
- сразу добавить метрики, причем желательно в персентелях;
- использование фича флагов для деплоймента;
- репликация данных поможет с partially available и reliability;
#distributed_systems
—————————————
Оптимизация хранения данных в PostgreSQL
Лонгрид о том, как оптимизировать хранение в постгресе (а еще скорость вставки и чтения). В качестве примера, автор, сделает таблицу customers с 23 столбцами (почти все number, есть и varchar) и миллионом записей. И в самом начале покажет как определить размер такой таблицы.
В тексте рассматривается четыре совета о том, как оптимизировать таблицу:
1. Определить какие данные будут использоваться и изменить таблицу под эти данные (boolean вместо number, integer вместо bigint, и так далее);
2. Самый магический совет. Связан с положением столбцов в таблице. Идея в том, чтобы в конец таблицы засунуть столбцы переменной длины, а столбцы, которые по большей части будут хранить null или значение по дефолту поставить в начало. Если таких столбцов будет много, получим ускорение чтения из таблицы (но размер станет больше на пару процентов);
3. Сгруппировать столбцы по типам. Т.е. сначала integer, потом столбцы с boolean. При этом, скорость вставки увеличивается, а размер таблицы уменьшается;
4. Использование smallint типа для небольших данных, что продолжает первый совет;
В целом, статья выглядит как оверинжиниринг и экономия на спичках, но знать что делать в ситуациях, когда все становится плохо стоит. Плюс, стоит всегда думать о нужных типах данных заранее.
#psql
—————————————
MMOG: World States and Reducing Traffic
Лонгрид о синхронизации состояния в MMO играх, а не веб приложениях. Начинается текст с двух состояний: на стороне клиента и сервера. Может показаться, что стейт лучше хранить на сервере, но подобный подход может разбиться о пропускную способность серверов. Автор сразу советует гонять между клиентом и сервером как можно меньше данных (упрощать модели персонажей, локаций, перевода игры из 3D в 2D и так далее)
После, автор добавляет еще один стейт – Publishable State, который связывает клиентский и серверный стейт и должен быть максимально сжатым. Кроме рассказа о стейте, автор также рассказывает и дает советы о том, как уменьшить Publishable State через сжатие, работу с типами и структурами. Причем, описывается четыре варианта сжатия, которые можно комбинировать.
Хоть статья выше не связана с веб приложениями, а связана с онлайн играми, но идеи и подходы можно попытаться адаптировать под другие цели (особенно идею с Publishable State и методы компрессии).
#games #state_managment
Запустился четвертый поток курса по анализу систем и принятию технических решений, старт 16 января
Привет!
В течение месяца будем учиться анализировать системы – определять элементы, связи и свойства (как системы, так и элементов). Благодаря чему можно обоснованно выбирать наиболее подходящее техническое решение. Если ждете выбор и работу с конкретными технологиями, подготовку к aws сертификации или подготовку к прохождению system design interview — курс не поможет. Вместо этого, акцент делается на мышлении, идеях, концепциях и как все складывается в одну картину.
Что будет:
- Работа с требованиями и стейкхолдерами;
- Взрослый поиск элементов, основанный на бизнес стратегии (и зачем на самом деле нужен DDD);
- Работа с характеристиками (их еще не функциональными требованиями или quality attributes называют) и внешними ограничениями;
- Принятие решений по структуре, видам баз данных, коммуникаций и паттернам, основываясь на характеристиках;
- Обсуждение способов описания архитектурных решений и почему важно отвечать на вопрос «что надо сделать?», вместо «как это делать?»;
- Как взаимодействовать с командой, основываясь на подобном описании;
- Урок, целиком связанный с распределенными системами (добавление, вынос, рефакторинг сервисов, фикс энтити сервисов и так далее);
- Отсылки на диско элизиум, заумь о космонавтике и бизнес эксплуатирующий кошачьи удовольствия;
⠀Курс не сделает из вас солюшен архитектора, тем более за месяц, но поможет собрать информацию вокруг темы в кучу и ответит на вопрос, почему «зависит от контекста» единственный вариант принятия решений. По сути, это выжимка моего опыта и структурирование кучи тем вокруг одной проблемы связанной с анализом систем и принятием технических решений.
При этом, я рассчитываю, что контента хватит на год самостоятельной работы и изучения (со всеми доп материалами и прочим). Получилось 5 уроков, в каждом - герой анализирует одну и ту же систему, используя больше и больше инструментов. При этом, каждый раз оказывается, что ситуация меняется, из-за чего приходится переосмыслить подходы и инструменты. В итоге, пройдя все сложности, получим оптимальную для реализации системы, удовлетворяющую всем требованиям бизнеса и других заинтересованных лиц.
Ну и самое удивительное для такого интроверта как я – p2p проверка домашек идеально вписалась в курс (это когда вам приходит N чужих домашек на проверку). Благодаря этому ученики посмотрели на чужие решения и чужой опыт (что отмечалось как один из главных плюсов курса), вместо того, чтобы вариться соло (хоть и были ситуации, когда на проверку забивали).
Полная программа и половина первого урока - на странице курса. Начало 16 января, а до 13 декабря действует промокод SA4PEPE на 10% скидки.
Марьяна отдельно попросила указать: следующий поток скорее всего не раньше лета. Платить картой любой страны, от юрлица и долями. Все еще действует образовательная лицензия школы (для налогового вычета).
Привет!
В течение месяца будем учиться анализировать системы – определять элементы, связи и свойства (как системы, так и элементов). Благодаря чему можно обоснованно выбирать наиболее подходящее техническое решение. Если ждете выбор и работу с конкретными технологиями, подготовку к aws сертификации или подготовку к прохождению system design interview — курс не поможет. Вместо этого, акцент делается на мышлении, идеях, концепциях и как все складывается в одну картину.
Что будет:
- Работа с требованиями и стейкхолдерами;
- Взрослый поиск элементов, основанный на бизнес стратегии (и зачем на самом деле нужен DDD);
- Работа с характеристиками (их еще не функциональными требованиями или quality attributes называют) и внешними ограничениями;
- Принятие решений по структуре, видам баз данных, коммуникаций и паттернам, основываясь на характеристиках;
- Обсуждение способов описания архитектурных решений и почему важно отвечать на вопрос «что надо сделать?», вместо «как это делать?»;
- Как взаимодействовать с командой, основываясь на подобном описании;
- Урок, целиком связанный с распределенными системами (добавление, вынос, рефакторинг сервисов, фикс энтити сервисов и так далее);
- Отсылки на диско элизиум, заумь о космонавтике и бизнес эксплуатирующий кошачьи удовольствия;
⠀Курс не сделает из вас солюшен архитектора, тем более за месяц, но поможет собрать информацию вокруг темы в кучу и ответит на вопрос, почему «зависит от контекста» единственный вариант принятия решений. По сути, это выжимка моего опыта и структурирование кучи тем вокруг одной проблемы связанной с анализом систем и принятием технических решений.
При этом, я рассчитываю, что контента хватит на год самостоятельной работы и изучения (со всеми доп материалами и прочим). Получилось 5 уроков, в каждом - герой анализирует одну и ту же систему, используя больше и больше инструментов. При этом, каждый раз оказывается, что ситуация меняется, из-за чего приходится переосмыслить подходы и инструменты. В итоге, пройдя все сложности, получим оптимальную для реализации системы, удовлетворяющую всем требованиям бизнеса и других заинтересованных лиц.
Ну и самое удивительное для такого интроверта как я – p2p проверка домашек идеально вписалась в курс (это когда вам приходит N чужих домашек на проверку). Благодаря этому ученики посмотрели на чужие решения и чужой опыт (что отмечалось как один из главных плюсов курса), вместо того, чтобы вариться соло (хоть и были ситуации, когда на проверку забивали).
Полная программа и половина первого урока - на странице курса. Начало 16 января, а до 13 декабря действует промокод SA4PEPE на 10% скидки.
Марьяна отдельно попросила указать: следующий поток скорее всего не раньше лета. Платить картой любой страны, от юрлица и долями. Все еще действует образовательная лицензия школы (для налогового вычета).
Новый ответ: как хранить и работать с графами в бд, если нельзя выбрать neo4j
Среди проектов с которыми работал, графы и графовые базы в частности, требовались в ~10% случаев. При этом, когда появлялась необходимость в работе с графами, возникали проблемы: либо поставить инстанс neo4j не было возможностей, либо разработчики не знали как переложить графовую структуру в базу и городили велосипеды. Поэтому сегодня отвечу на вопрос, что делать, если нужны графы, но без neo4j и при этом, закрывать задачи в джире.
Как хранить и работать с графами в бд, если нельзя выбрать neo4j
Сразу скажу, если до этого работали с графовыми базами данных и (или) проходили курс дискретной математики – ответ Америку вам не откроет. Но надеюсь, что текст поможет в ad-hoc ситуациях, либо подтолкнет к изучению теории графов.
---------
Пара организационных моментов: этот ответ – заключительный в 2024 году. В следующем году начну отвечать реже (пока планирую раз в 3-4 недели, но как в будет на деле – не знаю). Связанно это с тем, что переоценил собственные возможности, плюс вопросов в таком количестве не наберу (если хотите получить ответ связанный с архитектурой, системами или техническими штуками, анонимная еще работает).
Отдельно спасибо всем, кто в этом году читал ответы и задавал вопросы как по ответам, так и вне ответов! Это мотивирует и ценно.
Среди проектов с которыми работал, графы и графовые базы в частности, требовались в ~10% случаев. При этом, когда появлялась необходимость в работе с графами, возникали проблемы: либо поставить инстанс neo4j не было возможностей, либо разработчики не знали как переложить графовую структуру в базу и городили велосипеды. Поэтому сегодня отвечу на вопрос, что делать, если нужны графы, но без neo4j и при этом, закрывать задачи в джире.
Как хранить и работать с графами в бд, если нельзя выбрать neo4j
Сразу скажу, если до этого работали с графовыми базами данных и (или) проходили курс дискретной математики – ответ Америку вам не откроет. Но надеюсь, что текст поможет в ad-hoc ситуациях, либо подтолкнет к изучению теории графов.
---------
Пара организационных моментов: этот ответ – заключительный в 2024 году. В следующем году начну отвечать реже (пока планирую раз в 3-4 недели, но как в будет на деле – не знаю). Связанно это с тем, что переоценил собственные возможности, плюс вопросов в таком количестве не наберу (если хотите получить ответ связанный с архитектурой, системами или техническими штуками, анонимная еще работает).
Отдельно спасибо всем, кто в этом году читал ответы и задавал вопросы как по ответам, так и вне ответов! Это мотивирует и ценно.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How LinkedIn Customizes Its 7 Trillion Message Kafka Ecosystem
Статья рассказывает как используют кафку в компании, где технологию и придумали. Изначально может показаться, что статья о том, как разработчики используют кафку, на деле, текст о том, как компания поддерживает и развивает собственный форк кафки. При этом, в линкедине кафка используется для: трекинга активности юзеров, передачи сообщений в системе и сбора метрик. Для этого развернули 100 kafka кластеров с 4к+ брокеров, 100к+ топиками и 7кк+ партиций. А в день процессится 7ккк+ сообщений.
В начале текста описывается как экосистема работает в компании. В этом помогает: schema registry, клиенты (включая REST proxy для не java клиентов), инструмент для зеркалирования данных между кластерами (называется brooklin), инструмент для cluster maintenance и self-healing (cruise control) и пайплайн для аудита и метрик.
После, описывается как компания поддерживает собственный форк кафки. Присутствует описание работы с релизными ветками. Плюсом описывается как происходит добавление новых фичей в линкедин версию кафки. При этом, добавили flow chart того, как определяется в какую из веток попадет коммит. А в конце приводятся примеры изменений над основной версией кафки, которые сделали в компании (улучшили скалабилити, добавили maintenance mode и так далее).
#how_it_works #kafka
—————————————
How Nginx Handles Thousands of Concurrent Requests
Сразу отмечу, статья короткая и без хардкора. Подойдет тем, кто не знает как работает nginx и не хочет разбираться в кишках. Для большего погружения, лучше чем The Architecture of Open Source Applications (Volume 2): nginx еще не придумали.
В тексте рассматривается два подхода к обработке запросов: one request per process и event-driven. Первый подход подразумевает, что под каждый запрос будет создан тредом, который его обработает (если правильно помню, так работал апач когда-то). В случае с event-driven идея заключается в том, что есть заранее созданный «пул» воркеров, которые реагируют на новые запросы и обрабатывают запросы по мере поступления. За счет такого event-driven подхода память и cpu не увеличивается по мере увеличения нагрузки.
#nginx
—————————————
Why Payments Engineers Should Avoid State Machines
Если открыть ютуб или гугл, найдете туториалы по созданию платежных систем на основе стейт машины. На деле все не так просто, в частности, когда дело касается продакшн кода, а не system design interview. Поэтому сегодня статья, в которой автор объясняет почему стейт машины приносят проблемы в платежных системах.
Спойлер к тексту: стейт машины не могут прокручивать состояние в обратную сторону (в прошлое), т.е. стейт машины не позволят добиться replayability (как минимум поможет для обработки споров клиентов). Еще одна причина, почему скейт машина может помешать – проблемы с scalability, из-за скейлинга стейт машин под каждого клиента. Вместо этого автор предлагает рассмотреть pull-based подход основанный на событиях.
В статье найдете подробное рассуждение автора, с объяснением каждого пункта. Также добавлю, что текст касается только платежных систем и других доменов, где replayability важен для бизнес процесса (а не только для аудита).
#state_machine #payment_systems
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How LinkedIn Customizes Its 7 Trillion Message Kafka Ecosystem
Статья рассказывает как используют кафку в компании, где технологию и придумали. Изначально может показаться, что статья о том, как разработчики используют кафку, на деле, текст о том, как компания поддерживает и развивает собственный форк кафки. При этом, в линкедине кафка используется для: трекинга активности юзеров, передачи сообщений в системе и сбора метрик. Для этого развернули 100 kafka кластеров с 4к+ брокеров, 100к+ топиками и 7кк+ партиций. А в день процессится 7ккк+ сообщений.
В начале текста описывается как экосистема работает в компании. В этом помогает: schema registry, клиенты (включая REST proxy для не java клиентов), инструмент для зеркалирования данных между кластерами (называется brooklin), инструмент для cluster maintenance и self-healing (cruise control) и пайплайн для аудита и метрик.
После, описывается как компания поддерживает собственный форк кафки. Присутствует описание работы с релизными ветками. Плюсом описывается как происходит добавление новых фичей в линкедин версию кафки. При этом, добавили flow chart того, как определяется в какую из веток попадет коммит. А в конце приводятся примеры изменений над основной версией кафки, которые сделали в компании (улучшили скалабилити, добавили maintenance mode и так далее).
#how_it_works #kafka
—————————————
How Nginx Handles Thousands of Concurrent Requests
Сразу отмечу, статья короткая и без хардкора. Подойдет тем, кто не знает как работает nginx и не хочет разбираться в кишках. Для большего погружения, лучше чем The Architecture of Open Source Applications (Volume 2): nginx еще не придумали.
В тексте рассматривается два подхода к обработке запросов: one request per process и event-driven. Первый подход подразумевает, что под каждый запрос будет создан тредом, который его обработает (если правильно помню, так работал апач когда-то). В случае с event-driven идея заключается в том, что есть заранее созданный «пул» воркеров, которые реагируют на новые запросы и обрабатывают запросы по мере поступления. За счет такого event-driven подхода память и cpu не увеличивается по мере увеличения нагрузки.
#nginx
—————————————
Why Payments Engineers Should Avoid State Machines
Если открыть ютуб или гугл, найдете туториалы по созданию платежных систем на основе стейт машины. На деле все не так просто, в частности, когда дело касается продакшн кода, а не system design interview. Поэтому сегодня статья, в которой автор объясняет почему стейт машины приносят проблемы в платежных системах.
Спойлер к тексту: стейт машины не могут прокручивать состояние в обратную сторону (в прошлое), т.е. стейт машины не позволят добиться replayability (как минимум поможет для обработки споров клиентов). Еще одна причина, почему скейт машина может помешать – проблемы с scalability, из-за скейлинга стейт машин под каждого клиента. Вместо этого автор предлагает рассмотреть pull-based подход основанный на событиях.
В статье найдете подробное рассуждение автора, с объяснением каждого пункта. Также добавлю, что текст касается только платежных систем и других доменов, где replayability важен для бизнес процесса (а не только для аудита).
#state_machine #payment_systems
Пятничное чтиво
Канал уходит в ежегодный зимний отпуск, встретимся после 13 января. Спасибо каждому кто читает канал, комментирует и задает вопросы ❤️
Сегодняшний список включает четыре книги, два пейпера, один курс на ютубе и пару тем для изучения. На материалы стоит обратить внимание, если хотите во время длинных отпусков потратить время на обучение или прокачаться в системах. Так как 2024 год посвятил солюшен архитектуре и системной инженерии, то и материалы будут о системах.
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Книги
Architecture Modernization
Книга, в которой автор пытается объяснить как изменять системы. Может показаться, что модернизация автоматически подразумевает переписывание монолита на сервисы, но это частный случай. Так, могут поменять условия существования бизнеса, новая гипотеза выстрелит и перетянет на себя развитие бизнеса и так далее.
При этом, в книге упоминаются «популярные» концепции и подходы: team topology, wardley mapping, strategy DDD с core domain chart и EventStorming, способы выноса сервисов, DevEx и так далее. Так как собственные ожидания оказались выше, чем то, что получил по прочтению, то в личном рейтинге поставил оценку ниже среднего. Из минусов также отмечу сложную формулировку и слабую сквозную идею (допускаю, что личная проблема).
Книгу посоветую в случае, если хотите разобраться с «популярными» концепциями и подходами, а читать по отдельности о каждом времени нет.
Finding software boundaries for fast flow
Если автор прошлой книги пытался замахнуться на обширную тему в 500 страниц, то эта короткая брошюра с пятью статьями (50 страниц) покрывает идею того, как бизнес и разработка связаны. В книге найдете следующие статьи:
- Как связывается wardley mapping и концепции strategy DDD (советую хотя бы эту часть, так как покажет, что идеи из strategy DDD на самом деле не уникальны и подход можно заменить на другой, без потери смысла);
- Alberto Brandolini (автор EventStorming) описывает как связан team topology и context map (привязка к EventStorming тоже присутствует). При этом, следующий текст описывает аналогичную связь, но другим языком и другим автором;
- В четвертой статье описывается как используя стратегический ддд и тим топологию проводить анализ и развитие сервисов;
- Пятая описывает как находить границы бизнеса (тут уже описанные выше концепции используются);
Единственное, учтите, что это лид магнит team topology, поэтому к тексту стоит относиться со скепсисом.
Developing High Quality Data Models
Если времени (или сил) только на одну книгу, при этом хотите развиваться как разработчик или аналитик – однозначный мастхэв. Сразу скажу, книга старая (2011 год), но поможет в понимании модели данных (как концептуальных, так и логических). Благодаря чему, улучшите понимание проекта и следовательно качество кода (который опирается, в том числе, на модель данных). Из книги узнаете о разных моделях данных, основы entity relationship, как модели данных связаны с энтерпрайз архитектурой и основные принципы моделирования.
Советую ознакомиться с первой половиной, так как последняя глава затрагивает «High-Quality Data Model framework», который до знакомства с книгой нигде не встречал.
Канал уходит в ежегодный зимний отпуск, встретимся после 13 января. Спасибо каждому кто читает канал, комментирует и задает вопросы ❤️
Сегодняшний список включает четыре книги, два пейпера, один курс на ютубе и пару тем для изучения. На материалы стоит обратить внимание, если хотите во время длинных отпусков потратить время на обучение или прокачаться в системах. Так как 2024 год посвятил солюшен архитектуре и системной инженерии, то и материалы будут о системах.
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Книги
Architecture Modernization
Книга, в которой автор пытается объяснить как изменять системы. Может показаться, что модернизация автоматически подразумевает переписывание монолита на сервисы, но это частный случай. Так, могут поменять условия существования бизнеса, новая гипотеза выстрелит и перетянет на себя развитие бизнеса и так далее.
При этом, в книге упоминаются «популярные» концепции и подходы: team topology, wardley mapping, strategy DDD с core domain chart и EventStorming, способы выноса сервисов, DevEx и так далее. Так как собственные ожидания оказались выше, чем то, что получил по прочтению, то в личном рейтинге поставил оценку ниже среднего. Из минусов также отмечу сложную формулировку и слабую сквозную идею (допускаю, что личная проблема).
Книгу посоветую в случае, если хотите разобраться с «популярными» концепциями и подходами, а читать по отдельности о каждом времени нет.
Finding software boundaries for fast flow
Если автор прошлой книги пытался замахнуться на обширную тему в 500 страниц, то эта короткая брошюра с пятью статьями (50 страниц) покрывает идею того, как бизнес и разработка связаны. В книге найдете следующие статьи:
- Как связывается wardley mapping и концепции strategy DDD (советую хотя бы эту часть, так как покажет, что идеи из strategy DDD на самом деле не уникальны и подход можно заменить на другой, без потери смысла);
- Alberto Brandolini (автор EventStorming) описывает как связан team topology и context map (привязка к EventStorming тоже присутствует). При этом, следующий текст описывает аналогичную связь, но другим языком и другим автором;
- В четвертой статье описывается как используя стратегический ддд и тим топологию проводить анализ и развитие сервисов;
- Пятая описывает как находить границы бизнеса (тут уже описанные выше концепции используются);
Единственное, учтите, что это лид магнит team topology, поэтому к тексту стоит относиться со скепсисом.
Developing High Quality Data Models
Если времени (или сил) только на одну книгу, при этом хотите развиваться как разработчик или аналитик – однозначный мастхэв. Сразу скажу, книга старая (2011 год), но поможет в понимании модели данных (как концептуальных, так и логических). Благодаря чему, улучшите понимание проекта и следовательно качество кода (который опирается, в том числе, на модель данных). Из книги узнаете о разных моделях данных, основы entity relationship, как модели данных связаны с энтерпрайз архитектурой и основные принципы моделирования.
Советую ознакомиться с первой половиной, так как последняя глава затрагивает «High-Quality Data Model framework», который до знакомства с книгой нигде не встречал.
Продолжение
Пейперы
A Practical Model for Measuring Maintainability
Maintainability (как и modifiability) характеристика, о которой часто упоминают в контексте разработки, но редко когда понимают как оценить maintainability как свойство. Иногда предлагается оценивать через «user story-like» подход, когда, через описание сценариев предполагается требуемое значение или нет (пример: «при возникновении ошибки в оформлении заказов, исправленная версия кода окажется в продакшене через 2 часа»).
Авторы пейпера как раз пытаются определить, как считать характеристику, для чего придумали мат модель, которую планируют развивать в будущем. А если сделаете инструмент для популярных языков на основе описанной модели, может получиться DevEx стартап (либо же fitness function инструмент как opensource проект).
CRISP: Critical Path Analysis of Large-Scale Microservice Architectures
Пейпер от убера в котором описывается подход CRISP (Critical Path Analysis of Large-Scale Microservice Architectures) для трассировки RPC в распределенных системах. Изначальная проблема в том, что текущие трейсинг инструменты собирают много данных, но не помогают в определении критических мест в системах, размером с убер. Описанный в пейпере инструмент как раз помогает либо понять что происходит с конкретным эндпоинтом и где проблема, либо найти части системы, которые больше всего влияют на перфоманс, либо поиск аномалий в коммуникациях. А как работает CRISP – читайте в пейпере.
—————————————
Остальное
Ответы на 8 вопросов
С августа этого года отвечаю на вопросы связанные с системами и архитектурой. По ссылке можно найти полный список ответов. Темы разные, начиная от EventStorming и концептуальных моделей данных, заканчивая обсидианом, графами, менеджментом и так далее.
Distributed Systems 1.1: Introduction
Автор кабанчика 4 года назад выложил курс о распределенных системах, 23 видео в сумме. Темы связаны с низкоуровневой работой распределенных систем: RPC, consistency models, fault tolerance, clock synchronization, replications, quorums (включая raft) и так далее.
Полезно будет для тех, кто хочет разобраться в низкоуровневой составляющей распределенных систем и сделать базу данных. Если ожидаете, что в лекциях расскажут как писать микросервисы – к сожалению, курс не об этом.
Factorio: Space Age
Если пропустили, вышло дополнение к факторио, основанное на space exploration моде. Если не играли в факторио и не знаете чем игра поможет в разработке, советую цикл из двух статей об анализе архитектурных стилей на основе фабрик из факторио.
ДРАКОН
Если учить теории желания нет, Team Topology не интересен, а строить галактические фабрики в факторио скучно, но хочется прикоснуться к космосу – можно посмотреть на ДРАКОН. Это визуальный язык программирования, на котором писали автоматику для бурана. На сайте найдете учебник, а также найти интерпретатор (DRAKON Editor работает под мак).
gonec: 1С фреймворк для микросервисов
Если учить теории желания нет, Team Topology не интересен, строить галактические фабрики в факторио скучно, а изучать визуальный язык программирования желания нет – стоит попробовать написать микросервисы на 1С. В этом поможет фреймворк gonec. Ссылка скорее шуточная, но может кого заинтересует.
Пейперы
A Practical Model for Measuring Maintainability
Maintainability (как и modifiability) характеристика, о которой часто упоминают в контексте разработки, но редко когда понимают как оценить maintainability как свойство. Иногда предлагается оценивать через «user story-like» подход, когда, через описание сценариев предполагается требуемое значение или нет (пример: «при возникновении ошибки в оформлении заказов, исправленная версия кода окажется в продакшене через 2 часа»).
Авторы пейпера как раз пытаются определить, как считать характеристику, для чего придумали мат модель, которую планируют развивать в будущем. А если сделаете инструмент для популярных языков на основе описанной модели, может получиться DevEx стартап (либо же fitness function инструмент как opensource проект).
CRISP: Critical Path Analysis of Large-Scale Microservice Architectures
Пейпер от убера в котором описывается подход CRISP (Critical Path Analysis of Large-Scale Microservice Architectures) для трассировки RPC в распределенных системах. Изначальная проблема в том, что текущие трейсинг инструменты собирают много данных, но не помогают в определении критических мест в системах, размером с убер. Описанный в пейпере инструмент как раз помогает либо понять что происходит с конкретным эндпоинтом и где проблема, либо найти части системы, которые больше всего влияют на перфоманс, либо поиск аномалий в коммуникациях. А как работает CRISP – читайте в пейпере.
—————————————
Остальное
Ответы на 8 вопросов
С августа этого года отвечаю на вопросы связанные с системами и архитектурой. По ссылке можно найти полный список ответов. Темы разные, начиная от EventStorming и концептуальных моделей данных, заканчивая обсидианом, графами, менеджментом и так далее.
Distributed Systems 1.1: Introduction
Автор кабанчика 4 года назад выложил курс о распределенных системах, 23 видео в сумме. Темы связаны с низкоуровневой работой распределенных систем: RPC, consistency models, fault tolerance, clock synchronization, replications, quorums (включая raft) и так далее.
Полезно будет для тех, кто хочет разобраться в низкоуровневой составляющей распределенных систем и сделать базу данных. Если ожидаете, что в лекциях расскажут как писать микросервисы – к сожалению, курс не об этом.
Factorio: Space Age
Если пропустили, вышло дополнение к факторио, основанное на space exploration моде. Если не играли в факторио и не знаете чем игра поможет в разработке, советую цикл из двух статей об анализе архитектурных стилей на основе фабрик из факторио.
ДРАКОН
Если учить теории желания нет, Team Topology не интересен, а строить галактические фабрики в факторио скучно, но хочется прикоснуться к космосу – можно посмотреть на ДРАКОН. Это визуальный язык программирования, на котором писали автоматику для бурана. На сайте найдете учебник, а также найти интерпретатор (DRAKON Editor работает под мак).
gonec: 1С фреймворк для микросервисов
Если учить теории желания нет, Team Topology не интересен, строить галактические фабрики в факторио скучно, а изучать визуальный язык программирования желания нет – стоит попробовать написать микросервисы на 1С. В этом поможет фреймворк gonec. Ссылка скорее шуточная, но может кого заинтересует.
Канал возвращается из отпуска
Это информационный пост. Хочу заранее написать то, что ждать в ближайшее пол года от канала.
1. Пятничные ссылки без изменений, первые в 2025 году будут уже в это пятницу;
2. В четверг стартует новый поток Анализа Систем. Будем рисовать квадраты и обосновывать решения основываясь на бизнес;
3. В этом году ответы на вопросы будут раз в месяц, также по понедельникам (на чаще нет вопросов и ресурсов). Ответы из 2024 года можно посмотреть на сайте, а задать вопрос связанный с системами/архитектурой/техническими шуткам можно анонимно или пишите в личку;
4. Новая версия курса по асинхронным коммуникациям (АА) пишется. Больше конкретики будет в марте (во всяком случае такие планы);
Если возникли вопросы или предложения, пишите в комментарии к посту.
Это информационный пост. Хочу заранее написать то, что ждать в ближайшее пол года от канала.
1. Пятничные ссылки без изменений, первые в 2025 году будут уже в это пятницу;
2. В четверг стартует новый поток Анализа Систем. Будем рисовать квадраты и обосновывать решения основываясь на бизнес;
3. В этом году ответы на вопросы будут раз в месяц, также по понедельникам (на чаще нет вопросов и ресурсов). Ответы из 2024 года можно посмотреть на сайте, а задать вопрос связанный с системами/архитектурой/техническими шуткам можно анонимно или пишите в личку;
4. Новая версия курса по асинхронным коммуникациям (АА) пишется. Больше конкретики будет в марте (во всяком случае такие планы);
Если возникли вопросы или предложения, пишите в комментарии к посту.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Хороший ретрай, плохой ретрай, или История одного падения
Продолжение поста о коммуникациях в яндекс такси, только вместо идемпотентности обсуждаются ретраи.
В первой части описывается ситуация, когда ретраи кратковременные (пара минут).
Сначала ретраи предлагается сделать через цикл с фиксированным временем запросов (делаем запрос, получаем ошибку, ждет N времени, повторить M раз). После, объясняется как фиксированный цикл может привести к Retry Storm. А с исправлением проблем поможет использование экспоненциального откладывания (Exponential Backoff). Т.е. делаем запрос, если ошибка, то сначала ждем условно секунду, потом две, потом пять и так далее. Кроме этого, описывается подход со случайной задержкой (jitter), который выбирает случайное значение из рейджа, что еще сильнее уменьшает нагрузку на упавший сервер.
Следующая часть текста описывает проблемы, связанные с падением сервисов на продолжительный промежуток времени (часы). Тут проблема с накоплением запросов, которые увеличивают нагрузку на систему в разы. Тут описывается фундаментальная проблема связанная с триггерами ошибок и как растет нагрузка в случае возникновения проблем. Как решение – отключение ретраев когда сервис совсем лег (т.е. количество ошибок сервиса превышает процентный порог). В качестве реализации рассматривается два подхода: retry circuit breaker и retry budget.
Отдельно напишу, что понравились примеры симуляции поведения системы из статьи. Полезный навык, в статье можно посмотреть как организовывать подобное
Английский перевод
#sync_communications #retries
—————————————
10 Things to Avoid in Domain-Driven Design (DDD)
Короткая статья с очевидными советами связанными с DDD (точнее с тактическим DDD и реализацией domain model pattern). В список «проблем» входят:
- Фиксация на технических паттернах, вместо анализа доменной модели;
- Переусложнение доменной модели;
- Игнорирование ubiquitous language;
- Проблемы с пониманием bounded contexts (включая работу с entity, value objects и aggregates и domain events);
- Игнорирование доменных экспертов;
- Считать DDD серебряной пулей;
К каждой «проблеме» прилагается краткое описание как избегать подобных ситуаций. Если читали learning DDD или синюю/красную книгу по DDD, можно пропустить.
#DDD
—————————————
Exploring Google Spanner: The Backbone of Globally Distributed Systems
Еще одна статья из серии «как в X сделали Y». На этот автор пересказывает пейпер гугла о работе распределенной бд Google Spanner. При этом, цель создания подобной бд в том, что бы добиться low-latency, strong consistency и high availability.
Сначала автор рассказывает о Google Spanner – глобально распределенной, горизонтально масштабируемой бд, которая сочетает реляционные и NoSQL базы (SQL-like запросы с strong consistency и availability). При этом, используется собственная реализация часов для синхронизации данных. При этом, заявляется поддержка multi-site transactional consistency при низком лейтенси.
После описывается как бд работает. Там не так много, в основном рассказ о том, как реализация часов помогает, но упоминается, что CockroachDB вдохновилась бд от гугла. Из минусов – высокие инфраструктурные косты, задержка в случае гео транзакций.
Если пересказа не хватит, автор дает ссылку на пейпер, в котором найдете подробное описание работы бд.
#how_it_works #distributed_systems
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Хороший ретрай, плохой ретрай, или История одного падения
Продолжение поста о коммуникациях в яндекс такси, только вместо идемпотентности обсуждаются ретраи.
В первой части описывается ситуация, когда ретраи кратковременные (пара минут).
Сначала ретраи предлагается сделать через цикл с фиксированным временем запросов (делаем запрос, получаем ошибку, ждет N времени, повторить M раз). После, объясняется как фиксированный цикл может привести к Retry Storm. А с исправлением проблем поможет использование экспоненциального откладывания (Exponential Backoff). Т.е. делаем запрос, если ошибка, то сначала ждем условно секунду, потом две, потом пять и так далее. Кроме этого, описывается подход со случайной задержкой (jitter), который выбирает случайное значение из рейджа, что еще сильнее уменьшает нагрузку на упавший сервер.
Следующая часть текста описывает проблемы, связанные с падением сервисов на продолжительный промежуток времени (часы). Тут проблема с накоплением запросов, которые увеличивают нагрузку на систему в разы. Тут описывается фундаментальная проблема связанная с триггерами ошибок и как растет нагрузка в случае возникновения проблем. Как решение – отключение ретраев когда сервис совсем лег (т.е. количество ошибок сервиса превышает процентный порог). В качестве реализации рассматривается два подхода: retry circuit breaker и retry budget.
Отдельно напишу, что понравились примеры симуляции поведения системы из статьи. Полезный навык, в статье можно посмотреть как организовывать подобное
Английский перевод
#sync_communications #retries
—————————————
10 Things to Avoid in Domain-Driven Design (DDD)
Короткая статья с очевидными советами связанными с DDD (точнее с тактическим DDD и реализацией domain model pattern). В список «проблем» входят:
- Фиксация на технических паттернах, вместо анализа доменной модели;
- Переусложнение доменной модели;
- Игнорирование ubiquitous language;
- Проблемы с пониманием bounded contexts (включая работу с entity, value objects и aggregates и domain events);
- Игнорирование доменных экспертов;
- Считать DDD серебряной пулей;
К каждой «проблеме» прилагается краткое описание как избегать подобных ситуаций. Если читали learning DDD или синюю/красную книгу по DDD, можно пропустить.
#DDD
—————————————
Exploring Google Spanner: The Backbone of Globally Distributed Systems
Еще одна статья из серии «как в X сделали Y». На этот автор пересказывает пейпер гугла о работе распределенной бд Google Spanner. При этом, цель создания подобной бд в том, что бы добиться low-latency, strong consistency и high availability.
Сначала автор рассказывает о Google Spanner – глобально распределенной, горизонтально масштабируемой бд, которая сочетает реляционные и NoSQL базы (SQL-like запросы с strong consistency и availability). При этом, используется собственная реализация часов для синхронизации данных. При этом, заявляется поддержка multi-site transactional consistency при низком лейтенси.
После описывается как бд работает. Там не так много, в основном рассказ о том, как реализация часов помогает, но упоминается, что CockroachDB вдохновилась бд от гугла. Из минусов – высокие инфраструктурные косты, задержка в случае гео транзакций.
Если пересказа не хватит, автор дает ссылку на пейпер, в котором найдете подробное описание работы бд.
#how_it_works #distributed_systems
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Tech stack for Search system with Micro-services architecture
Поиск в распределенной системе задача со звездочкой. Помочь с принятием решения о реализации поиска должна сегодняшняя статья. Автор рассматривает два варианта: либо каждый сервис реализует собственный поиск, либо поиск по всей системе выносится в отдельный сервис. Для каждого из вариантов указываются плюсы и минусы решения,
Во второй части текста, автор, рассматривает способы реализации отдельного сервиса для поиска. Описываются возможные базы данных, способы заливки данных в сервис. В конце описывается два варианта реализации, с использованием эластика: в первом случае rabbitMQ ходит на прямую в эластик, во втором появляется прокладка в виде написанного сервиса.
Тезисный перевод на русский
#sync_communications #retries
—————————————
EP131: How Uber Served 40 Million Reads with Integrated Redis Cache?
Одна из рубрик автора, в которой берутся 3-4 темы и коротко описываются. По ссылке найдете три темы:
- как убер скейлит бд на чтение;
- из-за чего aws лямбды так быстро работают;
- шесть мест, где помогут распределенные локи;
В случае убера описываются три идеи: кеш на редисе для MySQL через CDC, Multi-Region кеширование с репликацией редиса и шардирование баз. К сожалению, подробностей мало.
Лямбды работают быстро из-за 4 причин: синхронный/асинхронный запуск функций, отдельный сервис для управления окружением для вызова функций, firecracker VM и стейт хранилище.
Список мест, где распределенные локи помогут: выбор лидира, task scheduling, аллокация ресурсов, обновление данных в сервисах, работа с доменом инвентаризации (склады и прочее) и работа с сессиям.
#faas #sql #scalability #distributed_lock
—————————————
OpenTelemetry from 0 to 100
Изначально, в компании пытались реализовать трассировку самостоятельно, через собственный стандарт наименования трейсов, но вышло не очень. Из-за чего решили остановиться на OpenTelemetry. Далее автор описывает, что такое OpenTelemetry, какие можно выбрать варианты для бэкендов (в статье будет о grafana tempo) и зачем нужен OpenTelemetry Collector. После рассказывается о инструментации (instrumenting) приложений (к сожалению, только о java приложениях).
Самая интересная часть – описание проблем, с которыми столкнулись в компании:
- шум в данных о трейсах, который решился фильтрацией входящих данных;
- сложности с трассировкой для event-driven систем, где консьюмеры потребляют все события и сами решают, что им нужно, а что нет (решения не нашел);
- проблемы с node;
- фильтрация сенситив данных;
В конце рассказывается, что в компании еще хотят добавить в будущем (дашборды, метрики, корреляцию с логами и метриками). Если хотите внедрить трассировку, но не знаете с чего начать, статья поможет.
Перевод на русский
#observability #distributed_tracing
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Tech stack for Search system with Micro-services architecture
Поиск в распределенной системе задача со звездочкой. Помочь с принятием решения о реализации поиска должна сегодняшняя статья. Автор рассматривает два варианта: либо каждый сервис реализует собственный поиск, либо поиск по всей системе выносится в отдельный сервис. Для каждого из вариантов указываются плюсы и минусы решения,
Во второй части текста, автор, рассматривает способы реализации отдельного сервиса для поиска. Описываются возможные базы данных, способы заливки данных в сервис. В конце описывается два варианта реализации, с использованием эластика: в первом случае rabbitMQ ходит на прямую в эластик, во втором появляется прокладка в виде написанного сервиса.
Тезисный перевод на русский
#sync_communications #retries
—————————————
EP131: How Uber Served 40 Million Reads with Integrated Redis Cache?
Одна из рубрик автора, в которой берутся 3-4 темы и коротко описываются. По ссылке найдете три темы:
- как убер скейлит бд на чтение;
- из-за чего aws лямбды так быстро работают;
- шесть мест, где помогут распределенные локи;
В случае убера описываются три идеи: кеш на редисе для MySQL через CDC, Multi-Region кеширование с репликацией редиса и шардирование баз. К сожалению, подробностей мало.
Лямбды работают быстро из-за 4 причин: синхронный/асинхронный запуск функций, отдельный сервис для управления окружением для вызова функций, firecracker VM и стейт хранилище.
Список мест, где распределенные локи помогут: выбор лидира, task scheduling, аллокация ресурсов, обновление данных в сервисах, работа с доменом инвентаризации (склады и прочее) и работа с сессиям.
#faas #sql #scalability #distributed_lock
—————————————
OpenTelemetry from 0 to 100
Изначально, в компании пытались реализовать трассировку самостоятельно, через собственный стандарт наименования трейсов, но вышло не очень. Из-за чего решили остановиться на OpenTelemetry. Далее автор описывает, что такое OpenTelemetry, какие можно выбрать варианты для бэкендов (в статье будет о grafana tempo) и зачем нужен OpenTelemetry Collector. После рассказывается о инструментации (instrumenting) приложений (к сожалению, только о java приложениях).
Самая интересная часть – описание проблем, с которыми столкнулись в компании:
- шум в данных о трейсах, который решился фильтрацией входящих данных;
- сложности с трассировкой для event-driven систем, где консьюмеры потребляют все события и сами решают, что им нужно, а что нет (решения не нашел);
- проблемы с node;
- фильтрация сенситив данных;
В конце рассказывается, что в компании еще хотят добавить в будущем (дашборды, метрики, корреляцию с логами и метриками). Если хотите внедрить трассировку, но не знаете с чего начать, статья поможет.
Перевод на русский
#observability #distributed_tracing
Пятничное чтиво
Сегодня спецвыпуск – три статьи связанные с kafka. Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Kafka Transactions Explained \(Twice!\)
При использовании кафки можно попасть в ситуацию, когда надо переложить данные из топика в другой топик. В частности, когда чтение из первого топика зафиксировались, но произошел сбой и данные не попали во второй топик. Автор статьи рассказывает о механизме транзакций в кафке, который должен решить подобные проблемы.
В начале автор приводит пример приложения, которое как читает из топиков, так и пишет в топики кафки, чтобы объяснить зачем транзакции в брокере нужны. После, автор разбирает принцип того, как транзакции работают. На деле, сообщения сразу попадают в топик как любые другие, хитрость в том, что у каждого консьюмера задается «isolation level», который определяет, можно ли читать закомиченные сообщения или нет. При этом, записи, которые появились после не закомиченной записи нельзя будет прочитать до момента коммита или отмены записи. После, автор рассказывает о том, как транзакции работают в WarpStream (аналог кафки от конфлюента).
#async_communications #kafka
—————————————
Introduction to Kafka Tiered Storage at Uber
Очередная статья о том, как убер решал технические проблемы. На этот раз о том, как инженеры готовят кафку для решения проблем связанных с flexibility, scalability (цена добавления ноды увеличивается) и deployability (больше кластер, больше проблем). Для решения этих проблем придумали Kafka Tiered Storage, подход который уменьшает связность между storage и processing в брокере.
Идея подхода в том, что создается два уровня хранения: local (локальное хранилище в самом брокере) и remote (внешнее хранилище для данных). При этом, каждый уровень конфигурируется по своему, что позволяет хранить данные локально несколько часов, а не дней, а в remote уровне месяцы. Благодаря чему scalability упрощается, так как не требует большего количества ресурсов.
В статье описывается сам подход, с объяснением архитектуры. Подробнее описываются причины и проблемы, которые привели к созданию такого решения. В конце найдете принципы репликации данных между слоями.
#how_it_works #kafka
—————————————
KCache: An In-Memory Cache Backed by Kafka
Building A Relational Database Using Kafka
А что будет, если вместо постгреса (mysql, oracle, подставте название) не сделать реляционную БД поверх кафки? Отвечает на этот вопрос автор статей выше.
Чтобы сделать реляционную бд, придется сначала заморочиться с KV, в чем поможет первая статья, которая объясняет как из одного compacted топика и консьюмера собрать аналог event log из event sourcing, который будет хранить проджекшен ключей и их значений.
Вторая статья показывает как собрать собственную базу из компонентов. Т.е.
- персистенс поверх KV из первой статьи и RocksDB;
- avro отвечает за сериализацию и эволюцию схемы данных;
- calcite поможет с парсингом SQL;
- omid поможет с поддержкой MVCC и транзакций;
#kafka #how_it_works
Сегодня спецвыпуск – три статьи связанные с kafka. Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Kafka Transactions Explained \(Twice!\)
При использовании кафки можно попасть в ситуацию, когда надо переложить данные из топика в другой топик. В частности, когда чтение из первого топика зафиксировались, но произошел сбой и данные не попали во второй топик. Автор статьи рассказывает о механизме транзакций в кафке, который должен решить подобные проблемы.
В начале автор приводит пример приложения, которое как читает из топиков, так и пишет в топики кафки, чтобы объяснить зачем транзакции в брокере нужны. После, автор разбирает принцип того, как транзакции работают. На деле, сообщения сразу попадают в топик как любые другие, хитрость в том, что у каждого консьюмера задается «isolation level», который определяет, можно ли читать закомиченные сообщения или нет. При этом, записи, которые появились после не закомиченной записи нельзя будет прочитать до момента коммита или отмены записи. После, автор рассказывает о том, как транзакции работают в WarpStream (аналог кафки от конфлюента).
#async_communications #kafka
—————————————
Introduction to Kafka Tiered Storage at Uber
Очередная статья о том, как убер решал технические проблемы. На этот раз о том, как инженеры готовят кафку для решения проблем связанных с flexibility, scalability (цена добавления ноды увеличивается) и deployability (больше кластер, больше проблем). Для решения этих проблем придумали Kafka Tiered Storage, подход который уменьшает связность между storage и processing в брокере.
Идея подхода в том, что создается два уровня хранения: local (локальное хранилище в самом брокере) и remote (внешнее хранилище для данных). При этом, каждый уровень конфигурируется по своему, что позволяет хранить данные локально несколько часов, а не дней, а в remote уровне месяцы. Благодаря чему scalability упрощается, так как не требует большего количества ресурсов.
В статье описывается сам подход, с объяснением архитектуры. Подробнее описываются причины и проблемы, которые привели к созданию такого решения. В конце найдете принципы репликации данных между слоями.
#how_it_works #kafka
—————————————
KCache: An In-Memory Cache Backed by Kafka
Building A Relational Database Using Kafka
А что будет, если вместо постгреса (mysql, oracle, подставте название) не сделать реляционную БД поверх кафки? Отвечает на этот вопрос автор статей выше.
Чтобы сделать реляционную бд, придется сначала заморочиться с KV, в чем поможет первая статья, которая объясняет как из одного compacted топика и консьюмера собрать аналог event log из event sourcing, который будет хранить проджекшен ключей и их значений.
Вторая статья показывает как собрать собственную базу из компонентов. Т.е.
- персистенс поверх KV из первой статьи и RocksDB;
- avro отвечает за сериализацию и эволюцию схемы данных;
- calcite поможет с парсингом SQL;
- omid поможет с поддержкой MVCC и транзакций;
#kafka #how_it_works
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Pushy to the Limit: Evolving Netflix’s WebSocket proxy for the future
Еще одна статья от нетфликса (хочу такую же продуктивность). На этот раз о сервисе Pushy, который является WebSocket сервисом для клиентов. Сервис обрабатывает сотни миллионов одновременных коннекшенов, сотни тысяч сообщений в секунду и поддерживает reliability доставки сообщений в 99.999%.
Текст начинается с объяснения двух причин, которые повлияли на создание сервиса: голосовое управление и получение актуального состояния на клиентских устройствах. После описываются подходы, которые помогли со скейлингом сервиса: асинхронный message processing, push registry для хранений метаданных коннекшена, горизонтальный и вертикальный скейлинг и работы над reliability сервиса. После описывается, что компания делает (или планирует делать) с сервисом. Тут и о пуш отправке данных, и о взаимодействии между девайсами и о том, как Pushy стал реализацией транспортна для передачи данных. Кроме этого, рассказывается о лейтенси и секьюрити.
#how_it_works #web_sockets
—————————————
Vector Databases Are the Wrong Abstraction
Важно для контекста: статья из блога timescale (делают time series db поверх постгреса). Завязка начинается с того, что общаясь с разработчиками ai систем, timescale заметили, что векторные бд используются как стандарт. Но на деле, возникают ситуации, когда одной векторной базы не хватает из-за чего возникает проблема синхронизации данных (в статье описывается ситуация, когда кроме векторов еще используется DynamoDB для обработки объектов и OpenSearch для лексического поиска). Дальше описывается «претензия» к векторным бд – нет нормальной работы для связи эмбендигов и исходных данных. А для решения этой проблемы команда придумала
В тексте найдете причины, почему в компании решили переработать абстракцию связанную с векторами, как работает расширение, как отслеживаются данные для перестройки векторов и как настроить плагин.
#vector_db #psql
—————————————
How Distributed Systems Avoid Race Conditions using Pessimistic Locking
Если работали с распределенными системами, то сталкивались с проблемой рейс кондишена во время обновления данных. Кто-то старается избегать этой проблемы обновляя данные только в одном месте (это я), а кто-то использует распределенные локи. Статья выше поможет разобраться в концепции pessimistic locking, которая блокирует доступ к ресурсу перед изменением данных.
В начале автор объясняет, что такое pessimistic locking, используя sequence diagram, объясняя откуда возникает потребность в локах в системах с мультипроцессорностью. После, автор переходит к распределенным системам, объясняя концепцию cluster-wide lock database, которая помогает синхронизировать информацию о том, что с ресурсом происходит и работая с таймаутами для локов. Кроме этого, расписывается ситуация когда сервис А лочит ресурс, отваливается в момент обновления, после чего переходит лок к сервису Б, который делает изменения и после этого сервис А просыпается и пытается накатить старое обновление.
В конце указали ссылку на подробную статью о pessimistic locking от автора кабанчика.
#distributed_systems #distributed_lock
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Pushy to the Limit: Evolving Netflix’s WebSocket proxy for the future
Еще одна статья от нетфликса (хочу такую же продуктивность). На этот раз о сервисе Pushy, который является WebSocket сервисом для клиентов. Сервис обрабатывает сотни миллионов одновременных коннекшенов, сотни тысяч сообщений в секунду и поддерживает reliability доставки сообщений в 99.999%.
Текст начинается с объяснения двух причин, которые повлияли на создание сервиса: голосовое управление и получение актуального состояния на клиентских устройствах. После описываются подходы, которые помогли со скейлингом сервиса: асинхронный message processing, push registry для хранений метаданных коннекшена, горизонтальный и вертикальный скейлинг и работы над reliability сервиса. После описывается, что компания делает (или планирует делать) с сервисом. Тут и о пуш отправке данных, и о взаимодействии между девайсами и о том, как Pushy стал реализацией транспортна для передачи данных. Кроме этого, рассказывается о лейтенси и секьюрити.
#how_it_works #web_sockets
—————————————
Vector Databases Are the Wrong Abstraction
Важно для контекста: статья из блога timescale (делают time series db поверх постгреса). Завязка начинается с того, что общаясь с разработчиками ai систем, timescale заметили, что векторные бд используются как стандарт. Но на деле, возникают ситуации, когда одной векторной базы не хватает из-за чего возникает проблема синхронизации данных (в статье описывается ситуация, когда кроме векторов еще используется DynamoDB для обработки объектов и OpenSearch для лексического поиска). Дальше описывается «претензия» к векторным бд – нет нормальной работы для связи эмбендигов и исходных данных. А для решения этой проблемы команда придумала
pgai Vectorizer, который использует векторы как индексы и о котором и рассказывается в статье.В тексте найдете причины, почему в компании решили переработать абстракцию связанную с векторами, как работает расширение, как отслеживаются данные для перестройки векторов и как настроить плагин.
#vector_db #psql
—————————————
How Distributed Systems Avoid Race Conditions using Pessimistic Locking
Если работали с распределенными системами, то сталкивались с проблемой рейс кондишена во время обновления данных. Кто-то старается избегать этой проблемы обновляя данные только в одном месте (это я), а кто-то использует распределенные локи. Статья выше поможет разобраться в концепции pessimistic locking, которая блокирует доступ к ресурсу перед изменением данных.
В начале автор объясняет, что такое pessimistic locking, используя sequence diagram, объясняя откуда возникает потребность в локах в системах с мультипроцессорностью. После, автор переходит к распределенным системам, объясняя концепцию cluster-wide lock database, которая помогает синхронизировать информацию о том, что с ресурсом происходит и работая с таймаутами для локов. Кроме этого, расписывается ситуация когда сервис А лочит ресурс, отваливается в момент обновления, после чего переходит лок к сервису Б, который делает изменения и после этого сервис А просыпается и пытается накатить старое обновление.
В конце указали ссылку на подробную статью о pessimistic locking от автора кабанчика.
#distributed_systems #distributed_lock
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How McDonald Sells Millions of Burgers Per Day With Event-Driven Architecture
Честно забайтился на название статьи, так как не каждый день можно почитать о том, как макдак работает в техническом плане.
Описание начинается с того, что в компании сделали технологическую трансформацию, в результате чего пришлось обрабатывать события трех видов: асинхронные, транзакционные и аналитические. Плюсом описываются требования к глобальному деплойменту, реалтайм обработке, cross-channel интеграции (что бы не значило) и high-volume transaction processing. Дальше описываются architecturally significant requirements, которые требовались от системы (scalability, HA, performance, security, reliability и consistency). Причина фокуса на каждую из характеристик описывается отдельно + набор тактик, которые компания планирует выполнять (или уже выполнила).
Во второй части описываются детали реализации: какой брокер выбрали (aws kafka, куда без нее), schema registry, резервный event store в случае, когда кафка не доступна, event gateway, SDK. Плюс, показывается event flow, которого придерживаются в компании. В конце еще три тактики для достижения характеристик из первой части: шардирование на основе DDD, автоскейлинг.
Ну и никаких открытий или подробных деталей от статьи не ждите, так как текст больше дженерик.
#how_it_works #event_driven_communications
—————————————
The Documentation System
По ссылке не статья, а документация о документации (простите). На деле, в документации описываются виды проектной документации, каждый из которых закрывает определенные цели и поэтому структурно уникален (по сути, ссылка описывает топологию документации). Причем четыре вида документов делятся на: практические/теоретические и полезны в обучении/работе:
- Tutorials – документация, которая нацелена на обучение и должна помочь новичку в теме начать что-то делать. Оформляется в виде уроков;
- How-to guides – документация, которая показывает как решить специфичную проблему. Оформляется в виде набора шагов;
- Reference – нацелена на информирование, т.е. на объяснение непонятной темы. Оформляется в виде сухих объяснений «как есть»;
- Explanation – в отличии от reference нужна для «понимания», т.е. если reference описывает тему как есть, то цель explanation как раз в том, что бы у человека появилось понимание темы;
По ссылке найдете гайды по каждому виду документации с советами, примерами и тем, как писать такие документы. Если занимаетесь документацией или опенсорсом – однозначный мастхев.
#documentation
—————————————
POSTGRES EXPLAIN
Кажется, что каждый разработчик давно уже знает об EXPLAIN в постгресе, но потом оказывается, что это собственная ошибка восприятия. Поэтому, сегодня статья (точнее tutorial по классификации выше), которая научит пользоваться как EXPLAIN так и EXPLAIN ANALYZE.
В начале объясняется как работает планировщик запроса в постгресе и что такое план запроса (и при чем тут деревья и стоимость узлов). Здорово, что объясняется как оценивается стоимость на основе шести параметров (каждый описывается). После автор рассказывает об ANALYZE и видах сканирования данных. После чего уже переходит на объяснение EXPLAIN ANALYZE с примерами. В конце показывается, как визуализировать результат работы EXPLAIN и искать тяжелые запросы.
Если с EXPLAIN не работали – прочитать стоит, если знаете, умеете и любите – новое, скорее всего, не узнаете.
#psql
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How McDonald Sells Millions of Burgers Per Day With Event-Driven Architecture
Честно забайтился на название статьи, так как не каждый день можно почитать о том, как макдак работает в техническом плане.
Описание начинается с того, что в компании сделали технологическую трансформацию, в результате чего пришлось обрабатывать события трех видов: асинхронные, транзакционные и аналитические. Плюсом описываются требования к глобальному деплойменту, реалтайм обработке, cross-channel интеграции (что бы не значило) и high-volume transaction processing. Дальше описываются architecturally significant requirements, которые требовались от системы (scalability, HA, performance, security, reliability и consistency). Причина фокуса на каждую из характеристик описывается отдельно + набор тактик, которые компания планирует выполнять (или уже выполнила).
Во второй части описываются детали реализации: какой брокер выбрали (aws kafka, куда без нее), schema registry, резервный event store в случае, когда кафка не доступна, event gateway, SDK. Плюс, показывается event flow, которого придерживаются в компании. В конце еще три тактики для достижения характеристик из первой части: шардирование на основе DDD, автоскейлинг.
Ну и никаких открытий или подробных деталей от статьи не ждите, так как текст больше дженерик.
#how_it_works #event_driven_communications
—————————————
The Documentation System
По ссылке не статья, а документация о документации (простите). На деле, в документации описываются виды проектной документации, каждый из которых закрывает определенные цели и поэтому структурно уникален (по сути, ссылка описывает топологию документации). Причем четыре вида документов делятся на: практические/теоретические и полезны в обучении/работе:
- Tutorials – документация, которая нацелена на обучение и должна помочь новичку в теме начать что-то делать. Оформляется в виде уроков;
- How-to guides – документация, которая показывает как решить специфичную проблему. Оформляется в виде набора шагов;
- Reference – нацелена на информирование, т.е. на объяснение непонятной темы. Оформляется в виде сухих объяснений «как есть»;
- Explanation – в отличии от reference нужна для «понимания», т.е. если reference описывает тему как есть, то цель explanation как раз в том, что бы у человека появилось понимание темы;
По ссылке найдете гайды по каждому виду документации с советами, примерами и тем, как писать такие документы. Если занимаетесь документацией или опенсорсом – однозначный мастхев.
#documentation
—————————————
POSTGRES EXPLAIN
Кажется, что каждый разработчик давно уже знает об EXPLAIN в постгресе, но потом оказывается, что это собственная ошибка восприятия. Поэтому, сегодня статья (точнее tutorial по классификации выше), которая научит пользоваться как EXPLAIN так и EXPLAIN ANALYZE.
В начале объясняется как работает планировщик запроса в постгресе и что такое план запроса (и при чем тут деревья и стоимость узлов). Здорово, что объясняется как оценивается стоимость на основе шести параметров (каждый описывается). После автор рассказывает об ANALYZE и видах сканирования данных. После чего уже переходит на объяснение EXPLAIN ANALYZE с примерами. В конце показывается, как визуализировать результат работы EXPLAIN и искать тяжелые запросы.
Если с EXPLAIN не работали – прочитать стоит, если знаете, умеете и любите – новое, скорее всего, не узнаете.
#psql
Forwarded from Ivan Chernov
Странная ссылка про документацию, потому что выглядит копипастой отсюда:
https://diataxis.fr/
https://diataxis.fr/
diataxis.fr
Diátaxis
Diátaxis is a widely-adopted, pragmatic and systematic approach to thinking about and creating documentation.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Fast, Reliable Serverless: From 50 minutes to 50 seconds a year of downtime on AWS
Еще одна статья «как в компании X решали проблему Y». Сегодня это runa (платежный гейтвей, как я понял), которая увеличивала SLA API сервиса для фин транзакций с 99.99% до 99.999% в aws.
В начале описывается, что было сделано для улучшения обсервабилити. Для этого добавили перформанс тестирование, которое помогло определить основные проблемные места. После чего рассказывается о трассировках (сделали через AWS X-Ray). После описываются проблемы, с которым столкнулись инженеры: проблемы с Lambda Layers, долгий cold start, слишком много выделяется памяти для лямбд, инициализация клиентов (для баз и прочего) в ламбде, отсутствие ретраев, проблемы канкаренси. Для каждой из проблем дается способ решения. В конце куча ссылок для самостоятельного изучения.
#how_it_works #aws #sla #faas
—————————————
Events are the Wrong Abstraction: Rethinking distributed systems
Disclaimer: учтите, текст выше от компании, которая продает распределенные воркфлоу энджины. Решил его добавить, только как пример взгляда «со стороны». Но, к сожалению, маркетинговости слишком много, поэтому disclaimer и появился.
Статья начинается с того, что некорректно выбранная перспектива системы может как усложнить понимание системы, так и упростить ее. Для этого приводят пример с Коперником, где показана модель движения небесных тел, с землей и солнцем в центре. Дальше, на примере странного разбития сервисов для обработки платежей показано, как смещение восприятия от событий может упростить систему. Для этого, сначала, описываются проблемы которые появляются с использованием EDA (проблемы спорные и больше связаны с проблемой границ элементов). В список вошли: проблемы с каплингом, отсутствием API, сложности с дебагом, увеличением лейтенси и рейс кондишены.
Как решение предлагается посмотреть в сторону durable execution. Это позволит «упростить» жизнь с созданием и обслуживанием процессов, появятся компенсации и так далее.
#workflow_engine #event_driven
—————————————
"Rules" that terminal programs follow
Честно признаюсь, редко когда статьи от Джулии подходят под пятничные ссылки, но сегодня день исключение. Идея в том, что во время работы с терминалом у автора возник вопрос, существуют ли общие правила для терминальных команд. И если да, то какие. В результате появилось шесть с половиной правил, каждое из которых поясняется и даются примеры с разными командами.
Сами правила звучат следующим образом:
- Не интерактивные программы должны завершаться при нажатии
- TUI программы должны завершаться при нажатии
- REPL-like программы должны завершаться при нажатии
- Ограниченное количество цветов (не более 16);
- Поддержка сочетаний клавиш из emacs/redline (это о
- Слова должны удаляться при нажатии
- Отключение цветов во время записи в pipe (т.е. при выполнении
Если занимаетесь разработкой CLI приложений и не знаете об этих правилах, стоит ознакомиться.
Русский перевод
#CLI
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Fast, Reliable Serverless: From 50 minutes to 50 seconds a year of downtime on AWS
Еще одна статья «как в компании X решали проблему Y». Сегодня это runa (платежный гейтвей, как я понял), которая увеличивала SLA API сервиса для фин транзакций с 99.99% до 99.999% в aws.
В начале описывается, что было сделано для улучшения обсервабилити. Для этого добавили перформанс тестирование, которое помогло определить основные проблемные места. После чего рассказывается о трассировках (сделали через AWS X-Ray). После описываются проблемы, с которым столкнулись инженеры: проблемы с Lambda Layers, долгий cold start, слишком много выделяется памяти для лямбд, инициализация клиентов (для баз и прочего) в ламбде, отсутствие ретраев, проблемы канкаренси. Для каждой из проблем дается способ решения. В конце куча ссылок для самостоятельного изучения.
#how_it_works #aws #sla #faas
—————————————
Events are the Wrong Abstraction: Rethinking distributed systems
Disclaimer: учтите, текст выше от компании, которая продает распределенные воркфлоу энджины. Решил его добавить, только как пример взгляда «со стороны». Но, к сожалению, маркетинговости слишком много, поэтому disclaimer и появился.
Статья начинается с того, что некорректно выбранная перспектива системы может как усложнить понимание системы, так и упростить ее. Для этого приводят пример с Коперником, где показана модель движения небесных тел, с землей и солнцем в центре. Дальше, на примере странного разбития сервисов для обработки платежей показано, как смещение восприятия от событий может упростить систему. Для этого, сначала, описываются проблемы которые появляются с использованием EDA (проблемы спорные и больше связаны с проблемой границ элементов). В список вошли: проблемы с каплингом, отсутствием API, сложности с дебагом, увеличением лейтенси и рейс кондишены.
Как решение предлагается посмотреть в сторону durable execution. Это позволит «упростить» жизнь с созданием и обслуживанием процессов, появятся компенсации и так далее.
#workflow_engine #event_driven
—————————————
"Rules" that terminal programs follow
Честно признаюсь, редко когда статьи от Джулии подходят под пятничные ссылки, но сегодня день исключение. Идея в том, что во время работы с терминалом у автора возник вопрос, существуют ли общие правила для терминальных команд. И если да, то какие. В результате появилось шесть с половиной правил, каждое из которых поясняется и даются примеры с разными командами.
Сами правила звучат следующим образом:
- Не интерактивные программы должны завершаться при нажатии
<C-c>;- TUI программы должны завершаться при нажатии
q (вимы, емаксы в TUI не входят);- REPL-like программы должны завершаться при нажатии
<C-d> ;- Ограниченное количество цветов (не более 16);
- Поддержка сочетаний клавиш из emacs/redline (это о
<C-u> для удаления строки, <C-y> для вставки удаленной строки и так далее);- Слова должны удаляться при нажатии
<C-w> (для вимеров, аналогом будет сочетаниеbde);- Отключение цветов во время записи в pipe (т.е. при выполнении
git log | less цветов не должно оказаться в less);Если занимаетесь разработкой CLI приложений и не знаете об этих правилах, стоит ознакомиться.
Русский перевод
#CLI
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Postgres as a search engine
Лет 10-15 назад (по личному опыту) было нормальной практикой по дефолту использовать «поисковую бд» для поиска в паре с реляционной базой данных, особенно когда
В начале создается таблица для исследований плюс запрос для полнотекстового поиска и семантического, с возможностью задать нужные веса, для каждого из видов поиска. После автор описывает как реализовывал триграмм поиск, дописав запрос для гибридного поиска. Дальше автор описывает как дебажил результаты для разных видов поиска. А после – как работал с весами и нормализацией для полнотекстового поиска в ситуациях, когда искать надо не по одной колонке, а по нескольким (например title + body). В конце немного рассказывается о ранжировании результатов, включая буст документов по каким-то правилам.
#psql #searching
—————————————
10 new Git commands you should start using today
Если кратко пересказывать статью то получится: 7 команд гита которые я либо не видел, либо видел пару раз в жизни и уже забыл. Из трех остальных: одна связана с autosquash для ребейза, о maintenance уже было две статьи (первая, вторая), причем по первой ссылке найдете упоминание о
Первая группа команд:
-
-
-
-
Вторая группа команд:
-
-
-
#git
—————————————
An Engineer’s Checklist of Logging Best Practices
Статья с десятью советами о том, как работать с логированием в проекте. Встречаются как базовые советы связанные со структуризацией логов (а лучше использовать стандартизированную структуру), предпочтением сериализации, вместо простого текста, использованием requestid или traceid, выносом сенситив информации из логов, настройка TTL для логов Так и не самые очевидные связанные с объединением нескольких записей в одно событие (но тут трейдофф между компактностью и полностью), использования логов как данные (например как это аналитики делают), использование централизованной системы, использование логов как метрик. Последний совет связан с тем, что стоит документировать вокруг логов, что бы было проще жить в будущем.
Учтите, что хоть каждый совет раскрывается и объясняется, но статья больше вводная, чем с advansed советами. Поэтому, если о логировании ничего не знаете, статья поможет первые шаги сделать.
Русский перевод
#observability #logging
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Postgres as a search engine
Лет 10-15 назад (по личному опыту) было нормальной практикой по дефолту использовать «поисковую бд» для поиска в паре с реляционной базой данных, особенно когда
LIKE/ILIKE уже не хватает. Сегодня, используя постгрес, можно делать поиск сразу по нескольким подходам. Автор статьи, как раз, описывает как реализовать одновременный поиск по тексту в постгресе используя: tsvector для полнотекстового поиска, pgvector для семантического поиска и pg_trgm для триграмм.В начале создается таблица для исследований плюс запрос для полнотекстового поиска и семантического, с возможностью задать нужные веса, для каждого из видов поиска. После автор описывает как реализовывал триграмм поиск, дописав запрос для гибридного поиска. Дальше автор описывает как дебажил результаты для разных видов поиска. А после – как работал с весами и нормализацией для полнотекстового поиска в ситуациях, когда искать надо не по одной колонке, а по нескольким (например title + body). В конце немного рассказывается о ранжировании результатов, включая буст документов по каким-то правилам.
#psql #searching
—————————————
10 new Git commands you should start using today
Если кратко пересказывать статью то получится: 7 команд гита которые я либо не видел, либо видел пару раз в жизни и уже забыл. Из трех остальных: одна связана с autosquash для ребейза, о maintenance уже было две статьи (первая, вторая), причем по первой ссылке найдете упоминание о
git sparse-checkout. Оставшиеся семь команд условно можно разделить на две группы: связанные с работой над репозиторием и связанные с «наблюдаемостью» вокруг репозитория. Первая группа команд:
-
git switch – замена checkout для работы с ветками;-
git restore – замена checkout для отката изменений;-
git worktree – создает отдельные папки под конкретную ветку проекта, вместо переключения веток в одном месте (полезно если со stash мучаетесь);-
git rebase --update-refs – обновляет референсы на измененные коммиты в проекте;Вторая группа команд:
-
git log --remerge-diff – реконструирует merge commit с merge strategy и показывает что изменилось (даже после конфликтов);-
git blame --ignore-rev – помогает блеймить людей, даже если существуют коммиты с изменением стиля кода от других людей;-
git range-diff – сравнивает два диапазона коммитов, показывая как одни превратились в другие;#git
—————————————
An Engineer’s Checklist of Logging Best Practices
Статья с десятью советами о том, как работать с логированием в проекте. Встречаются как базовые советы связанные со структуризацией логов (а лучше использовать стандартизированную структуру), предпочтением сериализации, вместо простого текста, использованием requestid или traceid, выносом сенситив информации из логов, настройка TTL для логов Так и не самые очевидные связанные с объединением нескольких записей в одно событие (но тут трейдофф между компактностью и полностью), использования логов как данные (например как это аналитики делают), использование централизованной системы, использование логов как метрик. Последний совет связан с тем, что стоит документировать вокруг логов, что бы было проще жить в будущем.
Учтите, что хоть каждый совет раскрывается и объясняется, но статья больше вводная, чем с advansed советами. Поэтому, если о логировании ничего не знаете, статья поможет первые шаги сделать.
Русский перевод
#observability #logging
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Apple built iCloud to store billions of databases
Очередная статья на тему «как в компании X решают проблему Y». На этот раз это эпл с icloud и проблема работы с миллионами баз данных в multi-tenant архитектуре. Для чего используют FoundationDB и Cassandra.
Начинается все с описания того, как в компании используют 300к инстансов Cassandra с петабайтами данных и миллионами запросов в секунду. Для этого заморачиваются с размещением нод кассандры в каждом сервере, сегментированию и радиусу вызова, что обеспечивает data availability близкой к 100%. Но на одной кассандре не уехать, поэтому в компании также используют FoundationDB (транзакционная и распределенная key-value бд) для CloudKit. Причем записи хранятся как прото сообщения. Дальше описывается как все это работает и при чем тут Record Layer. В конце даются решения некоторых проблем, с которыми столкнулись в компании: полнотекстовый поиск, обработка большого количества апдейтов, работа с high latency queries и разрешение конфликтных транзакций.
#how_it_works #db
—————————————
Representing The Same Data Structure in SQL and NoSQL
Выбор бд делают на основе характеристик, популярности и ограничений компании, при этом, редко когда сравнивают как одинаковые данные можно положить в разные бд и что из этого будет выгоднее. Таким вопросом задался автор статьи – сравнить SQL и noSQL подходы к хранению структур в базе, чтобы улучшить способ сравнения видов баз, потому что на одних характеристиках далеко не уедешь. При этом, автор сразу описывает что ждет от бд: получение отдельных записей по идентификатору, никакого неоправданного дублирования, «достаточно хорошо» выполнять запросы к бд.
Структура данных, с которой экспериментирует автор – игрок с инвентарем в ммо играх. В случае SQL базы будет создано 4 таблицы для хранения игрока, инвентаря и items в игре. Дальше описывается как будут делаться запросы и обсуждаются вопросы дупликации данных. Второй подход – SQL с xml (похоже на jsonb подход постгреса), в результате которого появляются некоторые проблемы: уменьшение перфоманса, не стандарт в sql базах и реализации отличаются. Третий подход связан с документо ориентированными бд (монгой, в случае автора). А четвертый с key-value.
К сожалению, статья не до конца дописана и датируется 2016 годом. Было бы здорово подобное увидеть с большим количеством примеров и в современных реалиях.
#data_managment #db
—————————————
Как ломаются системы и как их траблшутить
Статья от преподавателя ШАД как вводная в тему SRE. Текст начинается с рассказа о том, что такое распределенная система. Потом автор рассказывает об обсервабилити и при чем тут availability из которых собираются метрики. После этого текст переходит в сторону мониторинга и обнаружения аномалий.
Вторая часть текста описывает непосредственно варианты недоступности систем. Важная мысль, которая указывается автором – аварии случаются в любых системах, не важно больших или маленьких или вне зависимости от домена. Дальше дается список из девяти причин поломок: апгрейды, сеть, баги, мисконфигурация, всплески трафика, зависимости между элементами системы, проблемы с дисками, ошибки железа и внешние факторы (стихийные бедствия, уборщица, которая шнур выдернула и так далее). В конце описываются способы исправления аварий. Способы сводятся к управлению рисками и заранее реализованным подходам (рейт лимиты, дублирование данных, консенсус и так длалее), которые помогут избежать риски (и добавить новых).
От статьи не стоит ждать хардкора, скорее это вводная статья для тех, кто ничего не слышал об SRE до этого.
#sre #distributed_systems
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Apple built iCloud to store billions of databases
Очередная статья на тему «как в компании X решают проблему Y». На этот раз это эпл с icloud и проблема работы с миллионами баз данных в multi-tenant архитектуре. Для чего используют FoundationDB и Cassandra.
Начинается все с описания того, как в компании используют 300к инстансов Cassandra с петабайтами данных и миллионами запросов в секунду. Для этого заморачиваются с размещением нод кассандры в каждом сервере, сегментированию и радиусу вызова, что обеспечивает data availability близкой к 100%. Но на одной кассандре не уехать, поэтому в компании также используют FoundationDB (транзакционная и распределенная key-value бд) для CloudKit. Причем записи хранятся как прото сообщения. Дальше описывается как все это работает и при чем тут Record Layer. В конце даются решения некоторых проблем, с которыми столкнулись в компании: полнотекстовый поиск, обработка большого количества апдейтов, работа с high latency queries и разрешение конфликтных транзакций.
#how_it_works #db
—————————————
Representing The Same Data Structure in SQL and NoSQL
Выбор бд делают на основе характеристик, популярности и ограничений компании, при этом, редко когда сравнивают как одинаковые данные можно положить в разные бд и что из этого будет выгоднее. Таким вопросом задался автор статьи – сравнить SQL и noSQL подходы к хранению структур в базе, чтобы улучшить способ сравнения видов баз, потому что на одних характеристиках далеко не уедешь. При этом, автор сразу описывает что ждет от бд: получение отдельных записей по идентификатору, никакого неоправданного дублирования, «достаточно хорошо» выполнять запросы к бд.
Структура данных, с которой экспериментирует автор – игрок с инвентарем в ммо играх. В случае SQL базы будет создано 4 таблицы для хранения игрока, инвентаря и items в игре. Дальше описывается как будут делаться запросы и обсуждаются вопросы дупликации данных. Второй подход – SQL с xml (похоже на jsonb подход постгреса), в результате которого появляются некоторые проблемы: уменьшение перфоманса, не стандарт в sql базах и реализации отличаются. Третий подход связан с документо ориентированными бд (монгой, в случае автора). А четвертый с key-value.
К сожалению, статья не до конца дописана и датируется 2016 годом. Было бы здорово подобное увидеть с большим количеством примеров и в современных реалиях.
#data_managment #db
—————————————
Как ломаются системы и как их траблшутить
Статья от преподавателя ШАД как вводная в тему SRE. Текст начинается с рассказа о том, что такое распределенная система. Потом автор рассказывает об обсервабилити и при чем тут availability из которых собираются метрики. После этого текст переходит в сторону мониторинга и обнаружения аномалий.
Вторая часть текста описывает непосредственно варианты недоступности систем. Важная мысль, которая указывается автором – аварии случаются в любых системах, не важно больших или маленьких или вне зависимости от домена. Дальше дается список из девяти причин поломок: апгрейды, сеть, баги, мисконфигурация, всплески трафика, зависимости между элементами системы, проблемы с дисками, ошибки железа и внешние факторы (стихийные бедствия, уборщица, которая шнур выдернула и так далее). В конце описываются способы исправления аварий. Способы сводятся к управлению рисками и заранее реализованным подходам (рейт лимиты, дублирование данных, консенсус и так длалее), которые помогут избежать риски (и добавить новых).
От статьи не стоит ждать хардкора, скорее это вводная статья для тех, кто ничего не слышал об SRE до этого.
#sre #distributed_systems