Если надо хранить данные только 30 секунд, то, может, имеет смысл не нагружать лишний раз БД и хранить данные в, например, Redis? Там можно установить время жизни данных

Redis тоже БД :)

Пару минут назад как раз о Redis подумал.

Redis тоже БД :)

Безусловно, но более легковесная. Можно ещё memcache прикрутить

С Redis поприятнее как по мне.

Наверное потому, потому что ни разу с Mem... не работал.

К примеру таким образом: db.codes.ensureIndex( { "createdAt": 1 }, { expireAfterSeconds: 30 } )

А решение правильное? :)

Ладненько, доберусь, проверь сам.

Раз уж зашла тема, поясните что лучше Редис или Мемкешд? Производительнее/удобнее

Удобнее Redis. Это то, что знаю.

Знаю, слышал, видел.

Безопаснее от части.

Раз уж зашла тема, поясните что лучше Редис или Мемкешд? Производительнее/удобнее

Memcache удаляет данные совсем, если нет места. Redis в таком случае пишет на диск Оба хранят данные изначально в оперативной памяти

Memcache удаляет данные совсем, если нет места. Redis в таком случае пишет на диск Оба хранят данные изначально в оперативной памяти

Да, если Redis настроить :) а так все потерять может в критических обстоятельствах.

А по скорости?

Не могу ничего сказать.

Могу только в Google отправить :)

Кому интересно

https://anton.logvinenko.name/ru/blog/redis-vs-memcache-vs-memcached.html

Коль

https://storage.googleapis.com/themarket-sitemap/sitemap.xml

Кто нибудь знает, индексы по массивам в документах нормально в монге отрабатывают?

смотря что в массиве лежит, если просто числа/строки, то нормально

ну и смотря что считать нормальным

Есть документ entries[].tokens[].token

{ "v" : 2, "unique" : true, "key" : { "entries.tokens.token" : 1 }, "name" : "entries.tokens.token", "ns" : "demo", "sparse" : true },

Индекс

Кто нибудь знает, индексы по массивам в документах нормально в монге отрабатывают?

А что считается «ненормально»?

У меня COLLSCAN был в explain. Сейчас понял, что это я накосячил в запросе

Да у меня блин проблема. Монга сжирает всю память (16 гигабайт). Куда можно посмотреть, что память утекает? Есть мысль что слишком много течет в in-memory cache. Но подтвердить это как то не получилось

https://docs.mongodb.com/manual/reference/configuration-options/#storage.wiredTiger.engineConfig.cacheSizeGB

Я это читал

Можно пояснить?

Свой ответ

@dd_bb якорь в ссылке не отработал. Это я тоже читал, но мне нужно не ограничить кеш, а убедиться для начала, что проблема именно в этом

разве, уменьшив кэш, не получится подтвердить, течет ли монга в него или нет? если уменьшите кеш до 8 гб, а монга будет продолжать жрать 16 гб, значит, проблема не в нем (или не только в нем)

@dd_bb якорь в ссылке не отработал. Это я тоже читал, но мне нужно не ограничить кеш, а убедиться для начала, что проблема именно в этом

если данных больше 16гб, то конечно это нормально

кроме кеша WT ещё есть дисковый кеш

free -m, rss у mongod и вот это всё

опционально: https://github.com/y8/mongo_collection_exporter

опционально: https://github.com/y8/mongo_collection_exporter

Оно тебя съест!

кроме кеша WT ещё есть дисковый кеш

это смотрел, дисковый кеш со временем отпускает, и все пространство заполняет rss

щас еще один контейнер ебнется )

просто написано что этот кеш занимает не больше 50% RAM

чего тогда он все схавал?

если это в контейнере, то лучше выставить размер кеша руками.

хотя в целом не очень понятно что у тебя происходит

@dd_bb

@yarossl ?

он уже не ответит

надо было ro

зачем?

раз теперь так можно

украл, выпил, в банлист

а смысл?

ну ок :)

вообще чот в телеграмме второй день дискотека, как в ирц

Оппа: https://jira.mongodb.org/browse/SERVER-27848

в 3.6 будут хинты для агрегаций!

Оппа: https://jira.mongodb.org/browse/SERVER-27848

Оппа, mongo style! 🕺

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

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

глазами посмотреть в https://github.com/y8/mongo_collection_exporter

там есть cache usage per collection / per index

ну и активность кеша по коллекциям/индексам

Да вот чет на проде страшновато что то непонятное подключать :)

оно по своей сути делает три операции: listDatabase, listCollection и collStats. ну и ещё из local.oplog.rs читает последний и первый документ.

экспортер никуда не пишет, ей хватит clusterMonitor роли (как у mms), плюс listCollection на db: '', collection:'' и cluster: true и find в local.oplog.rs

о, сюда положу, пока до документации не добрался: #exporter #roles db.createRole({ role: "grafanaExporter", privileges: [ { resource: { db: "", collection: "" }, actions: [ "listCollections" ] }, { resource: { cluster: true }, actions: [ "listCollections" ] }, { resource: { db: "local", collection: "oplog.rs" }, actions: [ "find" ] } ], roles: [] }) db.grantRolesToUser(<username>, [ { role: "grafanaExporter", db: 'admin' }, { role: 'clusterMonitor', db: 'admin' } ])

Класс. Спасибо

У меня есть mongoose схема Post для статей в блоге Как мне сохранять текст из textarea, чтобы выводить потом текст по абзацам ? 1) делать массив через split('\n') и сохранять в монго как массив строк(абзацев)? или 2) делать массив после получения текста из базы и передавать на страницу отдельно ?

Сохранять текст с \n или жарить в редис и хранить ключи... И не в монге :). А вообще вопрос не по теме

Хватит топить за редис

Это как вариант. Просто кусок html там хранить. Можно выбрать и другое хранилище - я работал с этим, мне понравилось

Сохранять текст с \n или жарить в редис и хранить ключи... И не в монге :). А вообще вопрос не по теме

исходить их того что в монге лучше хранить так, как ты будешь читать. Т.е. необходимые трансформации лучше делать при вставке. Разбивка на параграфы не очень сложная трансформация. Если в дальнейшем «параграфы» останутся только эфемерная еденицей, то можно вообще хранить as is и разбивать на параграфы уже при чтении. Если параграфы будут использоваться шире чем просто «отобразить», то есть смысл подумать о том как именно они будут использоваться и исходя из этого выбрать наиболее эффективную схему. Массив строк или массив документов

Это как вариант. Просто кусок html там хранить. Можно выбрать и другое хранилище - я работал с этим, мне понравилось

Это чят про монгу, а не про редис. Если у тебя нет весомых аргументов почему для этой задачи лучше использовать другое хранилище, то не надо его совеовать. «Мне понравилось» не аргумент совершенно.

исходить их того что в монге лучше хранить так, как ты будешь читать. Т.е. необходимые трансформации лучше делать при вставке. Разбивка на параграфы не очень сложная трансформация. Если в дальнейшем «параграфы» останутся только эфемерная еденицей, то можно вообще хранить as is и разбивать на параграфы уже при чтении. Если параграфы будут использоваться шире чем просто «отобразить», то есть смысл подумать о том как именно они будут использоваться и исходя из этого выбрать наиболее эффективную схему. Массив строк или массив документов

в смысле «массив вложенных документов». ну или вообще каждый параграф в отдельном документе хранить (если тексты могут быть больше ~16Мб)

Огонь, кеш помог

Видимо докер просвечивал память хоста как объем выделенной памяти

15 из 16 гб данных под кеш это нормально?

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

При репликации, например