Очередная история успеха приложения на рельсах.
На этот раз у гитлаба
https://about.gitlab.com/blog/2021/09/29/why-we-spent-the-last-month-eliminating-postgresql-subtransactions/

Они месяц с недешевыми консультантами разгребали то, что им нагенерили рельсы. Причем приключение случилось в 4 строках кода.

Может быть вы помните статью dhh, что рельсы им стоят "всего" $450k в год, но зато какой кайф не писать этот богомерзкий SQL.
Это он посчитал только сколько им стоит лишнее железо.

Если решите повторить расчеты для своего ror-проекта, то закладывайте еще работу DBA из расчета где-то $500/час.

Я, честно говоря, не хотел акцентировать внимание на этой истории, потому что, ну а что вы, собственно, хотели от ror.
Но в твиттере CEO Fivetran напомнил о ней с каментом "нахер эти ORM", а дальше все как в тумане...

Никита хочет sql по файловой системе:
https://news.1rj.ru/str/nikitonsky_pub/203

В моей подборке как раз есть пара таких проектов…

Отличный мини сериал о том, как корпорация добра придумала отличную схему, позволившую кинуть множество небольших компаний по всему миру и в частности одну небольшую немецкую компанию, создавшую Terravision - прародителя google earth из 1994 года.

https://www.netflix.com/ru-en/noscript/81074012

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

В блоге Wix(это такой конструктор веб сайтов) рассказали какие базы они используют в каких частях проекта, плюс добавили свой взгляд на минусы и плюсы баз для разных кейсов. Немного поверхностно для такой обширной темы, но для общего понимания ок.

https://medium.com/wix-engineering/5-database-technologies-used-by-2000-wix-microservices-e4769638b8c3

Ничего не будет. Ни кино, ни театра, ни книг, ни газет – одно сплошное телевидение…

https://cloud.google.com/blog/topics/developers-practitioners/postgresql-interface-adds-familiarity-and-portability-cloud-spanner

Любите ли вы питон, как люблю его я...

рельсы-рельсы, шпалы-шпалы, 11 ярдов на насдаке...

https://www.cnbc.com/2021/10/14/gitlab-jumps-in-nasdaq-debut-after-pricing-ipo-above-expected-range.html

eto ya

К вопросу о "сделать плохо, но быстро" VS "сделать круто, но за год"

Я всегда был за первое, "из говна и палок, но вчера". А потом понял, что, во-первых, мне наверное везло с коллегами - которые могли и быстро, и без откровенного шлака. А во-вторых вспомнил про GST - "Google Standard Time".

Все сервера гугла работают в часовом поясе Pacific Time. Сколько у них серверов в разных концах света, миллионы? И на всех - калифорнийское время. В логах, в базах, в новостных лентах все хранится в PST. Даже в BigQuery если написать new Date() будет, сука, PST. Когда-то в самом начале делали "быстро" и решили забить, а теперь чинить настолько сложно и стремно, что проще оставить как есть.

Кто-то в шутку решил назвать "Google Standard Time". Так и прижилось.

все еще более проклято, чем казалось…

https://twitter.com/lefred/status/1449463283921137671

Подведем итог ^

В mysql при inline-объявлении внешнего ключа в CREATE TABLE, никакой FK не создается и сослаться можно на любые колонки, даже не имеющие unique констрейнта!

create table b (id int references a(id));

И это поведение не зависит от движка таблицы. При дампе DDL это свойство не будет отображено.

Создать внешний ключ можно только для движков innodb и ndb одним из 2 способов:

create table c (id int, constraint foreign key (id) references a(id));

или

alter table b add foreign key (id) references a(id);

Странно, что uppercase еще никого не оскорбляет…

https://twitter.com/sethrosen/status/1449719427600113669

Анонсирован CockroachDB Serverless

https://www.cockroachlabs.com/blog/announcing-cockroachdb-serverless

#cockroachdb

​Функциональщина в SQL by timescale:

SELECT device_id, 
  timevector(ts, val) -> sort() -> delta() -> abs() -> sum() 
      as volatility
FROM measurements
WHERE ts >= now()-'1 day'::interval
GROUP BY device_id;

https://blog.timescale.com/blog/function-pipelines-building-functional-programming-into-postgresql-using-custom-operators/

А давайте посмотрим что там еще есть в этом гитлабе.... 1/2

TOP GitLab DDL Warnings

Из top 15 найденных в DDL ворнингов, 13 касаются индексов. 5 из них рапортуют о различных пересечениях индексов - функциональных с обычными, частичных с функциональными и тд. Еще пять - о различных способах слишком большого покрытия таблиц индексами.

Еще парочка касается индексов и boolean полей.
Первое: не делать индексы только по булевым полям. В большинстве случаев такие индексы не будут использованы, т.к. по цене они будут дороже, чем seq scan.
Второе: не делать сравнение на равенство c булевыми константами (= TRUE). В pg есть две разные конструкции сравнения для булевого типа: = TRUE и IS TRUE. Рекомендуется везде использовать булево поле без сравнений вообще, чтобы не думалось.

Есть индексы на колонки без ограничений размерности. Например, типов TEXT и JSON(B) никак не ограничены. Это может привести к тому, что данные невозможно будет вставить с ошибкой "Values larger than 1/3 of a buffer page cannot be indexed.". Т.е. нужно либо ограничить размер колонки, чтобы он не превышал 1/3 от 8 кб (по умолчанию), либо нужно делать функциональные индексы на хеш значений из этой колонки.

Далее следует одна из совершенно базовых ошибок - сравнение с NULL.

 CREATE INDEX ON ... (group_id, noscript) WHERE (project_id = NULL::integer); 

Подразумевается, что он должен ускорить запросы вида

 WHERE group_id = 1 AND project_id = NULL 

Так вот, сам этот запрос не имеет физического смысла, т.к. project_id = NULL всегда вернет NULL. А TRUE AND NULL постгрес упростит до FALSE.
Т.е. этот индекс никогда не будет использован.

И завершает хит-парад ряд довольно популярных архитектурных ошибок.

Значение по умолчанию без ограничения NOT NULL. В большинстве случаев, если задано значение по умолчанию, разработчик не хочет чтобы оно было NULLом. Иначе зачем значение по умолчанию? :) Но если нет соответствующего констрейнта, то рассчитывать на это уже нельзя. А значит рано или поздно, NULL там окажется и сломает все, что можно сломать.
Причем часть разработчиков Gitlab это учитывает, а часть нет. В итоге схема напоминает письмо родителям дяди Федора из Простоквашино - рядом соседствуют поля с констрейнтами и без них.

Так же присутствуют поля с именем uuid, но типом VARCHAR, массивы идентификаторов, которые не проверяются на консистентность с таблицами, на которые они должны ссылаться и прочее и прочее...

Все сказанное выше, говорит, что архитектуру приложения стоит хорошенько переосмыслить, т.к. видно, что проблемы с тормозящими запросами пытаются решить созданием еще одного индекса, заточенного под конкретный запрос. Большое количество индексов снижает скорость вставки и обновления. Кроме того, как можно заметить, некоторые индексы никогда не будут использованы, а часть из них вообще может привезти к ошибкам в операциях вставки и обновления.

DSS21
Session recordings from Distributed SQL Summit 2021 are now available.

https://vimeo.com/showcase/8863402