А ты можешь сделать find().limit(1) и показать документ в монге?

Ну или если знаешь _id документа показать его представление в монге

Там есть прямой доступ btw, можешь поставить себе robomongo и сначала там попробовать.

Ааааа

Вот и ответ на вопрос

ага, блин что то я сам не додумался посмотреть

))

хм

`posting.key_auths.0: "foobar"`

Блин. Когда в iOS уже бэктики для кода поправят

Блин. Когда в iOS уже бэктики для кода поправят

и в макоси (но у меня бета просто)

В макоси, в нативном клиенте, всё норм

{"posting.key_auths.0":%20"STM6a4GQKwLokWPz6wJHzC5yEfxcu9dkW1GXhcJCZCfsMmRj8sg9V"} все равно не находит

Через веб или если в монгу запрос кидать?

Сдаётся мне что у них веб апи очень плохое

нет, просто с питона запросы делаю

А чё не сразу в монгу?

или апи/бд не твое? (ну, хотя да, что, в общем-то, логично)

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

А что 1 в конце значит?

Можешь попробовать искать совпадение по значению-массиву [foo, 1]

Тогда не надо .0 указывать

Можно ещё дикое `key_auths: {$elemMatch: {$elemMatch: {$eq:<string>}}` попробовать.

Это семантически ближе к тому что ты хочешь. По одному документу сложно сделать вывод как формируется массив массивов.

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

db.getCollection('Accounts').find({ "posting.key_auths": {$elemMatch: { $elemMatch: { $eq: "STM6a4GQKwLokWPz6wJHzC5yEfxcu9dkW1GXhcJCZCfsMmRj8sg9V" }}} })

это я через робомонгу попробовал

находит.

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

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

Спасибо большое! работает :) Да, есть и sql базы открытые для steemit блокчейна

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

видимо мне нужен явный сплит

разобрался, если кому интересно https://docs.mongodb.com/manual/reference/command/split/

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

Всё правильно нашёл, да.

Народ, как лучше организовать связь many-to-many? Если быть точнее, то нужно миллионы юзеров добавлять в группы и иметь возможность быстро вытаскивать пользователей по группе

Если у миллионов документов будет массив с сотнями айди, это норм идея? Или есть варианты получше?

Народ, как лучше организовать связь many-to-many? Если быть точнее, то нужно миллионы юзеров добавлять в группы и иметь возможность быстро вытаскивать пользователей по группе

Внутри пользователя храни номера групп.

где-нибудь есть хотя бы общее описание стейджей плана выполнения запросов? сейчас интересует SHARDING_FILTER и в чем разница в FETCH стейдже под ним и над ним в плане?

просто не могу понять где этот этап выполняется: на шарде, на монгосе, в драйвере?

Какую проблему ты пытаешься решить?

В драйвере в любом случае никаких шагов не выполняется, кроме как сделать bson и по wire protocol отправить его на сервер

В монгосе происходит только роутинг и мерж результатов

вообще задача в выборе индексов при шардировании. есть у меня шард ключ, и составной индекс где он является первым полем, всего три поля. Все при выборке по целому индексу все ок, но при попытке выбрать по второму и третьему - я попадаю на COLLSCAN. вот собственно приходится городить еще один индекс из этих двух полей. После чего прихожу к отсутствию необходимости в том индексе из трех полей, т.к. уже есть шардированный по первому полю и отдельный по двум полям

вот и сижу сравниваю планы выполнения

вот и двух из них было что SHARDING_FILTER и для него как инпут стейдж идет FETCH а в другом случае наоборот и хотелось бы понять какой импакт всего этого ибо стандарный план вообще не дает представления о масштабах пробелмы

FETCH это «дай мне документ»

если у тебя не index-only query, то fetch это нормально

иначе как монга тебе документ вернёт :)

SHARDING_FILTER это постобработка документов на соотвествие запросу

так как бывают ситуации когда чанк есть и тут и там

если мне память не изменяет

если ты падаешь на collscan то шардинг тут нипричём совершенно

ну это я подвел к чему я еще один индекс добавлял

составной индекс сторого префиксный

т.е. если у тебя индекс {a: 1, b: 2: c: 3}, ты не можешь искать по b или c

а при шардирвоании уникальынй индекс только с шард префиксом может быть?

точнее можешь, но тогда тебе надо явно сказать что a тебя волнует мало, но это потребует чтений индекса по всем значениям a, что крайне не эффективно

(например сказав a: MinKey .. MaxKey)

а при шардирвоании уникальынй индекс только с шард префиксом может быть?

afair да

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

мне от него не избавиться?

никак

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

если его не будет, монга не сможет отличать документы друг от друга

а свой ей подсунуть можно?

так

значит должно быт ьименно поле _id

ты можешь в _id писать всё что ты хочешь, если это удовлевторяет двум требовниям: значение уникально и не больше 1024 байт

все догнал

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

да с этим опыт уже был

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

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

нам не имеет смысла хранить ObjectId потому что он балласт и у нас и так уже есть уникальная пара атрибутов

мы можем положить это в _id: {t: 1234, d: 42}

вот как раз сейчас такой кейс

но выборки без полного указания _id (типа только по _id.t или _id.d) не будут работать без дополнительных индексов

но опять же для обращения к полям а не по целому _id нужны будут индекс по типу _id.docId