Группа хакеров 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 :)

Ребята из 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: читать начиная с закрепа