ибо я знаю что документ макс. 4мб весит

ты где-то не в том месте информацию берёшь

монга это фронтенд к хранилищу bson документов

в монге лимит на размер bson — 16 мб

хмм, окей

что там внутри этого bson — совершенно пофиг, главное чтоб было поле _id, значение которого меньше 1024 байт

т.е. если это другая bson структура, то опять-же, сериализированная в bson она должна быть меньше 1024 байт

к этим документам есть несколько разновидностей индексов

для того чтоб искать по _значениям_ аттрибутов внутри документа

угу, это понятно

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

я не устану повторять простую вещь: документы надо хранить так, как ты их будешь читать

понятно что должны быть разумные ограничения

зачем вытаскивать все 16 мегабайт ради 15 байт?

типа { members: [<user_id>] first: <datetime> last: <datetime> messages: [ { message: <text> author: <user_id> } ] }

max 50 message per document, or "page"

messages: [{t: DateTime, from: Boolean, text: String}]

хотя если надо по автору искать, то да, дублировать

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

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 теорему в этом чяте.

Прочитана