Минутка 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" (в постгресе называется "partial index").

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

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

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

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

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

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

CREATE INDEX myIndex


ON Messages (Column1, Column2...)

INCLUDE (Processed) --важно
WHERE Processed = 0

Все так, но есть пара нюансов, которые стоит учитывать:

1. Условие в частичном индексе или формула в функциональном должны быть ТАКИМИ ЖЕ, какими они будут в запросах.
Планировщики баз данных умеют минимальные оптимизации. В документации обычно так и пишут: "у нас тут не софт для теоретической алгебры, пишите нормально!".
Postgresql, например, поймет, если частичный индекс будет создан для

 a > 1 

и в запросе будет использовано выражение

 a > 2 

Но для выражения

 a + 1 > 0 

никаких оптимизаций сделано не будет.

Кстати, хозяйке на заметку: частичный индекс

 a IS NOT NULL 

может быть использован в любых запросах с колонкой a, кроме запроса

 a IS NULL 

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

Да, еще: будте осторожнее с отрицанием. Про de morgan law я писал вот тут https://news.1rj.ru/str/nosingularity/513.
Если коротко: булево отрицание не всегда есть то, что вы себе предполагаете. И некоторые конструкции SQL не эквивалентны, хотя кажется, что должны:

 A IS TRUE 

и

 A = TRUE 

не одно и тоже!

2. Одновременно существует индекс на всю колонку и частичный индекс на эту же колонку.
При вставке и обновлении этой колонки будут обновляться оба индекса.
По понятной причине такие операции будут жрать довольно много ресурсов. Поэтому стоит хорошо подумать: нужен ли вам индекс по всей колонке, если уже есть частичный.

Btw, частично с обнаружением таких спорных мест помогает holistic.dev :)

Казалось бы, все знают, что сравнивать с NULL не надо. Но вот такое до недавнего времени было DDL gitlab :

CREATE INDEX backup_labels_group_id_noscript_idx ON backup_labels USING btree (group_id, noscript) WHERE (project_id = NULL::integer);
CREATE UNIQUE INDEX backup_labels_project_id_noscript_idx ON backup_labels USING btree (project_id, noscript) WHERE (group_id = NULL::integer);
CREATE INDEX index_labels_on_group_id_and_noscript ON labels USING btree (group_id, noscript) WHERE (project_id = NULL::integer);

потом они это пофиксили, но завезли такое:

CHECK ((((project_id <> NULL::bigint) AND (group_id IS NULL)) OR ((group_id <> NULL::bigint) AND (project_id IS NULL))))

и такое:

CREATE INDEX ... ON users USING btree (id, last_activity_on) WHERE (((state)::text = 'active'::text) AND ((user_type IS NULL) OR (user_type = ANY (ARRAY[NULL::integer, 6, 4]))));

CREATE INDEX ... ON users USING btree (id) WHERE (((state)::text = 'active'::text) AND ((user_type IS NULL) OR (user_type = ANY (ARRAY[NULL::integer, 6, 4]))) ...

В последнем все примере похоже на какой-то грязный хак специально под RoR :)

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

Сейчас ищут докладчиков.
Я бы сам с удовольствием принял участие, но не могу придумать о чем именно рассказать.
Если бы вы хотели послушать что-нибудь про snowflake в моем исполнении, накидайте, пожалуйста, тем в комментарии?

Конференция о дата-инжиниринге SmartData 2021 ищет спикеров

Вам есть о чем рассказать и что обсудить с коллегами по цеху? Тогда вам нужно подать заявку на участие в конференции! В этом году SmartData пройдет в гибридном формате: онлайн+офлайн.

Темы, которые ждут больше всего:
– Стриминг;
– СУБД и хранилища для больших данных;
– Архитектура DWH;
– Data governance;
–Технологии построения ETL;
– Оркестрация и MLOps.

Но этим списком не ограничивается — вы можете подать заявку с любой темой из области дата-инжиниринга.

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

Подать заявку и узнать подробности можно на https://bit.ly/2SuaaOL

Вопросы присылайте на почту program@smartdataconf.ru

👀 Github показала Copilot, который они сделали совместно с OpenAI. В общем эта штука работает как TabNine, генерируя автоматически код на основе контекста. Умеет и в тесты и во все на свете.

Все это уже который раз напоминает шутку:
- За что тебе платят деньги? Ты же только копируешь все со StackOverflow!
- Да, но я знаю, какой код нужно копировать.

Прошлогодняя смарт дата:

https://youtube.com/playlist?list=PLeN_80lmoMY1ugdDLg2mWht5eQDq6CoNQ

ClickHouse Object Storage Performance: MinIO vs. AWS S3

https://altinity.com/blog/clickhouse-object-storage-performance-minio-vs-aws-s3

#altinity #clickhouse #s3 #minio

​Snowflake прилег во ВСЕХ регионах и лежит уже больше часа.

В чатиках (RU, EN) говорят, что кое-где работает, но status page горит алым пламенем...

А я еще думаю: что у меня тесты падают?..

Snowflake пролежал почти 2 часа. Неудачно накатили новую версию.

Пользуясь случаем, апну историю о том, как я много лет назад сломал биллинг сотового оператора :)

На осенний Highload тоже нужны доклады про Snowflake.
В отличие от JUG они делают вид, что проблем с пандемией нет и все будут выступать на площадке, in the flesh.

Btw, вы мне очень помогаете определиться с приоритетами.
Идей по темам докладов: 0
Желающих отправить меня в вебкам: 70

Пожалуй, не буду я тратить время на подготовку к конференциям...

Короткий тред:

https://twitter.com/adrien_nayrat/status/1411988614913929216

Все, говорит, сломать смогли. Кроме postgresql...

​Я ужасно ненавижу дефолты.
В любых проявлениях.

Но в аргументах методов особенно.
Я уже бомбил об этом здесь

Если коротко, то это write only фича. IDE тебе подскажет значения дефолтов, когда ты пишешь код.
А когда читаешь?
А если читаешь не в IDE, а, например, ревьюишь код в гитхабе(лабе)?

Все константы должны быть в конфиге и явно передаваться везде, где хочется воткнуть дефолт.

А что я об этом вспомнил?
У Никиты вышел пост про сборщики в java-мире.

Я застал и ant и groovy.
Возможно, это и было основной причиной того, что я никогда больше не хочу связываться с java.

Хотя, кого я обманываю... Конечно же, не только это.

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

Есть некоторые, простигосподи, CTO с 10k подписчиков в твиттере, которые не видят в этом никакой проблемы.

Предлагаю всем включить вопрос про дефолты в culture fit interview... :)

В чатике срач про дефолты. Люблю такое :)

PS: читать начиная с закрепа

​Разговорились с @oleg_log и по мотивам upstash.com родилась идея стартапа:

- Берем sqlite и redis
- Соединяем одно с другим, наружу выставляем sqlite
- Идем в YC как sql over redis as a service
...
- PROFIT!

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

Почему я не написал про pgday? Правильно, потому что никто не прислал письма с напоминанием...

Оказывается сегодня бесплатная конфа по #postgres

Список докладов https://pgday.ru/ru/2021/papers

​Чят, пожалуйста, помогите с кастдевом!

Мы делаем тулзу для поиска и анализа связей в структурах данных в аналитических базах данных.
Есть несколько гипотез, которые хочется протестировать.

Вендор базы значения не имеет, думаю, что проблемы у всех приблизительно одинаковые.

Есть большая потребность в теплом интро к Data Lead, Chief Data Officier, VP of Data Engineering - с любым техническим или нетехническим специалистам верхних уровней, связанных с датой.

Интересуют все области - и дата инжиниринга и дата саентисты. Может еще какие-то есть? :)

Не надо пугаться, на данный момент мы НИЧЕГО НЕ ПРОДАЕМ. Основная задача - проверить попадаем мы ли мы в боль и насколько сильно болит.
Поэтому не стесняйтесь сдавать своих коллег и коллег коллег :)

Языки - RU/EN.

Пишите @antonrevyako или в чат

Перефразируя классика:
Если в 2021 вы еще не в облаке, то что-то с вами не так и вообще позорище... :)

Событие пройдет сегодня-завтра, поэтому есть шанс про него не забыть (а не то что pgday).

☁️ Сегодня, в 18:00 (GMT+3), AWS комьюнити приглашает на All about AWS 2021 — бесплатный онлайн ивент, посвященный клауд миграции и её стратегиям ☁️

📍Язык ивента: украинский и русский

15 июля пройдут панельные дискуссии, где спикеры из AWS и SoftServe будут говорить о:

— миграции в клауд, как ее разумно планировать, чтобы сэкономить время и уменьшить расходы;
— почему бизнес решает оставаться в дата центрах.

👉 Регистрация

​SQL-WTF SQL-TIL snowflake edition

Такое ощущение, что в Snowflake сами не знают что умеет их база.

Недавно выяснилось, что при создании таблиц поддерживается описание типов из ORACLE:

VARCHAR2(100 BYTE),
NVARCHAR2(80)

В документации, конечно, тишина.

Сейчас понадобилось сделать демку с использованием MASKING POLICY. Решил освежить знания по документации. Листаю список ограничений: ... не применяется к виртуальным колонкам ...

WAT? Виртуальные колонки? Откуда в Snowflake виртуальные колонки?
Есть что-нибудь в документации? Есть, но про EXTERNAL TABLE.

А давайте попробуем...

create table vc_test (
  key       number,
  check_sum number as HASH(key)
);

insert into vc_test(key) values (1);
select * from vc_test;

-- 1,-4730168494964875235

oO
Работает!

Так, абажжи...

create table vc_test2(
  key       number,
  check_sum number as (SELECT key FROM vc_test) DEFAULT 1 NOT NULL
);
insert into vc_test2(key) values (1);

И это работает!

А ну-ка...

select * from vc_test2;

-- [42000][1003] SQL compilation error: syntax error line 1 at position 1 unexpected 'SELECT'. syntax error line 1 at position 31 unexpected 'GENERATOR'.

Чивооо? GENERATOR?

SELECT GET_DDL('table', 'VC_TEST2');

-- result:
create or replace TABLE VC_TEST2 (
  KEY NUMBER(38,0),
  CHECK_SUM NUMBER(38,0) AS ((SELECT 1 AS "KEY" FROM TABLE (GENERATOR)ROWCOUNT => 1, rowCount => 1) GENERATOR)) NOT NULL DEFAULT 1
);

Directed by Frank Slootman

Тейкэвей:
- в snowflake существуют виртуальные колонки для обычных таблиц
- при объявлении засунуть в них можно что угодно, но работать будет не все :)
- значения в колонках не мемоизируются
- с виртуальными колонками многое что нельзя, но несмотря на предыдущий пункт, кластеризацию все-таки можно

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