فریب کلاهبرداران را نخورید! تل‌متریو این کانال‌ها را شناسایی و برچسب‌گذاری می‌کند 👉 برای مشاهده برچسب، اشتراک تهیه کنید

There will be no singularity

رفتن به کانال در Telegram

Smartface, technologies and decay @antonrevyako

نمایش بیشتر

روسيا217 163فناوری و برنامه‌ها32 406

1 948

مشترکین

اطلاعاتی وجود ندارد24 ساعت

-17 روز

-630 روز

854

نمایش های پست

~ 64524 ساعت

~ 69648 ساعت

43.82%

نرخ مشارکت

اطلاعاتی وجود ندارد

پست های در روز

Ads index

آرشیو پست ها

1 948

https://twitter.com/toonkoppelaars/status/1441782060880855041?s=28

1 948

Как выглядел бы sql если бы его придумали в 2021

select:
  items:
    - foo
    - bar
  where:
    - eq:
      - foo
      - bar

из нашего чата

1 948

Музыкальная пауза. 5 ноября выйдет "новый" альбом Radiohead - Kid A Mnesia В кавычках, потому что это переиздание Kid A и Amnesiac + неизданное. А пока можно послушать свежую "If You Say The Word" где суровые мужики собирают по лесам заблудившихся клерков :) PS: еще они замутили что-то c epic games. Но на игру не похоже...

1 948

Добавил в свою подборку необычных применений SQL еще парочку записей. Внезапно обнаружилось сразу несколько проектов, реализующих SQL-интерфейс к облачной инфре: cloudquery.io steampipe.io iasql.com Последний не зарелижен, неизвестно будет ли opensource, но выглядит наиболее интересно. Если первые два дают возможность делать SELECT'ы, то последний еще и INSERT'ы (может еще и UPDATE'ы):

INSERT INTO aws_ec2 (ami_id, ec2_instance_type_id)
SELECT ami.id, ait.id
FROM ec2_instance_type as ait, (
    SELECT id
    FROM   amis
    WHERE  image_name LIKE 'amzn-ami-hvm-%'ORDER BY creation_date DESC
    LIMIT 1
) as ami
WHERE  ait.instance_name = 't2.micro';

Как вам идея?

1 948

Clickhouse теперь отдельная компания с $50m инвестиций. Переживаю за Altinity… https://vc.ru/services/295690-yandeks-s-fondami-otkryl-kompaniyu-clickhouse-ona-vypustit-servisy-na-osnove-sistem-upravleniya-bazami-dannyh

1 948

Distributed SQL Summit 2021 (кродеться) Sept 21 - 23 https://distributedsql.org/

1 948

Как и год назад для 13 версии, Hewlett Packard выложили 80 страниц с описанием изменений в Postgresql 14 по сравнению с предыдущей версией. Выделил самые, на мой взгляд, интересные: LZ4 compression TOAST колонки теперь можно жать. CREATE INDEX INCLUDE можно использовать для SP-GiST индексов

 CREATE INDEX idx1_gist1 ON gist1 USING spgist (c1) INCLUDE (c2)

BRIN index Можно делать Bloom-индексы

 CREATE INDEX idx1_data1 ON data1 USING brin (c1 numeric_bloom_ops (false_positive_rate = 0.05, n_distinct_per_range = 100))

Extended Statistics Можно создавать статистику по выражениям

 CREATE STATISTICS extstat1_data1 ON MOD(c1, 10), MOD(c2, 10) FROM data1

Multirange type

 SELECT '{[1, 5), (10, 20]}'::int8multirange

Jsonb type Более удобный синтаксис для JSONB

SELECT ('[1, "2", null]'::jsonb)[1] ;

SELECT ('{"age": 25}'::jsonb)['age'] ;

SELECT ('{"email":"pgsql-hackers@postgresql.org", "phone":"+3012345678"}'::jsonb) ['phone'] ;

Документ полностью

1 948

https://t.me/oleg_log/4870

SELECT
   NULL OR TRUE, -- TRUE
   NULL OR FALSE, -- NULL
   NULL AND TRUE, -- NULL
   NULL AND FALSE -- FALSE

1 948

Очень хочется сделать свою SQL бд? Вот тут ребята из Querify Labs показывают на пальцах как навесить SQL на Apache Ignite. Есть такая штука - Apache Calcite. На ней можно описать парсер и планер с оптимизатором. А потом научить этот план выполняться над целевой базой. Кому-то захочется реализовать мою бредовую идею SQL для редис - пожалуйста. У кого-то своя база на GPU но без SQL - пожалуйста. Есть желающие заменить уродский ELK-синтаксис на нормальный? Велкам. Короче, SQL в каждый дом :)

1 948

1 948

Давно не было выпусков ~~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 знака после запятой. Так и храните сумму в центах или в сотых долях цента! Если по какой-то причине точность плавает, то возьмите либо максимальную, либо храните точность в отдельном поле. Но при этом вы получите прирост скорости в операциях агрегации местами на несколько сотен процентов!

1 948

https://twitter.com/maxua/status/1435504605044133889

1 948

Конференция для дата-инженеров 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 билет). Подробнее почитать о принятых в программу докладах и купить билеты со скидкой можно на сайте.

1 948

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

1 948

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

1 948

Если вы думаете, что создатели 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

1 948

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

1 948

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

1 948

Ребята из 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. А еще вас будет ждать дискуссионная зона и розыгрыш подарков среди участников 🎁 Участие бесплатное, нужно только зарегистрироваться.