Sharding GridFS на MongoDB

Question

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

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

В книге О'Рейли "Scaling MongoDB" не рекомендуется использовать инкрементальный ключ шарда, чтобы избежать горячих точек (последний шард получит все записи и чтения).

что вы предлагаете для защиты коллекции GridFS?
кто-нибудь испытывал проблему с HotSpot?

спасибо.

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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