Небольшая ремарка о монге.

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

Если появляются дублирующиеся ключи - кидается исключение. Логично было бы ожидать, что запись всей пачки будет отменена. Но нет: все документы, которые могут провалятся в базу.

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

Возможно, есть обходные пути, но поведение "из коробки" - такое.

#кодинг
#mongodb

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

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

Для человека, два года пользующегося монгой и казалось бы привычного к ней, первое составление запроса вида (дико извиняюсь за псевдо-sql):

select distinct field1, field2 from table where (пара условий) order by field2 limit 100 skip 100

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

Сначала, как обычно, пытаешься слепить запрос прямо в c#, используя синтаксический сахар, предоставляемый библиотекой-конектором.

После полутора дней мучений в с# я отправился в дефолтную графическую оболочку над базой, где часа за 2 в конструкторе составил нужный мне запрос.

Теперь я имею json в 30 строк, который при выполнении в монге выдает нужный мне результат. Осталось корректно перенести его в с#.

#mongodb

Вот примерный json, генерируемый запросом. Сравните по читаемости с псевдо-sql версией в прошлом посте.

[{
$match: {
Field3: "qwerty123",
},
},
{
$group: {
_id: "$Field1",
id: {
$first: "$Field1",
},
Field2: {
$first: "$Field2",
},
},
},
{
$sort: {
Field2: -1,
},
},
{
$skip: 0,
},
{
$limit: 2,
},
{
$project: {
_id: 1,
},
},
]

group в данном случае используется для получения эффекта distinct из sql запроса.

Монга умеет в distinct запросы, но туда не завезли пагинации (постраничной отдачи), потому идём окольным путём 🤡

#mongodb

А от шарповой версии запроса уже конкретно начинает течь кровь из глаз, при том, что простые запросы там прекрасны. В качестве примерна приведу получение всех записей, где определенное поле равно чему-то:

_mongoCollection.Find(record=>record.Field3=="qwerty123").ToList();

В примере используется трансляция в монговский формат внутришарпового языка запросов к коллекциям LINQ, потому всё максимально прозрачно.

#mongodb

Sphagnum. Часть 5. Техобзор. Репликация и отказоустойчивость в MongoDB
#sphagnum@eshu_coding

MongoDB в качестве механизма репликации использует распространение между ведомыми нодами oplog-а. Изменения сперва записываются в WAL (Journaling в терминологии MongoDB), затем применяются к master-у (primary node), а затем - записываются в oplog - operation log - отдельную коллекцию (таблицу), из которой асинхронно расходятся по репликам (secondary).

Для организации отказоустойчивого кластера достаточно средств самой MongoDB. Кластер представляет собой primary-ноду и некоторое количество реплик. По ситуации могут быть добавлены специальные инстансы монги для поддержания целостности кластера: один или несколько arbiter. Выбор нового мастера может осуществляться двумя путями:
1. Совместным голосованием оставшихся в живых secondary инстансов
2. Голосованием с участием арбитров.

Ноды в replica set-е раз в две секунды пингуют друг друга. Если какая-то нода не отвечает 10 секунд - она объявляется недоступной. В случае, если это - primary, одна из нод может запустить выборы. Ноды имеют приоритет в очереди на престолонаследие и неравные веса голосов: целое число, минимум - 0, дефолт - 1.

Ноды с 0 голосов голосовать не могут вообще, но при этом могут наложить вето на запуск процедуры голосования.

Итого, из того, что мне пока хотелось бы взять для своего проекта:
1. Механизм вето запуска голосования.
2. Использование арбитров мне пока видится избыточным, но при проектировании системы стоит предусмотреть такую роль на будущее.

#sphagnum_theory@eshu_coding
#mongodb

Пожалуй пришло время обновить закреплённый пост. Каналу уже 5 лет, с прошлого закрепа изменилось многое.

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

За прошедшие 5 лет я сменил 4 места работы:
1. Фирма, занимающая АСУ ТП в области учёта ресурсов.
2. Медтех стартап в Сколково, делали системы поддержки принятия врачебных решений.
3. Сеть общепита, делал бэкенд службы доставки.
4. Банк, текущее место работы. Работаю в домене клиентских карточек.

Мой технологический стек:
C#, PostgreSQL. Плотно работал с MongoDB, RabbitMQ, Tarantool, умею строить базовую инфраструктуру: логи (Loki), метрики (Prometheus), девопсятина (gitlab, gitea, github actions, docker).

Поверхностно знаком с Apache Kafka, MS SQL и фронтовыми фреймворками - React.js и AvaloniaUI.

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

Далее будет навигация по каналу.

Общие теги:
#csharp@eshu_coding - общий тег для постов про разные аспекты разработки на языке программирования c#
#postgresql@eshu_coding - разные интересные моменты про PostgreSQL.
#devops@eshu_coding - мои эксперименты в девопсятине и инфраструктуре.
#mongodb@eshu_coding - записки про MongoDB.
#tarantool@eshu_coding - заметки про Tarantool.

Pet - проекты:
#палантир@eshu_coding - завершенный проект, которым я занимался весь 2021 год - поисковик по телеграму.
#sphagnum@eshu_coding - попытка написать свой брокер сообщений, пока застопорилась на стадии изучения теории и прототипирования по причине нехватки времени.

Книги:
#рихтер@eshu_coding - заметки и конспекты по основополагающей книге про C# - CLR via C#. Программирование на платформе Microsoft .NET Framework 4.5 на языке C#, Джеффри Рихтер. Хоть .NET 4.5 вышел до моего появления в IT, внутренности платформы во основном остались прежними.

Конспекты прослушанных выступлений на конференциях:
#dotnext@eshu_coding - Dotnext 2023
#highload@eshu_coding - Highload++ 2024

Шпаргалки и мои заметки для подготовки к собеседованиям #собес@eshu_coding

Природа и путешествия #природа@eshu_coding #путешествие@eshu_coding