Написал в рассылку о судьбе NoSQL в современном стеке данных [1]. Могу сказать что сейчас NoSQL и современные инструменты - это плохо сочетающиеся комбинации, как минимум в ряде задач. Это создает как проблемы, так и коммерческие возможности
Ссылки:
[1] https://begtin.substack.com/p/23
#datatools #mailing #nosql #mongodb
Ссылки:
[1] https://begtin.substack.com/p/23
#datatools #mailing #nosql #mongodb
Ivan’s Begtin Newsletter on digital, open and preserved government
#23. Судьба NoSQL в современном стеке данных
Во всём что касается современного стека технологий по работе с данными особенна интересна судьба NoSQL продуктов вроде MongoDB, ElasticSearch, Redis, Neo4J и других. Проблема в том что большая часть инструментов в Modern data stack ориентированы на наличие…
Вышла версия 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.
Для тех кто пользуется 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
Это не первая попытка проделать такое, эмулировать интерфейсы MongoDB в других СУБД и определенно эта попытка внимания заслуживает.
Зачем это нужно?
Две важнейшие причины:
1. Недооткрытый код MongoDB под SSPL лицензией. Для открытых сообществ - это как красная тряпка, для инфраструктурного бизнеса это ограничитель к облачному применению.
2. MongoDB далеко не оптимально по производительности, а тут возможность использовать наработки других СУБД.
3. Многим хочется иметь SQL и NoSQL сразу из коробки и давать удобные инструменты для каждой команды.
Ссылки:
[1] https://github.com/fcoury/oxide
#opensource #dbms #datatools #nosql #mongodb
Я тут несколько раз писал о том что нет удобных инструментов для обработки для обработки NoSQL данных. Нет аналога OpenRefine или возможности удобной манипуляции данными внутри NoSQL баз данных. Писал на русском [1] и на английском языках [2].
Но рассуждать вслух хорошо, а экспериментировать лучше. Поэтому на выходных я сделал вот такой простой инструмент mongorefine [3] воспроизводящий часть функций OpenRefine используя MongoDB как бэкенд. Штука эта экспериментальная, измерения по скорости с другими подходами могут быть не в её пользу, особенно в части плоских данных. Но для не-плоских данных, она полезна даже в таком виде.
Основная фича в том чтобы сделать оболочку поверх коллекций MongoDB позволяющую работать с записями как с колоночной базой данных. Свободно удалять отдельные колонки, создавать колонки на основе
Лично я пока не обладаю уверенностью что путь создания системы автоматизации обработки данных поверх MongoDB - это оптимальный путь.
Но если Вы готовы поэкспериментировать и дать обратную связь, то такой инструмент теперь доступен.
P.S. Никогда не делайте экспериментов на рабочих базах данных. Сделайте тестовую копию и тренируйтесь на ней;)
Ссылки:
[1] https://yangx.top/begtin/4255
[2] https://medium.com/@ibegtin/nosql-data-wrangling-50b5a2898a83
[3] https://github.com/ivbeg/mongorefine
#data #opensource #mongodb #dataengineering #datawrangling
Но рассуждать вслух хорошо, а экспериментировать лучше. Поэтому на выходных я сделал вот такой простой инструмент mongorefine [3] воспроизводящий часть функций OpenRefine используя MongoDB как бэкенд. Штука эта экспериментальная, измерения по скорости с другими подходами могут быть не в её пользу, особенно в части плоских данных. Но для не-плоских данных, она полезна даже в таком виде.
Основная фича в том чтобы сделать оболочку поверх коллекций MongoDB позволяющую работать с записями как с колоночной базой данных. Свободно удалять отдельные колонки, создавать колонки на основе
Лично я пока не обладаю уверенностью что путь создания системы автоматизации обработки данных поверх MongoDB - это оптимальный путь.
Но если Вы готовы поэкспериментировать и дать обратную связь, то такой инструмент теперь доступен.
P.S. Никогда не делайте экспериментов на рабочих базах данных. Сделайте тестовую копию и тренируйтесь на ней;)
Ссылки:
[1] https://yangx.top/begtin/4255
[2] https://medium.com/@ibegtin/nosql-data-wrangling-50b5a2898a83
[3] https://github.com/ivbeg/mongorefine
#data #opensource #mongodb #dataengineering #datawrangling
MongoDB взломали [1] и, похоже, скомпрометировали как минимум часть паролей клиентов, но пока нет подтверждений что хакеры получили доступ к данным клиентов в MongoDB Atlas. В любом случае, для SaaS сервиса обеспечивающего хранение данных этот инцидент крайне неприятный, плохо отразится на бизнесе.
Ссылки:
[1] https://www.mongodb.com/alerts
#data #saas #mongodb #security
Ссылки:
[1] https://www.mongodb.com/alerts
#data #saas #mongodb #security
JSONBench [1] свежий бенчмарк для аналитических баз данных работающих с JSON от команды ClickHouse. Ожидаемо в бенчмарке ClickHouse на первых местах ;), но надо отдать им должное, в блоге у них подробный методологический рассказ про это [2] и конкуренты могут прийти и возразить обоснованно, если, конечно, придут.
Сам бенчмарк основан на датасете размером в 482GB в несжатом виде событий из соцсети BlueSky. В сжатом с помощью zstd виде они занимают 124GB, а в ClickHouse 99GB и 622GB в PostgreSQL.
Споры тут могут быть, в основном, исходя из моделей использования и подходов. К примеру, у DuckDB есть тип данных JSON, но в целом с его помощью можно работать с JSON файлами как с таблицами и импортировать их не в JSON тип, а сразу развертывать в табличную форму.
Что я лично и сделал бы с этими данными BlueSky вначале преобразовав из в Parquet.
С другой стороны способность ClickHouse работать с JSON объектами явно растёт и с той точки измерений что они проводили - это хороший тест.
Ссылки:
[1] https://jsonbench.com/
[2] https://clickhouse.com/blog/json-bench-clickhouse-vs-mongodb-elasticsearch-duckdb-postgresql
#clickhouse #postgresql #mongodb #duckdb #benchmark #json #rdbms
Сам бенчмарк основан на датасете размером в 482GB в несжатом виде событий из соцсети BlueSky. В сжатом с помощью zstd виде они занимают 124GB, а в ClickHouse 99GB и 622GB в PostgreSQL.
Споры тут могут быть, в основном, исходя из моделей использования и подходов. К примеру, у DuckDB есть тип данных JSON, но в целом с его помощью можно работать с JSON файлами как с таблицами и импортировать их не в JSON тип, а сразу развертывать в табличную форму.
Что я лично и сделал бы с этими данными BlueSky вначале преобразовав из в Parquet.
С другой стороны способность ClickHouse работать с JSON объектами явно растёт и с той точки измерений что они проводили - это хороший тест.
Ссылки:
[1] https://jsonbench.com/
[2] https://clickhouse.com/blog/json-bench-clickhouse-vs-mongodb-elasticsearch-duckdb-postgresql
#clickhouse #postgresql #mongodb #duckdb #benchmark #json #rdbms