Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Посоветуйте плз по поводу архитектуры.  [new]
abrashka
Member

Откуда:
Сообщений: 521
День добрый!
Хотелось бы услышать мнение уважаемых форумчан по поводу такой проблемы:
Речь идет о билетной кассе(театры, концерты, музеи и т.п).
Базы не маленькие, на сегодняшний день некоторые достигают порядка 50Гб.
В каждой базе есть несколько больших таблиц с порядка 5 миллионов строк(транзакции, билеты, баркоды, клиенты), порядка 20 таблиц с около миллиона строк, ну и таблицы поменьше, всего около 150 таблиц в базе.
Таблицы постоянно изменяются, иногда чаще, иногда реже, перед каким-то грандиозным концертном изменения происходят достаточно интенсивно.
Необходимо составить механизм отчетов. На сегодняшний день существует пародия на хранилище данных, изменения в базе отслеживаются триггерами, которые вносят названия таблицы с измененными данными, ID измененной строки и вид изменения(insert/update/delete) в таблицу аудита, каждые две минуты бежит джоб(etl), который изменяет базу репортинга согласно аудиту. Сначала необходимые данные переносятся в Staging, ну после некоторых манипуляций изменяют Reporting.
Такая схема работает не очень корректно, по раным причинам.

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

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2550.0 (X64) Jun 11 2012 16:41:53 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)

Спасибо!
13 янв 14, 12:21    [15407141]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте плз по поводу архитектуры.  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
SSAS вам в руки.. как вариант можно сделать зеркало и с него ситать и строить репорты
13 янв 14, 12:23    [15407159]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте плз по поводу архитектуры.  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2423
abrashka,

AlwaysOn
13 янв 14, 12:31    [15407223]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте плз по поводу архитектуры.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31912
abrashka
На сегодняшний день существует пародия на хранилище данных, изменения в базе отслеживаются триггерами, которые вносят названия таблицы с измененными данными, ID измененной строки и вид изменения(insert/update/delete) в таблицу аудита, каждые две минуты бежит джоб(etl), который изменяет базу репортинга согласно аудиту. Сначала необходимые данные переносятся в Staging, ну после некоторых манипуляций изменяют Reporting.
Ну, если отчёты должны быть почти реал-тайм, то нужно просто иметь некий слепок базы, и непосредственно по ней строить репорты. Непонятно, зачем такие заморочки с выковыриванием изменений из логов аудита...

Слепок базы можно получать по раному, например, репликацией, или, как тут писали, AlwaysOn.
13 янв 14, 16:30    [15409116]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте плз по поводу архитектуры.  [new]
abrashka
Member

Откуда:
Сообщений: 521
Спасибо!
Какие варианты AlwaysOn могут быть приемлимы для данной задачи? О чем почитать?
Возможн ситуация, что грубо говоря началась продажа билетов на концерт какой-то звезды, продажи происходят в нескольких кассах одновременно, база одна, таблицы интенсивно изменяются, в это время кто-то хочет посмотреть отчеты: сколько билетов продали на определенный концерт, сколько всего продаж, какие суммы,цены, свободные места и т.п. Отчеты могут быть достаточно сложные.
Каким образом можно обеспечить нормальную работу в таких ситуациях?
15 янв 14, 22:26    [15421767]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте плз по поводу архитектуры.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31912
abrashka
Какие варианты AlwaysOn могут быть приемлимы для данной задачи? О чем почитать?
Возможн ситуация, что грубо говоря началась продажа билетов на концерт какой-то звезды, продажи происходят в нескольких кассах одновременно, база одна, таблицы интенсивно изменяются, в это время кто-то хочет посмотреть отчеты: сколько билетов продали на определенный концерт, сколько всего продаж, какие суммы,цены, свободные места и т.п. Отчеты могут быть достаточно сложные.
Каким образом можно обеспечить нормальную работу в таких ситуациях?
Прочитайте про "Группы доступности AlwaysOn", "асинхронный режим"
http://msdn.microsoft.com/ru-ru/library/hh510230.aspx

У вас будет второй сервер, специально для отчётных запросов, обращения к которому не будут влиять на работу приложения с оперативной базой.
16 янв 14, 08:46    [15422716]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте плз по поводу архитектуры.  [new]
invm
Member

Откуда: Москва
Сообщений: 9785
abrashka
Какие варианты AlwaysOn могут быть приемлимы для данной задачи?
В 2008 R2 нет AlwaysOn.

Т.к. у вас все крутится на одном сервере, можете попробовать включить на оперативной БД RCSI и выполнять отчеты напрямую в ней. Ну и про индексированные представления для агрегирования не стоит забывать.
16 янв 14, 10:33    [15423192]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте плз по поводу архитектуры.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31912
invm
abrashka
Какие варианты AlwaysOn могут быть приемлимы для данной задачи?
В 2008 R2 нет AlwaysOn.
А, ну да, 2008R2...

Репликацию ещё можно испоьзовать.
16 янв 14, 15:47    [15425394]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте плз по поводу архитектуры.  [new]
invm
Member

Откуда: Москва
Сообщений: 9785
alexeyvg
Репликацию ещё можно испоьзовать.
Репликация на одном сервере может быть накладнее, чем RCSI на оперативной БД и отчеты там же.
16 янв 14, 16:35    [15425661]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте плз по поводу архитектуры.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31912
invm
alexeyvg
Репликацию ещё можно испоьзовать.
Репликация на одном сервере может быть накладнее, чем RCSI на оперативной БД и отчеты там же.
Не, конечно, речь о двух серверах.

Иначе не имеет смысла, само собой.
16 янв 14, 17:16    [15425907]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте плз по поводу архитектуры.  [new]
invm
Member

Откуда: Москва
Сообщений: 9785
alexeyvg
Не, конечно, речь о двух серверах.
Насколько я понял, ТСу нужно решение в рамках одного сервера.
16 янв 14, 17:46    [15426034]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте плз по поводу архитектуры.  [new]
Александр52
Member

Откуда: Кокосовые острова ส็็็็็
Сообщений: 5136
WarAnt
abrashka,

AlwaysOn

2008 R2!
16 янв 14, 18:25    [15426202]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте плз по поводу архитектуры.  [new]
Александр52
Member

Откуда: Кокосовые острова ส็็็็็
Сообщений: 5136
Если БД постоянно меняется - реплика сразу отпадает.
1. Самописная синхра на insert/update/delete между группой серверов, на системе отслеживания изменений - вполне решение. + Sphinxsearch если нужен быстрый поиск.
2. Как вариант SSAS - но в нем без знаний трудно разобраться. Понадобится специалист.
16 янв 14, 18:29    [15426225]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте плз по поводу архитектуры.  [new]
abrashka
Member

Откуда:
Сообщений: 521
Большое спасибо!
К сожалению у некоторых клиентов всего один сервер, но если установка дополнительного сервера решит многие проблемы- то есть над чем подумать.
Какой тип репликации может подойти для этой задачи?
20 янв 14, 11:29    [15439296]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить