MongoDB *

Привет, Хабр! Я Сергей Гайдамаков. Уже 28 лет я занимаюсь проектированием и разработкой программных систем различного масштаба. Сейчас работаю в Т-Банке системным аналитиком и проектирую системы, которые в совокупности составляют большую распределенную систему. 

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

Привет, Хабр! Меня зовут Александр Цай, я ведущий аналитик в МТС Web Services, но на деле занимаюсь всеми вопросами, касающимися DA/DE/BI: выявлением потребностей и сбором требований, проектированием дашбордов и витрин для них, построением и развитием внутреннего хранилища, поиском источников данных, созданием сложных ETL-пайплайнов по их доставке, DQ, проведением аналитики и много чем еще.

В этом материале я расскажу про разворачивание пайплайна по стримингу данных из MongoDB в PostgreSQL с помощью Apache Flink (стримить из Kafka банально, а так заодно пощупаем документоориентированную БД). Делать это мы будем в minikube (kubernetes), а языком программирования для заданий выступит Python. Все описанное в посте выполняется на MacBook с процессором i7.

В интернете, тем более русскоязычном, нет информации о стриминге из MongoDB в Postgres с помощью Flink. Почти все материалы по Flink, которые мне попадались, сводятся к пережевыванию примера WordCount из flink-kubernetes-operator, где на запущенном поде из папки с примерами читается файл и в консоль выводится количество слов в нем. Если спускаться до использования PyFlink, то мы натыкаемся на кастомные образы с Harness SDK и Apache Beam и другие страшные слова. Знакомо?

Так вот, это не наш путь! Данное руководство будет полезно тем, кто такой же извращенец хочет пощупать Flink на родном Python и кто не планирует брать примеры, оторванные от реальности.

В работе веб-разработчика (в частности бекенд-разработчика) встречается много разных интересных и уникальных задач. В этой статье речь пойдёт о такой теме как написание миграций документно-ориентированной БД 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.