Anonymous
Я вот и призадумался.
Anonymous
Подожди, что ты имеешь в виду?
Anonymous
Несколько агрегаций по ID + timestamp, я чуть раньше сюда уже писал.
Anonymous
Несколько агрегаций по ID + timestamp, я чуть раньше сюда уже писал.
У нас берётся текущий timestamp, от него отматывается X дней и за это время запрашиваются данные.
Anonymous
Есть ещё поле Datetime, которое иногда используется если нужны таймзоны.
Anonymous
Ну если предположить, что они уже достаточно оптимизированы.
Anonymous
Просто объём данных растёт и будет расти дальше.
Anonymous
Как и в целом (т.е. в коллекции), так и в хвосте.
Anonymous
Если вчера запрашивали 10 ID, то завтра будет 11. И при этом сама коллекция, очевидно, тоже растёт.
Anonymous
Разве это не есть нормально, что время вычисления этой операции тоже растёт?
Anonymous
Является ли мысль хранения горячих данных в отдельной коллекции с TTL индексом хорошей идеей?
Тут мысль была такая, что будет быстрее работать с маленькой базой, в которой собирается весь хвост и удаляется по TTL.
Anonymous
Да.
Anonymous
И совокупный индекс id + timestamp.
Anonymous
И выборка вида.
Anonymous
И выборка вида.
id: $in {1, 2, 3}, timestamp: { $gte: XXXX }
Anonymous
Я переворачивал и делал индекс timestamp + id, медленнее работает.
Anonymous
Мы уже пробовали.
Anonymous
Примерно в два раза хуже.
Anonymous
То есть если я переверну индекс, все мои проблемы решатся?
Anonymous
id ts 1 4000 2 4001 3 4002 4 4003
Anonymous
Всё работает.
Anonymous
Поступают обновления на сервер, нужно пересчитать данные.
Anonymous
Пересчитать нужно за последние X дней.
Anonymous
Там есть кэширование последних X-1 дней, это сильно помогает, но всё ещё не решает проблему возрастающего времени выполнения.
Anonymous
Т.е. в сентябре 600 ID просчитывались за 100 секунд, а сейчас за 160.
Anonymous
😔
Anonymous
Проблема в том, что время выполнения растёт вместе с базой.
Anonymous
Это довольно логично, но хочется как-то это ускорить.
Anonymous
Так хвост тоже растёт.
Anonymous
В сентябре за последние X дней было 5 записей, сейчас 25.
Anonymous
По этим ID.
Anonymous
Я вот спросил, не влияет ли сам размер коллекции на время вычисления.
Anonymous
Не поможет ли производительности помещение хвоста в отдельную коллекцию с индексом по TTL.
Anonymous
И работа только с ней.
Anonymous
Основная коллекция тоже нужна - старые данные иногда подтягиваются, но это не рутинно, а по запросу.
Anonymous
Это база с аналитикой.
Anonymous
Добрый день! Смысл использования MondogDB в проектах.
Когда я изучал и разбирался с монгой год назад у нее были два огромных недостатка и я не понимал как люди могут выбирать эту базу - база данный которая предназначена для хранения документов в формате json - собственно вообще не умеет их хранить - я имею ввиду не умеет хранить валидный json с долларами и точками в свойствах. Ну и второй недостаток это размер документа в 16мб. В итоге вместо того чтобы просто сохранить валидный json одним вызовом функции как это происходит в нормальных базах данных (к примеру RethinkDB) я должен заботится и конвертировать свойства с точкой и долларом и думать о размере документа и разбивать его на несколько частей. Возможно что-то изменилось за последнее время поэтому поправьте если неправ.
Nikolay
Расскажите
Anonymous
Что за точка что за доллар
https://groups.google.com/forum/#!topic/json-schema/Nzh0sQP0uxQ https://stackoverflow.com/questions/12397118/mongodb-dot-in-key-name
yopp
но у тебя есть ошибка в суждении
yopp
«база данный которая предназначена для хранения документов в формате json»
yopp
A record in MongoDB is a document, which is a data structure composed of field and value pairs. MongoDB documents are similar to JSON objects. The values of fields may include other documents, arrays, and arrays of documents.
yopp
--> are similar to JSON objects <--
yopp
и данные теряет, да
Serg
А что за мем про "данные теряет"? )
Alex
Эт не мем, а очевидный факт же :)
Serg
А как повторить? )
Denis
Anonymous
Ребята, подскажите пожалуйста — как работает db.collection.createIndex(). Если мне нужен поиск по нескольким полям — я создаю индекс как db.collection.createIndex({field1:1,field2:1,field3:1,field4:1}). Насколько я знаю произойдет сортировка сначала по field1, затем по field2 и так до field4. А что если поиск нужно произвести только по field1 и field4 ? И, соответственно, индекс должен был бы выглядеть как: db.collection.createIndex({field1:1, field4:1}), чтобы произвести поиск быстрее. Нужно ли создавать индекс для каждого случая ?
Anonymous
nevermind. Я нашел в доке ответ. Если кому интересно (https://docs.mongodb.com/v3.2/core/index-compound/#prefixes)
Cocaine
посоветуйте какие вопросы про монгу можно задать человеку чтобы понять что он не дундук в ней?
Serg
Почему она данные теряет
Serg
:D
Stepan
=))
Serg
Я думаю базовых задач из юнивёрсити будет достаточно.
Serg
И вопросы там есть
Serg
К каждой главе
Cocaine
спасибки
Sergey
Это все элементарно забывается, если не ковыряешь базу каждый день
Pavel
почти каждый день работаю с монгой и периодически лажу в доку, чтобы обновить какие-то знания
Denis
Кстати, а у всех шард кластеры с репликами да ?
Vadim
Почему она данные теряет
а кстати, почему? не объясните верстальщику
Alex
А что такое реплики ?
yopp
Это все элементарно забывается, если не ковыряешь базу каждый день
вот по этому и спросить как менять шард ключ :)
Alex
Вот лучше скажите как корректно поднять кластер в докере, есть готовое решение ?
Alex
Чтоп раз такой, докер файл исполнил и у тебя реплики и все такое и отказоустойчивое
Alex
?
yopp
ахаха
yopp
statefull сервис в докере
yopp
ты группой промахнулся :)
Alex
Че это ? :) монга же нужна, стопудово есть сборочка
yopp
не важно
yopp
в докере всё, у чего есть «состояние» которое должно переживать смерть контейнера — ад и боль
yopp
простой ответ на твой вопрос: не надо пихать монгу в докер
Alex
Особенно видимо для монги
yopp
нет, для любой субд