а ещё и стоимость его обслуживания, простоя и вот этого всего

ну в принципе да

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

я сейчас несколькими БД уже больше терабайта съел. боюсь атлас бы не поятнул такие

ну за относительно низкий прайс

наверное 2 варианта ок для облачных решений. нет денег - нет нагрузки. много денег - есть нагрузка.

атлас будет около тыщи стоить на такой конфигурации, без учёте трафика

на другом проекте на амазоне монга. но там база около 30Гб всего

если на обычных дисках

у нас ссд

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

коробки надо содержать, почти ежедневно

это да

девопс постоянно что-то делает

ну вот, а это минимум тыщи полторы-три баксов в месяц на девопса, только зарплаты

через salt рулит всей кучей коробок. я не знаю что это, только ansible юзал, вроде примерно то же?

ну вот, а это минимум тыщи полторы-три баксов в месяц на девопса, только зарплаты

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

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

В сериале Кремниевая долина в последней серии прошлого сезона как раз на эту тему была история, когда Amazon все деньги спалил к херам, даже глазом не моргнув, хотя оно может и быть не надо

Выстрелили на продукханте, и словиди продуктхант эффект, и получили счет приличный в конце месяца, а доходов сильно меньше, так как не всех удалось сконвертировать даже в бесплатных пользователей по разным причинам

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

это плохой техдир

вообще делать продукт надо после того как есть пользователи, а не до

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

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

вот текущем проекте так и есть )

но это всё после того как все убедились что проблема есть на рынке и потенциальное решение готовы купить даже на словах. потому что иначе разработка это просто выкинутые деньги на ветер. разработку должны оплачивать клиенты. например с балансировщиком я не буду никакого продукта делать, до момента пока не будет с десяток клиентов, которые дадут денег за первый месяц. все мои текущие разработки это исключетльно проверка технологической гипотезы, что то что я хочу продавать, реально можно сделать. это мой личный академический интерес, чтоб мозг не засыхал. потому что потратить полгода на разработку продукта, который потом никому не нужен, это вобщем-то ошибка №1. наверное 90% компаний именно по этому и умирают, прожигая огромную дыру в карманах фаундеров

только не техдир наверное а фундер

серваков 20+ вроде все четко фурычит. мне прям нравится. у меня несколько коробок под задачи с 128Gb памяти, чтоб я так жил на амазоне.

клиенты денег несут? :)

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

эт не важно

важно: несут ли или не несут денег.

а что в explain по find?

Обычный IXSCAN. Я по курсору могу сделать count и он терпимо по скорости отрабатывает. Внутри unix timestamp. Главная проблема в том, что рабочие запросы к базе не больше 300 ms должны выполняться в этот момент. А удаление сильно нагружает сервера и в диск база начинает упираться. А что профитнее: bulkwrite удаление 1000 элементов и sleep или по одному с небольшим слипом между ними?

Всем привет. Подскажите какой индекс для такого запроса нужен? db.drops.find({ date: { $gt: 1538320801723 } }).sort({ itemPrice: -1 })

в коллекции drops порядка 120 миллионов записей за пару лет накопилось

и такой запрос нужно раз в минуту выполнять хотя бы

выполняется примерно 250ms

Пробовал индексы date_1_itemPrice_-1, itemPrice_-1_date_1, пробовал два отдельных индекса

по логике нужен индекс {date:1 , itemPrice:1}, но все проще првоеряется через explain

Если в существующую коллекцию указать уникальное индексируемое поле, монга сразу начнёт её индексировать?

по логике нужен индекс {date:1 , itemPrice:1}, но все проще првоеряется через explain

перепробовал все возможные комбинации, ничего не помогает(

Если в существующую коллекцию указать уникальное индексируемое поле, монга сразу начнёт её индексировать?

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

перепробовал все возможные комбинации, ничего не помогает(

а что значит "не помогает"?

а что значит "не помогает"?

лучший результат — 200ms

так это норм

то есть я уперся в возможности btree?)

с чего вы решили что быудет лучше на коллекции в 100кк?

влажные фантазии :)

есть еще другой момент, что по нагрузке на железо в моменты запроса?

и да сделайте explain c executionStats

каждую минуту скачет

ой, нет, не это

каждый час выполняется

что синее, что зеленое?

где waittime?

нагрузка на диски мониторится?

да

с диском все ок, nvme raid

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

и он очень сильно грузит cpu, нарузка возврастает в 4-5 раз

вы хотите сказат ьу вас всегда больше 500iops

вы хотите сказат ьу вас всегда больше 500iops

это мониторинг говорит, а не я)

за 10 минут

а кто вам генерит1.5крпс?

это нормально?

в нашем юзкейсе это ок

много данных собираем с разных источников

на проц нагрузка небольшая

в среднем 1/2 от одного ядра жрет

чтения мало, в основном запись

ок, выполните explain и куданить на пастебин например

Обычный IXSCAN. Я по курсору могу сделать count и он терпимо по скорости отрабатывает. Внутри unix timestamp. Главная проблема в том, что рабочие запросы к базе не больше 300 ms должны выполняться в этот момент. А удаление сильно нагружает сервера и в диск база начинает упираться. А что профитнее: bulkwrite удаление 1000 элементов и sleep или по одному с небольшим слипом между ними?

Bulk это сетевая оптимизация. Просто группировка запросов в один большой пакет. Мне кажется эффективные будте если вы поделите timestamp на диапазоны которые удаляются в примерно устраивающее вас время и сделаете deleteMany по этому диапазону. Так будет открываться один курсор и сразу дропать документы. У вас сейчас получается N+1 запрос.

лучший результат — 200ms

explain({“executuonStats”:1}) Время будет зависеть от «ширины» выборки. Чем больше документов будет попадать в выборку, тем медленнее это будет.

вопрос: можно ли во время аггрегации после unwind и всех нужных мне действий как-бы отменить unwind? т.е. собрать все данные обратно в один документ массива?

group

И там чтонить по типа аддТуСет

ща гляну, спс

а, там немного не то

через него надо тогда прогонять все данные же

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

Укаже в качестве _id поле по которому группировать

Если вам надо вообще все по в один большой список, то в качестве _id задайте константу какуюнить

наверное мне больше подойдет $mergeObjects

хотя не

я не хочу все параметры прописывать :(

Давайте проще, приведите пример того что вы сейчас получаете и что нужно получить

там еще массив в массиве, да

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