Клиенты RavenDB загружаются медленно

Мы используем RavenDB в мультитенантной среде, пользователи могут создавать своих собственных клиентов и создавать там свои собственные приложения.

Проблема, однако, в том, что их базы данных время от времени простаивают (конечно, при принятии, но это случается и в производственной среде), и по какой-то причине для их перезагрузки требуется более 40 секунд. Но у нас есть только ~ 1000 документов и ~ 300 индексов (это план для приложения, которое должно содержать намного больше документов, когда оно будет запущено в производство), и все индексы имеют одно предложение Map и TransformResults.

Версия: 2.0.2230 и 2.0.2261 (последняя стабильная на момент написания)

Общая статистика

 ...
TransactionalStorageSize:26222592,
TransactionalStorageSizeHumaneSize:"25.01 MBytes",
IndexStorageSize:376263,
IndexStorageHumaneSize:"367.44 KBytes",
TotalDatabaseSize:26598855,
TotalDatabaseHumaneSize:"25.37 MBytes",
CountOfDocuments:975,
...

Статистика базы данных

CountOfIndexes:305,
InMemoryIndexingQueueSize:0,
ApproximateTaskCount:0,
CountOfDocuments:975,
StaleIndexes:[],
CurrentNumberOfItemsToIndexInSingleBatch:256,
CurrentNumberOfItemsToReduceInSingleBatch:128,
DatabaseTransactionVersionSizeInMB:0.02,
....
Errors:[],
....

РЕДАКТИРОВАТЬ

Приложение, о котором мы говорим, имеет два компонента: конструктор и среду выполнения. В ravendb мы храним дизайн и данные, созданные / используемые во время выполнения. И каждый арендатор - это приложение.

У нас так много индексов, потому что для каждого запроса, который вы создаете в режиме разработки, мы создаем индекс в ravendb.

Индексы имеют форму: Map from ... [from...|let...] [where ... ] select ... с вызовами LoadDocument для загрузки необходимых связанных документов для заданных запросов lucene и аналогичных TransfromResults для формирования документов в требуемой форме.

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

В: Что лучше: иметь несколько гигантских индексов, скажем, по одному для каждой Сущности, по которой мы запрашиваем, или найти какой-то средний план?

В: На данный момент мы не позволяем в нашем дизайне Сущностей иметь «сложные» сущности, то есть ничего, кроме свойств значений или ссылок на другие документы, может ли это повлиять, если у нас будет немного меньше и больше документов, и таким образом, нужно делать меньше обращений к LoadDocument(...)?

Есть ли причина, по которой это занимает так много времени (40 с)? И любые возможные способы смягчить это будут оценены.


multi-tenant ravendb
person JorisG    schedule 08.03.2013    source источник
comment
Какая версия / сборка? Кроме того, группа Google - лучшее место для ответа на этот вопрос, поскольку s.o. Для вопросов по кодированию. ServerFault также может быть подходящим, но там не так много поддержки ravendb.   -  person Matt Johnson-Pint    schedule 08.03.2013
comment
Я отправил сообщение в список рассылки, я попробовал сначала по почте, а затем прямо в интерфейсе групп Google, но он не отображается ... Есть предложения @MattJohnson?   -  person JorisG    schedule 08.03.2013
comment
Не уверен, модерируют они новичков или нет. Если вы только что разместили свой первый пост, его одобрение может занять некоторое время.   -  person Matt Johnson-Pint    schedule 08.03.2013

Ответы (2)


arrow_upward
2
arrow_downward

Одна вещь, которую я нахожу немного странной - ваше соотношение индексов к документам кажется немного высоким. Зачем вам столько индексов? Можете ли вы их объединить?

Например, если у вас есть несколько индексов только для карты для одной и той же сущности, например:

// index 1
Map = customers => from customer in customers
                   select new
                   {
                       customer.FirstName
                   }

// index 2
Map = customers => from customer in customers
                   select new
                   {
                       customer.LastName
                   }

Ясно, что они могут быть в одном индексе:

Map = customers => from customer in customers
                   select new
                   {
                       customer.FirstName,
                       customer.LastName
                   }

Это значительно снизило бы нагрузку на сервер, если бы вы могли уменьшить количество индексов.

Имейте в виду, что все индексы применяются ко всем документам. На их переведенной карте вы увидите docs.customer, что является сокращением для фильтрации Raven-Entity-Type метаданных.

Итак, если у вас есть 1000 документов против 300 индексов, это 300 000 раз, когда карта должна оценивать. Если бы вы уменьшили индексы до чего-то более обычного - скажем, 20 или около того, это было бы намного лучше.

person Matt Johnson-Pint    schedule 08.03.2013
comment
Я добавлю больше информации к своему вопросу. Тем не менее, вы предоставили хорошую возможность для расследования. - person JorisG; 08.03.2013
comment
Я принял ваше на основании дальнейшего обсуждения в списке рассылки. Итак, да, иметь 300+ индексов - плохая идея, спасибо! - person JorisG; 13.03.2013

arrow_upward
3
arrow_downward

Отвечая на один подвопрос этого:

В: Что лучше: иметь несколько гигантских индексов, скажем, по одному для каждой Сущности, по которой мы запрашиваем, или найти какой-то средний план?

В обычных обстоятельствах вам никогда не понадобится более 1 индекса для каждого типа сущности.

Если у вас есть десятки типов сущностей, вы, вероятно, попали в яму, применяя проектирование модели РСУБД к нереляционному дизайну. Для сравнения: у нас есть функционально богатая система, построенная на основе 8 совокупных корней. С 2-3 поддерживающими инфраструктурными объектами.

Всего у нас 17 индексов. 8 карт, 5 мульти-карт и 5 карт-уменьшений. Как видите, соотношение индексов Map: Aggregate Root составляет 1: 1. С дополнительными индексами для поддержки агрегированного поиска и map / reduce для пользовательских результатов.

person Chris Marisic    schedule 08.03.2013