Вышла версия 6.0 MongoDB, самой популярной документо-ориентированной NoSQL СУБД в мире. Если Вы никогда о ней не слышали и не читали, но работаете с JSON документами, то самое время узнать что это такое и как работает.

В новой версии анонсируют:
1. Улучшение работы с временными рядами
2. Улучшение работы с потоками изменений и возможности подписки на них
3. Улучшенная обработка сложных запросов
4. Больше операторов в языке запросов
5. Улучшенная синхронизация и новые операторы для этих задач
6. Улучшенная безопасность (запросы к зашифрованным данным)
7. Улучшения в поиске в виде фасетного поиска

Если посмотреть на всё это вместе, то кажется всё, в общем-то, очень даже неплохо. Продукт развивается, у него реально очень мало альтернатив, наиболее близкий по функциям продукт ArangoDB, но мигрировать на него требует переписать все запросы, поэтому основная конкуренция идет между MongoDB Cloud и MongoDB-совместимыми облачными базами данных.

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

Дело в том что для многих задач без высокой нагрузки, с иерархическими данными, созданием API с отдачей JSON и тд. у MongoDB очень много уникальных возможностей. Многое готово из коробки, язык запросов прост, привычен, удобства очень велики.

Но, как только дело доходит до высокой производительности то часто оказывается что использовать MongoDB как расширенное key-value хранилище - это норм, а много сложных запросов на больших данных оно не тянет. По многим причинам, рассказывать о них можно много и отдельно, но в целом high-load - это не про MongoDB.

Другая проблема MongoDB в неэффективном хранении данных, по сравнению с колоночными базами данных, к примеру. Это особенность архитектуры, у данных нет схем, нет возможности сжатия их по колонкам, что сжатие улучшает.

Но самая главная проблема в том что MongoDB нет в Modern data stack! Понятно что MDS - это концепция, а не четкий стек инструментов, но MongoDB попадает туда только как унаследованное хранилище данных.

Ключевые продукты популярные в MDS основаны на SQL и плоских структурах данных с чёткими спецификациями. Инструменты вроде dbt не поддерживают MongoDB, не поддерживают его и большая часть ETL инструментов и так далее.

Фактически MongoDB и другие документо-ориентированные NoSQL СУБД - это продукты в себе. Чтобы реализовать для них полноценный инструмент по контролю качества данных или их преобразованию придётся делать его узкозаточенным и, как следствие, плохо переносимым на другие продукты.

И эти проблемы, увы, не решаются релизом 6.0, но, в остальном, конечно, это полезный продукт пригодный для многих задач когда данных много, они иерархичны (JSON) и проектировать таблицы не хочется.

Ссылки:
[1] https://www.mongodb.com/blog/post/big-reasons-upgrade-mongodb-6-0

#mongodb #data #datatools #rdbms

В рубрике интересных продуктов для работы с данными SurrealDb [1] свежая документоориентированная СУБД категории NewSQL позиционируемая создателями как облачная без-серверная СУБД.

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

Внутри язык запросов похожий на SQL, но не SQL, называется https://SurrealQL [2] не поддерживающий JOIN'ы по изначальному его дизайну.

Причём код стал открытым только летом прошлого года [3], а на сентябрь обещают версию 1.0, однако сейчас он стремительно набирает популярность, порядка 1500+ лайков за август 2022 года и далее популярность нарастает.

Среди клиентских библиотек основная NodeJS, по позиционированию СУБД скорее под Jamstack чем под MDS (Modern Data Stack), так что для тех кто программирует на JS она может быть полезной находкой.

Ссылки:
[1] https://surrealdb.com
[2] https://surrealdb.com/docs/surrealql
[3] https://surrealdb.com/roadmap

#opensource #rdbms #datatools

Онтология типов данных

Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология OntoDT [1] ещё 2016 года, но сайт с ним уже недоступен, и сама онтология кое-где ещё доступна как RDF/OWL [2]. Основной автор Panče Panov явно переключился на более прикладные исследования [3]

В качестве других примеров։
- онтология EDAM [4] в биоинформатике, с акцентом на особенности анализа и майнинга данных в этой области
- CDM (Common Data Model) [5] не-формальная онтологии от Microsoft привязанная с акцентом на продажах, пользователях, маркетинге и тд.
- онтология типов данных при ответах на вопросы по геоаналитике [6] прошлогоднее исследование с акцентом на геоданные.

Есть, также, какое-то количество других научных и не только научных публикаций на эту тему, но в целом их довольно мало. Они чаще всего происходят в контексте задач по анализу данных и его автоматизации. Самое развитое идёт в сторону автоматизации создания и аннотирование моделей для ИИ. Проект D3M (Data-Driven Discovery of Models) [7] от DARPA в США. Я не так давно писал о нём и порождённых им стартапах. [8]

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

Ещё какое-то время назад в СУБД на родном уровне поддерживались только самые базовые типы данных։ INT, FLOAT, STRING/VARCHAR, BLOB и тд. с небольшими вариациями. Сейчас, современные СУБД, поддерживают многочисленные дополнительные типы данных, перешедших из смысловых (семантических) в базовые типы. Пример: ip-адреса и mac-адреса уже достаточно давно имеющиеся в некоторых СУБД [9] и недавно добавляемые в другие [10].

Ранее всего это произошло с датами и временем в разных вариациях, с геоданными для которых есть сейчас много отдельных функций и индексов внутри СУБД. Также происходит с сетевыми наиболее популярными данными.

Мои ощущения что на этом процесс не остановится. Например, меня удивляет что всё ещё нет СУБД общего типа с отдельными типами данных под хэши (SHA1, SHA256 и др.).

Многие составные идентификаторы и коды классификаторов сейчас в СУБД хранятся как строки, при том что часто они нужны в декомпозированной форме и, в итоге, создаётся избыточность разбирая этот код на части. Пример в России: Вы можете хранить код КЛАДР как есть, а можете разделить его на подэлементы и осуществлять поиск по ним когда это необходимо.

Не знаю появится ли когда-либо движок для СУБД дающий возможность значительно большей гибкости в хранении и индексировании данных иди же, на самом деле, это далеко от насущных необходимостей, но важно то что к у каждого смыслового типа данных есть важная связка с практиками обработки данных и эволюция СУБД в этом направлении явно происходит.

Ссылки:
[1] https://fairsharing.org/FAIRsharing.ydnwd9
[2] https://kt.ijs.si/panovp/OntoDM/archive/OntoDT.owl
[3] https://orcid.org/0000-0002-7685-9140
[4] http://edamontology.org/page
[5] https://docs.microsoft.com/en-us/common-data-model/
[6] https://digitalcommons.library.umaine.edu/josis/vol2020/iss20/2/
[7] https://datadrivendiscovery.org
[8] https://t.me/begtin/3926
[9] https://www.postgresql.org/docs/current/datatype-net-types.html
[10] https://mariadb.com/kb/en/inet4/

#data #rdbms #research #metadata #semanticdatatypes

В рубрике интересного чтения про данные, технологии и не только:
- The Vector Database Index [1] сравнение нескольких векторных баз данных. Полезно для понимания как устроен этот рынок и того между чем можно и стоит выбирать. Не все продукты рассмотрены, но достаточно многие. Для тех кто не знает или подзабыл - векторные базы данных используются для построения нейросетей и, например, для поиска по подобиям, поиска аномалий и пользовательских рекомендаций и скоринга. Этот рынок растёт и в нём довольно много инвестиций уже есть и приходит.
- What I've learned from users [2] свежий текст Пола Грэхема о том чему научился от основателей стартапов профинансированных Y Combinator. Как и все тексты автора - почитать его стоит. Пишет он редко и всегда по делу.
- Modern COBOL Tooling [3] для тех кто хочет погрузится в вечность или даже не знаю как это описать, но набор инструментов в современных средах разработки и курсов по COBOL.
- Instant MD5 Collisions [4] всё ещё используете хэш функции MD5? А их уже подменяют моментально, на примере пары картинок и большой текст.
- Faster CPython ideas [5] репозиторий идей по ускорению языка Python реализованного на С. Python никогда не отличался высокой скоростью, но был и есть гибок. Интересно то как думают о его ускорении.
- SQLite: Past, Present, and Future [6] об устройстве и судьбе СУБД Sqlite. Важно потому что не стоит недооценивать масштабов её использования особенно в мобильных устройствах и IoT.
- Document Foundation starts charging €8.99 for 'free' LibreOffice [7] этот момент настал и LibreOffice в магазине для Mac'ов продается за 8.99 евро. Обещается что сумма пойдет на разработку ПО. Напомню что LibreOffice - это ответвление (форк) OpenOffice.

Ссылки:
[1] https://gradientflow.com/the-vector-database-index/
[2] http://paulgraham.com/users.html
[3] https://www.openmainframeproject.org/all-projects/cobolprogrammingcourse
[4] https://github.com/corkami/collisions
[5] https://github.com/faster-cpython/ideas
[6] http://muratbuffalo.blogspot.com/2022/09/sqlite-past-present-and-future.html
[7] https://www.theregister.com/2022/09/20/libre_office_macos_fees/

#opensource #readings #rdbms #data

Через месяц, 29 июня, закрывается проект bit.io [1] в связи с тем что их команду купил DataBricks. Для тех кто не помнит, bit.io - это был сервис облачного хостинга PostgreSQL с возможностью ручной загрузки данных, API, дистанционного подключения к СУБД, наличия большого числа опубликованных баз данных.

DataBricks такой сервис не нужен, а нужна только команда. Поэтому сервис закрывают.

Ссылки:
[1] https://bit.io

#startups #data #rdbms #databases #dataengineering