но не обязательно

first и last не надо

incremental page index?

если больше 2 участников, то да

{ members: [<user_id>] pageIndex: <integer> messages: [ { datetime: <datetime> message: <text> author: <user_id> } ] }

хмм, а что если например нужен поиск по времени (найди все сообщения с 1 июля 2016 по 3 июля 2016)

{ members: [<user_id>] pageIndex: <integer> messages: [ { datetime: <datetime> message: <text> author: <user_id> } ] }

надо хранить текущий счётчик

тогда нужны поля first и last для индексации

тогда нужны поля first и last для индексации

messages.datetime

messages.datetime

хмм... а как выглядит такой query?!

{ "messages.datetime" => { $gte: ..., $lt: ...} }

но надо понимать что тебе вернут не «поддокументы» а документы

хмм, окей, значит таким образом

ну да

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

тьфу

тело

ну да)

всё верно

норм

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

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

1. find between 01.07.2016-00:00 по 03.07.2016-00:00 = docs [doc1_id, doc2_id, ...] 2. for doc in docs retrieve document

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

а?

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

а получить лишь Id документов и качать поочерёдно уже body

не надо пытаться перехетрить планировщик

ты делая запрос открываешь «курсор»

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

дальше курсор набирает нужное количество документов (по-умолчанию сколько влезет в один 16 мегабайтный bson, потому что монговский протокол тоже на bson построен)

и возвращает в виде результата

за исключением сложных случаев с сортировками, тогда всё хуже

условно, если ты делаешь выборку без сортировки, с условием которое полностью зарешается с помощью индекса, то курсор составляет себе список _id документов и выбирает их не все, а в по мере «истощения»

ок, всё понял, значит всё-таки буду в монгу пихать page'ы чата дабы SQL не нагружать

сделай сначала прототип, чтоб схему понять

с просто pageIndex будет сложно вставлять поддокументы

с просто pageIndex будет сложно вставлять поддокументы

в смысле?

зачем pageIndex в поддокументах?

хотя наверное лучше так: chatrooms: { id: <object_id> members: [<user_id>] } messages: { room: <object_id> pageIndex: <integer> messages: [ { datetime: <datetime> message: <text> author: <user_id> } ] }

но там опять возникает вопрос по atomicity... что если нужно удалить чатрум, а во время удаления 10 документов удалились лишь 3 и сервер рухнул... 7 документов остаются в бд хотя система про чатрум забывает 😕 в результате uncollected garbage

Он не мешает консистентности базы. Ну и можно в бекграунде чистить

Ну или сначала чатрум скрывать, а удалять только после удаления всех документов

Зачем удалять?

Он не мешает консистентности базы. Ну и можно в бекграунде чистить

просто мусор набирается... а чистить чёт не каеф, считай в определённом интервале проходить по ВСЕМ chat page документов, проверять их ID и определять, удалять или нет

Флаг поставил в чятруме. А сообщения роботам скормил. Они за это могут всякой смешной бигдаты наварить

Не понимаю зачем в 2017 году данные удалять.

Ну или сначала чатрум скрывать, а удалять только после удаления всех документов

мы в принципе не можем определить "удаление всех релевантных документов" по причине отсутствия транзакций

мы в принципе не можем определить "удаление всех релевантных документов" по причине отсутствия транзакций

Зачем удалять-то? Флаг добавил и по нему отфильтровал

ну хотя если флаг ставить именно в chatroom документе тогда да

типа archived: bool

Именно

Вот, кстати, @dd_bb дело говорит. Зачем удалять вообще?

тогда операция атомарна

согласен, да, оставляешь page'ы, атомарно ставишь флаг archived и готово

отлично, ну вроде как всё встало на свои места, спасибо!

привет всем. резко перестала работать и монга и млаб. в чем прикол?

убунта, сервер на ноде

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

ничего не обновлялось. систему перегружал. старый рабочий 100% проект пробую - та же срань

я в шоке

сука. заработала. НИХЕРА НЕ ДЕЛАЛ

это пиздец какой-то, ебанное гавно монга

кто-то пробовал RethinkDB?

😂

это пиздец какой-то, ебанное гавно монга

Ты серьезно прикатился в чат чтобы изречь вот это?

Ты серьезно прикатился в чат чтобы изречь вот это?

монга во всем виновата же, очевидно

Ребят, а то, что в db. printSlaveReplicationInfo() и в rs.status() периодически проскакивают отрицательные числа - это норма или стоит беспокоиться? NTP есть.

у меня тоже бывает, единица обычно, ничего такого

Ребят, а то, что в db. printSlaveReplicationInfo() и в rs.status() периодически проскакивают отрицательные числа - это норма или стоит беспокоиться? NTP есть.

Норма.

NTP — eventually consistent, так что есть шанс что в единицу времени у тебя дрифт между нодами ненулевой

Но не в секунду же или даже больше

В секунду и даже больше ;)

Каждая из нод отстаёт от источника точного времени на 500мс, но с разным знаком. Дельта между нодами уже секунда

Дрифт в секунду и больше разве норма? Особенно если стоит свой ntp сервер ( а то и два) в своей подсети с нодами

Ох

Всем CAP теорему в этом чяте.

Прочитана

Толку то

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

Стоп, разве ntp клиент не меняет локального времени машины?