А пока идет перепись тех, у кого есть бесплатная столовка в офисе и тех, кому приходится наливать воду в куллере, аки холопам, вот еще один наброс в тему канала:

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

Бенчмарк (как и все бенчмарки) барахло (и переписывать все на сях я не буду), но в конце списка оказались именно те, кого мы там ждали: руби и питон :)

https://thenewstack.io/which-programming-languages-use-the-least-electricity/

Теперь мы знаем, кто виноват в глобальном потеплении...

​Пятничный SQL-WTF
Понедельничный SQL-TIL

Пару недель я занимаюсь описанием грамматики SQL-синтексиса базы snowflake. Это такая cloud-only база, которую пилят 8 лет, 1500 человек сотрудников, вышли месяц назад на IPO с оценкой $70B...

Как-то давно в твитерах молодежь жаловалась на непонятную документацию постгреса:
https://news.1rj.ru/str/nosingularity/165

Как же выглядит синтаксис snowflake?
Выглядит он как письмо дяди Федора родителям (олды тут?).


1) Нет нормальной структуры.
Часть команд очевидно где-то есть, но найти их не получается. Например, есть описание ALTER ACCOUNT, а CREATE ACCOUNT нет.
Оно, наверное, логично - аккаунт, это сущность, получаемая в результате регистрации. Но если выполнить "несуществующую" команду

CREATE ACCOUNT user

то получим не syntax error, а SQL access control error: Insufficient privileges to operate on account 'USER'


2) Одни и те же сущности описываются разными ключевыми словами:

SOURCE_COMPRESSION = AUTO_DETECT | GZIP | ... | NONE
COMPRESSION = AUTO | GZIP | ... | NONE

еще:

FILE FORMAT, FILE_FORMAT, STAGE_FILE_FORMAT

и еще:

NETWORK POLICY, NETWORK_POLICY

3) Определения повторяются.
Описание параметров FILE FORMAT занимает несколько страниц и копируется из раздела в раздел, везде, где это свойство используется. Видимо, зарплата привязана к количеству строк :)


4) У команд есть алиасы, но про них ничего не сказано.
Случайно узнаешь об этом из примеров. Есть команда REMOVE, во всех примерах - RM.


5) Содержимое строк является частью синтаксиса.

SCHEDULE = '{num MINUTE | USING CRON expr time_zone }'

или вот:

externalStageParams (for Amazon S3) ::= URL = 's3://_bucket_[/_path_/]' ...
externalStageParams (for Google Cloud Storage) ::= URL = 'gcs://_bucket_[/_path_/]' ...
externalStageParams (for Microsoft Azure) ::= URL = 'azure://_account_.blob.core.windows.net/_container[/_path_/]'

Видимо, есть некоторые сомнения в когнитивных способностях пользователей azure, т.к. одного протокола оказалось недостаточно...


6) В некоторых командах строки можно НЕ БРАТЬ в кавычки.
В документации:

PUT file:///tmp/data/mydata.csv @my_int_stage;

А можно брать. Но узнаешь, только если попробуешь...


7) Ключевые слова иногда можно использовать в кавычках:

... COMPRESSION = AUTO ...
... COMPRESSION = 'AUTO' ...

8) Свойства описаны как обязательные, но на самом деле таковыми не являются.
И даже в примерах об этом ничего не нет. Например, в FILE FORMAT можно пропустить описание type и тогда будет считаться, что за основу взят CSV.


9) Порядок некоторых свойств может быть произвольный.
Узнать какие именно свойства не зависят от порядка можно только императивно. Например, о том, что CLUSTER BY можно воткнуть перед описанием колонок я нашел в примере на гитхабе у какого-то левого чувака:

create or replace TABLE "tablecluster" cluster by LINEAR(DATE, ID)(
  DATE TIMESTAMP_NTZ(9),
  ID NUMBER(38,0),
  ...
);

10) Описанный ограничения синтаксиса некоторых свойств в реальности не существуют.
В примере выше CLUSTER BY описан как

CLUSTER BY ( expr1 [ , expr2 ... ] )

То, что параметром может выступать функция, не сказано нигде.


11) Описание аналогичных команд имеет разный формат.

PUT file://_path_to_file_/_filename_ internalStage
GET internalStage file://_path_to_file_/_filename

Видимо, это связанно с возможностью использования свойств в произвольном порядке, но блин!


Опустим подробности, что зарегистрироваться жителям РФ они не дают. Просто "ой, не работает" на этапе регистрации, а в каких-то формах страны просто нет.
Но когда вы прорветесь в админку, можно будет порадоваться - они вернули мне мой 2007. Такая убогая и тормозная админка ставит их на одну ступень со всеми серьезными игроками - гугл и амазон :)
И это не считая того, что там визуально не обозначено и половины тех функций, которые описаны в документации.

Все выпуски SQL-TIL:

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
5) (snowflake) https://news.1rj.ru/str/nosingularity/582

​В этом довольно специфичном тесте PostgreSQL выносит MSSQL и MySQL вперед ногами:


https://www.mssqltips.com/sqlservertip/6607/delete-sql-performance-for-sql-server-mysql-and-postgresql/

Ребята из @profunctor_io большие молодцы и я всегда готов поддержать их призывы рассказать про профунктор-джоб, поэтому вот:

Не секрет, что лучшие вакансии в айти расходятся задолго до попадания на hh и linkedin. Одно из мест где можно ловить такие варианты это канал Профунктора: NVIDIA, Revolut, Bolt, Мосбиржа и другие лучшие карьерные варианты для разработчиков появляются там регулярно. Стоит подписаться, чтобы быть в курсе того сколько нынче платят «по рынку», и не гнуть спину за полцены из-за того что неудачно прособеседовался год назад.

@profunctor_jobs

Андрюха, у нас пхп, возможно битрикс, по коням!

И первая хорошая новость за этот год:


https://www.government.is/news/article/2020/10/27/-Foreign-experts-can-work-remotely-in-Iceland/

​Не перестаю кекать со snowflakeDB (вот тут история, как я грамматику по документации начал писать)

Как можно одновременно выполнить запрос и выдать "SQL compilation error"?

Update: причем ошибка вываливается на примере из документации. А результат, который все-таки прилетает, не совпадает с результатом из документации...

PS: про сноуфлейк нет мемасов, поэтому вот вам демотиватор (!!!):

BORING!

​Прошло несколько месяцев с публикации прошлой версии подборки экзотических применений SQL, поэтому не грех опубликовать ее еще раз, добавив еще один пункт.

Не все знают, но SQL можно использовать не только для работы с данными в БД.
Есть возможность манипулировать данными из командной строки.
Зачем такое может понадобиться?

1) Парсинг JSON-логов
https://github.com/avz/jl-sql
Можно придумать много хороших usecases. Я писал про эту тулзу в статье про тестирование логов - https://news.1rj.ru/str/nosingularity/198

> cat data.json | jl-sql 'SELECT key, SUM(value) AS sum, COUNT(*) AS count GROUP BY key'

2) Работа с параметрами операционной системы
https://osquery.io/
Совершенно безумная и красивая идея. 257 источников данных!

> osqueryi --json "SELECT * FROM mounts m, disk_encryption d WHERE m.device_alias = d.name AND d.encrypted = 0;"

3) Работа с изображениями
https://github.com/escherize/img_sql/

> ./img_sql.py -i samples/matrix.jpg -o samples/matrix_out.jpg -s 'update pixels set r = g, b = r, g = b where x > 700'

Осталось написать транспайлер в GLSL и будет win :)

4) SQL для MongoDB, DynamoDB, Kafka, S3
Если не хочется работать с монгой, но очень нужно, то можно выкрутиться так
https://rockset.com/solutions/mongodb/

Например, отлично зайдет для использования в тулзах для визуализации, таких как Grafana.
Насколько это имеет смысл для работы с базами из приложения, сказать сложно.

5) SQL для запросов по git репозиториям
https://github.com/augmentable-dev/gitqlite (переименовали в askgit)

> -- how many commits have been authored by user@email.com?
> SELECT count(*) FROM commits WHERE author_email = 'user@email.com'

6) Играем музыку оО
https://relational-pipes.globalcode.info/v_0/examples-jack-midi-generating-1.xhtml

А вы тут спрашиваете, зачем я по snowflake упарываюсь...

https://twitter.com/dbengines/status/1322913553590996994

​Не было ни одного случая, чтобы мне не было больно от контакта с интерфейсами продуктов гугла.
Не бомбит только от gmail, да и то, это скорее всего стокгольмский синдром.

Каждый раз, когда появляется необходимость зайти в гугл аналитику или в G Suite, я стараюсь максимально отпрокрастинировать это действие. Потому что знаю, что потрачу в 10 раз больше времени, чем мог бы, и все равно все будет через одно место. И при этом, скорее всего, я не получу того, что мне было нужно, а просто забью.

Почему в аналитике статистика с задержкой в сутки? Виноват часовой пояс? Гуглим... 15 минут спустя находим как настроить часовой пояс для сайта. Проверяем: 10 кликов по менюшкам... Нет, все ок. Часовой пояс подходящий. Так, допустим, аналитика приезжает с задержкой. Гуглим... "Статистика (например, по кликам, конверсиям и показам), как правило, появляется с задержкой примерно в три часа". Ну допустим, но статы нет... А, ладно, хрен с ним, не больно и хотелось...

И так каждый раз! Сцк!

И грузится это все как будто сервера в секретном бункере под горой в Швейцарии, куда протянули только ADSL, а я через TOR захожу.

​я: что-то я не высыпаюсь...
wakatime: на этой неделе ты писал код 50 часов

PS: wakatime считает сколько ты нажимаешь на кнопки в IDE, если не ставить отдельные плагины для браузера и терминала. у меня стоят в vscode и datagrip. Т.е. сколько я гуглил и смотрел ютубчик тут не посчитано.

​Нашел где примененить слово "кринж":

haskell на js:

https://github.com/stevekrouse/hs.js

Саундтрек для дедов на выходных:

https://www.youtube.com/watch?v=nIrJGWohli0

​Пятничный SQL-WTF
Понедельничный SQL-TIL #6

Последние недели я с головой погружен в написание парсера для SnowflakeDB и все SQL-WTF касаются именно этой базы. Я понимаю, что эта база в русскоязычном сегменте интернета мало кого интересует, но других вотсдефаков у меня для вас нет :)

1) LIMIT - не ключевое слово
Источникам данных и колонкам можно задавать псевдонимы:

SELECT t.* FROM table1 AS t

или без AS

SELECT t.* FROM table1 t

Но на этом запросы обычно не заканчиваются. После списка источников данных может идти union, where, group by, having, order by.
Ни одно из этих ключевых слов не может быть использовано в качестве псевдонима. Кроме LIMIT:

SELECT limit.* FROM table1 limit LIMIT 10

2) Неявное именование подзапросов
Если в качестве источника данных используется подзапрос, для него должен быть задан псевдоним. Так работает в PostgreSQL, так работает в MySQL:

SELECT * FROM (SELECT * FROM table1) t

Но в SnowflakeDB это совершенно необязательно. Так же как и в SQLite... :)
Но что будет, если у нас два подзапроса?

SELECT * FROM (SELECT * FROM table1), (SELECT * FROM table1)

В SQLite будет магия - CROSS JOIN с колонками только из первой таблицы... Но, справедливости ради в SQLite даже с заданными псевдонимами и прописанным CROSS JOIN будет такой же результат... B как выяснилось, там нет RIGHT JOIN и FULL JOIN... Пользуясь случаям - привет всем фанатам этой базы :)
Но черт с SQLite, что там у SnowflakeDB?

> SQL compilation error: duplicate alias 'values'

Чего? Какой values?
Оказывается, что SnowflakeDB сам дописывает один и тот же псевдоним к каждому подзапросу:

SELECT values.* FROM (SELECT * FROM table1)

3) Нестрогие значения параметров
В SnowflakeDB есть такая функция для работы с датой:

SELECT  next_day(current_date(), 'Friday')

которая вернет дату следующей пятницы. Удобно. Молодцы. Но:

SELECT  next_day(current_date(), 'Friday I am in love')

даст такой же результат.
Как минимум, неплохо бы было описать это поведение в документации.

4) ISO? Какой ISO?
Правила сортировки (сollation) описываются в формате language[_country][-specifier ...]
И все бы было ок - возьми ISO639-1 для языков, ISO3166-1 для стран. Да, но кого интересуют эти мелочи?

SELECT 'foo' COLLATE 'trololo'

Как я об этом узнал? Случайно, потратив час на поиск того, как узнать доступный список collation.

----

Есть версия, что все эти странности связаны с тем, что основные пользователи SnowflakeDB - дата аналитики и грузить их всякими мелочами типа правильного названия стран и языков это лишнее. Мне сложно сказать что-то по этому поводу, но тем, кто перейдет на SnowflakeDB с мейнстрим баз, гарантированно будет некоторое время больно.
И уже сейчас понятно сколько невалидных отчетов из-за этого было построено, but who cares?