Это правда что для монги 64битная ось нужна? Удалось поставить 2.x.x какую-то там

Сильно она прожорлива по памяти? 512мб хватит для небольшого проекта? Но с частым обновлением данных прям очень и соответственно с чтением. Так же с большим трафиком

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

если не секрет, какой у кого трафик и на сколько монга загруженна, на каком сервере и как она вообще в деле

Траффик большой - и это самое узкое место у нас

А где вообще встречаются 32-битные оси

у меня небольшая vds'ka

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

Это правда что для монги 64битная ось нужна? Удалось поставить 2.x.x какую-то там

Wired Tiger требует 64, можно собрать из сорцов, без тигра, но там до версии 3.2 вроде

Но зачем?! За три бакса у овх можно взять 64 битную виртуалку с 2гб оперативы

Но зачем?! За три бакса у овх можно взять 64 битную виртуалку с 2гб оперативы

На arm?

А нет...прикольно

А есть чат по mongoose? А то здесь оффтопик будет, наверное.

Хотя все-таки попробую. Если у меня есть вложенные документы и я хочу по ним поиск делать по их id. Имеет смысл создать отдельную коллекцию со ссылками на id родительского документа? Или просто индекса на вложенный документ хватит?

А есть чат по mongoose? А то здесь оффтопик будет, наверное.

Не слышал о таком.

Господа, а кто нить пробовал использовать mongo in memory как замену memcached/redis ?

мм

а для чего

что ты там хранить собираешься?

то что сейчас храню в мемкеше.

результаты выборок из базы данных

тебе недостаточно тех структур данных которые предоставляет редис/мемкеш?

достаточно. но резервирование не радует

ну и по всёй видимости надо использовать не монгу а percona mongo

Привет. Это нормальная практика, когда таскаешь uuid записей в другие документы? Типа внешние ссылки в sql

Это звоночек что на самом деле нужна была sql

А если нужен сразу sql и document store? Использовать сразу две технологии?

Господа, а кто нить пробовал использовать mongo in memory как замену memcached/redis ?

Раз нужны быстродоступные данные в памяти то почему бы не использовать структуры данных на сервере, list, map, граф и др любой сложности, а базу использовать для сохранения на диск. Зчем выносить их во внешний redis огранниченный по функциональности?

А если нужен сразу sql и document store? Использовать сразу две технологии?

Сразу две не нужно

Сразу две не нужно

Есть разные кейсы

Есть разные кейсы

Расскажи про свой

Есть мероприятие и список участников, сейчас сделано так, что в мероприятии хранится список участников и их статусы (собирается посетить, не придет итд) и чем больше участников, тем жирней объект. В реляционке было бы две таблицы и только в том случае, когда мне нужны все участники, я бы лез в другую таблицу или делал бы джойн для получения кортежа: айди мероприятия, название, кол-во участников по какому-то критерию

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

Классический кейс для sql базы

И в этом же приложении есть "анкета", с большим кол-вом атрибутов, которые удобно хранить в одном документе и у них нет внешних зависимостей

И в этом же приложении есть "анкета", с большим кол-вом атрибутов, которые удобно хранить в одном документе и у них нет внешних зависимостей

На сервере сериализовать анкету в json и хранить в текстовом поле

в постгресе?

а то мускуль не особо в джейсон умеет

Про постгрес думал, но пока не дошли руки

Сериализовать в json не хочу, т.к. есть поиск по полям, например find({$exists: "age"})

а то мускуль не особо в джейсон умеет

Если внутри базы по полям анкеты не нужно делать запросов - то неважно, в любой sql базе

ну судя по всему нужно

поэтому приволокли монгу

Да, поэтому и не только, плюс еще удобная поддержка драйвером полиморфизма. У меня .net

На sql такое раскладывать очень обломно

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

По факту мне связи нужны только в одном-двух местах на всем проекте, но они performance critical

На sql такое раскладывать очень обломно

зато быстро

зато быстро

в чем скорость?

в sql ты тоже можешь подобие find({$exists: "age"}) запилить

age is not null

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

а в sql доступ не по ID ? лол

а в sql доступ не по ID ? лол

кол-во атрибутов заранее неизвестно, это не одна таблица с 25 столбиками

и что мешает в том же постгресе расширить это типом JSONB ?

и что мешает в том же постгресе расширить это типом JSONB ?

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

ой да ладно это делается менее чем за неделю.

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

ЛОЛ

у меня был опыт

По-моему слишком смелое заявление без знания кодобазы

мышки плакали кололись но упорно ели кактус :)

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

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

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

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

И что в итоге? Вернулись?

нет

остались

просто удалили монгу )))

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

Было бы все так просто) у меня перформанс хаки завязаны на патчи в монге, придется код лопатить нехило, плюс npgsql (.net драйвер) местами очень мерзкий

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

Потому что ну невыносимо было этим пользоваться

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

кол-во атрибутов заранее неизвестно, это не одна таблица с 25 столбиками

В sql можно к анкете присавокупить поле с метками которое проиндексировать и по которому быстро фильтровать анкеты.. В обоих мирах есть решения, тут скорее вопрос про дальнейшее развитие проекта, в какой парадигме его удобнее дальше наращивать

Было бы все так просто) у меня перформанс хаки завязаны на патчи в монге, придется код лопатить нехило, плюс npgsql (.net драйвер) местами очень мерзкий

А сколько анкет в ьазе? Какая скорость выборки

Сейчас скажу

~300 тысяч, объект в среднем 48кбайт

premature optimization as is

premature optimization as is

Опять-таки преждевременное заявление, не понимаю зачем так говорить

Что выбираешь и за сколько мс это происходит?

Есть набор перформанс тестов в apache jmeter

Что выбираешь и за сколько мс это происходит?

К этой коллекции сейчас доступ в основном по id + кеш, здесь нечего оптимизировать пока что

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

Кеш и сокращение обращений к данной коллекции решило проблему, сейчас есть коллекция, в которую чисто аппендится новый стейт, там 8.5млн объектов, там была только проблеа с group, но я вроде решил и это

Хотя, может подскажете решение лучше

Сформулируй вопрос

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

.aggregate([ { $match: { eventid: 12345, categoryid: 25 } }, { $sort: { created: -1 } } { $group: { _id: "$questionid", state: { $first: "$answerText" } } } ])

Индекс такой { eventid: -1, categoryid: 1, created: -1, questionid:1 }