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

Question

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

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

Спасибо.

Answer 1

Это зависит.

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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

Answer 8

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

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

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

Answer 9

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

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