Ivan Begtin
7.99K subscribers
1.88K photos
3 videos
101 files
4.58K links
I write about Open Data, Data Engineering, Government, Privacy, Digital Preservation and other gov related and tech stuff.

Founder of Dateno https://dateno.io

Telegram @ibegtin
Facebook - https://facebook.com/ibegtin
Secure contacts [email protected]
Download Telegram
Вышла версия 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] https://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.iss.one/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] https://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] https://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
Полезная статья Is MySQL Dying? [1] для понимания того как развиваются современные СУБД, от Tim Sehn, создателя облачной СУБД Dolt, совместимой с MySQL.

Сам продукт Dolt интересный, это одна из немногих версионируемых СУБД, её, например, активно используют в игровой индустрии. Но тут интереснее прочитать про судьбу экосистемы MySQL.

Можно узнать, например, что AWS гораздо эффективнее монетизирует MySQL совместимую облачную СУБД чем Oracle, де факто владелец MariaDB PLC, компании создающей оригинальную версию MySQL/MariaDB. При этом интерес к MySQL с годами снижается, а к PostgreSQL, наоборот, растёт. Автор связывает это, в том числе, с тем что в PostgreSQL значительно раньше появилась поддержка векторов и, соответственно, применение СУБД для LLM значительно продвинулось, а в MySQL поддержка векторов появилась совсем недавно.

Ссылки:
[1] https://www.dolthub.com/blog/2024-10-14-is-mysql-dying/

#opensource #rdbms #mysql #postgresql
Пока я рассуждал о том что новые инструменты data wrangling'а (манипуляция и трансформация данных) появятся уже на базе движков вроде DuckDB или Clickhouse, они начали появляться. Свежее видео выступления Hannes Mühleisen - Data Wrangling [for Python or R] Like a Boss With DuckDB [1] ровно про это и слайды к нему же [2].

Автор/докладчик там сравнивает DuckDB в загрузке файлов и упоминает duckplyr [3] очень производительный заменитель популярной библиотеки Dplyr [4] для языка R.

Всю презентацию можно свести к утверждению что DuckDB - это круто для манипуляции данными и я склонен с этим согласиться.

Я бы ещё добавил что хорошо и правильно сравнивать и с интерактивными инструментами вроде OpenRefine, Talend, Trifacta и ещё рядом других. Собственно только отсутствие UI поверх движка DuckDB или Clickhouse ограничивает их популярность.

Если бы, к примеру, OpenRefine авторы переделали на движок DuckDB то цены бы ему не было и возможность работать с большими данными стала бы естественной. Но OpenRefine так просто не переделать, так что больше надежды что это создаст кто-то другой.

Я какое-то время назад проектировал такой движок и могу сказать что это не так сложно. Если бы не прорыв в индексации каталогов данных превратившийся в Dateno, я может быть такой data wrangling инструмент бы даже попробовал сделать, но сейчас просто мало времени на такое, тоже интересное занятие.

P.S. Кстати, для Python есть аналог dplyr под названием dplython [5], но попроще.

Ссылки:
[1] https://www.youtube.com/watch?v=GELhdezYmP0&list=PL9HYL-VRX0oSFkdF4fJeY63eGDvgofcbn&index=66
[2] https://blobs.duckdb.org/posit-conf-2024-keynote-hannes-muehleisen-data-wrangling-duckdb.pdf
[3] https://github.com/tidyverse/duckplyr?tab=readme-ov-file
[4] https://dplyr.tidyverse.org/
[5] https://github.com/dodger487/dplython

#opensource #data #datatools #rdbms #duckdb #dataengineering
Полезные ссылки про данные, технологии и не только:
- The DuckDB Avro Extension [1] новое расширение для DuckDB для поддержки формата файлов Apache Avro. Не то чтобы Avro часто встречается в дикой природе, но во многих корпоративных стеках данных он есть и хорошо что к нему есть расширение. Заодно полезное чтение про внутреннее устройство и специфику этого формата.
- Prototype Fund: a successful story of project replication within the Open Knowledge Network [2] в блоке Open Knowledge Foundation видео с рассказом про Prototype Fund в Германии и Швейцарии. Это специальный фонд для поддержки проектов с открытым кодом, про открытые данные и вообще про технологические аспекты открытости (например, стандарты) в контексте цифровой общей инфраструктуры. Иначе говоря поддержка открытых проектов создаваемых для общественного блага. Жаль этот опыт трудновоспроизводим.
- The History of the Decline and Fall of In-Memory Database Systems [3] приятный текст про "взлет и падение" баз данных работавших только в памяти и о том почему почти все СУБД вернулись к модели постоянного хранения. Спойлер: потому что цены гигабайт на SSD падают быстрее чем цены за гигабайт RAM
- Researchers achieve 96% accuracy in detecting phishing emails with open-source AI [4] вот полезное применение LLM, ловить фишинговые письма. Правда, сдаётся мне что есть способы и попроще, но и этот весьма неплох. Причём 95% точности достигается довольно легковесной моделью, а 96% уже с существенно большими требованиями
- An Open Source Python Library for Anonymizing Sensitive Data [5] статья об анонимизации данных и открытой библиотеке авторов о том как ей пользоваться.

Ссылки:
[1] https://duckdb.org/2024/12/09/duckdb-avro-extension
[2] https://blog.okfn.org/2024/12/05/prototype-fund-a-successful-story-of-project-replication-within-the-open-knowledge-network/
[3] https://cedardb.com/blog/in_memory_dbms/
[4] https://the-decoder.com/researchers-achieve-96-accuracy-in-detecting-phishing-emails-with-open-source-ai/
[5] https://www.nature.com/articles/s41597-024-04019-z

#opensource #ai #rdbms #readings