atis //: ok, проблема в $regex, не используйте его на больших коллекциях. Под него индекс не строится, и происходит полный перебор.
Если нужен поиск по тексту то используйте текстовый индекс. Если нужен поиск каких-то ключевых слов, то можно сделать массив (с индексом) для этого.
Алексей Ярков: тут тоже нет кода работы с базой, вообщем монга не причем, кривой фреймворк или не правильное его использование.
попробуйте вызвать какую-нибудь функцию сохранения сессии.
Aristes: Какие вы запросы используете?
Если у вас во всех запросах есть фильтр по времени/дате, то можно все данные нашинковать под дням, либо часам - под каждый час своя таблица, итого один индекс можно выкинуть.
На поле bool вообще индекс не рекомендуется, т.к. каждое из двух значений будет содержать по пол базы. - трата памяти впустую, проще разнести все данные на 2 базы.
Далее если нужен разрез который не подходит под уже существующую шинковку, то можно просто сделать копию всех данных в новом разрезе, ssd дешевле чем ram.
Так же данные нарезанные по часам можно паковать, итого 55Гб могут превратится в 5Гб. А индексы уменьшаться до 100Мб, а может и ещё меньше.
При этом ещё будет профит - выборка может ускориться в 10 раз, за счет получения сжатых данных в пакетном режиме.
Эти советы хорошо подходят если вам нужно строить аналитику по данным.
Decadal: Если делается веб приложение, то лучше использовать какую-нибудь "высокоуровневую" либу, чем изобретать наколенный велосипед, т.к. без этого, примеры чуть сложнее могут вылиться в горы js.
И там 21кб передается, а не 67.
db.posts.update({'vote.user1': {$exists: false}}, {votes: {$inc: 1}})
по результату можно проверить прошла запись или нет, если не прошла - значит коллизия (двойное нажатие)
а на клиентской стороне кнопка будет просто не активна если пользователь уже проголосовал (это достается в одном запросе с постом)
Александр Вульф:
покажите мне пост на стековерфлоу где есть 100к голосов
даже если такие будут, и если они будут тормозить, то их можно будет поместить в группу особенных и обрабатывать по другому
если пробовать хранить компактно то это 100к * 3байта на юзера = всего 300кб
D_E_S:
tsvector - не индекс, это лексер (для него тоже индекс нужен)
Даже если индексы созданы, значит фильтры такие что psql их не использует, например если вы в запрос с tsvector добавите какое-то условие (create_date < $date или status = 7), то этот индекс уже может не покрывать запрос, и psql будет пробовать другие запросы или делать полный перебор. Делайте анализ запросов.
Самое простое с чего можно начать, собрать статистику длительности запросов, например если это веб, то добавить в логи nginx/веб сервера.
Далее спарсить логи и выявить самые тормознутые запросы, и их оптимизировать. Самые тормознутые запросы чаще всего и создают проблему.
fedot1325:
Не понял вопроса,
изменение проиндексированных полей изменяют индекс, индекс как работал так и будет работать, размер индекса влияет на производительность, без индекса будет тормозить.
