There will be no singularity

У всех так пригорело от поста Тонского (см выше), что Никиту в комментах почти распяли, а сам он даже начал отползать с извинениями. Между тем Кортланд Аллен недавно позвал в свой подкаст "Indie hackers" Андрея Азимова - живущего на Бали парня, который кодить почти не умел и продукты делал настолько "на коленке", что волосы шевелятся. Когда он писал свою тулзу "year in progress" - Андрюха не знал, как сделать в макоси прогресс-бар. Поэтому он нарисовал сто (!) картинок от 1% до 100% и написал сто if-ов "if (x==1) нарисовать 1.gif" (это буквальная цитата из его рассказа, я так ржал, что почти врезался в человека на пробежке) От такого кода у любого уважающего себя синьора, конечно, вытекут глаза. Андрей, между тем, зарабатывает $10к в месяц и сам над собой хохочет. Когда он строил какой-то очередной сайт-поделку, он не умел в базы данных. Поэтому засунул все в google sheets и за пару дней наговнокодил скрипт (на php конечно) который забирает контент по API и пихает в HTML. После чего почесал репу и создал из этого красивый продукт https://www.sheet2site.com/ (на этом месте вытекли глаза не только у сеньоров, а вообще у всех продактов/стартаперов) Зато все маркетологи мира очень ему благодарны. Поправил табличку - сайт изменился. Никаких тебе логинов, вордпрессов, CMS-ок или даже маркдауна с джемстеком и тейлвиндом с деплоем через git. Просто дай права на гугл-доку, выбери шаблон - и вот вам ваш готовый сайт. Свободная касса. PS. подкаст тут (на английском), там сверху ссылки itunes/spotify и тд

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

​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 существуют виртуальные колонки для обычных таблиц - при объявлении засунуть в них можно что угодно, но работать будет не все :) - значения в колонках не мемоизируются - с виртуальными колонками многое что нельзя, но несмотря на предыдущий пункт, кластеризацию все-таки можно

Перефразируя классика: Если в 2021 вы еще не в облаке, то что-то с вами не так и вообще позорище... :) Событие пройдет сегодня-завтра, поэтому есть шанс про него не забыть (а не то что pgday). ☁️ Сегодня, в 18:00 (GMT+3), AWS комьюнити приглашает на All about AWS 2021 — бесплатный онлайн ивент, посвященный клауд миграции и её стратегиям ☁️ 📍Язык ивента: украинский и русский 15 июля пройдут панельные дискуссии, где спикеры из AWS и SoftServe будут говорить о: — миграции в клауд, как ее разумно планировать, чтобы сэкономить время и уменьшить расходы; — почему бизнес решает оставаться в дата центрах. 👉 Регистрация

​Чят, пожалуйста, помогите с кастдевом! Мы делаем тулзу для поиска и анализа связей в структурах данных в аналитических базах данных. Есть несколько гипотез, которые хочется протестировать. Вендор базы значения не имеет, думаю, что проблемы у всех приблизительно одинаковые. Есть большая потребность в теплом интро к Data Lead, Chief Data Officier, VP of Data Engineering - с любым техническим или нетехническим специалистам верхних уровней, связанных с датой. Интересуют все области - и дата инжиниринга и дата саентисты. Может еще какие-то есть? :) Не надо пугаться, на данный момент мы НИЧЕГО НЕ ПРОДАЕМ. Основная задача - проверить попадаем мы ли мы в боль и насколько сильно болит. Поэтому не стесняйтесь сдавать своих коллег и коллег коллег :) Языки - RU/EN. Пишите @antonrevyako или в чат

Оказывается сегодня бесплатная конфа по #postgres Список докладов https://pgday.ru/ru/2021/papers

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

​Разговорились с @oleg_log и по мотивам upstash.com родилась идея стартапа: - Берем sqlite и redis - Соединяем одно с другим, наружу выставляем sqlite - Идем в YC как sql over redis as a service ... - PROFIT! Сами мы это, конечно, делать не будем, но вдруг вам захочется странного...

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

​Я ужасно ненавижу дефолты. В любых проявлениях. Но в аргументах методов особенно. Я уже бомбил об этом здесь Если коротко, то это write only фича. IDE тебе подскажет значения дефолтов, когда ты пишешь код. А когда читаешь? А если читаешь не в IDE, а, например, ревьюишь код в гитхабе(лабе)? Все константы должны быть в конфиге и явно передаваться везде, где хочется воткнуть дефолт. А что я об этом вспомнил? У Никиты вышел пост про сборщики в java-мире. Я застал и ant и groovy. Возможно, это и было основной причиной того, что я никогда больше не хочу связываться с java. Хотя, кого я обманываю... Конечно же, не только это. Так вот, Никиту бомбит с того, что джависты взялись писать сборщики на groovy. И там считается нормальным напихать дефолты в любую дырку... Есть некоторые, простигосподи, CTO с 10k подписчиков в твиттере, которые не видят в этом никакой проблемы. Предлагаю всем включить вопрос про дефолты в culture fit interview... :)

Короткий тред: 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 будет ошибка :)