да

Можно я еще позадаю, если будут? )

нет

сами проходите :)

Понял принял

не пройдёте, приходите, поможем

Короткие поля ммм

Всякие метрики так хранят и отдают по апи

не кажется ли вам, что это экономия на спичках ?

В больших масштабах экономия на спичках не может быть заметна?

не кажется ли вам, что это экономия на спичках ?

когда у тебя 10Тб, не кажется

В больших масштабах экономия на спичках не может быть заметна?

а есть какие-нибудь статейки (или свои данные) с графиками/статистикой типа: "сидели горевали, потом на спичках поэкономили и все полетело" (ну я утрирую конечно, но суть ясна)

можно на таких вот спичках до 25% экономии получить

оно никуда не полетит

скорость от этого практически не меняется, меняется объём хранилища

хорошо резервируемое хранилище стоит _очень дорого_ за гигабайт

очень дорого это доллары за гигабайт

или даже десятки долларов

например если нам нужно хранилище с горячим резевированием в нескольких регионах

и в нескольких АЗ на регион

да-да

и тут когда мы можем из 10Тб сделать 9Тб, мы можем получить например -10-15к в год

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

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

(если конечно под рукой они)

ну тут не статьи, но изза кривой начальной архитектуры и недальновидности, получили что в трех отдельных нодах лежало 5Тб данных без репликаций и бекапов. После принятия факта проблемы, заделали шард, перепелили структуру данных, вынесли часть логики на эластик. в результате чистых данных около 2Тб на шардированном кластере + реплики. Собственно задействовано новых 4 сервака+под монгос нормально дышащих, вместо старых 3 еле шаволящихся.

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

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

когда уже сделают sharded indexes

или index-only ноды

да хоть и такие есть, собственно по этой инсталляции я прикидывал что на индексы, чтобы прям помещались надо 1:10, потом тупо дропнул один из них

стало 1:20

даже 1:40 сейчас проверил, 100Гб индексов на 4.5Тбданных

хорошие у вас данные

а сколько документов?

3млрд

100 гигов это вместе с _id?

да

43Гб на _id

22 на шард ключ

1.5кб на документ

нормально

да

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

стата?

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

типа првоерка приходил док или нет

электронный документооборот?

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

наподобие

клёво

доки толкьо добавляются, так что можно и так назвать

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

ну тут не статьи, но изза кривой начальной архитектуры и недальновидности, получили что в трех отдельных нодах лежало 5Тб данных без репликаций и бекапов. После принятия факта проблемы, заделали шард, перепелили структуру данных, вынесли часть логики на эластик. в результате чистых данных около 2Тб на шардированном кластере + реплики. Собственно задействовано новых 4 сервака+под монгос нормально дышащих, вместо старых 3 еле шаволящихся.

круто, спасибо, что поделились опытом )

в итоге и было решено тупо оставить как хранилище, без случайных запросов

а да диски обычные HDD, поэтому только хранить)))

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

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

Можно включить db.profile

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

https://github.com/dtruel/mongo-live-logger

ок, спасибо за оба совета!

Привет! При перезапуске(первом запуске) nodejs - tailable cursor возвращает все документы из capped коллекции. Как можно получить только новые документы, без документов, которые были уже получены ранее? Вот код получения курсора: dbutils.sub = function(filter){ return ps.find({filter:filter}) .lean() .tailable() .cursor(); } подписываюсь на новые документы так: dbutils.sub() .on('data', doc => console.log('on doc', doc));

в фильтр добавить условие

Как правильно написать валидатор масива строк? Пишу просто { “category”:{$type: ‘array’}} пишет validation failed

_id в Mongodb уникален на всю базу или только внутри коллекции?

Such an id must be unique for each member of a collection;

Such an id must be unique for each member of a collection;

то есть он уникален только внутри коллекции?

Там не сказано что он не уникален на всю базу

id уникален внутри коллекции

как и id в таблицах реляцыоных бд

коллекции ~ таблицы (если брать идею)

точно?

Он уникален в пределах primary index, как и в любой БД.

можно ссылку на это в доке? найти не могу

https://docs.mongodb.com/manual/core/index-unique/

A unique index ensures that the indexed fields do not store duplicate values; i.e. enforces uniqueness for the indexed fields. By default, MongoDB creates a unique index on the _id field during the creation of a collection.

так там же id формируется что-то типа дата-мак-пид-сам_инкрементируемый_ид

Никто не мешает писать свой.

только не так часто это нужно

это же свойство _id, т.е. по соглашению не стоит менять