Не является ли SQL Server только для сообщения о накладных расходах?

Question

Недавно я поговорил с пользователем SQL Server 2005, который сказал, что их база данных была слишком нормализована и они реплицируют данные на сервер отчетов. Разве база данных не должна обрабатывать как транзакции, так и отчетность? Почему я должен инвестировать в 2 сервера и реплицировать?

Я знаю, что это открытый, субъективный вопрос, и у меня нет статистики в приведенном выше случае, но не настроена база данных, достаточная для обработки отчетов о транзакциях? Я могу понять, что для сценария интеллектуального анализа данных нам нужен отдельный сервер с Analysis Services и де-нормализация. Но для текущих сделок?

Спасибо.

Answer 1

От этого зависит.

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

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

Что касается чрезмерно нормализованного - это может означать много чего.

Answer 2

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

Это, в основном, простая организационная мера, создающая границу между пользователями и пользователями отчетов.

Answer 3

На чистом техническом уровне нет причин, по которым два сервера должны быть отдельными. Вполне вероятно, что они приняли решение по «коммерческим причинам», таких как:

1. В зависимости от сложности отчетов, они могут потреблять значительные ресурсы, когда бежится. Если это влияет на производительность для других пользователей системы, это аргумент для сброса данных на отдельный сервер базы данных «отчетности».

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

Answer 4

Я думаю, что отдельный сервер отчетов с сервера производства/транзакции часто является хорошей идеей. У меня установлены серверы отчетов со структурой данных, которая полностью «ненормирована» и сделает реляционные пуристы съежимыми ... но это сервер отчетов, поэтому это не имеет значения.

Пользователи любят быть в состоянии добраться до «своих» данных без поддержки DBA в пути (база данных отчетов, конечно, доступна только для чтения).

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

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

Answer 5

Это действительно зависит от вашей среды и приложений в игре. Наличие отдельного сервера отчетов - безопасная ставка. Если у вас есть производственная система с сильно нормированной схемой и с большим количеством транзакций, происходящих и брошенных в блокировку записей, тогда запуск сложных отчетов против этого может привести к разрушительным результатам производительности. Если, например, запросы отчетов, построенные, возможно, другим разработчиком, не включают (NOLOCK) в сложные объединения, почти наверняка будут проблемы. Правильный запрос (т. Е. Неправильный) может привести к остановке всей базы данных. Если отчеты позволяют пользователям извлекать большие объемы данных, вы можете также взглянуть на них. Возможно, вам придется защититься от предоставления пользователю возможности запуска такого запроса. Делайте такие отчеты только по запросу. IMHO

Answer 6

Две базы данных могут иметь смысл. Вот пример моего собственного опыта.

База данных 1 используется для сбора истории платежей по миллионам договоров аренды оборудования. Эта основная цель этой базы данных - собирать данные от разных кредиторов и служить INPUT для расчета кредитных баллов. Эта база данных огромна, обновляется много, никогда не подвергается воздействию Интернета.

База данных 2 предназначена для отчетности. Значительно меньше. Никогда не обновлялся. Вычисляет ли результат расчета кредитного балла. Доступен через Интернет. Включает в себя множество таблиц, индексов для поддержки нечетких запросов по имени, адресу и т. Д.

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

Answer 7

Загрузка приложений (OLTP) и отчетов (DW) может быть и, как правило, очень различна при использовании шкалы . Частоты OLTP обрабатываются небольшим количеством записей за раз, часто случаются и могут быть выбраны, вставлены или обновлены. Запросы DW, как правило, обрабатывают большее количество записей, случаются реже и должны быть прочитаны только.

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

Ниже приведен обзор двух видов рабочей нагрузки.

Запросы OLTP обычно пишутся разработчиками, которые заинтересованы в производительности приложений и точно знают, с какими бизнес-функциями они пытаются встретиться. Тот же запрос выполняется много раз в день, и проблемы настраиваются. Вот несколько примеров типа рабочей нагрузки.

• запись о продаже.
• проверить пароль.
• Извлечь деталь продукта.
• обновить профиль пользователя.

Запросы DW могут быть сгенерированы автоматически с помощью инструментов запроса для отчетов adhoc или могут быть написаны непосредственно аналитиком или бизнес-пользователем с небольшим техническим опытом. Некоторые могут предпочесть сделать выбор * в свой выбор, например SAS или Mathematica. Эти типы запросов, если они не выполнены с грязными чтениями, могут нанести ущерб производительности приложения OLTP. Даже хорошо написанный запрос для проведения аналитических анализов или группировки большого количества клиентов в процентили может потребовать полного сканирования таблицы в силу требования всех данных. Типы вопросов, на которые может потребоваться ответ.

• Сколько велосипедов продано сегодня, на этой неделе, в прошлом месяце.
• Что является самым популярным продуктом.
• В какое время суток продается продукт с высокой маржой.
• Дайте мне обзор графиков просмотров за год.

Answer 8

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

Answer 9

Создайте несколько представлений (только для чтения) для авторов отчетов, если они не понимают структуру данных. Запускайте ресурсоемкие отчеты, когда бремя транзакций невелико. Имейте базу данных разработки, чтобы предотвратить вмешательство в производство.

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

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