
Roman
12.09.2016
11:12:08

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

Dmitry
12.09.2016
11:18:02
ща подумаю
условно мне нужно вытаскивать список....последние 30 записей...

Google

Dmitry
12.09.2016
11:19:53
проваливаться в какую-нить запись, ее редактировать...
в принципе пофиг...
похоже
просто я хотел красивые айди...
в общем с точки зрения безопасности вы рекомендуете не юзать _id а генерить некий uuid?
и его юзать?
ответьте плиз)

ptchol
12.09.2016
12:05:55
да.
а последние 30 реализуй просто датой
и индексом по ней если много записей.
в монге есть паршал индексы, если ты уверен что не будешь выбирать данные за большой период времени
это скоратит размер индекса.

Dmitry
12.09.2016
12:07:53
ок спс

Google

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

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

Dmitry
12.09.2016
12:51:52
в общем чувствуется я многого не знаю
ну оно и логично что с монго я работаю два дня)

Serge
12.09.2016
12:52:52
Если прямо хочется последовательные айди, типа как в багтрекерах, например. Ну, т.е. требование такое есть, то можно использовать findAndModify на специальном отдельном документе в отдельной коллекции.
Да, это приведет к тому, что появится очередь на получение ключей, но если требование есть, то это оправдано
Во всех остальных случаях, для начала достаточно oid. Как правило, важно сделать приложение, а для этого достаточно oid.

Dmitry
12.09.2016
12:55:04
вот как в багтрекере
это и нужн омрне
последовательность

Serge
12.09.2016
12:55:19

Dmitry
12.09.2016
12:55:30
ок покурю
спасибо

Serge
12.09.2016
12:55:38

Dmitry
12.09.2016
12:56:02
представим что систему которую я пилю очень похожа на багтрекер
скажем даже - копия ) тока назначение другое

Serge
12.09.2016
12:56:34
Ну, т.е. люди будут пользоваться этими номерами. Тогда да
Тут есть еще один плюс в гибкости. Можно делать в одной коллекции несколько последовательностей, например с разными префиксами.

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

Google

Dmitry
12.09.2016
13:06:14
а для юзеров...вот думаю что показывать потомссс
кароче море вопросов, почитаю я пока что-то

Sergey
12.09.2016
14:36:50

yopp
12.09.2016
14:37:02
это значит у тебя докер ;)
или МИКРОЯДРО
прости господи

Sergey
12.09.2016
14:37:59
Даже в докере плохая идея держать что-то с pid=1
Не зря в всякие dumb-init придумали
Хотя, докероводы обычно на это плюют

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

Dmitry
12.09.2016
15:17:10
интересно а как получить pid если ты доступа не имеешь к mongodb
я помню когда дисскуссия поднялась, но не понимаю почему

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

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

Serge
12.09.2016
15:24:55
Вот тут надо определиться чем лучше
Ну видно некий pid. И что? Вот что?

Google

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

Alex
12.09.2016
15:27:31
facepalm.jpg

Sergey
12.09.2016
15:27:47
При желании, можно запатчить исходники и вместо pid писать что-то другое
Некую константу, сгенеренную при старте инстанса базы

Dmitry
13.09.2016
15:32:01
понял что оказывается id мне не пригодится...
тока в иерархии parent - child

ptchol
13.09.2016
15:32:45
посоны, смотрите есть задача.
здесь кто нить есть ? )

Alex
13.09.2016
15:33:05
ты пишы пишы )

Serge
13.09.2016
15:33:05
Никого нет

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

Serge
13.09.2016
15:35:23

ptchol
13.09.2016
15:35:29
да да да

Serge
13.09.2016
15:35:33
И?

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

Serge
13.09.2016
15:36:05
Почему?

yopp
13.09.2016
15:36:09
tag aware sharding

Google

ptchol
13.09.2016
15:36:12
а нет разве ?

yopp
13.09.2016
15:36:21

Serge
13.09.2016
15:36:23

yopp
13.09.2016
15:36:32
документацию читай )))))))
а, этож не докерчят
тут шутку не поймут!

Serge
13.09.2016
15:37:41
Ну, все равно смешно:)

ptchol
13.09.2016
15:37:55
тогда получается что мы ручками должны балансить на основании тегов

yopp
13.09.2016
15:38:10
не вы, а монга

Serge
13.09.2016
15:38:12

yopp
13.09.2016
15:38:15
ты назначешь на шард тег
и оно само

Serge
13.09.2016
15:38:29
Короче, я пошёл.

ptchol
13.09.2016
15:38:41
у нас коллекция разбита на N чанков
чанки привязаны к шардам
шард = нода

yopp
13.09.2016
15:38:54
ты про чанки забудь ваще
это детали реализации

ptchol
13.09.2016
15:39:02
нельзя про них забыть

yopp
13.09.2016
15:39:05
можно и нужно