ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
14 сообщений из 14, страница 1 из 1
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39987545
Freincman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Freincman
Гость
Есть желание организовать считывание большого количества данных с реплики на чтение(read-only), затем там же рассчитать,
итоговые снимки сохранять уже на основной реплике.

Много написано, как настроить AlwaysOn, но мало по его использованию в качестве источника данных для отчетов.
AlwaysOn и слушателей мы настроили, SSRS нормально работает от реплики-read-only.

Но тяжёлая часть по чтению и расчету биллинг-данных, пока не разведена по репликам.
Подскажите, плиз, схему, как считать на одной реплике, закидывать результат на основную?
Обязательно ли через SSIS?

*снимки отчетов обычно храним таблице в поле формата XML
...
Рейтинг: 0 / 0
07.08.2020, 16:00
| Ответить | Цитировать | Написать  
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39987554
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
Freincman,

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

Отчеты делаются от Хранилища данных. От витрин.

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

Все эти извращения с репликами ведут в никуда.

Правильный подход описан здесь

https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/books/microsoft-data-warehouse-dw-toolkit/
...
Рейтинг: 0 / 0
07.08.2020, 16:15
| Ответить | Цитировать | Написать  
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39987556
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
Freincman,

SSIS - самое простое решение.
...
Рейтинг: 0 / 0
07.08.2020, 16:16
| Ответить | Цитировать | Написать  
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39987559
Freincman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Freincman
Гость
Да, костыль, прогиб под клиента и прочее.

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

BI не слишком тут подходит
...
Рейтинг: 0 / 0
07.08.2020, 16:17
| Ответить | Цитировать | Написать  
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39987573
Фотография miceonly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miceonly
Участник
Freincman
Биллингу нужны конечные цифры и отчеты расшифровки.

BI не слишком тут подходит

Я извиняюсь, а для чего тогда хранилища и BI нужны?
...
Рейтинг: 0 / 0
07.08.2020, 16:33
| Ответить | Цитировать | Написать  
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39987595
Freincman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Freincman
Гость
miceonly
Freincman
Биллингу нужны конечные цифры и отчеты расшифровки.

BI не слишком тут подходит

Я извиняюсь, а для чего тогда хранилища и BI нужны?



Согласен, что в идеале всё считать из хранилища и закидывать в кубы.
У нас есть небольшой опыт построения OLAP кубов и сбор данных.

Но! в этом процессе слишком много нюансов. Если положить допустим 15 сущностей с 30-50 атрибутами на измерения, которые частично используются для разных клиентов и соответственно отчетов, то схема-звезда заимеет очень много лучей.
Прописывание часто изменяемых условий для расчета требуемых Стоимостей, КПИ и прочего займёт года и кучу рукочасов.

Поэтому, в таком случае если и закидывать данные в хранилище, то уже частично посчитанные(сведенные к нескольким измерениям и фактам). А частично посчитанные данные не имеют расшифровки. Тогда смысл в Кубе и Хранилище, если из него не достать ключевых деталей.
...
Рейтинг: 0 / 0
07.08.2020, 16:52
| Ответить | Цитировать | Написать  
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39987598
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
Freincman

Кубы не подойдут, т.к. очень много естественных ключей.


Какая разница какие ключи в источнике. Надо строить модель на суррогатных ключах. Надо спроектировать ХД.

Если это скоростное что-то, то надо делать Operational Data Storage. Все равно вы упретесь в то, что понадобиться дополнительные справочники. Будет обвешивать индексами и т.п.
...
Рейтинг: 0 / 0
07.08.2020, 16:54
| Ответить | Цитировать | Написать  
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39987599
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
Freincman

Биллингу нужны конечные цифры и отчеты расшифровки.



Посмотрите вот это
YouTube Video
YouTube Video
...
Рейтинг: 0 / 0
07.08.2020, 16:55
| Ответить | Цитировать | Написать  
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39987607
Freincman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Freincman
Гость
a_voronin
Freincman

Кубы не подойдут, т.к. очень много естественных ключей.


Какая разница какие ключи в источнике. Надо строить модель на суррогатных ключах. Надо спроектировать ХД.

Если это скоростное что-то, то надо делать Operational Data Storage. Все равно вы упретесь в то, что понадобиться дополнительные справочники. Будет обвешивать индексами и т.п.



Ну, как бы пробовали у нас построить хранилище данных для складской выработки. Собирается всё отлично, замечательно, из разных источников.

Только вот посчитать красиво (при допустим ежемесячных изменениях фильтрации):
- на каком источнике данных
- какого типа операции
- какого клиента
- какого товара
- когда
- где
- чем
- с каким качеством
- etc
как выдавать расценку, трудозатратность и прочее - стало просто не реально.

Пришли к тому, что литься будут данные в ХД уже посчитанные группой преднастроенных датасэтов. Т.к. ведение логики вышеперечисленных в самом кубе приведёт к сумасшествию и конфликтам. Ну и потерям денег

в итоге думается будут храниться только ключевые вещи
код норматива-исполнитель-дата-стоимость-количество-время ну и небольшое прочее
...
Рейтинг: 0 / 0
07.08.2020, 17:09
| Ответить | Цитировать | Написать  
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39987609
Freincman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Freincman
Гость
штош, спасибо за наставления и внимание.

Буду думать...
...
Рейтинг: 0 / 0
07.08.2020, 17:12
| Ответить | Цитировать | Написать  
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39987615
Фотография miceonly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miceonly
Участник
Freincman
Но! в этом процессе слишком много нюансов. Если положить допустим 15 сущностей с 30-50 атрибутами на измерения, которые частично используются для разных клиентов и соответственно отчетов, то схема-звезда заимеет очень много лучей.
Прописывание часто изменяемых условий для расчета требуемых Стоимостей, КПИ и прочего займёт года и кучу рукочасов.

А у вас сейчас все считается "на лету"?
...
Рейтинг: 0 / 0
07.08.2020, 17:24
| Ответить | Цитировать | Написать  
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39987619
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
Freincman
a_voronin
пропущено...


Какая разница какие ключи в источнике. Надо строить модель на суррогатных ключах. Надо спроектировать ХД.

Если это скоростное что-то, то надо делать Operational Data Storage. Все равно вы упретесь в то, что понадобиться дополнительные справочники. Будет обвешивать индексами и т.п.



Ну, как бы пробовали у нас построить хранилище данных для складской выработки. Собирается всё отлично, замечательно, из разных источников.

Только вот посчитать красиво (при допустим ежемесячных изменениях фильтрации):
- на каком источнике данных
- какого типа операции
- какого клиента
- какого товара
- когда
- где
- чем
- с каким качеством
- etc
как выдавать расценку, трудозатратность и прочее - стало просто не реально.

Пришли к тому, что литься будут данные в ХД уже посчитанные группой преднастроенных датасэтов. Т.к. ведение логики вышеперечисленных в самом кубе приведёт к сумасшествию и конфликтам. Ну и потерям денег

в итоге думается будут храниться только ключевые вещи
код норматива-исполнитель-дата-стоимость-количество-время ну и небольшое прочее


Я делал миллиардные остатки с 20+ измерениями и кучей вычислений. Не понимаю, о каком сумасшествии идет речь. Вы не смогли правильно построить модель.

Я кстати сейчас рассматриваю предложения о работе. Пишите, если что на a_voronin собака list.ru Москва
...
Рейтинг: 0 / 0
07.08.2020, 17:33
| Ответить | Цитировать | Написать  
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39988053
Freincman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Freincman
Гость
miceonly
Freincman
Но! в этом процессе слишком много нюансов. Если положить допустим 15 сущностей с 30-50 атрибутами на измерения, которые частично используются для разных клиентов и соответственно отчетов, то схема-звезда заимеет очень много лучей.
Прописывание часто изменяемых условий для расчета требуемых Стоимостей, КПИ и прочего займёт года и кучу рукочасов.

А у вас сейчас все считается "на лету"?



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

Видео приложенное про лямбду очень интересное, но нам на лету - не надо)
...
Рейтинг: 0 / 0
10.08.2020, 09:29
| Ответить | Цитировать | Написать  
AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
    #39988054
Freincman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Freincman
Гость
a_voronin
Freincman
пропущено...



Ну, как бы пробовали у нас построить хранилище данных для складской выработки. Собирается всё отлично, замечательно, из разных источников.

Только вот посчитать красиво (при допустим ежемесячных изменениях фильтрации):
- на каком источнике данных
- какого типа операции
- какого клиента
- какого товара
- когда
- где
- чем
- с каким качеством
- etc
как выдавать расценку, трудозатратность и прочее - стало просто не реально.

Пришли к тому, что литься будут данные в ХД уже посчитанные группой преднастроенных датасэтов. Т.к. ведение логики вышеперечисленных в самом кубе приведёт к сумасшествию и конфликтам. Ну и потерям денег

в итоге думается будут храниться только ключевые вещи
код норматива-исполнитель-дата-стоимость-количество-время ну и небольшое прочее


Я делал миллиардные остатки с 20+ измерениями и кучей вычислений. Не понимаю, о каком сумасшествии идет речь. Вы не смогли правильно построить модель.

Я кстати сейчас рассматриваю предложения о работе. Пишите, если что на a_voronin собака list.ru Москва


у нас допустим измерений 20+*15, из них то, что нужно клиенту 10+.
За каждым следить и тем более кому либо давать в доступ и на каждое настраивать фильтр - не реально
...
Рейтинг: 0 / 0
10.08.2020, 09:32
| Ответить | Цитировать | Написать  
14 сообщений из 14, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / AlwaysOn - собрать с реплики-readonly, результат закинуть на реплику-readwrite
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=46&msg=39987609&tid=1685794]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 42ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 55ms
get tp. blocked users:
 2ms
others: 16ms
total:  163ms
созд. / загр.: 163ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]