Comments 22
при этом они ведут себя вполне «таблично»
А можно поподробнее?
Смысл в том, что при проходе древовидной структуры мы как бы генерируем таблицу. Первый столбец — где были на первом шаге, второй — где на втором. Чем правее столбец, тем больше в нем уникальных значений. «Маршрут» — это такой rowset provider, как OPENXML в MS SQL Server. Потом эти таблички можно подджойнивать к чему-нибудь или друг к другу.
Менее утрированное объяснение — разделы 3.3 и 5.3 спецификации.
Автору бы постесняться, языков программирования не в пример больше, чем языков запросов, и ничего.
Согласен, что «мусорных языков запросов» действительно много. Но ограничиться одним SQL не выйдет, коль скоро есть модели данных, отличные от реляционной. Прелесть PartiQL как раз в том, что это более-менее естественное расширение SQL. Одному из авторов SQL даже понравилось.
Половина статьи по ссылке про ORM, не про языки запросов. Я бы уклонился от обсуждения по существу, а развернул бы эту часть его рассуждений против другой, про языки запросов. Можно сказать, что разные language integrated queries как раз для тех, кому лень выучить даже язык запросов.
SQL/JSON Standard-2016, не ?
Нет. Там упор на функции по работе с JSON, а здесь работа с JSON интегрирована в язык. Вероятно, авторы подумали: язык-то декларативный когда-то был, может, хватит его функциями раздувать? За счёт этого иерархические данные стали сущностями.
И поэтому здесь, например, оказалось возможным поддержать лишь совсем базовый JSONPath, а там поддерживаемые возможности JSONPath раздуты чуть ли не до имеющихся в XPath.
сущностями
Имелось в виду «сущностями первого класса».
Там упор на функции по работе с JSON, а здесь работа с JSON интегрирована в язык
Если разработчики подписываются под то, что реализовали функционал из SQL/JSON (частичный или полностью), тогда получается, что работа с JSON интегрирована в язык.
И поэтому здесь, например, оказалось возможным поддержать лишь совсем базовый JSONPath, а там поддерживаемые возможности JSONPath раздуты чуть ли не до имеющихся в XPath
JSONPath в отличии от XPath не стандартизирован, поэтому каждый делает свою реализацию. Кстати какого функционала не хватает в реализации JSONPath по SQL/JSON?
Ну и в (спеке PartiQL) нет вообще информации по JSONPath
Просто пока выглядит как "очередной язык, который хочет казаться SQL, но работает несколько иначе, поэтому вы будете думать почему привычное вам, перестало работать". Как всегда рассудит время
Если разработчики подписываются под то, что реализовали функционал из SQL/JSON (частичный или полностью), тогда получается, что работа с JSON интегрирована в язык.
В первой части соответствующего change proposal создатели стандарты писали, что давайте делать все «using built-in functions». То есть существуют, значит, какие-то иные способы, и есть между этими способами некоторая разница.
На самом деле, конечно, сделали по образу и подобию поддержки XML, особо головой не подумав. Тогда подумать было некогда (или не захотели связываться), а сейчас лень.
Но больше тут вопрос языкового пуризма, конечно. Я вот пурист.
Ну и в (спеке PartiQL) нет вообще информации по JSONPath
У них это называется path navigation, которая бывает всего видов: tuple navigation и array navigation. И примечание: «notice that consecutive tuple/array navigations… navigate deeply into complex value».
Кстати какого функционала не хватает в реализации JSONPath по SQL/JSON?
Пройдусь по двум пунктам из своего поста («вот что делает иерархически организованные данные практически сущностями первого класса в PartiQL»), от второго к первому:
- я так и не понял, как в SQL/JSON получить список ключей, и лучше в привязке к значениям, а не просто значения.
- эти селекторы не «созависимы». Например, насколько понимаю, при
SELECT JSON_VALUE(T.J, '$.persons[*].name'), JSON_VALUE(T.J, '$.persons[*].surname'), мы получим декартово произведение множеств имен и фамилий. То есть утрачивается реляционность. Может, можно сделать что-то с помощьюJSON_TABLE, но уж больно все громоздко, я не разбирался.
поэтому вы будете думать почему привычное вам перестало работать
Обещают, что при представлении в абстрактной модели PartiQL чисто реляционных данных все запросы из SQL-92 останутся работоспособными. В конце концов, для разбирательств есть формальная семантика PartiQL. В других «очередных языках» с этим хуже.
В первой части соответствующего change proposal создатели стандарты писали, что давайте делать все «using built-in functions».
Как бы логично, типов много. Как бы отработал a.country если a имеет тип int или varchar или point
На самом деле, конечно, сделали по образу и подобию поддержки XML, особо головой не подумав. Тогда подумать было некогда (или не захотели связываться), а сейчас лень.
Как то токсичненько
У них это называется path navigation
Yet another standard
tuple navigation
Cоздатели же знают, что называют кортежами в других языках? Почему интересно не object navigation ?
я так и не понял, как в SQL/JSON получить список ключей, и лучше в привязке к значениям, а не просто значения.
$.keyvalue()
Правда зачем, это не понятно. Нужен бизнес смысл этого действия
эти селекторы не «созависимы». Например, насколько понимаю, при SELECT JSON_VALUE(T.J, '$.persons[].name'), JSON_VALUE(T.J, '$.persons[].surname'), мы получим декартово произведение множеств имен и фамилий.
Не правильно понимаете, в режиме lax получите NULL, в режиме strict получите ошибку.
Хотите массив получить, тогда JSON_QUERY, хотите отношение сгенерировать JSON_TABLE
запросы из SQL-92 останутся работоспособными.
Немного черного юмора: "А также добавят обратную совместимость с Windows 3.1 и дистрибутивами на ядре Linux 0.0.1"
Кстати интересно, как отработает по такому JSON:
{"a": 1, "a": 2, "a": 3, "b": null}Как бы отработалa.countryесли a имеет типintилиvarcharилиpoint
В PartiQL в свободном режиме (permissive mode) будет возвращено MISSING, в режиме проверки типов (type checking mode) запрос не выполнится. Можно «предохраняться»: CASE WHEN a IS TUPLE и т. д.
Как-то токсичненько
Ну да, ядовито. Но сами ведь пишут: а давайте сделаем как с XML.
Yet another standard
Точка и квадратные скобки, которые ведут себя практически как в Javascript, а вы там ниже предлагаете освоить JSON_TABLE, примеры использования которой ужасают даже в спецификации, где они по идее должны быть игрушечными :).
Cоздатели же знают, что называют кортежами в других языках? Почему интересно не object navigation?
Создатели знают, что называется кортежем в SQL, и пытаются это обыграть. Кортеж из реляционной модели представляется в абстрактной модели данных PartiQL плоским (со скалярными значениями полей) объектом.
$.keyvalue()
Правда зачем это, не понятно. Нужен бизнес-смысл этого действия
Спасибо, буду знать! Бизнес-смысл: допустим, есть внешний большой JSON и нужно по этим ключам сджойнить соответствующие значения из JSON с кортежами из таблицы, в которой в одном из полей лежит что-то похожее на эти ключи.
Неправильно понимаете, в режимеlaxполучитеNULL, в режимеstrictполучите ошибку.
Хотите массив получить, тогдаJSON_QUERY, хотите отношение сгенерировать —JSON_TABLE.
Насколько можно судить по таблицам в разделе 5.9.2 второй части, правильно. Но даже рад, если неправильно. Значит, настолько все сложно :-) В то время как в PartiQL одна простая концепция (вместо мощного языка путей и впиливаемых в декларативный язык функций): маршрут порождает отношение. Добавил там в статье обновление, объясняющее, каким образом.
Кстати интересно, как отработает по такому JSON:
{"a": 1, "a": 2, "a": 3, "b": null}
В PartiQL в щадящем режиме [a] вернет, вероятнее всего, 1 (оставляется на откуп реализации). В режиме проверки типов будет ошибка, см. стр. 13 спецификации. Но можно вытащить и все значения "a" с помощью UNPIVOT.
Я бы предложил разойтись вот на чем. В SQL/JSON доступ к внешним JSON-данным отнесен к числу «non-goals» (см. раздел 1.1.8 первой части), в то время как в PartiQL все наоборот.
Во-вторых, SQL/JSON рассчитан на работу исключительно с JSON, в то время как PartiQL — и с другими иерархическими форматами (Parquet, Amazon Ion). Всем этим, можно считать, и обусловлена разница в дизайне SQL/JSON и PartiQL.
Реального мира нет, он съеден софтом, а софт подъедается облаками. Но ОК, пусть приватные и гибридные облака тоже имеют кусок.
Для тех, кого не съели, в оригинальной записи в блоге предлагается архитектурная картинка. Я бы сказал, что тут примерно как с GraphQL. Стандартный путь — сделать resolver, который работает с имеющимся хранилищем. Но некоторые хранилища начинают и сами понимать GraphQL (тот же Stardog, упомянутый в статье).
Вот в Couchbase, например, уже поддержали SQL++, сейчас вроде раздумывают, реализовать ли PartiQL.
Но что дальше?
Цель этой статьи была в том, чтобы на примере AWS (в предположении, что там все делают правильно), ответить на следующие вопросы:
- Какие парадигмы интеграции данных нынче актуальны? С организационной точки зрения, так сказать. Ответ — NoETL, data fabric и пр.
- Как это реализуется технически? Ответ — виртуализация источников, универсализация языков.
- Что будет после этого (хоть и к этому еще не все пришли)? Ответ — похоже, мультимодельность.
Ну а системы, делающие все «правильно», есть и в «реальном мире».
Ну прямо сейчас можно поднять AWS EMR с Presto или тоже самое сделать с AWS EC2 или вообще поднять на своем железе и работать все это будет на SQL
Хорошо, амазоны заявляют, что один запрос может содержать гетерогенный запрос, т.е. к разным источникам данных. На их тестовых файлах я посмотрел, ну, да, загрузил файл с данными, сделал запрос, работает.
Но я вот торможу: как в PartiQL запросе распознать к каким источниками данных идут запросы, если это реально к разным серверам баз, например?
Как загрузить файли с данными понятно, но куда и как указывать серверы баз?
Прошу прощения за задержку с ответом. Нет, REPL CLI умеет только работать с данными в абстрактной модели PartiQL (которая тем самым становится не такой уж и абстрактной). Отображать в нее данные из внешних источников он не умеет.
Если очень хочется попробовать, в Redshift Spectrum поддержка PartiQL более полная, чем в S3 Collect. Нужно создавать внешние таблицы как описано здесь.
Еще, говорят, PartiQL поддерживается в Amazon QLDB, но тот в статусе превью.
Я, кстати, задал вопрос и в их форуме, ответов пока(?) нет:
community.partiql.org/t/how-to-recognize-different-data-sources-in-a-query/47
Там есть тоже логичный вопрос по стандарту SQL:
Why only being compatible to SQL:92 and not at least to SQL:2016?
community.partiql.org/t/why-only-being-compatible-to-sql-92-and-not-at-least-to-sql-2016/45/2
Спасибо за ссылку. Да, реализация отстает, особенно в публично доступных сервисах. Мне-то больше интересна концепция, но, видимо, не смог её коротко и вместе с тем ясно изложить. Вынес ответ на первый комментарий в текст самой статьи.
А про «тучи», если интересно… Вот попался на днях гартнеровский прогноз:
- By 2023, 75% of all databases will be on a cloud platform, reducing the DBMS vendor landscape and increasing complexity for data governance and integration.
- By 2022, 50% of cloud buying decisions will be based on data assets provided by the cloud service provider rather than on product capabilities.
Вообще, появление PartiQL можно рассматривать в рамках тренда SQL Interfaces to Cloud Object Stores, зафиксированного в гартнеровских Hype Cycle for Data Management 2017, 2018 и 2019 годов и потихоньку смещающегося там вправо.
IBM движется тем же путем. Из Introducing IBM Cloud SQL Query от 2 апреля 2018 года:
SQL Query supports using standard ANSI SQL to analyze CSV, Parquet, and JSON files stored in IBM Cloud Object Storage.
Добавлю, что полтора месяца назад упоминавшаяся в статье Couchbase получила инвестиции серии G в размере $105M. По объему средств этот инвестиционный раунд в топ-3 или топ-5 за всю историю индустрии СУБД. Couchbase пропагандирует концепцию NoETL, в русле которой создан и PartiQL. Более того, PartiQL создал тот же человек, что и SQL++, поддержанный недавно в Couchbase.
Amazon представил PartiQL: SQL-совместимый язык запросов к данным в различных форматах