Как повысить производительность при извлечении сложного бизнес-объекта?

В настоящее время у нас есть сложный бизнес-объект, которому требуется около 30 объединений в нашей базе данных sql для извлечения одного элемента. (и это наш основной вариант использования). База данных составляет около 2 ГБ на сервере sql. Мы используем структуру сущностей для извлечения данных, и для извлечения одного элемента требуется около 3,5 секунд. Мы заметили, что использование подзапроса в параллельном вызове более эффективно, чем использование соединений, когда в другой таблице много строк. (так что у нас есть что-то вроде 10 подзапросов). Мы не используем хранимую процедуру, потому что хотели бы сохранить уровень доступа к данным в «простом С#».

Цель состоит в том, чтобы получить элемент менее чем за 1 секунду без слишком большого изменения среды. Мы рассматриваем решения без sql (RavenDB, Cassandra, Redis с «клиентом документов») и новую функцию «база данных в памяти» сервера sql.

Что вы порекомендуете ? Как вы думаете, достаточно ли одного вызова хранимой процедуры с EF?

РЕДАКТИРОВАТЬ 1: у нас есть индексы для всех столбцов, где мы делаем соединения


person Pak    schedule 22.02.2014    source источник


Ответы (1)


На мой взгляд, если вам нужно 30 объединений для извлечения одного элемента, это что-то не так с дизайном вашей базы данных. Может быть, это правильно с реляционной точки зрения, но совершенно непрактично с точки зрения функциональности/производительности.

Мне пришло в голову несколько решений:

  • Денормализация дизайна вашей базы данных. Я почти уверен, что вы можете уменьшить количество объединений, значительно улучшив свою производительность с помощью этой техники. http://technet.microsoft.com/en-us/library/cc505841.aspx

  • Используйте решение NoSQL, как вы упомянули. Из-за количества вовлеченных таблиц SQL это не будет простым изменением, но, возможно, вы можете начать использовать NoSQL как кеш для этих сложных объектов. Сценарии использования NoSQL или КОГДА использовать NoSQL

Конечно, использование хранимых процедур для этого случая намного лучше, и это улучшит производительность, но я не верю, что это приведет к кардинальным изменениям. Вы должны попробовать id и сравнить. Также пересмотрите все ваши индексы.

person Rafa Paez    schedule 22.02.2014