Языку SQL уже много, очень много лет, но он продолжает быть чуть-ли не основным для аналитиков данных, инженеров и иных специалистов по работе с данными. Разве что дата сайентисты в некоторых задачах могут избежать счастья работать с SQL и используют Python/Java/R и др.

У SQL много достоинств и не меньше недостатков, главным из которых я бы назвал отсутствие удобных способов работы с не-плоскими данными, такими как JSON и тд. Время от времени появляются альтернативы, которые редко выходят за пределы конкретного продукта, но могут быть очень интересными.
Итак:
- SpyQL [1] гибрид SQL и Python, утилита командной строки позволяет выполнять SQL-похожие запросы с выражениями на Python внутри. Умеет работать с CSV, JSON и текстовыми файлами
- LINQ [2] объектный родной для .NET язык запросов придуманный Microsoft. Не используется за пределами экосистемы .NET
- SPARQL [3] язык запросов родом из Sematic Web. Сложен для непосвящённых, так и не получил массового распространения как и сами СУБД которые его поддерживает, но имеет немало, в первую очередь научных внедрений и использования.
- GraphQL [4] изначально язык API, но есть немало СУБД для которых он уже стал нативным. Малопопулярен в среде обработки данных, но популярен для веб-продуктов, стыковки бэкэнда и фронтэнда.
- Pony [5] специальный маппер выражений из своего синтаксиса в синтаксис SQL. Изначально написан для Python для работы с объектами для задач ORM.
- LookML [6] язык запросов сервиса по визуализации Looker, свой формат, свой синтаксис. Пока мало где используемый за пределами Looker'а
- Malloy [7] ещё один язык от Looker, относительно свежий
- Prql [8] язык запросов ориентированный на преобразование данных.

И многие другие. Защитники SQL возразят что современные SQL базы давно уже поддерживают JSON объекты и функции по работе с ними, а для гибкости пользовательские функции (UDF) можно реализовывать хоть на Python, хоть через .NET, хоть на других языках в зависимости от движка СУБД.

Появится ли у SQL стандарта достойная признанная замена? Пока непонятно, но можно экспериментировать.

Ссылки:
[1] https://github.com/dcmoura/spyql
[2] https://en.wikipedia.org/wiki/Language_Integrated_Query
[3] https://www.w3.org/TR/rdf-sparql-query/
[4] https://graphql.org/
[5] https://github.com/ponyorm/pony/
[6] https://docs.looker.com/data-modeling/learning-lookml/what-is-lookml
[7] https://github.com/looker-open-source/malloy
[8] https://github.com/max-sixty/prql

#sql #nosql #queries #datatools

Написал в рассылку о судьбе NoSQL в современном стеке данных [1]. Могу сказать что сейчас NoSQL и современные инструменты - это плохо сочетающиеся комбинации, как минимум в ряде задач. Это создает как проблемы, так и коммерческие возможности

Ссылки:
[1] https://begtin.substack.com/p/23

#datatools #mailing #nosql #mongodb

В рубрике инструментов работы с данными Mistql [1] [2] утилита и библиотека для JS и Python позволяющая делать сложные запросы к JSON подобным данным.

Например, mistql умеет отрабатывать подобные запросы "events | filter type == "send_message" | groupby email | keys". Синтаксис немного необычный, но вполне понятный, по мне так он гораздо понятнее и удобнее языков запросов вроде jq и, конечно, очень хотелось бы чтобы NoSQL базы данных умели бы такие запросы обрабатывать и, вообще, нехватает универсального языка запросов для NoSQL баз данных.
Например, их не хватает для MongoDB или ArangoDB.

А я думаю добавить поддержку mistql в мой инструмент undatum [3]. Потому что текущий язык фильтрации данных совершенно несовершенен, а тут хороший подход и много задач где такое нужно.

Ссылки:
[1] https://www.mistql.com/
[2] https://github.com/evinism/mistql
[3] https://github.com/datacoon/undatum

#data #datatools #querylanguage #nosql #json

Написал очередной текст на английском про будущее NoSQL в Modern Data Stack [1]. В этот раз не писал с нуля, а перевел свою февральскую статью [2] с русского на английский.

Заметка о том почему NoSQL продукты вроде MongoDB выпадают из современного стека данных и что с этим можно поделать.

Ссылки:
[1] https://medium.com/@ibegtin/future-of-nosql-in-modern-data-stack-f39303bc61e8
[2] https://begtin.substack.com/p/23

#data #datacatalogs #nosql #moderndatastack

В рубрике интересных стартапов в рынке данных компания Dgraph [1] создатели одноимённой графовой NoSQL системы управления базами данных с открытым кодом. Буквально только что они подняли раунд инвестиций на $6M [2] под их продукт Dgraph Cloud.

Фаундеры обещают обновить команду проекта, уже наняли нового CTO [3] и новый релиз этим летом.

В основе Dgraph собственной движок СУБД с родной поддержкой GraphQL и языком запросов DQL (Dgraph query language) на основе всё того же GraphQL и расширяющий его возможности.

В сравнениях они приводят другие NoSQL продукты, например, Neo4J и MongoDB [4], в свою пользу, конечно.

Я бы сказал так, GraphQL - это интересная концепция, язык запросов и альтернатива SQL, но "серебряной пулей" не является до сих пор.

Из достоинств Dgraph - это зрелость как продукта с открытым кодом и, на удивление, хорошо и подробно написанная документация.

Сама бизнес модель уже привычная. Берем зрелый продукт с открытым кодом и делаем облачный сервис. Причем они продают не собственное облако, а обслуживание dedicated servers на облаках других провайдеров.

Ссылки:
[1] https://dgraph.io
[2] https://dgraph.io/blog/post/funding-20220720/
[3] https://discuss.dgraph.io/t/new-funding-announcement/17377
[4] https://dgraph.io/comparison/

#opensource #clouds #nosql #dbms #data #datatools

Для тех кто пользуется MongoDB и постоянно ищет альтернативы, OxideDB [1] эмуляция MongoDB поверх PostgreSQL. Внутри движок которые запихивает объёкты документов в тип JSON для PostgreSQL и умеет конвертировать запросы MongօDB (язык MQL) в сложные SELECT.

Это не первая попытка проделать такое, эмулировать интерфейсы MongoDB в других СУБД и определенно эта попытка внимания заслуживает.

Зачем это нужно?
Две важнейшие причины:
1. Недооткрытый код MongoDB под SSPL лицензией. Для открытых сообществ - это как красная тряпка, для инфраструктурного бизнеса это ограничитель к облачному применению.
2. MongoDB далеко не оптимально по производительности, а тут возможность использовать наработки других СУБД.
3. Многим хочется иметь SQL и NoSQL сразу из коробки и давать удобные инструменты для каждой команды.

Ссылки:
[1] https://github.com/fcoury/oxide

#opensource #dbms #datatools #nosql #mongodb

Давно хочу написать про обработку документальных структурированных данных в NoSQL. Я затрагивал эту тему в англоязычной заметке Future of NoSQL in Modern Data Stack [1], но проблема, гораздо глубже, она связана со спецификой данных.

Классические наиболее распространенные подходы к обработке/очистке данных сейчас - это, или SQL запросы, или датафреймы вроде того же pandas, или инструменты вроде OpenRefine и Trifacta. Они все оперируют простыми плоскими таблицами и умеют по этим таблицам проводить относительно простые операции: переименовать колонку, разделить её, создать новую на основе имеющейся, изменить значение и тд.

В SQL это делается относительно просто, с учётом ограничений языка, конечно. В OpenRefine, Trifacta - это внутренние индексы для табличных данных и встроенные функции или внешний код. А для pandas и подхода через датафреймы - это код Python (или похожий в других языках).

Для данных с вложенными документами вроде тех что сериализуются в JSON или хранятся в MongoDB так не получится. При переносе из MongoDB в pandas вложенные объекты автоматически не нормализуются. А если их нормализовать, то потом назад в СУБД не перенести так просто. Будут потери, или в данных, или в возможности их обработки. И так со всем остальным, OpenRefine и аналоги также такой тип данных не поддерживают, только "уплощают" их в таблицы, но обратно могут отдать уже только плоскую таблицу.

Как работать с JSON подобными структурами? Например, используя языки запросов у NoSQL баз данных предварительно загрузив данные в саму СУБД.

А тут у нас начинают возникать уже ограничения другого рода. Ключевая NoSQL СУБД MongoDB не поддерживает большую часть операций по модификации данных иначе как запуском операций по перебору значений запроса итератором forEach. Самый банальный пример - это преобразование значений в полях в нижний или верхний регистр. То что в SQL решается простейшей командой UPDATE MyTable SET MyColumn = UPPER(MyColumn)
для MongoDB требует команды вроде
db.MyTable.find([find_criteria]).forEach(function(doc) {
db.MyTable.update(
{ _id: doc._id},
{ $set : { 'MyColumn' : doc.MyColumn.toUpperCase() } },
{ multi: true }
)
});

Похоже со многими другими операциями по преобразованию данных которые просты в табличных структурах, особенно в SQL и крайне затруднены в MongoDB. При том что MongoDB наиболее популярная NoSQL СУБД.

Можно ли такие операции проводить не в MongoDB, а, например, в другой NoSQL базе? Их поддерживает, например, ArangoDB. Там также есть циклы на выполнение операций, но они могут проводится внутри движка СУБД. Например, вот так.

FOR u IN MyTable
UPDATE u WITH {
MyColumn: UPPER(MyColumn)
} IN MyTable

Будет ли это быстрее чем если эту операцию делать извне? Непонятно, требует проверки.

Альтернативой использования СУБД является написание аналога pandas DataFrame для не-табличных документов. У Python есть библиотека glom [2] которая позволяет что-то подобное и может быть расширена, но имеет довольно серьёзные ограничения по объёмам данных и по скорости их обработки.

В итоге, если честно, я до сих пор не вижу оптимальный бэкэнд для data wrangling для NoSQL. Лучший кандидат как СУБД - это ArangoDB, но без интенсивного тестирования это неточно.
Наиболее эффективным способом обработки JSON/JSONlines всё ещё является программная обработка за пределами СУБД и инструментов ручного data wrangling вроде OpenRefine.


Ссылки:
[1] https://medium.com/@ibegtin/future-of-nosql-in-modern-data-stack-f39303bc61e8
[2] https://glom.readthedocs.io

#data #datatools #thoughts #nosql #dataengineering #datawrangling