В течение многих лет я читал мнения многих людей о том, как повысить производительность их запросов SQL (Microsoft SQL Server, просто чтобы мы все были на одной странице ...). Однако все они, похоже, тесно связаны либо с высокопроизводительной настройкой OLTP, либо с настройкой OLAP хранилища данных (cubes-galore ...). Тем не менее, моя сегодняшняя ситуация вроде как в середине 2, поэтому моя нерешительность.
У меня есть общая структура БД [Contacts], [Sites], [SiteContacts] (таблица соединений [Sites] и [Contacts]), [SiteTraits] и [ContractTraits]. У меня есть около 3 миллионов контактов с около 50 полями (между [Контактами] и [ContactTraits]), относящимися только к контакту, и около 600 тысяч сайтов с около 150 полями (между [Сайтами] и [SiteTraits]), относящимися только к сайтам. , В основном это довольно большая сплюснутая таблица или представление ... Большинство столбцов: int , bit , char (3) или short varchar (ы). Моя проблема в том, что значительная часть этих столбцов доступна для использования пользователем в специальных запросах, и как можно быстрее, потому что основным пользовательским интерфейсом для этого будет веб-сайт. Я знаю самые распространенные фильтры, но даже при большой индексации по ним, я думаю, это все равно будет чудовищно ... Эти данные доступны только для чтения; данные не меняются в течение дня, и база данных будет обновляться только самой последней информацией во время запланированного простоя. Поэтому я вижу эту ситуацию как базу данных OLAP с требованиями чтения базы данных OLTP.
вижу 3 варианта; 1. Разбейте таблицу на более мелкие делимые единицы, выполнив подзапрос для всего, 2. создайте одну плоскую таблицу и по-настоящему отправьтесь в город для индексации 3. Создайте куб OLAP и выполните подзапрос для остальных, основываясь на значениях фильтра, которые я не помещаю как размеры куба, так и. Я не так много сделал с кубами OLAP, поэтому, честно говоря, даже не знаю, возможен ли такой вариант, но из того, что я сделал с ними в прошлом, я думаю, что это может быть вариант. Кроме того, просто чтобы уточнить, что я имею в виду, когда говорю «подзапросить все», вместо того, чтобы иметь предложение WHERE для внешнего выбора, будет один (если применимо) для каждой таблицы, вводимой в запрос, и затем таблицы ВНУТРЕННЕЕ СОЕДИНЕНИЕ, чтобы устранить действительно большой Декартовой продукт. Что касается второго варианта одной большой таблицы, я слышал и видел противоречивые результаты при таком подходе, поскольку он экономит на объединениях, но в то же время сканирование таблицы занимает гораздо больше времени.
Идеи кого-нибудь? Нужно ли мне поделиться тем, что я курю? Я думаю, что это может превратиться в довольно хорошую дискуссию, если каждый вложит свои 2 цента. Да, и не стесняйтесь сказать мне, если я далеко от базы с идеей куба OLAP, если это так, я тоже новичок в этом.
Заранее благодарим за любые мнения и помогаем решить эту дилемму, в которой я оказался.