@MongoDBRussian

Страница 26 из 342
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
вот как в багтрекере

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

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

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м объектов в коллекции. производительности запроса по индексу в данной колекции недостаточно. индекс большой получается. запросы по своей специфике могут быть адресованы только части данных. Тоесть, скажем у нас есть поле в документе "регион" и к примеру все наши данные равномерно распредлены по нескольким десяткам этих регионов.

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

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
а нет разве ?
tag aware shading

Serge
13.09.2016
15:36:23
tag aware sharding
Именно

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
не вы, а монга

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

и оно само

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
можно и нужно

Страница 26 из 342