и данные?

Сделали вид, что монга их утеряла )

шикарный кейс переезда )

огонь да )

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

а какой кейс-то? я уже потерял основную нить

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

Что бы ускорить запросы: 1. ограничить варианты выборки по признакам до 20 -30 штук 2. заранее группировать по ним на стадии записи данных (а не на стадии выборки), т.е. иметь и поддерживать готовые группы которые моментально отдаются по запросу вот решение в стиле nosql насчёт переезжать на sql не факт что там будет в целом удобнее и быстрее, там возникнут свои проблемы

Что бы ускорить запросы: 1. ограничить варианты выборки по признакам до 20 -30 штук 2. заранее группировать по ним на стадии записи данных (а не на стадии выборки), т.е. иметь и поддерживать готовые группы которые моментально отдаются по запросу вот решение в стиле nosql насчёт переезжать на sql не факт что там будет в целом удобнее и быстрее, там возникнут свои проблемы

по пункту два: т.е. мне сделать, условно говоря, документ-аггрегат, где будет в качестве айди признак и вложенный массив со значениями? а вставлять не insert в коллекцию, а update({}, {$push}) в документ?

по пункту два: т.е. мне сделать, условно говоря, документ-аггрегат, где будет в качестве айди признак и вложенный массив со значениями? а вставлять не insert в коллекцию, а update({}, {$push}) в документ?

да, то что ты собираешься моментально отдать - должно уже быть в готовом виде всвязи с этим видимо прийдётся ограничить разнообразие поисков. и расчитать варианты заранее —--------- другое решение, менее напряжное, но которое ты видимо уже используешь это кеширование. Т.е. первый запрос медленно посчитали и положили в кеш, второй такой запрос отдаётся быстро из кеша. из минусов - первый запрос тормозит - данные в кеше стали не актуальными (добавились ещё анкеты)) —--- какой вариант оптимизации применять - зависит от структуры данных и структуры запросов

ммм, спасибо

а если

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

и продолжать также писать во вторую последовательно

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

это рабочий nosql-like подход?

избыточность - это норма для nosql решений

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

единственное, что парит в третьем варианте это удвоенное кол-во записей

точнее вместо insert будет insert в одну+ update во вторую

но здесь я так понимаю уже нагрузочные тесты покажут что эффективней

сейчас терабайтные дисковые массивы, а у тебя анкета 48кб )

я бы ещё это расчитанное - в пямяти бы хранил !

да, я бы тоже, но у меня несколько серверов (одни пишут, другие читают)

если только в редис класть

рассчитанное

в принципе тоже идея

что за проект, он в продакшене ?

образовательная система

в продакшене, уже года два

и заказчик обозначил перформанс как требование

плюс сокращение расходов на железо

А сколько сейчас серверов ?

три веб-сервера в лоад балансере, два почти всегда выключено

и 5-6 процессинг-серверов

где-то 4 работает обычно

там elastic load balancing у aws

на чём написаны ?

.net

на основных сценариях один веб-сервер примерно вытягивает до 300запросов\сек, может больше, наверное

не супер хайлоад, конечно

а где эта система сейчас используется ?

страны т.е. какие?

я наверное не могу по нда сказать где именно)

по nda нельзя про структуры данных рассказывать )

да я толком ничего и не раскрыл

id, eventid, categoryid мало о чем говорит

народ, а кто-то замерял скорость поиска при использовании лукапа и последовательного поиска (то есть сперва готовишь список айдишников из внешней коллекции, а потом полученный массив подставляешь в фильтр фильтруемой коллекции) ?

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

Как ты надоел

зато быстро

И ты тоже. Что быстрее и где бенчмарки, с анализом вводных и результатов?

Короч, я всех участников дискуссии выше предупреждаю, особенно @CapDev и @dezconnect: прекратите с умным видом давать советы про sql/nosql. Вы оба не пытаетесь разобраться в чужой проблеме и предложить решение с документным подходом и начинаете советовать какую-то тухлую пежню. Бездумно топить за SQL и предлагать переписать существующий проект на пг за неделю идите в другом месте. Здесь мы помогаем решить проблемы с дизайном для документной субд. Если вы ее не осилили, сначала осильте, потом давайте советы. Это было последнее предупреждение, дальше на неделю в r/o.

1

Короч, я всех участников дискуссии выше предупреждаю, особенно @CapDev и @dezconnect: прекратите с умным видом давать советы про sql/nosql. Вы оба не пытаетесь разобраться в чужой проблеме и предложить решение с документным подходом и начинаете советовать какую-то тухлую пежню. Бездумно топить за SQL и предлагать переписать существующий проект на пг за неделю идите в другом месте. Здесь мы помогаем решить проблемы с дизайном для документной субд. Если вы ее не осилили, сначала осильте, потом давайте советы. Это было последнее предупреждение, дальше на неделю в r/o.

👍 справедливо

чат по монге, предлагают переехать на sql

прикольно =)

Ты нас покидаешь за хамство.

По озвученному вопросу. В дизайне данных есть два полюса: высокая нормализация (данные хранятся один раз в одном месте, все остальное ссылается на хранимые данные) и высокая денормализация (данные хранятся много раз, в нужных местах). Но нужно понимать что это не строго одно или другое, это шкала от одного до другого. Реляционные субд в целом эффективнее для работы с нормализованными данными, тогда как документные субд эффективнее для работы с денормализованными данными. На практике многие субд реализуют работу с информацией в двух формах с разной степенью эффективности. Выбирать решение нужно исходя из того как будет использоваться информация. Если информация часто обновляется и нужно всегда иметь актуальное на текущий момент состояние связанных сущностей — без ссылок не обойтись. Если информация не изменяется, то можно обойтись вложенными документами. Если нужна только часть информации, то лучше разделить её на несколько документов. В контексте монги, нужно понимать что классические паттерны из sql тут не работают. Если нужно many to many для динамических данных, то эффективнее нормализовать отношения, но не создавать связующий объект, а хранить указатели в массиве, в каждой из сторон ассоциации. Если данные immutable но их много и все они не нужны при запросе документа, их можно денормализировать, разделить на группы и хранить в отдельных документах. Для того чтоб выбрать решение, нужно понимать какие проблемы необходимо решить прямо сейчас, а не в будущем. Если проблема не понятна — выбирать решение которое проще реализуется и накапливать опыт, который уже использовать для улучшения схемы. Сделать идеальную схему невозможно. Лучше вложить силы в инструменты которые позволят безболезненно менять схему, чем тратить силы и энергию на попытку угадать проблему.

Дельно. Спасибо.

лучше вытащить две коллекции и на беке объединить

монга начинает провисать при поиске в связанных коллекциях

я бы сперва сделал запрос с сортировкой по ParentDirID (там где она null - это получится родительская директория) и в бэке перебирал массив

многомерный ассоциативный массив. где ключ - айди категории

думаю сперва стоит собрать дерево категорий

а потом распихивать по нему "файлы"

собери потом массив файлов вида {dir_id: {file_id: id, name: name}}

и потом этот массив файлов проще будет вставлять в содержимое дерева папок

Если бы ты с первого раза услышал и сделал materialized path, ты бы уже неделю назад решил свою проблему

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

Т.е. твоя проблема всё ещё в разделении папок и файлов на две разные сущности. Если ты объеденишь их в одну, то даже без materialized path тебе станет сильно проще вытаскивать куски дерева

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

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

В чем может быть проблема? Не работает (пишет Invalid command: --auth): pm2 start mongod -- --dbpath /home/data/db -- --auth Все ок: mongod --dbpath /home/data/db --auth

В чем может быть проблема? Не работает (пишет Invalid command: --auth): pm2 start mongod -- --dbpath /home/data/db -- --auth Все ок: mongod --dbpath /home/data/db --auth

перед --auth не надо ещё раз --

первый -- отделяет собственные аргументы pm2 от аргументов команды которую он запускает

т.е. когда я хочу передать параметры скрипту самому, то нужно лишь один раз поставить -- перед всеми аргументами, верно?

видимо да, так получилось, спасибо

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

так и надо через всяекие pm2 запускать?

systemd можно использовать для автостарта

народ, а в монге есть транзакции?

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

нашел только некий оператор $isolated