LINUX.ORG.RU

Сколько массив будет в памяти

 ,


0

3

Есть схема с полями-массивами [Schema {uid: ObjectID, createdAt: Data}], где-то 10 массивов, типа друзья(+100), подписки(100+), сообщения (1000+), их размер контролируется приложением, то есть расти безусловно не могут, но не могу понять исходя из чего выбирать ограничение. Сейчас я тупо 100 поставил. Вопрос в том, что при выборке документов все эти массивы гоняются туда-сюда, иногда они нужны, иногда нет. Потом я сделал в конкретном запросе явную выборку select с указанием какие массивы мне нужны в данный момент от сервера получить с документом. Уже лучше! Потом я подумал и посчитал что негоже гонять целый массив, например если в запросе мне нужно получить список файлов определенных размеров, но фильтрую ещё и конкретный массив (типа $filter в агрегате).

Но тут посмотрел как монга выдернула мне 122 000 документов за 5 сек. и поместила результат в память (это я увидел в дебагере webstorm при ошибке в коде, кстати он бесплатным стал). К сожалению не смог понять сколько заняли эти документы в памяти, это не тривиальная штука как гуглежка показала. НО- вроде ничего не опухло, не застряло... Так вот я думаю, правильно ли я делаю, стоит ли заморачиваться с этими select*ами, фильтрацией в каждом запросе или тупо весь документ со всеми потрохами запрашивать? Вопрос в использовании памяти и как повлияет это на нагрузку. Интересует как это на практике у кого вылезает, не синтетические тесты

Ну и плюс к тому, есть демон, он хранит одновременно порядка 1000 загруженных mongo-документов. Есть массив в домументе, который потенциально может содержать 5000 элементов (а то и более). Вот я думаю хранить его постоянно или нет. Понятно что тесты нужны, но в данный момент хотелось бы услышать как делают такие вещи на практике

★★★★

Зависит от того что ты делаешь. Если это какое-то web api, то 5+ сек на ответ это неприемлемо долго. Делать или не делать перечисления списка полей зависит от того сколько документов за раз ты выбираешь, какая у них структура, нужны ли эти поля для выполнения запроса, нагрузки на этот код

cobold ★★★★★
()

Смотря что за данные, как часто меняются, как часто они нужны, какой отклик нужен. Если это полу-статика типа списка товаров в магазине который меняется раз в неделю и вызывается по несколько раз в минуту - можно и в память засунуть и повесить watch чтоб подтягивать изменения. А если данные меняются непрерывно или нужны редко - нужны очень весомые аргументы чтоб держать их в памяти

upcFrost ★★★★★
()

Так вот я думаю, правильно ли я делаю

давай предположим, что вместо монги ты решил хранить данные в каком-то другом виде - в реляционной СУБД, в колоночной СУБД или еще как-то. Оцени, улучшится ли твоя архитектура в результате такого изменения. Если да, то ответ очевиден - ты делаешь неправильно.

FishHook
()

тупо весь документ со всеми потрохами запрашивать

Первое правило для любой СУБД - доставай только то что тебе нужно.

anonymous
()
Ответ на: комментарий от qulinxao3

жаль Автор тахионы словил от вашего сообщения позавчера окончательно

вот ты смотрел например, турецкий народный киберпанк «Отряд 2069 2034» ?

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

и полный бандустан виртуальной реальности.

очень рекомендую. жаль там всего ~8 серий, требую продолжения банкета.

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

anonymous
()
Ответ на: комментарий от qulinxao3

еще смешной индийский народный киберпанк, например, какой-то фильм про терминатора по индийски.

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

anonymous
()
Ответ на: комментарий от qulinxao3

indijskie-filmy-pro-kiborgov

top-8-sci-fi-india

pikabu.ru…vstavay_samuray_v_indii_kiberpank_snyali_10729635

обучающее видео: 65f6f067bda04d58fb9744fb или просто погугли по «Индийский терминатор»

им вообще-то можно просто махабаратху какую-нибудь экранизировать или рамаяну или виманику шастсра на 10500 серий, но там другое.

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

робот 2.0.

anonymous
()
Ответ на: комментарий от qulinxao3

Сколько массив будет в памяти

здесь при том, что там наверняка индусокод в прошивке робота 2.0 и stack overflow и buffer overrun

полный срыв стека головного моска

anonymous
()
Ответ на: комментарий от qulinxao3

вот, кажется это вот эта нет.ленка:

индийский фильм робот 2010г фантастика боевик

кто напомнит, как оно называлось на IMDB на самом деле?

а может есть какой-то kinopoisk ил rotten tomatoes для непризнанных шедевров болливуда?

робот 2.0 робот 2010 война робатофф и прочее такое всякое разное

типа, там есть настоящие перлы… а мужыки-то не знают :)))

anonymous
()