MongoDB Index в памяти с шардингом - PullRequest
2 голосов
/ 31 января 2012

На улице говорят, что MongoDB работает медленно, если вы не можете сохранить индексы, которые используете в памяти.Как это работает с шардингом?Хранит ли сегментированный только свой собственный BTree в памяти, или каждый шард должен хранить индекс для всей коллекции в памяти?

Ответы [ 2 ]

6 голосов
/ 01 февраля 2012

Хранит ли осколок только свой собственный BTree в памяти ...?

Да, каждый осколок управляет своими собственными индексами.

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

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

Если вы выполняете запрос, используя ключ шарда, он будет перенаправлен непосредственно на правильный сервер (ы).В большинстве случаев это выравнивает рабочую нагрузку.Таким образом, 100 запросов могут быть распределены по 100 серверам, и каждый сервер отвечает только на 1 запрос.

Однако, если вы выполняете запрос с использованием вторичного ключа, этот запрос должен поступить на каждый сервер.Таким образом, 100 запросов к маршрутизатору приведут к 10000 запросов на 100 серверах или 100 запросов на сервер.Когда вы добавляете больше серверов, эти запросы «не по ключу» становятся все менее и менее эффективными.Рабочая нагрузка не становится более сбалансированной.

Некоторые подробности доступны в документации MongoDB здесь .

0 голосов
/ 31 января 2012

Только его собственная часть индекса (он не знает о данных других шардов).В противном случае масштабирование не сработает.См. Эту документацию для получения дополнительной информации о шардинге: http://www.mongodb.org/display/DOCS/Sharding+Introduction

http://www.mongodb.org/display/DOCS/Choosing+a+Shard+Key

...