Что такое ORM наоборот?
Давайте я для начала попробую озвучить основные плюсы использования ORM для реляционных баз как я их вижу.
Disclamer: я имел не очень большой опыт с ORM и было это довольно давно, поэтому озвучу базовые моменты. Возможно, я где-то неправ или существуют интересные фичи, о которых мне стоило бы знать. Если да, расскажите, пожалуйста об этом в чате канала.
1) Все пишется на одном языке, который знает разработчик любого грейда
2) Схема базы описываться в коде приложения, т.е. мы имеем один источник правды
3) Одна модель - один релейшен. CRUD может сгенерировать сам фреймворк.
4) Запросы собираются в коде и полностью соответствуют схеме
5) ORM все знает про маппинг типов базы в типы языка программирования
6) Вся логика в приложении, база только хранит данные
Из 2 и 4 следует еще один плюс - при миграции сложно будет все сломать.
Насколько я понимаю, без типизации сломать таки будет несложно, но давайте предположим, что мы все пишем на языках с явной типизацией. (хехе)
Не будем выявлять слабые места в этом списке. Лучше посмотрим на текущую ситуацию с разработкой приложений с использованием реляционных баз на чистом SQL.
Очевидные минусы:
1) Нужно знать +1 язык программирования (SQL)
2) Нужно разбираться в тонкостях работы используемой базы
3) Маппинг типов может зависеть от используемой библиотеки и об этом нужно знать
4) Приходится писать избыточный код - один раз на SQL и в приложении, чтобы отдать данные потребителю.
И самое неприятное - НЕТ НИКАКОЙ ГАРАНТИИ СООТВЕТВИЯ ЗАПРОСОВ И СХЕМЫ, а так же ТИПОВ РЕЗУЛЬТАТА ЗАПРОСА И ТИПОВ ВНУТРИ ПРИЛОЖЕНИЯ.
Каждые изменения в схеме влекут за собой ручную проверку, много тестов, переписывание типов и схем для протоколов.
А плюсы?
1) Можно максимально гибко использовать возможности базы
2) В большинстве случаев можно избежать проблемы N+1, что очень благотворно сказывается на производительности приложения и бюджете на железо
3) Вычисления рядом с данными делаются намного быстрее, чем те же вычисления в приложении
Кроме того, нормализация данных не подразумевает, что мы запихиваем одну доменную сущность в одну таблицу. Т.е. CRUD, затрагивающий 1 таблицу практически никогда не имеет смысла.
Создание или изменение бизнес сущности генерирует изменения в нескольких таблицах. Если выполнять все эти операции в одном запросе c common table expression, то все это выполнится (или нет) в пределах 1 транзакции. Иначе нам придётся реализовывать все нужные шаги в приложении с соответствующим количеством сетевых взаимодействий.
Но как же нам быть, если мы по какой-то причине уже хорошо знаем SQL, умеем CTE, LATERAL, FILTER, IS DISTINCT OF и знаем как оптимизировать count, но нам надоело контролировать целостность руками и писать кучу лишнего кода внутри приложения только для того, чтобы прокинуть данные от базы к клиенту?
Я предлагаю взять лучшее от обоих миров: пишем на SQL, а (почти) весь код приложения будет генерироваться автоматически!
Что нам для этого понадобится?
1) DDL в одном или нескольких файлах
2) Каждый отдельный DML-запрос придется теперь не собирать в коде приложения, а хранить в виде отдельного файла
3) Какое-то соглашение по именованию объектов в сгенерированном коде: как бы будем генерить имена типов, контроллеров, моделей и всего остального
4) Шаблоны кода для интересующего нас языка программирования
5) Маппер типов базы в типа интересующего нас языка программирования
Берем DDL, DML, извлекаем из DML метадату о результате (типы, nullability, класс количества строк), генерируем код (+ схемы, + тесты) и экономим больше половины рабочего времени!
Бонусом идут:
1) Автоматический контроль за изменением типов возвращаемых запросом значений при рефакторинге базы или запроса
2) Автоматический контроль за соответствием типов в запросе и коде приложения
3) Интеграция в CI
4) Все бенефиты статического анализатора holistic.dev :)
Ну как?
Давайте я для начала попробую озвучить основные плюсы использования ORM для реляционных баз как я их вижу.
Disclamer: я имел не очень большой опыт с ORM и было это довольно давно, поэтому озвучу базовые моменты. Возможно, я где-то неправ или существуют интересные фичи, о которых мне стоило бы знать. Если да, расскажите, пожалуйста об этом в чате канала.
1) Все пишется на одном языке, который знает разработчик любого грейда
2) Схема базы описываться в коде приложения, т.е. мы имеем один источник правды
3) Одна модель - один релейшен. CRUD может сгенерировать сам фреймворк.
4) Запросы собираются в коде и полностью соответствуют схеме
5) ORM все знает про маппинг типов базы в типы языка программирования
6) Вся логика в приложении, база только хранит данные
Из 2 и 4 следует еще один плюс - при миграции сложно будет все сломать.
Насколько я понимаю, без типизации сломать таки будет несложно, но давайте предположим, что мы все пишем на языках с явной типизацией. (хехе)
Не будем выявлять слабые места в этом списке. Лучше посмотрим на текущую ситуацию с разработкой приложений с использованием реляционных баз на чистом SQL.
Очевидные минусы:
1) Нужно знать +1 язык программирования (SQL)
2) Нужно разбираться в тонкостях работы используемой базы
3) Маппинг типов может зависеть от используемой библиотеки и об этом нужно знать
4) Приходится писать избыточный код - один раз на SQL и в приложении, чтобы отдать данные потребителю.
И самое неприятное - НЕТ НИКАКОЙ ГАРАНТИИ СООТВЕТВИЯ ЗАПРОСОВ И СХЕМЫ, а так же ТИПОВ РЕЗУЛЬТАТА ЗАПРОСА И ТИПОВ ВНУТРИ ПРИЛОЖЕНИЯ.
Каждые изменения в схеме влекут за собой ручную проверку, много тестов, переписывание типов и схем для протоколов.
А плюсы?
1) Можно максимально гибко использовать возможности базы
2) В большинстве случаев можно избежать проблемы N+1, что очень благотворно сказывается на производительности приложения и бюджете на железо
3) Вычисления рядом с данными делаются намного быстрее, чем те же вычисления в приложении
Кроме того, нормализация данных не подразумевает, что мы запихиваем одну доменную сущность в одну таблицу. Т.е. CRUD, затрагивающий 1 таблицу практически никогда не имеет смысла.
Создание или изменение бизнес сущности генерирует изменения в нескольких таблицах. Если выполнять все эти операции в одном запросе c common table expression, то все это выполнится (или нет) в пределах 1 транзакции. Иначе нам придётся реализовывать все нужные шаги в приложении с соответствующим количеством сетевых взаимодействий.
Но как же нам быть, если мы по какой-то причине уже хорошо знаем SQL, умеем CTE, LATERAL, FILTER, IS DISTINCT OF и знаем как оптимизировать count, но нам надоело контролировать целостность руками и писать кучу лишнего кода внутри приложения только для того, чтобы прокинуть данные от базы к клиенту?
Я предлагаю взять лучшее от обоих миров: пишем на SQL, а (почти) весь код приложения будет генерироваться автоматически!
Что нам для этого понадобится?
1) DDL в одном или нескольких файлах
2) Каждый отдельный DML-запрос придется теперь не собирать в коде приложения, а хранить в виде отдельного файла
3) Какое-то соглашение по именованию объектов в сгенерированном коде: как бы будем генерить имена типов, контроллеров, моделей и всего остального
4) Шаблоны кода для интересующего нас языка программирования
5) Маппер типов базы в типа интересующего нас языка программирования
Берем DDL, DML, извлекаем из DML метадату о результате (типы, nullability, класс количества строк), генерируем код (+ схемы, + тесты) и экономим больше половины рабочего времени!
Бонусом идут:
1) Автоматический контроль за изменением типов возвращаемых запросом значений при рефакторинге базы или запроса
2) Автоматический контроль за соответствием типов в запросе и коде приложения
3) Интеграция в CI
4) Все бенефиты статического анализатора holistic.dev :)
Ну как?
Чувствую, что к предыдущему посту требуется пояснительная бригада.
Я не призывал заменить все приложения на SQL. Я ж не из компании Oracle :)
И не из Lingualeo :)
Совершенно необязательно подобным образом генерировать весь код приложения. Можно генерировать код только для точек сопряжения приложения и базы.
Мне любезно подсказали инструмент, который решает ту же проблему:
https://github.com/adelsz/pgtyped
Задумано красиво - берем запросы, берем готовую запущенную(!) базу, делаем prepared statements, понимаем что будет на выходе.
Несомненный плюс - невозможно накосячить. Типы будут экспортированы точно так как нужно, а не так, как запрограммировал какой-то анон из интернета.
Но не обошлось без минусов:
- работает только с Postgresql
- экспортирует только в ts
- ничего не знает про nullability результатов
- ничего не знает про класс количества строк
Если про первые 2 пункта все понятно, то про важность последних поговорим отдельно.
Если вы пишете не на Java, где любая переменная может быть null, то довольно много логики может быть завязано на то, может ли переменная принимать значение null или нет.
Читаешь из ответа поле и используешь его в качестве индекса массива или имени свойства объекта? Молодец, лови undefined! Или сегфолт.
Или проверяй каждый раз - null или нет. И думай что делать, если null, которого быть не должно.
WTF класс количества строк?
Статическими методами, естественно, невозможно оценить сколько точно строк вернет запрос. Но можно попробовать рассчитать количество в следующих категориях - NONE, ONE, ONE OR NONE, MANY, MANY OR NONE. Если вы пишете на js и используете pg-promise, то в нем есть методы с соответствующими названиями, которые автоматически делают assert.
Зачем?
Обычно я привожу такой пример.
Пишите вы финансовую систему. Есть у вас запрос, который создает ордер на вывод денег. И запрос сложный. С кучей изменяющих данные CTE, джойны из вьюх и вот это все.
И вы знаете, что он вернет ровно одну строку, в которой будет id нового ордера.
На самом деле вы ДУМАЕТЕ, ЧТО ЗНАЕТЕ. В случае со сложными запросами это практически нереально оценить на глаз. Особенно человеку, который только онбордится в проект.
Но допустим, что это реально так.
Вы написали тесты на этот функционал все вроде бы ок.
Но вот нужно сделать новую фичу. Вы, или что хуже, новый сотрудник, рефакторит базу. В процессе удаляет какой-то существующий констрейнт. Например, NOT NULL становится NULL.
Внимание, вопрос: сломается ли что-то из 500/1000/2000 запросов в вашей базе?
А это мы сейчас проверим! У нас же есть тесты! (гыгыгы)
Давайте опустим тот момент, что тесты не покрывают все возможные комбинации данных в базе.
Запустили тесты и... Все ок :) Старое поведение не поменялось.
Все задеплоили, ушли домой.
Но, как обычно, в ночь с пятницу на субботу, начали массово поступать данные от новой фичи.
И внезапно оказывается, что теперь запрос, генерящий ордера на вывод денег стали генерировать не 1 ордер и возвращать 1 строку, а генерит несколько ордеров и возвращает несколько строк...
И хорошо, если у вас не крипто проект.
Иначе в понедельник можно будет на работу уже не выходить, т.к. за выходные все деньги компании будут выведены.
-----
Есть еще много полезных вещей, которые можно извлечь из запроса, если парсить его целиком, а не читить, как pgtyped.
Например, список всех релейшенов (таблицы, вьюхи) и типы воздействия на них (SELECT/INSERT/UPDATE/DELETE)
Или список всех связей, которые есть в join/where.
Я не призывал заменить все приложения на SQL. Я ж не из компании Oracle :)
И не из Lingualeo :)
Совершенно необязательно подобным образом генерировать весь код приложения. Можно генерировать код только для точек сопряжения приложения и базы.
Мне любезно подсказали инструмент, который решает ту же проблему:
https://github.com/adelsz/pgtyped
Задумано красиво - берем запросы, берем готовую запущенную(!) базу, делаем prepared statements, понимаем что будет на выходе.
Несомненный плюс - невозможно накосячить. Типы будут экспортированы точно так как нужно, а не так, как запрограммировал какой-то анон из интернета.
Но не обошлось без минусов:
- работает только с Postgresql
- экспортирует только в ts
- ничего не знает про nullability результатов
- ничего не знает про класс количества строк
Если про первые 2 пункта все понятно, то про важность последних поговорим отдельно.
Если вы пишете не на Java, где любая переменная может быть null, то довольно много логики может быть завязано на то, может ли переменная принимать значение null или нет.
Читаешь из ответа поле и используешь его в качестве индекса массива или имени свойства объекта? Молодец, лови undefined! Или сегфолт.
Или проверяй каждый раз - null или нет. И думай что делать, если null, которого быть не должно.
WTF класс количества строк?
Статическими методами, естественно, невозможно оценить сколько точно строк вернет запрос. Но можно попробовать рассчитать количество в следующих категориях - NONE, ONE, ONE OR NONE, MANY, MANY OR NONE. Если вы пишете на js и используете pg-promise, то в нем есть методы с соответствующими названиями, которые автоматически делают assert.
Зачем?
Обычно я привожу такой пример.
Пишите вы финансовую систему. Есть у вас запрос, который создает ордер на вывод денег. И запрос сложный. С кучей изменяющих данные CTE, джойны из вьюх и вот это все.
И вы знаете, что он вернет ровно одну строку, в которой будет id нового ордера.
На самом деле вы ДУМАЕТЕ, ЧТО ЗНАЕТЕ. В случае со сложными запросами это практически нереально оценить на глаз. Особенно человеку, который только онбордится в проект.
Но допустим, что это реально так.
Вы написали тесты на этот функционал все вроде бы ок.
Но вот нужно сделать новую фичу. Вы, или что хуже, новый сотрудник, рефакторит базу. В процессе удаляет какой-то существующий констрейнт. Например, NOT NULL становится NULL.
Внимание, вопрос: сломается ли что-то из 500/1000/2000 запросов в вашей базе?
А это мы сейчас проверим! У нас же есть тесты! (гыгыгы)
Давайте опустим тот момент, что тесты не покрывают все возможные комбинации данных в базе.
Запустили тесты и... Все ок :) Старое поведение не поменялось.
Все задеплоили, ушли домой.
Но, как обычно, в ночь с пятницу на субботу, начали массово поступать данные от новой фичи.
И внезапно оказывается, что теперь запрос, генерящий ордера на вывод денег стали генерировать не 1 ордер и возвращать 1 строку, а генерит несколько ордеров и возвращает несколько строк...
И хорошо, если у вас не крипто проект.
Иначе в понедельник можно будет на работу уже не выходить, т.к. за выходные все деньги компании будут выведены.
-----
Есть еще много полезных вещей, которые можно извлечь из запроса, если парсить его целиком, а не читить, как pgtyped.
Например, список всех релейшенов (таблицы, вьюхи) и типы воздействия на них (SELECT/INSERT/UPDATE/DELETE)
Или список всех связей, которые есть в join/where.
Продолжают поступать ссылки на различные тулзы, связанные с SQL. У меня есть подборка, куда я все это добро добавляю:
https://github.com/antonrevyako/useful-links/blob/master/opensource-sql-tools.md
Так же есть пост с подборкой экзотических применений SQL:
https://news.1rj.ru/str/nosingularity/595
https://github.com/antonrevyako/useful-links/blob/master/opensource-sql-tools.md
Так же есть пост с подборкой экзотических применений SQL:
https://news.1rj.ru/str/nosingularity/595
Новых баз развелось настолько много, что до сих пор есть такие, про которые я ничего не слышал :)
Вот 3 последних открытия:
edgedb.com - combines the simplicity of a NoSQL database with relational model’s powerful querying, strictness, consistency, and performance
materialize.com - Incrementally-updated materialized views - in ANSI Standard SQL and in real time.
github.com/dolthub/dolt - is a SQL database that you can fork, clone, branch, merge, push and pull just like a git repository
Вот 3 последних открытия:
edgedb.com - combines the simplicity of a NoSQL database with relational model’s powerful querying, strictness, consistency, and performance
materialize.com - Incrementally-updated materialized views - in ANSI Standard SQL and in real time.
github.com/dolthub/dolt - is a SQL database that you can fork, clone, branch, merge, push and pull just like a git repository
Помнится, еще был такой проект, который блокчейн поверх postgresql делал:
https://github.com/postgrespro/pg_credereum
Видеоблог с летсплеем баз что-ли запилить? :)
https://github.com/postgrespro/pg_credereum
Видеоблог с летсплеем баз что-ли запилить? :)
Как вы думаете, сколько времени уйдет на поиск этой проблемы в проде?
https://twitter.com/lukaseder/status/1336607250765508608
А использовал бы holistic.dev - таких проблем бы не было:
https://holistic.dev/playground/23136705-a747-44f8-8fe0-881c17edc222
> Alias "expiration_date" equal to the field name in relation "public.license" (alias-equal-to-field-name)
На самом деле до прода бы это, скорее всего, не дошло. Но лишние 30-60 минут бы съело, если бы заметили на этапе тестов. Или больше, если тестов нет :)
Именно поэтому правила про архитектуру мне нравиться писать больше, чем про производительность :)
https://twitter.com/lukaseder/status/1336607250765508608
А использовал бы holistic.dev - таких проблем бы не было:
https://holistic.dev/playground/23136705-a747-44f8-8fe0-881c17edc222
> Alias "expiration_date" equal to the field name in relation "public.license" (alias-equal-to-field-name)
На самом деле до прода бы это, скорее всего, не дошло. Но лишние 30-60 минут бы съело, если бы заметили на этапе тестов. Или больше, если тестов нет :)
Именно поэтому правила про архитектуру мне нравиться писать больше, чем про производительность :)
Twitter
Lukas Eder
OK, I was staring at this for way too long!! 😂
Sysadmin Tools 🇺🇦
И вот как бы в #aws завезли Babelfish SQL Server-compatible end-point for PostgreSQL https://aws.amazon.com/blogs/opensource/want-more-postgresql-you-just-might-like-babelfish/ #postgresql #mssql #sql #databse #amazon
Еще один rewrite engine для HiveQL, Presto, Apache Spark и Apache Pig.
На джаве, на чем же, блин, еще...
https://github.com/linkedin/coral
На джаве, на чем же, блин, еще...
https://github.com/linkedin/coral
GitHub
GitHub - linkedin/coral: Coral is a translation, analysis, and query rewrite engine for SQL and other relational languages.
Coral is a translation, analysis, and query rewrite engine for SQL and other relational languages. - linkedin/coral
Вернемся к тому странному IS NULL
Если вы с ходу не рассмотрели, подсказываю - разработчик забыл запятую между именами полей. По стандарту второй идентификатор считается алиасом.
Эти выражения
дадут идентичный результат.
В комментариях к твиту люди указывали, что они потратили от одной до пяти минут на поиск проблемы. Некоторые читатели моего канала потратили на много больше, даже зная, что проблема существует :)
Прекрасно (нет), если есть возможность потестить запрос на реальных данных. Но такое бывает довольно редко. И не со всеми запросами такое можно делать.
Если разработчик писал этот запрос в IDE и не проверил в реальной базе, то к осознанию того, что проблема существует, он придет далеко не сразу. Возможно, даже после отправки кода в прод.
Если у разработчика IDE от JetBrains, то ему повезло. DataGrip подсветит конкретно эту проблему. Если нет, то нет :)
А сейчас, комрадс, у меня к вам будет ряд важных вопросов. Буду благодарен, если вы мне поможете в кастдеве (customer development)
Первый:
хотели бы вы видеть интеграцию holistic.dev с основными IDE, чтобы можно было получать репорты, не отвлекаясь от разработки запросов?
Если вы с ходу не рассмотрели, подсказываю - разработчик забыл запятую между именами полей. По стандарту второй идентификатор считается алиасом.
Эти выражения
SELECT a AS b FROM t
SELECT a b FROM t
дадут идентичный результат.
В комментариях к твиту люди указывали, что они потратили от одной до пяти минут на поиск проблемы. Некоторые читатели моего канала потратили на много больше, даже зная, что проблема существует :)
Прекрасно (нет), если есть возможность потестить запрос на реальных данных. Но такое бывает довольно редко. И не со всеми запросами такое можно делать.
Если разработчик писал этот запрос в IDE и не проверил в реальной базе, то к осознанию того, что проблема существует, он придет далеко не сразу. Возможно, даже после отправки кода в прод.
Если у разработчика IDE от JetBrains, то ему повезло. DataGrip подсветит конкретно эту проблему. Если нет, то нет :)
А сейчас, комрадс, у меня к вам будет ряд важных вопросов. Буду благодарен, если вы мне поможете в кастдеве (customer development)
Первый:
хотели бы вы видеть интеграцию holistic.dev с основными IDE, чтобы можно было получать репорты, не отвлекаясь от разработки запросов?
Вопрос #2: В каких IDE вы пишите SQL-запросы?
Anonymous Poll
50%
что-то из JetBrains (в т.ч. DataGrip)
14%
VSCode
1%
Atom
20%
специальные под SQL - EMS, Dbeaver, ...
15%
другие
Тотальная слежка и контроль!
(но это не то, о чем вы подумали)
Пока киберпанк завезли только в виде игры, но это не останавливает человечество от попыток приблизить его в реальной жизни.
Кажется, люди начинают что-то подозревать и с завидной регулярностью появляются проекты, направленные на наведение порядка в том бардаке, который мы с вами устраиваем в своих проектах.
Вообще у меня давно сформировалось понимание к чему должны быть приложены максимальные усилия айтишников - на УМЕНЬШЕНИЕ ЭНТРОПИИ.
И в те дни, когда король разработки с хабра добрался до андерхуд паблика в твиттере и теперь и там ноет, что все пропало и что мы все умрем, подоспело несколько интересных новостей из области контроля за тем, что творят кожаные мешки на своих рабочих местах.
Про питон в AWS CodeGuru я недавно писал, но есть еще:
- Criticality Score от Google. Предлагается способ ранжирования проектов по степени пролюбленности полимеров, основываясь на мета-данных из репозитория
- ControlFlag от Intel. Машинлергинг ищет баги.
- Qodana от JetBrains. Статический анализ в CI с гуем.
Все что может быть автоматизированно, должно быть автоматизированно.
Никто не любит дебажить. Все любят творить.
Сейчас статическая типизация присутствует практически во всех мейстримовых языках программирования. Даже, простигосподи, в Ruby :)
Линтеры сделали для чего угодно - вплоть до markdown и ямлов докера.
Know Your Foe!
Вступай в отряды федерации борцов с багами!
(но это не то, о чем вы подумали)
Пока киберпанк завезли только в виде игры, но это не останавливает человечество от попыток приблизить его в реальной жизни.
Кажется, люди начинают что-то подозревать и с завидной регулярностью появляются проекты, направленные на наведение порядка в том бардаке, который мы с вами устраиваем в своих проектах.
Вообще у меня давно сформировалось понимание к чему должны быть приложены максимальные усилия айтишников - на УМЕНЬШЕНИЕ ЭНТРОПИИ.
И в те дни, когда король разработки с хабра добрался до андерхуд паблика в твиттере и теперь и там ноет, что все пропало и что мы все умрем, подоспело несколько интересных новостей из области контроля за тем, что творят кожаные мешки на своих рабочих местах.
Про питон в AWS CodeGuru я недавно писал, но есть еще:
- Criticality Score от Google. Предлагается способ ранжирования проектов по степени пролюбленности полимеров, основываясь на мета-данных из репозитория
- ControlFlag от Intel. Машинлергинг ищет баги.
- Qodana от JetBrains. Статический анализ в CI с гуем.
Все что может быть автоматизированно, должно быть автоматизированно.
Никто не любит дебажить. Все любят творить.
Сейчас статическая типизация присутствует практически во всех мейстримовых языках программирования. Даже, простигосподи, в Ruby :)
Линтеры сделали для чего угодно - вплоть до markdown и ямлов докера.
Know Your Foe!
Вступай в отряды федерации борцов с багами!
CEO jitbit написал пост про выбор no-code конструктора админок. И в частности про тот самый retool, который я пару раз уже упоминал.
И все в этом деле круто, кроме одного - давать доступ к базе внешним сервисам. Вынесут retool = вынесут всех клиентов.
Да, если пермишены были только на чтение, то только вынесут, удалить не смогут. А если есть пермишены на запись, то привет.
PS: retool теперь стоит под ярд, и это одновременно круто и непонятно.
И все в этом деле круто, кроме одного - давать доступ к базе внешним сервисам. Вынесут retool = вынесут всех клиентов.
Да, если пермишены были только на чтение, то только вынесут, удалить не смогут. А если есть пермишены на запись, то привет.
PS: retool теперь стоит под ярд, и это одновременно круто и непонятно.
Еще один экземпляр в коллекцию экзотических применений SQL (этот же список на гитхабе)
7) cloudquery - запросы по вашей облачной инфре
https://github.com/cloudquery/cloudquery
7) cloudquery - запросы по вашей облачной инфре
https://github.com/cloudquery/cloudquery
> SELECT * FROM aws_elbv2_load_balancers WHERE scheme = 'internet-facing'
Мы подошли к финалу разговора про ORM наоборот.
Новость #1 (хорошая)
Все, что нужно для создания кодогенераторов под любой язык и фреймворк, готово к использованию!
Мы зарелизили новый проект - parsers.dev - AST парсеры и компиляторы для различных SQL диалектов as a service.
Сейчас доступен следующий функционал:
- SQL -> AST парсинг для Postgresql и Snowflake
- SQL -> IR компиляция (на данный момент только для Postgresql)
SQL -> AST парсеры
AST (Abstract syntax tree) - объект, описывающее дерево, которое репрезентует исходный запрос в машиночитаемом виде.
Может пригодиться для создания:
- плагинов для IDE (подсветки синтаксиса, IntelliSense, LSP)
- линтеров (как sonarsource.com или некоторые правила holistic.dev)
- преттиеров и бьютифаеров (например, как у tensor.ru)
- трансформаторов запросов (например, кросс-db aws babelfish)
- сервисов графического отображения схем и запросов (например, для ETL процессов)
- инструментов создания и валидации миграций схем баз данных
- еще чего-нибудь крутого, о чем мы пока не догадываемся :)
SQL -> IR компиляция
IR (Intermediate representation) - объект, описывающий состояние схемы базы данных после применения всех DDL команд, или содержащий подробную информацию о DML-запросе с типами, нуллами, классом количества строк используемыми таблицами и вьюхами.
Может пригодиться для создания:
- генераторов кода!!! Можно генерировать части микросервисов или сделать аналоги dbcore, octo-cli и xgenecloud для генерации микросервисов целиком
- статических анализаторов (да, вы сможете писать правила, как в holistic.dev)
- инструментов для создания каталогов запросов
- инструментов для поиска логических проблем в запросах
- новых крутых ed-tech проектов
- любых инструментов из предыдущего раздела с более глубоким функционалом
Как пользоваться?
Все просто - регистрируетесь на parsers.dev, получаете API токен, идете в документацию или качаете postman-коллекцию.
Сколько стоит?
Пока бесплатно. Позже будет платно. И бесплатно тоже будет.
Новость #2 (тоже хорошая)
По понятным причинам мы не сможем сделать все эти крутые инструменты сами и нам нужна помощь. Ну т.е. как нам... Всем!
Что было бы круто реализовать:
- кодогенераторы под разные языки
- плагины для IDE. Судя по голосованию в топе JetBrains (на groovy) и vscode (на typenoscript)
- плагины для CI (github, gitlab и тд)
- SDK, cli и другие тулзы
Мы соберем это все в отдельный проект и будем его везде всячески форсить.
Возникает законное замечание - "Ты самый хитрый? Сейчас мы понаделаем интеграций, а ты потом включишь монетизацию и заработаешь мильен денег!"
МЫ ПРЕДЛАГАЕМ ПАРТНЕРСТВО.
После включения монетизации, авторам всех полностью бесплатных плагинов, через которые будут пользоваться платными подписками, будет выплачиваться вознаграждение.
Если у вас есть желание создать платные или бесплатные инструменты на базе нашего API, пишите в личку @antonrevyako, на почту info@parsers.dev или в чат канала.
Новость #1 (хорошая)
Все, что нужно для создания кодогенераторов под любой язык и фреймворк, готово к использованию!
Мы зарелизили новый проект - parsers.dev - AST парсеры и компиляторы для различных SQL диалектов as a service.
Сейчас доступен следующий функционал:
- SQL -> AST парсинг для Postgresql и Snowflake
- SQL -> IR компиляция (на данный момент только для Postgresql)
SQL -> AST парсеры
AST (Abstract syntax tree) - объект, описывающее дерево, которое репрезентует исходный запрос в машиночитаемом виде.
Может пригодиться для создания:
- плагинов для IDE (подсветки синтаксиса, IntelliSense, LSP)
- линтеров (как sonarsource.com или некоторые правила holistic.dev)
- преттиеров и бьютифаеров (например, как у tensor.ru)
- трансформаторов запросов (например, кросс-db aws babelfish)
- сервисов графического отображения схем и запросов (например, для ETL процессов)
- инструментов создания и валидации миграций схем баз данных
- еще чего-нибудь крутого, о чем мы пока не догадываемся :)
SQL -> IR компиляция
IR (Intermediate representation) - объект, описывающий состояние схемы базы данных после применения всех DDL команд, или содержащий подробную информацию о DML-запросе с типами, нуллами, классом количества строк используемыми таблицами и вьюхами.
Может пригодиться для создания:
- генераторов кода!!! Можно генерировать части микросервисов или сделать аналоги dbcore, octo-cli и xgenecloud для генерации микросервисов целиком
- статических анализаторов (да, вы сможете писать правила, как в holistic.dev)
- инструментов для создания каталогов запросов
- инструментов для поиска логических проблем в запросах
- новых крутых ed-tech проектов
- любых инструментов из предыдущего раздела с более глубоким функционалом
Как пользоваться?
Все просто - регистрируетесь на parsers.dev, получаете API токен, идете в документацию или качаете postman-коллекцию.
Сколько стоит?
Пока бесплатно. Позже будет платно. И бесплатно тоже будет.
Новость #2 (тоже хорошая)
По понятным причинам мы не сможем сделать все эти крутые инструменты сами и нам нужна помощь. Ну т.е. как нам... Всем!
Что было бы круто реализовать:
- кодогенераторы под разные языки
- плагины для IDE. Судя по голосованию в топе JetBrains (на groovy) и vscode (на typenoscript)
- плагины для CI (github, gitlab и тд)
- SDK, cli и другие тулзы
Мы соберем это все в отдельный проект и будем его везде всячески форсить.
Возникает законное замечание - "Ты самый хитрый? Сейчас мы понаделаем интеграций, а ты потом включишь монетизацию и заработаешь мильен денег!"
МЫ ПРЕДЛАГАЕМ ПАРТНЕРСТВО.
После включения монетизации, авторам всех полностью бесплатных плагинов, через которые будут пользоваться платными подписками, будет выплачиваться вознаграждение.
Если у вас есть желание создать платные или бесплатные инструменты на базе нашего API, пишите в личку @antonrevyako, на почту info@parsers.dev или в чат канала.
Forwarded from oleg_log (Oleg Kovalov)
Просто бизнес понял, что крупный бизнес™ не уйдет с реляционных, а продать им что-то надо /тред
https://twitter.com/copyconstruct/status/1342360717135998978
https://twitter.com/copyconstruct/status/1342360717135998978
В комментах под последним сообщением разгорелся небольшой срач, в котором меня явно приняли не за того.
Пользуясь случаем хочу прояснить несколько моментов:
1) on-premise bare metal, on-premise в облаке, managed database и serverless database это настолько разные с точки зрения эксплуатации вещи, что обсуждать что из них лучше без приземления в контекст не имеет никакого смысла. Даже любая опенсорсная база (mysql/postgresql), запущенная 4 разными способами будет иметь 4 разных набора свойств и тонких мест. А если еще начать сравнивать реализации у разных облачных провайдеров, можно совсем кукухой поехать :)
И тот, кто говорит, что можно легко развернуть базу на виртуалках и не переплачивать за RDS, скорее всего не делал этого для нагруженных проектов. Например, на AWS эта история довольно быстро упирается в лимиты iops и cpu credits.
2) Я не эксперт и не евангелист snowflake. (евангелист - Кент)
Мне категорически все равно будете ли вы использовать snowflake, redshift, bigquery или у вас много свободных сисадминов и вы сможете поднять кластер на clickhouse сами.
До весны 2020 я ничего не слышал про snowflake, но сейчас решил хайпануть и нажиться на кровавом ынтерпрайзе(и не только), который сплошь и рядом его использует.
Snowflake задуман интересно, реализован так себе, но невозможно отрицать то, что он дал волшебный пендель всей индустрии serverless db.
В нем встроены инструменты, которые для любой другой базы пришлось бы прибивать сбоку. Например, column-level security и etl.
Так же они попытались совместить в одной базе OLTP и OLAP, что тоже наложило свой отпечаток (микро-партишены, отсутствие вторичных индексов). А раздельное масштабирование compute и storage скорее всего станут key-feature многих новых баз.
И немного погрузившись в контекст, я понял почему ее выбирают крупные компании.
3) Clickhouse отличный продукт, мы использовали его в одном из проектов и после этого остались только положительные впечатления. Есть много тонкостей как в плоскости администрирования, так и в плоскости архитектуры, без знания которых использование принесет страдания.
Я очень надеюсь, что Althinity сделают из clickhouse удобную serverless платформу.
4) Утверждение, что в облаках сидят только стартапы, а серьезные ребята строят свои дц, пахнет нафталином :) Рассуждая об облаках, многие апеллируют к тому, что облака это дорого. Это справедливо, если считать железо "в лоб". Но правильный ответ зависит от разных вещей: cost management strategy - оптимизация capex или opex является приоритетом, стратегия масштабирования, найма и тд. Ведь железо надо покупать и обслуживать.
Подведу итог.
Существует много разных баз. Рассуждать кто кого заборет и воевать за какую-то одну не вижу никакого смысла. Мне хотелось бы делать инструменты для пользователей разных баз и зарабатывать на всех :)
Но т.к. ресурсы конечны, приходится держать нос по ветру, и бежать туда, где есть деньги.
Пользуясь случаем хочу прояснить несколько моментов:
1) on-premise bare metal, on-premise в облаке, managed database и serverless database это настолько разные с точки зрения эксплуатации вещи, что обсуждать что из них лучше без приземления в контекст не имеет никакого смысла. Даже любая опенсорсная база (mysql/postgresql), запущенная 4 разными способами будет иметь 4 разных набора свойств и тонких мест. А если еще начать сравнивать реализации у разных облачных провайдеров, можно совсем кукухой поехать :)
И тот, кто говорит, что можно легко развернуть базу на виртуалках и не переплачивать за RDS, скорее всего не делал этого для нагруженных проектов. Например, на AWS эта история довольно быстро упирается в лимиты iops и cpu credits.
2) Я не эксперт и не евангелист snowflake. (евангелист - Кент)
Мне категорически все равно будете ли вы использовать snowflake, redshift, bigquery или у вас много свободных сисадминов и вы сможете поднять кластер на clickhouse сами.
До весны 2020 я ничего не слышал про snowflake, но сейчас решил хайпануть и нажиться на кровавом ынтерпрайзе(и не только), который сплошь и рядом его использует.
Snowflake задуман интересно, реализован так себе, но невозможно отрицать то, что он дал волшебный пендель всей индустрии serverless db.
В нем встроены инструменты, которые для любой другой базы пришлось бы прибивать сбоку. Например, column-level security и etl.
Так же они попытались совместить в одной базе OLTP и OLAP, что тоже наложило свой отпечаток (микро-партишены, отсутствие вторичных индексов). А раздельное масштабирование compute и storage скорее всего станут key-feature многих новых баз.
И немного погрузившись в контекст, я понял почему ее выбирают крупные компании.
3) Clickhouse отличный продукт, мы использовали его в одном из проектов и после этого остались только положительные впечатления. Есть много тонкостей как в плоскости администрирования, так и в плоскости архитектуры, без знания которых использование принесет страдания.
Я очень надеюсь, что Althinity сделают из clickhouse удобную serverless платформу.
4) Утверждение, что в облаках сидят только стартапы, а серьезные ребята строят свои дц, пахнет нафталином :) Рассуждая об облаках, многие апеллируют к тому, что облака это дорого. Это справедливо, если считать железо "в лоб". Но правильный ответ зависит от разных вещей: cost management strategy - оптимизация capex или opex является приоритетом, стратегия масштабирования, найма и тд. Ведь железо надо покупать и обслуживать.
Подведу итог.
Существует много разных баз. Рассуждать кто кого заборет и воевать за какую-то одну не вижу никакого смысла. Мне хотелось бы делать инструменты для пользователей разных баз и зарабатывать на всех :)
Но т.к. ресурсы конечны, приходится держать нос по ветру, и бежать туда, где есть деньги.