Михаил Макарычев

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

yopp

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

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

Михаил Макарычев

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

это дата

Sergey

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

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

yopp

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

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

yopp

Afaik

Sergey

Регуляркой)

Sergey

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

Oleg

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

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

Sergey

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

Sergey

А не как дата

Oleg

А не как дата

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

Михаил Макарычев

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

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

Oleg

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

Михаил Макарычев

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

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

Sergey

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

Oleg

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

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

Alexey (boblin)

котики, вопрос по монге. есть монго-база вида [ {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?

Oleg

котики, вопрос по монге. есть монго-база вида [ {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 и оптимизация запроса/индекса

Serg

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

yopp

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

yopp

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

yopp

> 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.

yopp

😂

yopp

> 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.

yopp

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

yopp

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

yopp

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

yopp

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

Pavel

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

yopp

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

yopp

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

Roman

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

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

yopp

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

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

yopp

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

yopp

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

yopp

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

yopp

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

yopp

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

Roman

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

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

yopp

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

yopp

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

yopp

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

yopp

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

Denis

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

yopp

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

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

yopp

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

Konstantin

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

Denis

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

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

yopp

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

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

Denis

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

yopp

тоесть у тебя приехала операция из будущего

Denis

мммм.

Denis

нет

Denis

если повторно выполнить команду тут же тот там 0 потом опять -2 или -1

yopp

ну да

yopp

ntp настрой

yopp

и следи за дрифтом

yopp

и проверь что у ты конфиг сервера уже как CSRS задеплоил. не rs конфиги ко разнице во времени критичны были

yopp

если повторно выполнить команду тут же тот там 0 потом опять -2 или -1

наприер если монга не будет 10 часов менятся, у тебя там будет 10 часов лаг :)

Denis

и проверь что у ты конфиг сервера уже как CSRS задеплоил. не rs конфиги ко разнице во времени критичны были

ntp говорит что всё зашибись

yopp

это нормально. оно считает время относительно последенй известной операции

yopp

проверяй на обоих серверах

yopp

вообще я бы особо не парился, если у тебя CSRS

yopp

2-3 секунды — фигня

Denis

у меня не шард

Denis

или я не понял о чем ты

yopp

а, если не шард, тогда вообще забей

Denis

Хм.

Denis

{ "v" : 1, "key" : { "track_id" : 1 }, "name" : "track_id_1", "ns" : "drm.track_restrictions", "background" : true, "uniqueue" : true },что это такое ?

Denis

"uniqueue" : true

Denis

а данные неуникальны