Всем привет. А какой true way реализовать timeline (получение данных с какого-то момента) в монге? Что я пробовал: 1. Optimistic Loop (надежно, но медленно при многопоточной записи). 2. Коллекция счетчиков (быстрее, но возможен рассинхрон при многопоточной записи). 3. Поле с CurrentDate (быстро, но возможен рассинхрон при многопоточной записи). Есть варианты получше? Надежно и быстро? ObjectId не подходит потому что нужно иногда Updat'ить данные и соответственно обновлять точку синхронизации

меня просто напрягает такая статистика во времени выполнения "executionTimeMillis" : 658, "totalKeysExamined" : 342702, "totalDocsExamined" : 56,

Пример запроса покажи?

Сейчас до компа дойду

Всем привет. А какой true way реализовать timeline (получение данных с какого-то момента) в монге? Что я пробовал: 1. Optimistic Loop (надежно, но медленно при многопоточной записи). 2. Коллекция счетчиков (быстрее, но возможен рассинхрон при многопоточной записи). 3. Поле с CurrentDate (быстро, но возможен рассинхрон при многопоточной записи). Есть варианты получше? Надежно и быстро? ObjectId не подходит потому что нужно иногда Updat'ить данные и соответственно обновлять точку синхронизации

Для времянных рядов лучше всегда использовать время. Почему может возникнуть «рассинхрон» и какой физический смысл данных?

Для времянных рядов лучше всегда использовать время. Почему может возникнуть «рассинхрон» и какой физический смысл данных?

Тесты показывают, что при использовании CurrentDate легко следующий элемент в многопоточной среде имеет значение меньше чем предыдущий (даже если это timestamp). Данные - это сообщения в чате. Смысл в дочитывании новых сообщений. Чат с высокой нагрузкой.

Дату используй и не парься.

Серверную

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

Глеб, Монго это не реляционная ДБ со всеми вытекающими. Некоторую подобную функциональность (крайне неэффективную vs реляционные дб) можно посмотреть здесь: https://stackoverflow.com/questions/2350495/how-do-i-perform-the-sql-join-equivalent-in-mongodb

Мгм, спасибо. Попробую) На самом то деле есть как раз таки aggregation, который кое-что по связям умеет делать. Плюс вещи типа $lookup. В NoSQL нет JOIN, на замену им MapReduce операции. Вопрос в том, что $in от нескольких десятков ключей - тоже такая себе идея, так что выбираем одно из двух зол.

Потом чяты с высокой нагрузкой это всё ещё достаточно низкая частота событий, ну может быть пара сообщений в секунду.

Пример запроса покажи?

db.orders.find({"created": { $gte: ISODate("2017-10-17T05:53:13Z") }, "channel": "smth", $or: [ { "status_external.smth" : 1, "notified.$id" : ObjectId("id") }, { "owner.$id" : ObjectId("id") }, { "performer.$id" : ObjectId("id") } ], "status_external.smth": { $nin: [8,7,9,10] } }).hint({"created": -1, "channel": 1, "status_external.smth": 1})

пока ускорил пересобрав индекс с использованием partial и ttl

Взять и по уменьшению селективности сделать компаунд индекс

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

Нужно уменьшить выборку.

Плюс у тебя там статус два раза

выборка продиктована бизнесом (не знаю на какой фиг так) пока вижу только частичный + ттл

Выборку в смысле число ключей которые монга выбирает просканировать

Попробуй компануд индекс

так у меня комаунд

в хинте как раз поля компаунд индекса

Какое из них?

все три

А как индекс выглядит?

именно в такой последовательности и сортировке

{"created": -1, "channel": 1, "status_external.smth": 1} прямо вот так

А сколько записей в коллекции?

миллионов 20 (возможно больше, уже не могу посмотреть)

Channel насколько уникальные значения содержит?

4 вида значений

А статусов сколько?

10+ значений

А в час сколько примерно записей помещается?

? примерно 2-3 тыс.

Меньше записи в секунду. Дату префиксом лучше не использовать.

Дату отдельным индексом, в компаунде оставить статус и канал.

и без хинта?

Планировщик сам должен справиться

Хинты в основном нужны когда планировщик выбирает не тот индекс из доступный.

Тебе надо уменьшить totalKeysExamined на один два порядка.

ага, знаний пока не хватает по этому вопросу ) спасибо, попробовать смогу уже только завтра

сегодня еще как раз новые блоки в монго универе откроются по индексам

Лучше на два. Тысяча ключей на сотню документов — нормальный баланс

ну пока это было достигнуто путем partial + ttl просто за счет того, что в индексе меньше данных

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

С другой стороны если ttl и partial подходят к задаче то и отлично.

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

хотя да, именно так... и это в принципе логично (сейчас пересмотрел блок в монго универе)

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

Грубо говоря, у тебя матрешка из индексов получатся. Причём не одна, а на каждое уникальное значение индекса у тебя по матрёшке

Т.е. компаунд по дате в твоём случае делает тебе на первом уровне матрешек по числу уникальных дат

ну теперь хоть понятно почему не стоит использовать дату в префиксе )

Что делает остальные уровни бесполезными

ага, осознал спасибо )

Мгм, спасибо. Попробую) На самом то деле есть как раз таки aggregation, который кое-что по связям умеет делать. Плюс вещи типа $lookup. В NoSQL нет JOIN, на замену им MapReduce операции. Вопрос в том, что $in от нескольких десятков ключей - тоже такая себе идея, так что выбираем одно из двух зол.

$in на несколько десятков ключей лучше чем $lookup

Даже на несколько сотен

@dd_bb https://docs.mongodb.com/manual/release-notes/3.4-changelog/#id1 чутка рано, но на днях выйдет 3.4.10

господа в db.currentOp() вижу поля desc и clientMetadata можно их как то заюзать ?

например для указания откуда запрос пришел

или как это сделать веселее ? mongoengine==0.13.0

Первое вроде как в запросе настраивается, через $comment: https://docs.mongodb.com/manual/reference/operator/query/comment/

Второе фича клиента. Зависит целиком от драйвера

да я нашел

+ adult = (User.objects.filter(age__gte=18) + .comment('looking for an adult') + .first())

пример из примера

Ага. https://docs.mongodb.com/v3.2/reference/method/cursor.comment/

Если драйвер не умеет прямо, можешь попробовать старый addOption, может сработать.

Ребят, привет Такой вопрос: роллбэк на реплике сейчас занимает 16+гб. Есть вариант его аккуратно почистить ?

посмотри что там в ролббэке, и если эти данные не нужны, то просто удали

Спасибо)

но вообще лучше разобраться откуда столько роллбэка

это не очень хорошо

Понял, спасибо)

онлайн есть кто?

Больше шансов получить ответ если сразу задать вопрос.

WiredTiger в монге сильно отличается от аэроспайковского и кассандры

вот предположим есть кластер, 256 гб оперативы его общее кол-во, размер базы 3+ тб, запросы разные, например вывести список товаров прошедших через юзера в компании за пол года, или вообще весь, а так же целиком у компании

где до 30 юзеров

сколько такие запросы потребуют iops при выполнении в сравнении с выше перечисленными бд

:)))))))))

Случайное число от 0 до «сколько вытянет сторадж»

Случайное число от 0 до «сколько вытянет сторадж»

вот тут то и оно, что базе одновременно ещё есть хранимые xml до разбора приложением

Но в целом, в худшем случае, по числу страниц которые необходимо просмотреть для поиска по индексу и потом ещё по числу страниц для чтения документов.

и еще учесть фрагментацию файловой системы, и тип схд

и длинну кабелей до схд. и качество лунного света.

Нормальные стораджи блоком пишут

и еще учесть фрагментацию файловой системы, и тип схд

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

Так что фрагментация не должна ролять

будут netapp+iscsi как мне известно

Потому что не будет последовательного чтения в худшем случае

Потому что не будет последовательного чтения в худшем случае

f tuj b yt vj;tn ,snm

его и не будет

так и так

оценка iops для базы при выполнеии запроса... хм.