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

Тебе зачем именно по числу? Почему не какой-либо хеш или случайное значение?

простому аля name итд

у документа всегда есть поле с неким индентификатором выглядящим как некий хеш, и все что уходит в сторону клиента идентифицриует объект именно по этому ключу.

ща подумаю

условно мне нужно вытаскивать список....последние 30 записей...

проваливаться в какую-нить запись, ее редактировать...

в принципе пофиг...

похоже

просто я хотел красивые айди...

в общем с точки зрения безопасности вы рекомендуете не юзать _id а генерить некий uuid?

и его юзать?

ответьте плиз)

да.

а последние 30 реализуй просто датой

и индексом по ней если много записей.

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

это скоратит размер индекса.

ок спс

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

Раскрытие пида не большая угроза, имхо. Даже если там 1.

в общем чувствуется я многого не знаю

ну оно и логично что с монго я работаю два дня)

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

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

Во всех остальных случаях, для начала достаточно oid. Как правило, важно сделать приложение, а для этого достаточно oid.

вот как в багтрекере

это и нужн омрне

последовательность

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

Можно, например, почитать как устроены sequence в постгрес и провести в голове аналогию.

ок покурю

спасибо

это и нужн омрне

Хочется или нужно? Это разные вещи.

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

скажем даже - копия ) тока назначение другое

Ну, т.е. люди будут пользоваться этими номерами. Тогда да

Тут есть еще один плюс в гибкости. Можно делать в одной коллекции несколько последовательностей, например с разными префиксами.

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

_id использовать безопасно или лучше юзать свой uuid?

а для юзеров...вот думаю что показывать потомссс

кароче море вопросов, почитаю я пока что-то

Например если pid == 1, значит твоя субд работает под рутом

Это значит, что у тебя БД вместо init

это значит у тебя докер ;)

или МИКРОЯДРО

прости господи

Даже в докере плохая идея держать что-то с pid=1

Не зря в всякие dumb-init придумали

Хотя, докероводы обычно на это плюют

это значит у тебя докер ;)

Весьма не факт

Даже в докере плохая идея держать что-то с pid=1

Вот именно

Хотя, докероводы обычно на это плюют

А как кстати официальный монговский контейнер устроен. Надо бы глянуть

Так то пихать везде один и тот же pid - это практически выключить скалинг в рамках одного хоста

интересно а как получить pid если ты доступа не имеешь к mongodb

я помню когда дисскуссия поднялась, но не понимаю почему

ObjectID включает в себя pid. Ибо он не хэш ни разу

аа вот оно что

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

Вот тут надо определиться чем лучше

Ну видно некий pid. И что? Вот что?

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

facepalm.jpg

При желании, можно запатчить исходники и вместо pid писать что-то другое

Некую константу, сгенеренную при старте инстанса базы

понял что оказывается id мне не пригодится...

тока в иерархии parent - child

посоны, смотрите есть задача.

здесь кто нить есть ? )

ты пишы пишы )

Никого нет

ок

есть к примеру данных 800м объектов в коллекции. производительности запроса по индексу в данной колекции недостаточно. индекс большой получается. запросы по своей специфике могут быть адресованы только части данных. Тоесть, скажем у нас есть поле в документе "регион" и к примеру все наши данные равномерно распредлены по нескольким десяткам этих регионов.

идея заключается в том, чтобы разрезать индекс на эти несколько десятков

есть к примеру данных 800м объектов в коллекции. производительности запроса по индексу в данной колекции недостаточно. индекс большой получается. запросы по своей специфике могут быть адресованы только части данных. Тоесть, скажем у нас есть поле в документе "регион" и к примеру все наши данные равномерно распредлены по нескольким десяткам этих регионов.

Шардинг

да да да

И?

первая мысль которая приходит в голову

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

Почему?

tag aware sharding

а нет разве ?

а нет разве ?

tag aware shading

tag aware sharding

Именно

документацию читай )))))))

а, этож не докерчят

тут шутку не поймут!

Ну, все равно смешно:)

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

не вы, а монга

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

Не мы , а монга

ты назначешь на шард тег

и оно само

Короче, я пошёл.

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

Погугли ж

у нас коллекция разбита на N чанков

чанки привязаны к шардам

шард = нода

ты про чанки забудь ваще

это детали реализации

нельзя про них забыть

можно и нужно