В настоящее время у нас есть SQL Federated DB, разделенная на 10 сегментов в примерно равных частях данных, отфильтрованных по идентификатору клиента.
В настоящее время мы испытываем проблемы с производительностью при выполнении отфильтрованных запросов, например, выполнение запроса для определенного клиента может занять более 3 минут, чтобы вернуть 4000 строк в некоторых осколках. Однако выполнение точно такого же запроса в нефильтрованном соединении на том же осколке возвращает результат в течение 4 секунд. Один заметный аспект заключается в том, что сегменты, испытывающие замедление, как правило, содержат больше клиентов, хотя и с меньшим объемом данных. Наиболее вероятным ингибитором производительности (я полагаю) будет индексация и что-то, что связано с фильтрованным/нефильтрованным соединением.
Проведя поиск, я не нашел много информации о производительности запросов по сегментам/конкретным стратегиям индексирования на сегментах (кроме того, что Azure, по-видимому, не поддерживает индексированные представления). Мое впечатление (и, следовательно, потребность в пояснении) заключается в том, что индексы применяются ко всем членам шарда, а не к каждому члену.
Если первое, то мы находимся в затруднительном положении, за исключением повторного разделения этого конкретного сегмента, что не имеет смысла, учитывая, что единственная разница заключается в количестве клиентов, а не в размере данных. Несколько вещей, которые мы собираемся попробовать, — это явное добавление фильтра в индексы или даже добавление фильтра к каждому запросу. Можно с уверенностью сказать, что нам не нравится отказываться от соединения с фильтрацией.
Кто-нибудь еще сталкивался с этой проблемой или мог бы указать, что нефильтрованное соединение значительно превосходит фильтрованное соединение?
Заранее спасибо...
