​Есть такой замечательный дядька Andy Pavlo из Carnegie Mellon University.
Он одно время разрабатывал pelotondb - автоматическую систему управления БД. Это когда ML считает метрики и подкручивает планировщик в нужную сторону.
Похожие фичи есть у Azure и Oracle.

Проект закопали, и сейчас он занимается новым - ottertune.com
Уже не опенсорс (хехе) и на деньги инвесторов (привлек $2.6m)

Еще у него есть пара отличных курсов на ютубе: Intro to Database Systems, Advanced Database Systems и куча другого годного контента на канале CMUDatabaseGroup
На выходных вместо сериальчиков - милое дело :)

А еще есть конфа про распределенные системы Hydra (плейлисты за 2019 и 2020).
Нет, это не та гидра, о которой все подумали, это другая (нормально назвались, да?).

Andy выступит на этой конфе через пару недель c докладом "The official ten-year retrospective of NewSQL databases".

Вы знаете, что рекламу я не размещаю, но отказать организаторам в том, чтобы рассказать про Andy, я не мог.
Поэтому вот ссылка на ленд и вот купон на скидку: cnb2021JRGpc

Мне за это ничего не будет (разве что из-за упоминания гидры возьмут на карандаш, самизнаетегде), а вам, надеюсь, будет польза :)

Если вдруг когда-то хотели подучить регулярные выражения, RegexOne отлично с этим поможет.

​Китайцы пошли в опенсорс.

Были жалобы, что алибаба выложили PolarDB только для Postgresql. Возрадуйтесь, вот есть compatible with MySQL protocol and syntax распределенная база OceanBase:

https://github.com/oceanbase/oceanbase

Рассказывают, что
Linear scalability OceanBase Database scales transparently to applications and balances the system load automatically. Its cluster can contain more than 1500 nodes. The data volume can reach petabytes. The records in a single table can be more than a trillion rows


Пока все доки на китайском...

​Бен, это Данила, ай нид хелп...

Нам в dwh.dev очень нужен специалист по интерфейсам.
Мы делаем инструменты для визуального менеджмента объектов и работы со сложными связями в базах данных Snowflake (и не только).
И если с экспертизой в области БД, бека и фронта у нас проблем нет, то с крутым и удобным визуалом нам нужна помощь.

Задачи оказались слишком интересными, чтобы хватило ресурсов сделать это силами front-end инженеров :)

Как обычно, не обойдется без нюансов, но об этом в личной переписке (@antonrevyako).

Лайк, шер, во имя скорейшего наступления сингулярности :)

Тут в одном канале напомнили про отличную книгу Skunk Works: личные мемуары моей работы в Локхид

Мне не очень близка тема авиации, но в свое время читал эту книгу запоем.
Совру в цифрах, но был один момент в духе: "самолет сделали за 1 год и пару миллионов долларов".
Сейчас мобильное приложение за такой срок и деньги с трудом сделать можно, а они самолет...

Перевод делали фанаты, он бесплатен. Ссылочки в посте.
https://news.1rj.ru/str/yclibrary/200

PS: Я ее оказывается как-то давно уже рекомендовал :)

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

Ну, во-первых, это красиво...

Не знаю, кто использует airtable так, что бы это стало актуальным, но концепция интересная: синхронизировать состояние внешнего сервиса в базу:

https://syncinc.so/

по наводке @oleg_log

«12 SQL and NoSQL Datastores for Your Application» - еще одна
статья-введение в современные СУБД.

Есть слайды, на которых нормально пояснены:
🔹разница между OLTP / OLAP;
🔹SQL / NoSQL;
🔹разные варианты хранения неструктурированных или частично структурированных данных.

Гвоздь программы: сводная табличка с классическими и облачными решениями (AWS, Azure, GCP) для хранения всех возможных типов данных.

🔗Ссылка

#базы_данных

ДА ЛАДНО!

https://github.com/google/fully-homomorphic-encryption

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

Группа хакеров N-ое время назад взломала CD Project Red (польская игровая студия) и вытащила исходники Cyberpunk 2077.

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

ClickHouse вошла в топ-50 самых популярных в мире СУБД

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

ClickHouse доступна в виде облачного сервиса на платформе Yandex.Cloud. Прямо сейчас вы можете воспользоваться всеми преимуществами СУБД, не вникая в тонкости настройки и обслуживания.

Подробнее о новости читайте в материале на Хабре →

#yacloud_news

Многие знают, что в js (и не только) для большей читаемости можно разделять числа символом подчеркивания:

console.log(1_000_000);
// 1000000

А теперь вопрос со звездочкой (без подглядывания в консоль):

Что получится в результате вызова
SELECT 1_000_000

Справедливо для postgresql, mssql и snowflake. В mysql и sqlite будет ошибка.

Ответы в комменты :)

Вдогонку к

SELECT 1_000_000 

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

SELECT 'foo'
'bar'

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

Все выпуски SQL-TIL (чтобы вы могли пошарить):

postgresql edition:
1) https://news.1rj.ru/str/nosingularity/535
2) https://news.1rj.ru/str/nosingularity/541
3) https://news.1rj.ru/str/nosingularity/548
4) https://news.1rj.ru/str/nosingularity/572

snowflake edition:
5) https://news.1rj.ru/str/nosingularity/582
6) https://news.1rj.ru/str/nosingularity/602
7) https://news.1rj.ru/str/nosingularity/753 и https://news.1rj.ru/str/nosingularity/754
8) https://news.1rj.ru/str/nosingularity/762

mix:
9) https://news.1rj.ru/str/nosingularity/755
10) https://news.1rj.ru/str/nosingularity/803 и https://news.1rj.ru/str/nosingularity/804

"А давайте сделаем сервис на 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

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