There will be no singularity

Все выпуски SQL-WTF 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 9) https://t.me/nosingularity/826 mix: 10) https://t.me/nosingularity/755 11) https://t.me/nosingularity/803 и https://t.me/nosingularity/804 12) https://t.me/nosingularity/808 и https://t.me/nosingularity/809 13) https://t.me/nosingularity/857

​Давно не было выпусков SQL-WTF SQL-TIL, поэтому давайте сегодня я исправлюсь и разберу один кейс, с которым столкнулся соучастник нашего Snowflake чатика. Реляционщики, не расходитесь! Кейс может быть воспроизведен в любой БД :) Да, и в Postgresql тоже. Вводные: есть несложный вопрос с парой джойнов, группировкой и having. Упростим его значимую часть до такой:

SELECT id
FROM t1
  LEFT JOIN t2 ON t2.t1id=t1.id
GROUP BY id
HAVING SUM(amount) = 0

Логика такая: необходимо выбрать все объекты, за которые заплатили, но деньги за них были возвращены в полном объеме, т.е. сумма всех платежей = 0. Проблема заключалась в следующем: запрос возвращает 2 строки, но при добавлении имени таблицы в условие группировки (

 GROUP BY t1.id 

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

 HAVING SUM(amount) = 0 

во втором случае отбрасывает один нужный ряд. Очевидно, что какая-то проблема с суммированием, но без данных понять какая на глаз довольно сложно. Но и после предоставления реальных данных баг воспроизвелся не так, как было в условии. Но причина была та же - у колонки AMOUNT тип FLOAT! Каждому разработчику стоит запомнить первое правило бойцовского клуба: НЕ ХРАНИТЬ ФИНАНСОВЫЕ ДАННЫЕ В ТИПЕ FLOAT! Так почему сумма FLOAT может быть не равна нулю, там где она должна быть равна нулю? Не, snowflake не сломан. Баг есть во всех базах. А разгадка одна — безблагодатность IEEE 754 standard. С примерами можно ознакомиться тут: 0.30000000000000004.com Если коротко, математические операции над числами с плавающей точкой сломаны во всех языках программирования и вам стоит избегать их, если требуется точная математика :) Ну ок, допустим, но почему имя таблицы аффектит математику, спросите вы. А оно и не аффектит :) Фокус в том, что эти фантомные знаки после запятой зависят от мест слагаемых! Да, забудьте все то, чему вас учили в школе, добро пожаловать в реальный мир :)

SELECT
  0.1::FLOAT - 0.1::FLOAT + 0.2::FLOAT - 0.2::FLOAT,
  0.1::FLOAT + 0.2::FLOAT - 0.1::FLOAT - 0.2::FLOAT

даст 0 и 0.000000000000000027755575615628914. Т.е. разный изначальный порядок значений в колонке amount даст разные значения при суммировании, и соответственно,

 HAVING SUM(amount) 

будет равен нулю не всегда... А почему меняется порядок значений? И тут предъявлять претензии к Snowflake так же будет безосновательным. Все дело в том, что порядок значений не гарантирован без явного указания сортировки практически в любой базе. Да, именно так. Если не указан ORDER BY, то в общем случае порядок записей будет рандомным. Все будет зависеть от того как планировщик посчитает нужным доставать данные в текущий момент. Когда у вас есть джойны, группировки и тд - энтропия только увеличивается, потому что алгоритм, по которому будет произведен JOIN может различаться от запуска к запуску. То же самое касается и GROUP BY. Отдельный вопрос, конечно, почему указание имени таблицы как-то на это повлияло, но общую ситуацию это никак не меняет. В следующий раз стрельнуло бы не это, так другое. Например, у меня описанное поведение воспроизводилось при добавлении/удалении JOIN. Что же стоит сделать прямо сейчас, чтобы не пролюбить все полимеры? 1) найти руками все места в вашем проекте, где используется FLOAT и проверить, не участвует ли он в математических операциях. 2) для хранения финансовых данных заменить FLOAT на NUMERIC, а в приличных базах лучше на INT. 3) дождаться реализацию автоматической проверки в holistic.dev для вашей базы :) Почему int/bigint лучше numeric? В 99 случаев из 100 вы знаете с какой точностью вам нужно хранить дробные числа. Обычно это 2 или 4 знака после запятой. Так и храните сумму в центах или в сотых долях цента! Если по какой-то причине точность плавает, то возьмите либо максимальную, либо храните точность в отдельном поле. Но при этом вы получите прирост скорости в операциях агрегации местами на несколько сотен процентов!

Конференция для дата-инженеров SmartData 2021 — 11-14 октября, онлайн Вас ждёт 4 дня докладов о разных аспектах дата-инжиниринга: стриминг, хранение данных, MLOps, инструменты и многое другое. Среди спикеров: — Andy Pavlo, профессор компьютерных наук в университете Carnegie Mellon, эксперт по базам данных; — Ash Berlin-Taylor, контрибьютор и член core team Apache Airflow, Director of Airflow Engineering в Astronomer; — Владимир Озеров, руководитель компании Querify Labs, которая занимается исследованием и разработкой компонентов СУБД для технологических компаний; — Tejas Chopra, Senior Software Engineer в команде Data Storage Platform в Netflix. И это лишь начало списка — программа постоянно пополняется! Специально для нашего канала организаторы сделали промокод nosingularity2021JRPc (действует на Personal Standard билет). Подробнее почитать о принятых в программу докладах и купить билеты со скидкой можно на сайте.

Кажется, что на smartdata я не попадаю в качестве докладчика со своими крутыми историями про snowflake, но это, конечно же, не повод не посмотреть эту конференцию. Вот, кстати список докладов. И еще...

Патент на JOIN… https://twitter.com/andy_pavlo/status/1432405663523688449

Если вы думаете, что создатели ORM уж точно умные ребята, с большой экспертизой в разных БД и знают как надо делать хорошо точно лучше, чем вы (и если историй про Django было недостаточно), то вот sequelize: CREATE OR REPLACE FUNCTION pg_temp.sequelize_upsert() RETURNS integer AS $func$ BEGIN INSERT INTO ... VALUES(...); RETURN 1; EXCEPTION WHEN unique_violation THEN UPDATE ... SET ... WHERE ... ; RETURN 2; END; $func$ LANGUAGE plpgsql; SELECT * FROM pg_temp.sequelize_upsert(); from https://twitter.com/samokhvalov/status/1431147427612880899

​У меня есть еще одна коллекция - подборка экзотических применений SQL Чего там только нет - и парсинг json и работа с файловой системой, с блокчейном и даже кубером. Сегодня добавился еще один пункт - рейтрейсинг oO

Jupyter notebooks здорового человека для дата инженеров: evidence.dev маркдаун с sql, который рендерится в статический html Обсуждение на HN: https://news.ycombinator.com/item?id=28304781

Ребята из JUG опять что-то мутят :) На этот раз про бигдату с джавой. 26 августа в 18:00 компания IT_One вместе с JUG Ru Group проведет бесплатный онлайн митап по Big Data и Java. На «IT_One Meet Up: Java and Big Data» эксперты будут говорить о технологиях, инструментах, методах и многом другом, чем живут дата-специалисты. В программе: — Максим Стаценко, «Обзор технологий хранения больших данных. Плюсы, минусы, кому подойдет»; — Вадим Опольский, «Apache Flink vs Свой Java Код. Для приземления данных из Kafka»; — Круглый стол c Максимом Юнусовым, Вадимом Опольским и Максимом Стаценко, на котором спикеры обсудят системы хранения данных, архитектуры и разные подходы к работе с Big Data. А еще вас будет ждать дискуссионная зона и розыгрыш подарков среди участников 🎁 Участие бесплатное, нужно только зарегистрироваться.

Алекс поделился историей про саппорт aws: https://t.me/devfounder/112 Для меня недосягаемой вершиной саппорта всегда был Рокетбанк. Без булщита, с живыми людьми, которые говорят с тобой на одном языке. Вот тут коротенько написано про них. С чем категорически не согласен, так это что саппорт это _дешевая_ замена маркетинга. Хороший саппорт - это, сцк, очень дорого.

​Firebolt зовут на Product Showdown 25 августа Но внезапно обнаружились записи весенних сессии https://vimeo.com/522252264 https://vimeo.com/511021032 Коротко: - Архитектура Snowflake-like - хранение на s3, независимо запускаемые compute инстансы + слой оркестрации и метадаты. - Хранение данных очень похоже на clickhouse: колонки, партиции и сжатие. Колонки сортируются по PRIMARY KEY в пределах партиции (видимо). Для тех, кто не знаком с clickhouse, замечу, что PK в данном случае не имеет ничего общего с уникальностью. Это sparse index, который определяет поля, по которым будет проводиться сортировка (в пределах партиции). - Есть еще 2 типа индексов - aggregated и join. Aggregate похож на materialized view. Но это не точно: https://vimeo.com/512940949 Join похож на... обычный индекс: https://vimeo.com/512937916 Пока индексы нужно создавать вручную, но потом система сама начнет их рекомендовать. Почему не делать автоматически - хз. - Есть ДВА доступных движка: read/write для general purpose (ETL) и read only для data analytics. Движки выбираются в специальном интерфейсе (а не из SQL, как ожидалось бы) и запускаются на EC2 инстансах, размер которых нужно выбрать до запуска. Можно указать auto-stop период для каждого инстанса: 20 минут/час/никогда. - Упоминается Firebolt ETL на SQL. Из уникальных фич: импорт из kafka. - Заявляется в 10 раз более эффективное расходование ресурсов aws. $16 snowflake vs $1.54 firebot. Табличка сравнения содержит запросы #1, #2, #3, #4 и #5. Что бы это ни значило.... - Вопрос из зала #1: чем вы отличаетесь от snowflake? - во-первых, мы быстрее - во-вторых, мы даем вам больше свободы выбора железа - в-третьих, мы дешевле ¯\_(ツ)_/¯ - Вопрос из зала #2: какой дилект SQL вы поддерживаете? - Postgre-sh - Вопрос из зала #3: сколько времени занимает изменение размера compute-инстанса? - 2-3 минуты Формально получается, что firebolt - это оркестратор managed баз. Скорее всего только Posgresql. В разделе про неструктурированные данные идет речь о функции unnest, которая есть, кажется, только в Posgresql и BigQuery. Еще возникают интересные вопросы, например, об уровне изоляции транзакций в read/write движке. Теоретически, его же можно применять не только для ETL. Можно же, да?.. Пока рано говорить об удобстве использования, но выбор движка в интерфейсе, 3 настройки автостопа, и запуск инстанса за 2-3 минуты заставляет приуныть...

​Phil Eaton, который перепиливал PostgreSQL на go, запостил список SQL парсеров на go, js, java, python: https://twitter.com/phil_eaton/status/1428490231532212231 До моей коллекции SQL тулзин на github ему, конечно, далеко, но несколько новых ссылок я туда добавил :)

​Известного в 80-90х годах музыканта, когда он в сотый раз поехал с турне «лучшее за 30 лет», спросили, не собирается ли он написать новых песен, а то сколько уже можно? Он ответил: «новые песни пишут те, у кого старые плохие» Вот и Егор иногда стряхивает пыль со своих нетленок: ActiveRecord Is Even Worse Than ORM

@здец подкрался незаметно, хоть виден был из далека... Сложно это признавать, но не только таксистов и продавцов со дня на день заменят железные болваны, но и нас с вами. Нас, это нас - программистов, верстальщиков, тестировщиков. Всех. Вы хочите пруфов? Их есть у меня: https://www.youtube.com/watch?v=Mc-gWblq7K4 Ничего не будет. Ни кино, ни театра, ни книг, ни газет – одно сплошное телевидение. Пользуясь пятницей, предлагаю отправиться в запой. В этом нас AI пока не догнал. Но это только ПОКА...

Из нашего чатика: https://twitter.com/andy_pavlo/status/1425277882935488518

​Хозяйке стартаперам на заметку: в B2B все происходит ОЧЕНЬ долго. Многие из вас знают, что мы разрабатываем несколько продуктов - holistic.dev, parsers.dev и dwh.dev У holistic.dev есть интеграции со всеми основными клауд провайдерами в РФ. Они сделаны в виде FaaS (function as a service) только по одной причине - облакам некогда заниматься такими интеграциями. Но ребята из MCS (облако mailru) оказались наиболее легкими на подъем и запилили интеграцию для своих managed баз прямо к себе в админку. Таймлайн выглядел так: - 2020 весь год. Я ищу контакты в MCS - 2020 декабрь. С первого разговора с нужным человеком MCS принимают решение об интеграции - 2021 февраль. Интеграция готова - 2021 март. Я узнаю о том, что интеграция готова, мы начинаем общаться о промо материалах - 2021 апрель. Я рассказываю об интеграции у себя в канале - 2021 июнь. Мы общаемся о промо материалах. - 2021 август. Промо выходит в медиа каналах mail.ru (Новость на сайте и в телеге) Собственно, это была подводка к новости - про нашу интеграцию с MCS объявлено официально, ура! :) PS: если решите делать B2B стартап, ищите sales-кофаундера сразу....

Oracle придумал ускоритель для managed mysql в своем облаке (HeatWave): oracle.com/mysql/heatwave/ Это такая in-memory ai нахлобучка, что бы все было быстрее. For analytics workloads, HeatWave is 6.5X faster than Amazon Redshift at half the cost, 7X faster than Snowflake at one-fifth the cost, 9X faster than Google Big Query at one-fourth the cost, 3X faster than Azure Synapse at one-fifth the cost, and 1400X faster than Amazon Aurora at half the cost. For mixed workloads, HeatWave delivers 42 times better price performance than Amazon Aurora. Как понимаю, это что-то похожее на ottertune.com от Andy Pavlo. Мне кажется, что что-то похожее есть в самом оракле уже года 3-4. Но это не точно..

​Слышали про язык V (As fast as C)? Вот и я не слышал... Но вдруг вам захочется странного, вот SQL database written in pure V. PS: добавил в свою коллекцию опенсорц тулзин для SQL на github. По наводке @sysadmin_tools