https://www.mongodb.com/docs/v5.0/core/index-partial/#std-label-partial-index-with-unique-constraints только в условии поменять допустим что тип равняется строке и тогда все null будут пропущены

Всем привет, может кто сталкивался с подобной проблемой. Вот примерно такая статистика по загрузки монги. Во время выполнения снапшотинга вся активность замирает (видны провалы на верхнем графике) потом всё оживает. Соответственно общее время отклика сервиса плящет от 2 до 150 и под нагрузкой от 2 до 300 мс. Железо - bare metal 96гб 64cpu SSD, загрузка CPU не более 10%, загрузка дисков средняя. Ну и такая же картина на 2х репликах, т.е. даже запросы на чтение с реплик всё равно лагают.

Привет, подскажите, пожалуйста, методы интеграции данных из mongodb в elasticsearch. смотрел какие-то коннекторы, но многие устарели. остановился на интеграции с logstash. но, может, есть другие варианты, более лучшие?

Может у кого есть мысли по этому поводу

Ты хочешь логи монги в elastic складывать?

А fs и ос какая?

нет, я хочу сделать поиск по документам. например, есть документ вида {_id, title, some other fields}. для реализации fulltext поиска, но по части слова, я бы складывал в эластик id и title. сам поиск был бы в эластике, который возвращал список найденных айди. со списком айди уже шел бы в монго.

Слишком много записей в сек как по мне. Нужно повоерить current operations, проверить индексы или проставить там где необходимо. У studio 3t на сайте есть много туториалов по оптимизации монги, рекомендую!

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

Я написал просой скрипт который по крону наполняет данные в эластик

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

Честно, даже не искал тут инструментов, я накидал скрипт за полчаса и все))

да, скрипт можно сделать, но если их много будет, то что-то не айс

А зачем, скрипт 1 просто научи его работаь с разными коннектами

И вот ещё кейс, не уверен, что у стороних решений для интеграции с elk есть возможность прописывать синонимы без лишних манипуляций. Пример, у тебя есть поле name и по нему ты хочешь нагенерить синонимов, для более глубокого и продуманного поиска

ext4 centos 8

Думаю xfs исправит ситуацию

2500 insert в сек. На xfs работа с снапшотами лучше... Профайлинг ещё включи с 0ms посмотри что логах будет

Ну это не маленькие, а индексы?

индексы все необходимы есть, есть пара "лишних", мы в процессе избавления от них

Я больше про их размеры

Ну не совсем. А как вообще с железом? Raid есть-ли контроллер? Какой iops

Думаю после перехода на xfs проблема уйдет

Добрый вечер! Подскажите пожалуйста. Как быстрее писать? Использую updateOne с upsert и в bulkWrite. Монга в облаке яндекса, процессор грузит на 100%, а скорость записи 1 документ / 1,2 сек. Коллекция 2.8 млн документов

скорее всего у вас выражение в update части не попадает под этот индекс

то есть нужно создать индекс с этими полями?

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

доброго дня всем вопрос по деревьям. нашёл часть ответов тут: https://www.mongodb.com/docs/manual/applications/data-models-tree-structures/ так же тут: https://www.mongodb.com/docs/manual/tutorial/model-tree-structures-with-materialized-paths/ мне подходит 2 вариант: "Структуры дерева моделей с материализованными путями", однако, в доке показан example с разделителями в виде "," запятой. есть-ли вариант как-то это изменить (разделитель)? и общий вопрос: стоит-ли пользоваться этим дефолтным инструментом и подстраивать свою архитектуру под него, либо можно и свою реализацию написать? какая необходима функциональность: - у меня есть статьи (объекты данных с полями) - каждая из статей расположена в какой то конечной точке иерархии - каждая конечная точка иерархии может становиться НЕ конечной, то есть становиться вложенной - при этом названия любой точки из иерархии могут меняться (не важно это конечная или вложенная структура) подойдёт-ли "Структуры дерева моделей с материализованными путями"? и какие могут быть подводные камни? если какой-то инфы не хватает, дополню, пните

стоит-ли пользоваться этим дефолтным инструментом - я бы сказал он добавляет сложности только, плюсов никаких в статье не вижу. Проще выглядит обычная реализация, пример: вам нужен Books.Programming.Language - то такое query и пишете, без всяких запятых, циферок и тд. С того, как вы описали ваши модели - структура может быть довольно вложенная или наоборот довольно нуллабл - главное помнить, чтобы вложенность объектов не была выше 100эл суммарно.

хочу разные базы, для юзеров и токенов и для форумов и тд

Создай разные коллекции, зачем разные бд под это?

можно ли это реализовать через монгу? например у меня 123 людей в базе нужно сделать топ 100 людей и отсортировать по значению

Можно, а в чем проблема?