MongoDB *

В работе веб-разработчика (в частности бекенд-разработчика) встречается много разных интересных и уникальных задач. В этой статье речь пойдёт о такой теме как написание миграций документно-ориентированной БД mongo. Как и в любой задаче у нас имеется несколько вариантов решения проблемы. Мы подробно разберём примеры использования 2х разных c#-библиотек, не углубляясь в детали реализации. Посмотрим их плюсы и минусы и выберем 1 из них для выполнения поставленной задачи. В конце нас ждёт небольшое сравнение производительности, так что пристегнитесь, ведь будет интересно.

Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных (реляционная или NoSQL), поддержку транзакций, масштабируемость, требования к согласованности и многого другое. Одним из ключевых архитектурных аспектов, влияющих на эффективность и надежность системы, является модель репликации данных. Репликация означает поддержание копий одних и тех же данных на нескольких узлах (серверах), соединённых по сети​.

Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность)​.

Однако реализация репликации сопряжена с серьёзными архитектурными компромиссами. Согласно теореме CAP, в распределённой системе невозможно одновременно гарантировать все три свойства: консистентность данных, доступность сервиса и устойчивость к разделению сети. При возникновении сетевых сбоев (разбиении на изолированные сегменты) системе приходится жертвовать либо мгновенной согласованностью данных, либо доступностью части узлов. Поэтому разные СУБД делают разные выборы в этих компромиссах. Архитектурная модель репликации, лежащая в основе СУБД, определяет, как база данных достигает (или не достигает) консистентности, доступности и отказоустойчивости. Понимание этих различий крайне важно для архитекторов и разработчиков: зная поведение репликации, вы сможете выбрать такую СУБД, которая лучше соответствует требованиям вашего проекта по масштабу, геораспределенности, допустимой задержке и устойчивости к сбоям.

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

PostgreSQL и MongoDB: два подхода к управлению данными

В мире баз данных существует множество решений, каждое из которых подходит для определённых задач. Два популярных представителя — это PostgreSQL и MongoDB. Они представляют собой разные подходы к хранению и обработке данных: реляционный и документоориентированный. Рассмотрим их основные особенности.

Привет, Хабр!

Меня зовут Алена Метенева, я работаю старшим инженером по обеспечению качества в компании SM Lab в проекте «Кассы». Я тестирую бэкенд и интеграции и там, где это возможно, автоматизирую тесты на Java. Сегодня я хочу рассказать вам о том, как MongoDB помогает мне с этим процессом.

Что такое MongoDb

Думаю, многие работали с MongoDB (Монга) и знают, что это нереляционная СУБД, которая использует для хранения данных JSON-структуру: вместо таблиц и строк, как в реляционных базах данных, в MongoDB есть коллекции (набор документов, эквивалент таблицы реляционной базы данных) и документы (внутри коллекции они могут отличаться друг от друга размером, содержанием и количеством полей), которые состоят из пар «ключ–значение».

Для чего Монга тестировщику 

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

Что я имею в виду?

Представьте, что вы тестируете интеграцию с другой системой. Если все работает стабильно, то пройти позитивные сценарии будет проще всего. А если вы хотите протестировать кейс, в котором смежная система выдает ошибку 503 (Service Unavailable) – это будет уже сложнее. Хорошо, если вы управляете обеими системами и можете просто перезагрузить одно приложение и попытаться достучаться до него через второе. А если система не ваша? В таком случае принято использовать моки. Но есть и третий вариант: если ваше приложение для подключения к другому берет ссылку из MongoDB, то эту ссылку можно просто подменить, добавив в нее лишние символы, чтобы получить ту самую ошибку 503 или 404 (Not Found), например.

10 лет назад мы начинали бизнес студии с разработки сайтов на CMS 1С-Битрикс. Сегодня наш основной стек связан с подходом Single Page Application на Symfony и Nuxt, но клиенты по-прежнему просят сайты на Битриксе.

Отказываться от работы не хочется, однако приходится обходить ограничения Битрикса, чтобы делать быстрые и качественные продукты. В этой статье о том, как мы написали сервис для обработки больших объемов данных на Symfony и MongoDB и интегрировали его с 1С-Битрикс.

В данной статье мы рассмотрим взаимодействие apache airflow, rabbitMQ и postgreSQL. Научимся правильно устанавливать соединения между ними и напишем базовый ETL.

MongoDB — это популярная NoSQL база данных, широко используемая для хранения больших объемов данных. Одной из ключевых возможностей MongoDB является механизм Oplog (операционный журнал), который позволяет отслеживать изменения в коллекциях. В этой статье мы рассмотрим, как работать с Oplog, искать документы, преобразовывать временные метки и выводить результаты в читаемом формате, что крайне удобно для аналитиков.

Моя профессия далека от IT технологий. Я работаю на производстве кажется всю жизнь довольно давно. Тематика - производство и ремонт металлообрабатывающих станков. Производим станки как новые, так и ремонтируем. Стараемся все делать локализировано (импортозамещение ж)- все железки точим, шлифуем, собираем и т.д

Проверка юридических документов с помощью визуальных помощников может оказаться важной задачей. Если человек способен хранить в голове одновременно в зоне его мозговых вычислений 6-8 параметров, ну может и больше, если гений... А остальные держать в блокноте. То ИИ учитывает больше параметров, те же модели LLM доступны с количеством 70 миллиардов параметров. То есть мы-то тоже ежедневно принимаем решения на основе большого количества входных параметров: купить ли сегодня эту вещь, поехать ли отдыхать на море, бросив все, доехать на такси или на автобусе. Но учитываем не все сразу, хотя что-то учитывается на подсознательном уровне. Эдакое дело вкуса, когда просто чувствуешь, что так правильнее, и в итоге не прогадал.

Правда люди еще не научились влиять на решения сети. У нейросетей особенные вкусы. Если GAN-сеть создает нам девушку, у которой 2 руки, то для каких-нибудь художников эпохи Сюрреализма это могло бы показаться гениальным. Двумя руками обнимает парня, словно вцепилась в него всей душой и влюбилась всем сердцем... К сожалению или к счастью, в задачах создания юридических документов мало необходимости творить что-либо на уровне латентного вектора в цепочке между кодировщиком и декодировщиком. Но работа с юридическими документами – тот самый скоп задач, где важно найти судебную практику, предшествующие документы и просто оформить все примерно также.

Таким образом, работа с юридическими документами – лакомый кусочек уже лет так 5, особенно на зарубежном рынке, где задача автоматизации рутинной деятельности сводится именно к тому, чтобы из исторически предшествующих документов собрать что-то стоящее, применимое к текущему документу. По семантическому окрасу и истории работы с документом можно понимать, что именно перед тобой: проигрышная трактовка, выигрышная трактовка, доводы, играющие в пользу истца или аргументы, помогающие ответчику, если дело идет о судебных исках.

В мире инструментов веб‑разработки особое место занимают технологии, объединенные аббревиатурой MERN (MongoDB, Express, React, Node.js), представляющие собой комплексное решение для разработки современных веб‑приложений. Книга Владимира Дронова «Node.js, Express, MongoDB и React. 23 урока для начинающих» представляет собой полезный ресурс для тех, кто хочет освоить этот стек технологий. И еще важно — это мощная книга на 600+ страниц, а не проходная брошюрка.

Я работаю в компании STM Labs, где мы строим большие высоконагруженные системы класса Big Data. Эта статья написана по мотивам моего выступления на конференции Saint Highload 2023. Хочу рассказать вам увлекательную историю про то, как мы искали лучшее решение по синхронизации аналитического и оперативного хранилищ в реальном времени. Нам важно было сделать это без потерь, потому что на кону стояли сотни и более терабайт данных.

Сразу обозначу, чего в этой статье не будет:

• Я не буду подробно говорить о типах СУБД и их различиях.
• Я не буду делать обзор аналитических СУБД. Тут каждый выбирает сам.
• Я не буду подробно останавливаться на архитектуре, отказоустойчивости и масштабировании СУБД MongoDB.
• Я не буду делать обзор отличий OLAP и OLTP.
• Я не буду делать обзор и сравнение реализаций CDC в различных СУБД.

Русский или English? Что для бота хорошо, то разработчику работа :)

Введение

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

Постановка Задачи

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

В этом цикле статей я подробно расскажу о процессе создания моего нетривиального телеграм-бота World for Life Bot. Этот бот представляет собой уникальный инструмент, который предоставляет обширную статистику о стоимости жизни в разных уголках мира, помогая пользователям оценивать и сравнивать уровень жизни в различных городах.

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

Чтобы применять Domain-Driven Design, DDD Aggregate и Transactional outbox на MongoDB, наша команда создала open source — библиотеку calypso для работы с BSON.

Публикация для тех, кто стремится к современным практикам разработки и разделяет наше влечение к Scala 3.

Готовы к открытиям? Добро пожаловать в мир функционального программирования и надёжной работы с schema-on-read.

Привет, меня зовут Мария Карпенко, я разработчик в команде 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 для создания веб приложений и, поэтому, выбор был очевиден.