There will be no singularity

Короткий тред: https://twitter.com/adrien_nayrat/status/1411988614913929216 Все, говорит, сломать смогли. Кроме postgresql...

На осенний Highload тоже нужны доклады про Snowflake. В отличие от JUG они делают вид, что проблем с пандемией нет и все будут выступать на площадке, in the flesh. Btw, вы мне очень помогаете определиться с приоритетами. Идей по темам докладов: 0 Желающих отправить меня в вебкам: 70 Пожалуй, не буду я тратить время на подготовку к конференциям...

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

​Snowflake прилег во ВСЕХ регионах и лежит уже больше часа. В чатиках (RU, EN) говорят, что кое-где работает, но status page горит алым пламенем... А я еще думаю: что у меня тесты падают?..

Казалось бы, все знают, что сравнивать с NULL не надо. Но вот такое до недавнего времени было DDL gitlab : CREATE INDEX backup_labels_group_id_title_idx ON backup_labels USING btree (group_id, title) WHERE (project_id = NULL::integer); CREATE UNIQUE INDEX backup_labels_project_id_title_idx ON backup_labels USING btree (project_id, title) WHERE (group_id = NULL::integer); CREATE INDEX index_labels_on_group_id_and_title ON labels USING btree (group_id, title) 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 :)

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

 a > 1 

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

 a > 2 

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

 a + 1 > 0 

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

 a IS NOT NULL 

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

 a IS NULL 

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

 A IS TRUE 

и

 A = TRUE 

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

Минутка 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

"А давайте сделаем сервис на 100% доступным". Хороший пост рассказывающий чего вам это будет стоит. Авторы говорят о 10x increase in development costs(!) Спойлер, определите уровень который нужен вам врядли это именно 100%, каждая 9 после 99% стоит оочень много. "Say a feature is estimated to take 20 days of development (including design). Add a further 10 days for testing (using the top end industry estimate of one-third time), and you have a total of 30 days cost for the good reliability feature. For the 100% reliability feature, we need much more testing, around 200 days using Colm’s talk. That means a total of 30 days for adding a feature with good reliability becomes 220 days for 100% reliability. More than seven times the cost. These are just rough estimates, but conservative and indicative of how there is a 10x increase in development costs." https://medium.com/expedia-group-tech/the-cost-of-100-reliability-ecb2901f23a4

Все выпуски SQL-TIL (чтобы вы могли пошарить): postgresql edition: 1) https://t.me/nosingularity/535 2) https://t.me/nosingularity/541 3) https://t.me/nosingularity/548 4) https://t.me/nosingularity/572 snowflake edition: 5) https://t.me/nosingularity/582 6) https://t.me/nosingularity/602 7) https://t.me/nosingularity/753 и https://t.me/nosingularity/754 8) https://t.me/nosingularity/762 mix: 9) https://t.me/nosingularity/755 10) https://t.me/nosingularity/803 и https://t.me/nosingularity/804

Вдогонку к

SELECT 1_000_000 

Есть еще один момент, который, я, кажется, не упоминал в своих выпусках SQL-TIL:

SELECT 'foo'
'bar'

Mysql, postgresql и sqlite вернут 3 разных результата, а в snowflake будет ошибка :)

Многие знают, что в js (и не только) для большей читаемости можно разделять числа символом подчеркивания: console.log(1_000_000); // 1000000 А теперь вопрос со звездочкой (без подглядывания в консоль): Что получится в результате вызова SELECT 1_000_000 Справедливо для postgresql, mssql и snowflake. В mysql и sqlite будет ошибка. Ответы в комменты :)

ClickHouse вошла в топ-50 самых популярных в мире СУБД Распределённая система управления базами данных ClickHouse впервые вошла в топ-50 самых популярных в мире СУБД по версии DB-Engines Ranking. Это один из главных отраслевых рейтингов в мире СУБД. Он публикуется с 2012 года и сейчас охватывает 371 систему. На сегодняшний день это единственная СУБД российского происхождения в топ-50 рейтинга. ClickHouse доступна в виде облачного сервиса на платформе Yandex.Cloud. Прямо сейчас вы можете воспользоваться всеми преимуществами СУБД, не вникая в тонкости настройки и обслуживания. Подробнее о новости читайте в материале на Хабре → #yacloud_news

Группа хакеров N-ое время назад взломала CD Project Red (польская игровая студия) и вытащила исходники Cyberpunk 2077. Есть верхушка того, что уже расковыряли, но в целом там все, как в лучших софтварных проектах: 1) машина — это абстракция над лошадью, у которой есть двери 2) смешные enum’ы с перечислением цензуры (где отдельный параметр цензуры для Китая называется Censor_WinnieThePooh 3) хаки для E3 2019 с комментами REMOVE ASAP

Геймдев есть геймдев. AAA+ или инди на флеше - same vibe... :)

ДА ЛАДНО! https://github.com/google/fully-homomorphic-encryption

«12 SQL and NoSQL Datastores for Your Application» - еще одна статья-введение в современные СУБД. Есть слайды, на которых нормально пояснены: 🔹разница между OLTP / OLAP; 🔹SQL / NoSQL; 🔹разные варианты хранения неструктурированных или частично структурированных данных. Гвоздь программы: сводная табличка с классическими и облачными решениями (AWS, Azure, GCP) для хранения всех возможных типов данных. 🔗Ссылка #базы_данных

Не знаю, кто использует airtable так, что бы это стало актуальным, но концепция интересная: синхронизировать состояние внешнего сервиса в базу: https://syncinc.so/ по наводке @oleg_log

Одного канала всегда (никогда) недостаточно :) Я тут вспомнил, что заводил канал, чтобы делиться всякой красотой. Не канал с мемами, конечно, но почему бы и нет... Ну, во-первых, это красиво...