MongoDB *

Будет ли MongoDB правильным выбором для вашего приложения?

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

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

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

В этой статье мы обсудим несколько возможностей MongoDB, которые стоит знать прежде чем вы решитесь выбрать и развернуть ее.

Как (и зачем?) написать голосовой дневник, используя open source инструменты.

Всем привет! Меня всё ещё зовут Антон. В предыдущей  статье я провел небольшой обзор APIM Gravitee и в целом систем типа API Management. В этой статье я расскажу, как поднять ознакомительный стенд APIM Gravitee (https://www.gravitee.io), рассмотрим архитектуру системы, содержимое docker compose file, добавим некоторые параметры, запустим APIM Gravitee и сделаем первую API. Статья немного погружает в технические аспекты и может быть полезна администраторам и инженерам, чтобы начать разбираться в системе.

В 1943 году психолог Абрахам Маслоу опубликовал свою знаменитую работу, в которой выделил пять категорий потребностей, мотивирующих человека: физиологические потребности, потребность в безопасности, потребность в принадлежности и любви, потребность в уважении и потребность в самоактуализации.

Сегодня эта теория известна под названием «Иерархия потребностей» и, как правило, изображается в виде пирамиды. Основная идея заключается в том, что человек начинает испытывать потребности более высокого уровня только после удовлетворения потребностей нижних уровней.

"Размышления без практики приводят к заблуждению, практика без размышления приводит к затруднению."

Мы ведём войну с индивидуальностью у шардов в кластере MongoDB. Это продолжение статьи Шардинг от которого невозможно отказаться, а это значит, что наступила пора конкретики.

Как я и обещал, здесь мы рассмотрим подробнее:

• настройку процесса выравнивания размера шардов
• расчет поправок для коррекции границ
• мониторинг распределения данных в коллекциях

Многие наши клиенты предоставляют своим командам разработчиков доступ к MongoDB как к сервису. Разработчики могут запросить экземпляр базы данных MongoDB и получить строку для подключения и учетные данные за считаные минуты. Переходя на использование MongoDB Atlas, наши клиенты заинтересованы и в том, чтобы дать своим разработчикам соответствующий уровень обслуживания.

В Atlas есть очень мощный уровень управления для предоставления кластеров. Однако в крупных организациях, где работают тысячи разработчиков, не всегда целесообразно предоставлять такому количеству людей прямой доступ к этому интерфейсу. Цель этой статьи — показать, как можно использовать API-интерфейсы Atlas для предоставления доступа к MongoDB как к сервису, когда MongoDB работает под управлением Atlas.

В частности, мы продемонстрируем способ создания интерфейса, предлагающего разработчикам набор вариантов для создания экземпляра базы данных MongoDB. Чтобы упростить себе задачу, рассмотрим, как предоставить разработчикам набор вариантов памяти и хранилища для настройки кластера. Прочие параметры, например выбор провайдера облачных услуг и региона, мы рассматривать не будем. Мы также расскажем о том, как добавлять метки к кластерам Atlas, так как эта функция не поддерживается в пользовательском интерфейсе Atlas. Для примера мы добавили метку для описания кластера.

Разработчики находятся в постоянном поиске новых способов быстрой модернизации приложений, чтобы оперативно подстраиваться под меняющиеся потребности клиентов. Один из таких способов — новые динамические схемы в MongoDB. Это мощный и гибкий инструмент, который позволяет хранить данные в JSON-документах вместо реляционных таблиц. В частности, разработчикам нравится гибкость и безсхемная природа JSON-документов.

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

Это Hackolade. Вот уже несколько десятилетий для визуального представления структуры данных реляционных БД используются ER-диаграммы. Изначально они предназначались только для плоских структур данных. Hackolade, сертифицированный технологический партнер MongoDB, предлагает расширенные ER-диаграммы, которые позволяют адаптировать представление иерархической структуры JSON с вложенными объектами и массивами. Hackolade — это первое решение для моделирования данных и проектирования схем для баз данных NoSQL и REST API.

А не пора ли нам шардить коллекции?
Не-е-е:

• у нас нет времени, мы пилим фичи!
• CPU занят всего на 80% на 64 ядерной виртуалке!
• данных всего 2Tb!
• наш ежедневный бекап идет как раз 24 часа!

В принципе, для большинства проектов вcё оправдано. Это может быть еще прототип или круг пользователей ограничен… Да и не факт, что проект вообще выстрелит.
Откладывать можно сколько угодно, но если проект не просто жив, а еще и растет, то до шардинга он доберется. Одна беда, обычно, бизнес логика не готова к таким "внезапным" вызовам.
А вы закладывали возможность шардинга при проектировании коллекций?

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

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

Онлайн-курс: "OTUS.NoSQL".

Проект: https://github.com/BorisPlus/mongodb_geo

MongoDB — одна из самых популярных NoSQL/документоориентированных баз данных в мире веб-разработки, поэтому многие наши клиенты используют её в своих продуктах, в том числе и в production. Значительная их часть функционирует в Kubernetes, так что хотелось бы поделиться накопленным опытом: какие варианты для запуска Mongo в K8s существуют? В чем их особенности? Как мы сами подошли к этому вопросу?

Ведь не секрет: несмотря на то, что Kubernetes предоставляет большое количество преимуществ в масштабировании и администрировании приложений, если делать это без должного планирования и внимательности, можно получить больше неприятностей, чем пользы. То же самое касается и MongoDB в Kubernetes.

Добрый день! Решил поделиться своими небольшими достижениями в использовании популярной библиотеки Passport.js. Задача была такой: использовать две локальные стратегии passport.js при том, что пользователи находятся в двух разных коллекциях Mongo Atlas.

Итак, дано: две коллекции пользователей в Mongo Atlas, и две локальные стратеги в Passport.js.

Задача, реализовать аутентификацию учителей по логину и паролю, учеников по Фамилии и номеру класса. Тут кстати в вопросе за одно и объясняется, почему мы используем две локальных стратегии, именно потому, что способы идентификации пользователя разные (учителя- логин/пароль, ученики - Фамилия/класс).

Всем привет. В этот раз я решил сделать нечто более интересное, чем очередной бот, поэтому далее я покажу как реализовать REST API с Deno, подключить и использовать MongoDB в качестве базы данных, и всё это запустить из под Linux.

Недавно я столкнулся с задачей визуализации данных от датчиков (температура, влажность, частицы PM2.5). Для решения подобных задач существует несколько бесплатных инструментов, например, Grafana + InfluxDB. Найденные мной решения показались слишком сложными и требовательными к ресурсам сервера, поэтому я решил "изобрести свой велосипед", а точнее создать шаблон для Shopker.

• заполнить MongoDB данными;
• написать несколько запросов на выборку и обновление данных
• создать индексы и сравнить производительность.

• Крайне важно разработать схему несмотря на то, что в MongoDB она необязательна.
• Аналогично, индексы должны соответствовать вашей схеме и шаблонами доступа.
• Избегайте использования больших объектов и больших массивов.
• Будьте осторожны с настройками MongoDB, особенно если речь идет о безопасности и надежности.
• В MongoDB нет оптимизатора запросов, поэтому вы должны быть осторожны при выполнении операций запроса.

• как мы от open source-решений пришли к Database as a Service;
• какие существуют подходы к развертыванию баз данных в облаке;
• как Kubernetes может заменить DBaaS, устранив зависимость от вендора и сохранив простоту СУБД как сервиса.

“Иногда мы платим больше всего за то, что получаем бесплатно.” — А.Эйнштейн

• Что будет с перформансом?
• На сколько операции замедлятся?
• Готовы ли мы пожертвовать скоростью ради (хоть какой-то) точности?

• Все ли операции будут замедлены за счет транзакций?
• На сколько замедлятся комбинации операций?

Моему почтовому ящику на gmail много лет. Более десяти лет самостоятельного существования, а также в нем лежат архивы из других почтовых систем. Все эти годы я использовал его так как и нужно использовать умные продукты:

• Не сортировал письма, так как для этого есть хороший поиск
• Не удалял письма с большими вложениями, так как для этого есть куча пространства
• Не категоризировал письма и позволял сервису обучаться на моих привычках, для автоматических эвристик

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

Задача навести порядок не была самоцелью, скорее меня начало раздражать что весь inbox завален каким-то мусором: заказы из магазинов, рекламные письма, обновления от почты, все это вперемешку с периодическими дайджестами и личной перепиской.

^^ Это не настоящий скрин моей почты. Просто картинка для превью.