Минутка tech porn.

У нас огромная multi-tenant реляционная база данных. Таблицы по 200 ГБ - рехнуться, если честно. При этом для multi-tenant архитектуры мы юзаем самую тупую модель - "Pool" - это когда во все таблицы добавляется ключик "tenant_id". Модель неэффективная, но зато простая в реализации и поддержке.

(кстати у AWS пролетала классная дока про дизайн multi-tenant систем, где разобраны все варианты, мастрид для всех CTO)

Все тормозило и заикалось. Клиенты бесились, сервера перегревались. Задачи типа "получить запись по ID" работали нормально, но любой список типа "непрочитанные письма за сегодня" в многотерабайтной базе начинает жестко тупить. Даже с правильными индексами. Один жирный клиент с дохреллионом записей притормаживает мелких клиентов, у которых данных совсем мало. Надо что-то делать.

И тут нам пришло Великое Озарение [sarcasm], которое рано или поздно приходит любому DBA - о том, что основная работа всегда ведется с "верхушкой" данных. А огромный "long tail" всегда лежит мертвым грузом и нахуй не нужен юзается только в отчетах.

Первая мысль - надо сделать "вертикальный" партишенинг. Т.е. "старые" данные спихивать куда-то за горизонт (на отдельный диск или даже сервер), а "активные" данные держать где-то под рукой.

Мысль правильная, но нет.

Грамотный партишенинг - это оказалось сложно, долго и с первого раза не работает. Перефразируя известную поговорку про яхтинг, в жизни DBA есть два счастливых дня - день когда он настроил партишенинг и день когда он его прибил. Ибо сервер все равно время от времени сканил партишены как попало и расследовать это довольно тяжело.

Я уже слышу крики из зала: "шардинг", "кликхаус", "разделяй OLTP и DWH". И прочий оверинжиниринг. Сразу нет. У нас есть self-hosted версия, которая должна заводиться в один клик даже у домохозяек. Хотелось простой хак, который решит все проблемы одной строчкой.

И тут я случайно вспомнил про офигенный читкод - фильтрованные индексы. Ведь по умолчанию индекс делается по всей таблице. Но зачем, если можно индексировать только 0.1%?

В коде любого CRUD-приложения, в бизнес-логике всегда есть признак, который отличает "старые" данные от "новых". Ну типа "статус проекта = сдан". Или "статус заказа = обработан". И это условие уже есть в большинстве ваших SELECT'ов. В нашем случае это был "статус тикета = закрыт".

Что делает DBA-джун? Создает индекс по этой колонке. Чтобы, значит, поиск незакрытых тикетов был быстрым и классным.

CREATE INDEX myIndex
ON messages (processed)

Что делает прошаренный DBA-синьор? Создает еще "filtered index" с этим условием

CREATE INDEX myIndex
ON messages (column1, column2...)
WHERE processed = 0 --вот так

И следит, чтобы это условие было в селектах.

В результате даже в многотерабайтной базе мы имеем маленький быстрый индекс всего в десятки мегабайт (!), который всегда показывает на самые последние данные. Как только данные перестают удовлетворять признаку - они из индекса улетают. Сами.

Когда мы прикрутили первый фильтрованный индекс и стали смотреть статистику использования, мы офонарели - SQL Server бросил все дела, и стал жадно его жрать. Приложение ускорилось в разы, нагрузка на проц снизилась на 80%. Посмотрите график - до и после внедрения только ОДНОГО пробного индекса.

Наш бд-сервер имеет всего 4 ядра и 32 гига памяти, при этом запросто тянет базу в несколько терабайт и сотни тысяч DAU. У нас в команде есть негласный челлендж - сколько можно протянуть на этом железе без апгрейдов? Уже годы держимся))

К чему я все это - не бегите прикручивать громоздкие решения, старые и скучные rdbms умеют много крутых штук даже на дохлом железе.

PS. "Filtered/partial index" есть в SQL Server, PG и в Монге. В мускуле есть воркераунд

PPS. есть нюанс, кстати. Когда делаете filtered index, обязательно включайте фильтрованную колонку в "include". Так мы заставляем сервер поддерживать "статистику" по колонке. Без статистики все это великолепие работать не будет, сервер индекс не заметит.

CREATE INDEX myIndex
ON Messages (Column1, Column2...)
INCLUDE (Processed) --важно
WHERE Processed = 0

Всем привет. Я думаю многие из тех кто интересуется микросервисной архитектурой знает, такой сайт https://microservices.io/ на котором собраны все основные паттерны применяемые при разработке микросервисов.

🌐 Если вы вдруг не знаете о таком сайте, советую его посетить. У меня конечно есть вопросы к его визуальной составляющей💩, однако информация там собрана вполне себе годная 👍🏻, хоть и в достаточно урезанном объеме. Я частенько использую данный сайт как справочник.

📚 Но речь не столько о сайте, а вот о чем. У Криса Ричардсона, автора данного ресурса, есть отличная книга которая называется “Microservices Patterns”. Вот ее то я вам и хочу порекомендовать.

❓Если вы читали только классику, а именно “Building Microservices: Designing Fine-Grained Systems”, у вас скорее всего осталось достаточно много практических вопросов типа: “А как быть с распределенными транзакциями?”, “А где должна быть бизнес-логика?”, “Как работать с доменными событиями?”, “А внешний API как предоставлять”?

❗️Эта книга, как раз таки дает практические ответы на большинство подобного рода вопросов. Т.е. там есть примеры кода. В общем читайте и изучайте, книга полезная и нормально структурирована. Т.е. если у вам уже есть опыт и вы на практике столкнулись с какой то конкретной проблемой, вы можете читать именно ту главу которая эту проблему решает. Единственный момент, ниже парочка замечаний.

💡 Во первых, я бы рекомендовал оригинальный вариант книги. Я сам приобрел перевод от издательства “Питер” и он оказался местами кривоват. Например в разделе о тестировании “stubs” и “mocks” переводятся как “заглушки” и внимание... “макеты” (wat?) 🤨.

💡 Во вторых, особенно новичкам я рекомендовал бы критически отнестись к первой главе. В русской версии она называется “Побег из монолитного ада”. Имея некоторый опыт такого “побега”, могу с уверенностью сказать о том, что может случиться так, что из монолитного ада вы прибежите в распределенный. И это значительно хуже монолитного ада. В остальном книга годная в особенности что касается деталей работы с распределенными транзакциями, Service Discovery, проектировании внешних API и т.д.

На этом у меня все. Всем добра! 👋

большой список практический занятий по технологиям aws
https://awsworkshop.io/

📺 Больше Брендана в ленте!

▶️ Весь плейлист YOW! September Online 2020.

#linux #видео #фидбечат

🔩 Awesome eBPF: https://github.com/zoidbergwill/awesome-ebpf #ebpf #линк

🔍 A tcpdump Tutorial with Examples — 50 Ways to Isolate Traffic - интересный материал с примерами применения tcpdump. #tcpdump #напочитать

🔧 https://slowfil.es/ - интересный ресурс, позволяющий вызвать файл с задержкой и нужным кодом ответа.

Полезно для случаев, когда мы хотим посмотреть, а что будет, если на нашем сайте, или в нашем веб-приложении, какой-то элемент будет подгружаться слишком медленно, либо не будет подгружаться вовсе. #линк

⚙️ How To Add eBPF Observability To Your Product: https://brendangregg.com/blog/2021-07-03/how-to-add-bpf-observability.html

#ebpf #напочитать

🎲 The SRE Incident Response game - занятная игра получилась бы, подумал я и решил загуглить...

Оказывается, так называемые Incident Response Games - это вполне себе практика, которую используют в работе и обучении. Возможно, и вам будет интересно почитать...

- Backdoors & Breaches, an Incident Response Card Game
- Teach Incident Response with Games
- Defensomania is a security monitoring and incident response card game

#напочитать #sre #будничное

📎 Визуализация цепочек iptables на сервере: https://github.com/Nudin/iptable_vis Удобно для ситуаций, когда нужно наглядно показать последовательность обработки правил. #iptables #фидбечат #будничное

Distributed Tracing in Practice
Instrumenting, Analyzing, and Debugging Microservices

Since most applications today are distributed in some fashion, monitoring their health and performance requires a new approach. Enter distributed tracing, a method of profiling and monitoring distributed applications, such as microservices and serverless.

There's just one problem: distributed tracing can be hard. But it doesn't have to be. In this book, Distributed tracing experts from Lightstep, Google, and Twitter, and the Max Planck Institute for Software Systems share ways to more effectively build, operate, and understand your software.

Austin Parker, Daniel Spoonhower, Jonathan Mace, and Rebecca Isaacs with Ben Sigelman

2020

Интересная утилита для обработки трафика и дампов: https://github.com/emmanueltouzery/hotwire

#tcpdump #hotwire #wireshark

🔐 Drago - инструмент для централизованного управления конфигурацией Wireguard. Выглядит удобным, надо сказать.

- Docs: https://seashell.github.io/drago/#/docs/overview
- Github: https://github.com/seashell/drago

#wireguard #vpn #будничное