c $expr 6 секунд с $where 43 секунды

это нормально вообще?

да

я молодец что переписал? можно меня похвалить?

можно

))

какая же монга крутая кайф

если вы будете сразу писать в базу following * 2 у вас запрос вообще без математики будет

я думал об этом изначально, но так нельзя

пользователь захочет и на 3 и на 4 и на 5

а что это вообще?

подписок в 2 раза больше чем подписчиков

детектим ботов короче

а может просто коэффициент писать?

и его уже выбирать типа больше 2

а вот это офигенная идея

и это тоже да

добавил фолловера - обновил коффициент

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

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

в рамках одной

в рамках одного документа

тогда @yatoba очень прав — считайте при обновлении

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

ну короче я понимаю, монгой лучше ничего вообще не считать

это не монгой, это любой базой

просто заранее понять что посчитать нужно невозможно сначала собираем базу, потом смотрим и думаем, в этом и беда вся

тогда не стоит вписываться в шардинг

Ок, если не шардинг, то как тогда хранить большие объемы данных и иметь возможность горизонтального масштабирования? Или строить что-то типа ceph и давать монге блочные устройства? Просто избыточность сильно большая получаеться.

никак не планировать вообще

и не надо ceph в монгу

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

сейчас в сервер можно полтерабайта памяти воткнуть

три сервера с полтерабайта всё равно будет операционно дешевле чем бекапить шардированный кластер из пары десятков нод

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

До террабайта я думаю я на mongos ноде могу и монгодампы делать ;-)

вам не нужен шардинг

шардинг — ОЧЕНЬ дорогое с точки зрения операционных затрат удовольствие

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

вам не нужен шардинг

Тогда вопрос, когда данные будут over50tb как масштабировать?

вы читаете между строк

ещё раз: когда данных нет, шардинг не нужен

99% бизнесов умирает в первый год

так что шанса что там будет 10тб практически нет

это как делить шкуру мертвого медведя

Ну как бы бизнес живой (это не стартап) и он просто меняет архитектуру.

тогда ещё раз: сколько сейчас данных

и какой у вас бюджет

Речь идет о примерно 120Tb реальных данных.

План поднять на 9 серверах.

Плюс монгос, плюс конфиг реплика сет.

вам это не надо

это очень дорого

а, тьфу, терабайт

тогда надо! а что в текущей архитектуре не устраивает?

походу лучше спросить как текущая структура устроена

а вообще, https://db-ai.co, приходите. я вам помогу сделать это экономически целесообразным

а вообще, https://db-ai.co, приходите. я вам помогу сделать это экономически целесообразным

Хорошо. Спасибо всем еще раз за теорию. Попробем на тестовом стенде, если что - знаем куда идти. Еще раз спасибо ;-)

идти лучше сейчас

потому что топология без привязки к тому как вы оперируете данными — неэффективная стратегия

плюс топология меняется очень легко, а вот шард ключ — очень тяжело

9 серверов вероятно не самый оптимальный выбор, потому что 2 реплики на 120тб это 60тб на реплику, это очень много. даже если у вас индексы в 1% от данных, это уже 600Гб.

Хорошо. Спасибо всем еще раз за теорию. Попробем на тестовом стенде, если что - знаем куда идти. Еще раз спасибо ;-)

а расскажите как оно сейчас у вас стока хранится и хотя бы образно каки задачи решаеются с таким объемом данных

@dd_bb я во вчерашнем решение немного проапдейтил - теперб юзаю mongoose.connection.readyState: https://gist.github.com/MaxVinogradov/117dd7784447c8768da7b406a7dee559 и теперь ко вчерашней рандомно падает +1 ошибка: MongoError: no connection available for operation and number of stored operation > 0 File "/opt/nodejs/node_modules/mongodb-core/lib/error.js", line 43, col 12, in Function.create return new MongoError(options);

на графике атласа смотрю что там ещё дофига можно коннекшенов поднять

Так вы не сохраняете соединение же.

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

Так вы не сохраняете соединение же.

а разве монгуз не кешит у себя соединение?

я залогировал - mongoose.connection.readyState === 1

Я не знаю как устроен монгус, но судя по этому чату — очень плохо :)

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

Возможно в монгусе тоже так, и он лениво инициализирует подключения, но в этом случае промис, наверное, вообще не нужен.

Возможно в монгусе тоже так, и он лениво инициализирует подключения, но в этом случае промис, наверное, вообще не нужен.

ок, но это не объясняет этой ошибки. даже двух

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

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

каким образом я это сделал =)?

какой пропертёй?

каким образом я это сделал =)?

bufferCommands: false, bufferMaxEntries: 0,

bufferCommands: false, bufferMaxEntries: 0,

до это их не было . и сейчас убрал

вот думаю насколько фиговая идея подымать конекшен на каждую лямбду, а потом тушить его, не кешируя

так себе идея

ваша проблема начинается с таймаутов https://github.com/mongodb-js/mongodb-core/blob/master/lib/connection/connection.js#L250

вероятно между вызовами хендлеров проходит больше времени чем позволяет таймаут