2013-11-20 5 views
4

В настоящее время у нас есть SQL Federated DB, разбитый на 10 фрагментов в примерно равных частях данных, отфильтрованных по идентификатору клиента.SQL Azure Federations and Indexes - Уточнение в производительности

В настоящий момент у нас возникают проблемы с производительностью, связанные с фильтрацией запросов, например, выполнение запроса для конкретного клиента может занять более 3 минут, чтобы возвращать 4000 строк в некоторых осколках. Однако выполнение точно такого же запроса в нефильтрованном соединении с одним и тем же осколком возвращается в течение 4 секунд. Одним из примечательных аспектов является то, что осколки, испытывающие замедление, имеют тенденцию содержать больше клиентов, хотя и с меньшим количеством данных. Наиболее вероятным ингибитором эффективности (я считаю) будет индексирование и что-то, что связано с фильтрованным/нефильтрованным соединением.

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

Если вначале мы находимся в небольшом рассоле, кроме того, что пересматриваем этот конкретный осколок, который не имеет смысла, учитывая единственное различие - это количество клиентов, а не размер данных. Несколько вещей, которые мы собираемся попробовать, явно добавляют фильтр к индексам или даже добавляют фильтр к каждому запросу. Безопасно сказать, что мы не счастливы, удаляясь от фильтрованного соединения.

Кто-нибудь еще испытал эту проблему или мог бы указать какое-то направление, что нефильтрованное соединение значительно превосходит фильтрованное соединение?

Заранее спасибо ...

+0

Было бы интересно узнать, что вы найдете, я предполагаю, что в какой-то момент я столкнулся с той же проблемой, сейчас все хорошо работает для меня только с несколькими клиентами в Shard :) – pateketu

+0

Не могли бы вы предоставить примерный запрос ? Вы используете ** SELECT * FROM TableName **? –

+0

Пожалуйста, посмотрите мой прошлый ответ: http://stackoverflow.com/questions/17998196/computed-columns-sometimes-missing-from-select/20835737#20835737 –

ответ

0

Индексы в федерации применяются на основе федерации Член-по-члена. Если вы начали с одного проиндексированного элемента и выполнили операцию SPLIT, то индексы автоматически применяются к продуктам SPLIT. Но если вы применяли индексы после создания нескольких членов, вам нужно явно добавлять индексы к каждому члену.

Так что, надеюсь, вы не в маринаде.

Возможно, вы захотите рассмотреть альтернативы федерациям, которые продвигаются вперед, поскольку эта функция не поддерживается новыми SKU, анонсированными в апреле.