Вышла версия 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
В новой версии анонсируют:
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
MongoDB
7 Big Reasons to Upgrade to MongoDB 6.0 | MongoDB Blog
First announced at MongoDB World 2022, MongoDB 6.0 is now generally available and ready for download now. Learn more.
В рубрике интересных продуктов для работы с данными 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
Облачная версия у них ещё в разработке, а открытый код уже общедоступен, можно установить и тестировать на собственных задачах.
Внутри язык запросов похожий на 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
SurrealDB
SurrealDB | The ultimate multi-model database for tomorrow's applications
SurrealDB is the ultimate database for tomorrow's serverless, jamstack, single-page, and traditional applications.
Онтология типов данных
Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология 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
Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология 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
Docs
Common Data Model - Common Data Model
Common Data Model is a standardized, modular, and extensible collection of data schemas that Microsoft published to help you build, use, and analyze data.
В рубрике интересного чтения про данные, технологии и не только:
- 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
- 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
Gradient Flow
The Vector Database Index - Gradient Flow
Measuring the popularity of different Vector Databases. By Ben Lorica and Leo Meyerovich. Introduction Vector databases and vector search are on the radar of a growing number of technical teams. A key driver is that advances in neural networks have made dense…
Через месяц, 29 июня, закрывается проект bit.io [1] в связи с тем что их команду купил DataBricks. Для тех кто не помнит, bit.io - это был сервис облачного хостинга PostgreSQL с возможностью ручной загрузки данных, API, дистанционного подключения к СУБД, наличия большого числа опубликованных баз данных.
DataBricks такой сервис не нужен, а нужна только команда. Поэтому сервис закрывают.
Ссылки:
[1] https://bit.io
#startups #data #rdbms #databases #dataengineering
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
Сам продукт 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
Dolthub
Is MySQL Dying?
A comparison of the vibrancy of the MySQL and Postgres ecosystems.
Пока я рассуждал о том что новые инструменты 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
Автор/докладчик там сравнивает 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