MongoDB *

Привет, меня зовут Мария Карпенко, я разработчик в команде Yandex Tracker — сервиса для управления процессами и проектами. Внутри Яндекса сервис  используется для постановки задач практически во всех командах, так что общее количество событий по задачам исчисляется уже миллиардами. 

Как внутренний сервис Tracker существует с 2012 года, и старые инстансы исторически использовали базы данных on-premise. Но к 2023 году многие части даже из списка легаси должны были переехать в облако — и нам понадобилось продумать бесшовный переезд для достаточно объёмных БД.

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

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

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

Меня зовут Вадим Ивахин, я техлид в Vi.Tech — это IT-дочка ВсеИнструменты.ру.

Я и мои коллеги трудимся над большим количеством проектов и используем в своей работе различные инструменты, в том числе MongoDB. В этой статье я не стану рассказывать о том, что такое MongoDB. Хочу рассказать о её интересной и удобной особенности — механизме Watch, и о том, как с его помощью спроектировать приложение, способное выдержать десятки тысяч rps.

Хотел бы поделиться интересным решением, которое, уверен, было бы полезно для кооперативов и товариществ.

Современные технологии постепенно проникают во все области нашей жизни. Сегодня сложно представить соседей многоквартирных домов или земельных участков СНТ/ДНТ без группового чата в мессенджере. Такие группы удобны для общения, они позволяют оперативно решать вопросы, публиковать объявления, делиться новостями и даже проводить опросы и голосования.

Кстати, голосование в мессенджере может иметь юридическую силу. Для этого нужно принять решение о возможности применения электронных средств при принятии решений общим собранием членов товарищества и внести соответствующие изменения в устав товарищества (п. 25 ч. 1 ст. 17 федерального закона № 217-ФЗ). При создании нашего товарищества так мы и сделали, и теперь большинство вопросов мы решаем удаленно через Telegram.

Результаты опросов, проведенных в Telegram, отображаются почти моментально в интерфейсе мессенджера. Однако такие результаты не учитывают случаи, когда количество голосов у членов товарищества отличается. Кроме того, в общем чате могут присутствовать супруги/родственники участников, которые могут проголосовать без права голоса. В итоге всё сводится к тому, что необходимо каждый раз пересчитывать голоса.

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

На скриншотах ниже представлены результаты одного из первых Telegram-опросов, которые мы провели.

Всем привет! Меня зовут Александр, мне 33 года и я React-разработчик из Беларуси (10 лет опыта во фронтенде).

Я хочу рассказать о моем опыте создания мобильного приложения для хранениях прочитанных книг BookDesk.

Все началось еще в 2020 году, когда началась пандемия коронавируса, и всем пришлось находиться в изоляции. Тогда и пришла идея о создании своего приложения. У меня богатый опыт разработки веб-приложений на React, и поэтому я решил попробовать себя в новом направлении. Я решил долго не думать над технологиями и использовать React Native в связке с Node.js и MongoDB, т. к. ранее я уже работал с Node.js и MongoDB для создания веб приложений и, поэтому, выбор был очевиден.

С момента своего появления MongoDB успела завоевать огромную популярность благодаря своей способности обрабатывать большие объемы данных. Ее принятие только растет, впрочем, как и сам рынок, на котором она востребована. Если вы нацелены связать свою карьеру с MongoDB, то сейчас самое время. Чтобы помочь вам на этом пути, мы подготовили список часто задаваемых вопросов по MongoDB с собеседований и ответов на них.

Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. Как вы помните из предыдущих частей (1, 2, 3), у нас уже есть функциональность для работы с планировщиком в бэкенде. Теперь нашей задачей будет создать удобный и интуитивно понятный пользовательский интерфейс, чтобы пользователи могли легко взаимодействовать с задачами.

Дети часто задаются вопросом - кто сильнее, кит или слон? каратист или боксер? В этой статье мы попробуем ответить на на похожий вопрос, сравнив SQL (ну или почти SQL) базу данных PostgreSQL и NoSQL базу данных MongoDB. И понять, для каких проектов лучше подойдет реляционная PostgreSQL, а для каких MongoDB.

Данное сравнение также важно, потому что, учитывая новый функционал, MongoDB стала обладать некоторыми качествами SQL СУБД, включая многодокументные ACID-транзакции, вторичный индекс и расширенные возможности запросов. А PostgreSQL расширяет возможности работы с JSON, включаяиндексирование и оптимизацию запросов.

Добрый день, уважаемые коллеги!

Меня зовут Анкин Николай и это мой первый пост. На текущий момент я тружусь в должности DevOps Engineer в компании Altenar. История о том , как я сэкономил денег своему любимому работодателю.

На что мы тратим 3k$ в месяц ?

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

В предыдущей статье мы подготовили наше тестовое приложение — бота для обмена анонимными сообщениями в Telegram.

Пришло время отобразить все данные, которые мы собрали. Для этого мы будем использовать Redash.

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

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

Привет Хабр!

В Kubernetes StatefulSet — это реплицированные группы Pod’ов, аналогичные ReplicaSet’ам.

Каждая реплика получает постоянное имя хоста с уникальным индексом (например, database-0, database-1 и т. д.).

Каждая реплика создается в порядке от самого низкого до самого высокого индекса и создание блокируется до тех пор, пока под с предыдущим индексом не станет работоспособным и доступным. Это относится и к масштабированию.

При удалении StatefulSet каждый из управляемых подов реплики также удаляется в порядке убывания. Это также относится к уменьшению количества реплик.

Оказывается, этот простой набор требований значительно упрощает развертывание приложений для хранения данных в Kubernetes. Например, сочетание стабильных имен хостов (например, database-0) и ограничений порядка означает, что все реплики, кроме первой, могут надежно ссылаться на database-0 для целей обнаружения и установления кворума репликации.

Сегодня мы развернем реплицированный кластер MongoDB с StatefulSet.

В настоящее время объектно-ориентированные базы данных (ООБД) не имеют достаточно большого распространения в повседневном использовании, да и более того, не настолько популярны как реляционные базы данных, которые не один десяток лет уже активно поддерживаются различными сообществами и имеют долгую историю применения.

В данной статье рассматривается реализация ООБД в контексте разработки системы, состоящей из микросервисов, на примере Perst и Db4o. Также будет рассмотрена отдельная реализация с документно-ориентированной базой данных MongoDB, работа с которой имеет много общего с ООБД.

Целью данной статьи является рассмотрение практического применения ООБД и решения проблем совместимости с помощью микросервисной архитектуры.

Несмотря на то, что MongoDB начало движение в сторону строгости реляционной модели, она по прежнему остается документной БД и предполагает возможность сохранения документов произвольной структуры. И при использовании MongoDB в языках с динамической типизацией (JavaScript, Python) сохранение или генерация объектов не вызывает сложностей, поскольку заранее не требуется определить структуру извлекаемого или сохраняемого объекта. Но как действовать в случае использования драйверов для MongoDB для языков со строгой типизацией?

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

Зачастую возникает необходимость начать новый микросервис.

Вот и у меня совсем недавно возникла такая потребность. А ведь еще хочется и чего-то новенького попробовать.

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

Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. В прошлой части мы разобрали, как создать аутентификацию с помощью библиотеки Passport, а сегодня мы рассмотрим такие манипуляции, как добавление, редактирование, удаление и получение задач. Для начала давайте разберём HTTP и некоторые типы запросов.

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

Я ни в коем случае не считаю, что MongoDB это плохая БД и ее не нужно использовать. Более того, я считаю, что только мои кривые руки завели меня в ситуацию, из которой пришлось выходить переписыванием сервиса под другую БД (ушел на Postgres и кайфую).

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

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

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

Действие разворачивается на базе очень большой track & trace системы класса big data. В ней давно откладывали переход на шардированную архитектуру хранилища. Поэтому главному герою предстоит справиться справиться со злом, пробудившимся в системе под нагрузкой: деградацией производительности, полкой по блокировкам и алертами о перегрузке.

В конце — как обычно, хэппи-энд. Наш герой бесстрашно меняет архитектуру решения на лету без downtime (DT) и обеспечивает штатную работу системы. Зло повержено, а отважный инженер купается в овациях!

Статья написана по мотивам доклада на конференции Saint Highload++ 2022. Если не хотите читать — можно посмотреть видео-версию выступления.

В этой статье сравним MongoDB и Cassandra — две самые популярные NoSQL базы данных.

На выбор подходящей СУБД для проекта может уйти довольно много времени. Требования к базе данных могут включать упрощенную модель данных, гарантию транзакций, производительность чтения/записи, горизонтальное масштабирование и отказоустойчивость.

Для начала нужно определиться с типом СУБД: SQL или NoSQL. Если вы выберите NoSQL, то дальше появляется вопрос: MongoDB или Cassandra. Да, на рынке существует множество NoSQL-баз данных, но среди них лидируют MongoDB и Apache Cassandra. Оба продукта похожи, но все-таки разные. Давайте сравним эти две СУБД, чтобы сделать правильный выбор.