Разделение GridFS на MongoDB

Я документирую GridFS и возможность ее разделения между разными машинами.

Читая документацию здесь, предлагаемый ключ сегмента — chunks.files_id. Этот ключ будет связан с _id коллекции файлов, поэтому этот _id является инкрементным. Каждый новый файл, который я сохраняю в сетке, будет иметь новый инкрементный _id.

В книге O'Reilly «Масштабирование MongoDB» использование добавочного ключа сегмента не рекомендуется, чтобы избежать горячих точек (последний сегмент получит все операции записи и чтения).

каковы ваши предложения по сегментированию коллекции GridFS?
Кто-нибудь сталкивался с проблемой HotSpot?

Спасибо.


mongodb sharding gridfs
person ALoR    schedule 17.03.2011    source источник

Ответы (3)


arrow_upward
17
arrow_downward

Вы должны разбить files_id, чтобы сохранить фрагменты файлов вместе, но вы правы, что это создаст точку доступа. Если можете, используйте для _ids в коллекции fs.files что-то другое, кроме ObjectId (вероятно, MD5 будет лучше, чем ObjectId).

Мы добавим хеширование для сегментирования, что решит эту проблему, но не раньше версии 2.0.

person kristina    schedule 17.03.2011
comment
Привет Кристина. Как обстоят дела с этим сейчас, учитывая, что ответ был еще в 2011 году? Спасибо. - person Mike Bartlett; 12.02.2013
comment
2.4 позволяет использовать хешированные ключи осколков, поэтому вы можете создать хешированный индекс для files_id. - person kristina; 12.02.2013
comment
К сожалению, hashed files_id не будет работать в последней версии 2.4 jira.mongodb.org/browse/SERVER-9888. - person Mark; 11.06.2013

arrow_upward
5
arrow_downward

Вы можете сегментировать данные gridfs, потому что gridfs это всего две коллекции: куски и файлы. А шардинг gridfs — это очень полезная и замечательная вещь. О ключе осколка gridfs всегда плохо выбирать случайный или добавочный ключ осколка, потому что данные неравномерно распределяются по осколкам. В случае инкрементного ключа сегмента все записи идут в последний сегмент и он увеличивается, и как только разница между фрагментами становится 10 или более, балансировщик перемещает данные в другие сегменты. Перенос данных на другой шард — всегда сложная задача, которую следует по возможности избегать.
Поэтому при выборе ключа сегмента следует позаботиться о равномерном распределении данных.
Также, если вам повезет, mb автор 'Scaling MongoDB' kristina (отличный специалист в ключах сегмента) ответит на ваш вопрос.
В документации говорится, что в общих случаях вы должны выбрать индекс по умолчанию fileId:1,n:1 в качестве ключа сегмента:

Существуют различные способы разделения GridFS в зависимости от необходимости. Один из распространенных способов сегментирования на основе уже существующих индексов:

Коллекция «файлы» не сегментирована. Все записи файлов будут жить в 1 шарде. Настоятельно рекомендуется сделать этот сегмент очень устойчивым (набор реплик не менее 3 узлов). Коллекция «chunks» сегментируется с использованием существующего индекса «files_id: 1, n: 1». Фрагменты некоторых файлов в конце диапазона могут быть разделены на сегменты, но большинство файлов будут полностью содержаться в одном сегменте.

person Andrew Orsich    schedule 17.03.2011
comment
Я подумал об имя файла, но оно находится в коллекциях files, а не в chunks, которые нуждаются в сегментировании. - person ALoR; 18.03.2011
comment
я так и думал ;) Но файлов небольшая коллекция и она будет жить на одном осколке. И я вижу только два ключа осколка для gridfs: fileId и fileId,n. - person Andrew Orsich; 18.03.2011

arrow_upward
0
arrow_downward

В настоящее время MongoDB версии 1.8.1 поддерживает только сегментирование поля «file_id» из-за использования md5 для проверки загрузки, но пока не работает с сегментами. Таким образом, вы не можете разделить один файл на осколки. Ответить в группе Google7

person smokeny    schedule 05.05.2011