в upgrade notes всё написано: как лучше апгрейдить репликасет/кластер

ок, изучу матчасть

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

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

3.2 до 3.0, емнип, тоже не откатывается

откатывается

точнее, что ты называешь «откатывается»

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

https://docs.mongodb.com/manual/release-notes/3.2-downgrade/

магия всё же нужна

Remove or downgrade version 3 text indexes before downgrading MongoDB 3.2 to 3.0. Remove or downgrade version 3 2dsphere indexes before downgrading MongoDB 3.2 to 3.0.

после апдейта до 3.2 апается версия индексов же

Ммм. Да, ты прав.

Печалька!

ничо, бывает

Всем привет! Скажите, а при создании индекса, {"background" : true} что он делает? И может подскажите где можно про принцип работы индексов почитать развернуто?

Всем привет! Скажите, а при создании индекса, {"background" : true} что он делает? И может подскажите где можно про принцип работы индексов почитать развернуто?

https://ru.wikipedia.org/wiki/B-%D0%B4%D0%B5%D1%80%D0%B5%D0%B2%D0%BE

Нет, мне другое. {"background" : true} то индекс создается во время внутренних процессов, поэтому если я быстро попробую обратится, то возможно индекс еще не будет создан? А если не будет этого ключа, то он сразу после вставки его создает, и индекс будет уже сразу?

background=true - вещь достаточно бесполезная, имхо. да, она позволяет не лочить мастер при создании индекса, но оно намного медленнее (из-за двух (минимум?) проходов по данным) и все-равно лочит слейвы

Опять же, если я ставлю экеспир по времени, то в какое время происходит удаление? и каким способом? Помечается как удаленная, или сразу удалятеся? В какоий момент тримится? МОжет ли создавать какие нибудь всплески io?

А где про это можно почитать более развернуто, а то не могу найти (

в исходниках

А в доке может быть есть где инфа?

https://docs.mongodb.com/manual/core/index-creation/#background-construction

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

Спасибо, буду читать

видимо совсем новичковый вопрос, но я не смог разобраться, хотя сделал как в доках http://pastebin.com/XwiD7cZB этот пример не выводит ничего в пимонго не получается запустить перегрузку языка если default_languge русский то не ищутся английские слова, и наоборот, если убрать установку дефолтного языка то находятся английские слова, но не русские

del

Всем привет, есть вопрос. Работаю с монгой через node.js. У объектов в БД есть поле date, где я храню дату в таком виде: 2017-01-23T15:25:45.573Z. Как мне выбрать все объекты, у которых в поле date указана дата 2017-01-23, независимо от записанного туда времени?

Всем привет, есть вопрос. Работаю с монгой через node.js. У объектов в БД есть поле date, где я храню дату в таком виде: 2017-01-23T15:25:45.573Z. Как мне выбрать все объекты, у которых в поле date указана дата 2017-01-23, независимо от записанного туда времени?

$gte + $lte ?

Всем привет, есть вопрос. Работаю с монгой через node.js. У объектов в БД есть поле date, где я храню дату в таком виде: 2017-01-23T15:25:45.573Z. Как мне выбрать все объекты, у которых в поле date указана дата 2017-01-23, независимо от записанного туда времени?

По граничным датам между 23.01 и 24.01

Или хранить дату отдельным полем

Хотя тут могут быть проблемы с таймзонами

спасибо за ответы, буду пробовать

Всем привет, есть вопрос. Работаю с монгой через node.js. У объектов в БД есть поле date, где я храню дату в таком виде: 2017-01-23T15:25:45.573Z. Как мне выбрать все объекты, у которых в поле date указана дата 2017-01-23, независимо от записанного туда времени?

Если это строка, то это одна история. Если дата то $gte/$lte

Если это строка, то это одна история. Если дата то $gte/$lte

это дата

Если это строка, то это одна история. Если дата то $gte/$lte

Если дата в iso (а она в iso, судя по примеру), то строки точно так же можно сортировать по gte + lt

Если дата в iso (а она в iso, судя по примеру), то строки точно так же можно сортировать по gte + lt

Сортировать то да. А вот фильтровать нет

Afaik

Регуляркой)

Хотя должна сортироваться

Сортировать то да. А вот фильтровать нет

Mongo имеет внутренее представление даты/времени, это как раз ISO. Этот тип индексируется, так что фильтровать можно.

Речь была про то, что дата может как строка храниться

А не как дата

А не как дата

@mak_tu явно строкой храните?

@mak_tu явно строкой храните?

я простою выполняю new Date() и сразу записываю

Если в запросе передается Date, то драйвер в node.js сохраняет как тип ISODate

Если в запросе передается Date, то драйвер в node.js сохраняет как тип ISODate

спасибо за инфу) $gte и $lte отлично работают

Лучше справа lt использовать, наверное

спасибо за инфу) $gte и $lte отлично работают

Главное индексы не забыть создать, а то отлично работать будет не долго

котики, вопрос по монге. есть монго-база вида [ {t: nnn, e:[{a:xxx, b:yyy, c:zzz}, {}, {}]}, {}, {} ] к ней делается много запросов вида count({ e: { $elemMatch: { a: { $gte: 100}, b : 0, c : 99, } }, t: 10 }) в каждом е порядка 400 элементов, записей таких около 30к (and growing). Каждый такой count выполняется где-то четверть секунды, что непозволительно долго. можно ли как-то облегчить ей участь? ну там, проставить индексы для вот этих элементов в e?

котики, вопрос по монге. есть монго-база вида [ {t: nnn, e:[{a:xxx, b:yyy, c:zzz}, {}, {}]}, {}, {} ] к ней делается много запросов вида count({ e: { $elemMatch: { a: { $gte: 100}, b : 0, c : 99, } }, t: 10 }) в каждом е порядка 400 элементов, записей таких около 30к (and growing). Каждый такой count выполняется где-то четверть секунды, что непозволительно долго. можно ли как-то облегчить ей участь? ну там, проставить индексы для вот этих элементов в e?

Видимо, сейчас нет индекса на е. Сделайте и посмотрите. А дальше уже explain и оптимизация запроса/индекса

https://www.mongodb.com/webinar/back-to-basics-webinar-series?utm_medium=email&utm_source=Eloqua&utm_campaign=Int_WB_Back%20to%20Basics%20Series%20%28English%29_01_17_EMEA%20-%20Announcement%203&utm_content=Webinar%201

https://blog.discordapp.com/how-discord-stores-billions-of-messages-7fa6ec7ee4c7#.jdr694jpk

ещё одни в монгу не смогли

> The messages were stored in a MongoDB collection with a single compound index on channel_id and created_at. Around November 2015, we reached 100 million stored messages and at this time we started to see the expected issues appearing: the data and the index could no longer fit in RAM and latencies started to become unpredictable. It was time to migrate to a database more suited to the task.

?

> We don’t have dedicated DevOps engineers yet (only 4 backend engineers), so having a system we don’t have to worry about has been great.

Пиздец конечно.

Just returning 50 messages to a user can result in many random seeks on disk causing disk cache evictions.

embeded docs для слабаков

Отличная иллюстрация: «Мы не читали доку, по этому как только у нас начались проблемы, мы сменили СУБД»

недавно же статья была, как 22000 серверов взломали с монгой из-за дефолтных настроек "в инструкцию смотрят только лохи"

ладно когда ещё люди в файрвол не могут, это ещё объяснимо

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

embeded docs для слабаков

а чем им это помогло бы?

а чем им это помогло бы?

это ровно тоже самое что они в кассандре по сути получили

{channel_id: xxx, time_slice: yyy, messages: [{user_id: zzz, message: fff, created_at: ddd}]}

time_slice: можно заменить на bucket_size

и делать бакеты, например, по сто сообщений

Это уменьшает в разы, если не на порядки, размеры индексов. Тебе теперь вместо того чтоб указывать например на 1000 страниц на каждое значение channel_id, надо указывать на 10

индексы по датам тоже самое

Это уменьшает в разы, если не на порядки, размеры индексов. Тебе теперь вместо того чтоб указывать например на 1000 страниц на каждое значение channel_id, надо указывать на 10

а. ну олени, чо.

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

они могли ничего не меняя хуйнуть почти любой шард-ключ, даже hashed по _id и в ус не дуть

Можно конечно их похвалить за то, что они смогли субд за неделю сменить. Это клёво. Но кассандра, без людей которые её умеют варить, они себе заложили очень большую свинью :(

Особенно с таким отношением

source: ***.me:27017 syncedTo: Wed Jan 25 2017 12:53:42 GMT+0300 (MSK) -2 secs (0 hrs) behind the primary

source: ***.me:27017 syncedTo: Wed Jan 25 2017 12:53:42 GMT+0300 (MSK) -2 secs (0 hrs) behind the primary

ну и чо такого?

ваши часы — говно :)

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

ваши часы — говно :)

а он разве не на время в оплоге смотрит ?

а он разве не на время в оплоге смотрит ?

ну, с primary приехал op с датой, у тебя часы на слейве отстают на 2с, вот и результат