Ivan Begtin
8.07K subscribers
1.5K photos
3 videos
100 files
4.25K links
I write about Open Data, Data Engineering, Government, Privacy and Data Preservation and other gov and tech stuff
Telegram @ibegtin
Facebook - https://facebook.com/ibegtin
Secure contacts ivan@begtin.tech

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

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

#datatools #mailing #nosql #mongodb
Вышла версия 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
Для тех кто пользуется 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 данных. Нет аналога OpenRefine или возможности удобной манипуляции данными внутри NoSQL баз данных. Писал на русском [1] и на английском языках [2].

Но рассуждать вслух хорошо, а экспериментировать лучше. Поэтому на выходных я сделал вот такой простой инструмент mongorefine [3] воспроизводящий часть функций OpenRefine используя MongoDB как бэкенд. Штука эта экспериментальная, измерения по скорости с другими подходами могут быть не в её пользу, особенно в части плоских данных. Но для не-плоских данных, она полезна даже в таком виде.

Основная фича в том чтобы сделать оболочку поверх коллекций MongoDB позволяющую работать с записями как с колоночной базой данных. Свободно удалять отдельные колонки, создавать колонки на основе

Лично я пока не обладаю уверенностью что путь создания системы автоматизации обработки данных поверх MongoDB - это оптимальный путь.

Но если Вы готовы поэкспериментировать и дать обратную связь, то такой инструмент теперь доступен.

P.S. Никогда не делайте экспериментов на рабочих базах данных. Сделайте тестовую копию и тренируйтесь на ней;)

Ссылки:
[1] https://t.me/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