Советы по расщеплению базы данных - PullRequest
0 голосов
/ 03 декабря 2009

Я прочитал пару книг по SQL Server 2005, но не нашел правильного ответа на то, что ищу.

Проблема в следующем: У меня есть база данных, которая используется 5-20 пользователями одновременно для бронирования заказов клиентов. Они получают много заказов в день по телефону, поэтому размещение заказов и поиск товаров \ старых заказов должны быть быстрыми.

Со временем было размещено много заказов. Есть много таблиц, которые содержат детали этого заказа, и есть много отчетов, которые используют эти данные. Проблема в том, что отчеты очень медленные. Индексирование помогло немного, но не так сильно, как я ожидал.

Прочитав немного, я хочу попробовать разделить базу данных на две части - одну для онлайн-транзакций и одну только для отчетов.

Я был бы очень благодарен вам, если бы вы помогли мне, предложив книгу или сайт, который научит меня, как Разработать базу данных для быстрой отчетности и как разделить две базы данных: одну для онлайн-транзакций, а другую для быстрой отчетности (Будет ли это хранилище данных для быстрой отчетности?)

Моя главная цель - создавать очень быстрые отчеты (некоторые отчеты теперь выполняются за 5 минут, и с увеличением количества данных они будут работать медленнее). Буду очень признателен за любую помощь в указании меня в правильном направлении.

Ответы [ 2 ]

1 голос
/ 04 декабря 2009

Во-первых, определенно посмотрите на существующий дизайн и рабочую нагрузку.

Если вы не можете больше оптимизировать свою сторону OLTP, я бы полностью перешел к методологии хранилища данных Kimball. Обновите свои данные в обычной базе данных, используя SSIS или что-то еще, и преобразуйте свои данные в звезды. Что вы должны найти, так это то, что ваша производительность отчетов должна значительно улучшиться и не мешать вашим производственным транзакциям на OLTP / нормализованной стороне.

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

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

1 голос
/ 03 декабря 2009

Посмотрите на Инструментарий хранилища данных от Ральфа Кимбалла. Простая схема звезды может ускорить создание отчетов. И вот пример того, как схема «звезда» упрощает отчетность.

...