alex55555s_ustinovДобавить памяти и процессоров часто означает другую версию СУБД. Например, если переходить с MS SQL Standard на Enterprise, цена отдельного нового сервера покажется очень незначительной.
Вообще говорить можно, но бесполезно. Надо конкретику. Сколько стоит хранилище и все сопутствующие затраты. Сколько стоит расширение мощностей БД, ну и сопутствующие, понятно. И потом сравнивать.
s_ustinovНу и сама идея запускать аналитические запросы на рабочей базе... Лично мне подобная идея кажется очень уж экстремальной.
В чём здесь проблема?

Если анализом занимается 1-2 человека, то что изменится для 1000 остальных? Особенно если память и прочее железо добавлены.

Хотя да, можно сгородить огород "каждому оператору по витрине данных", но это к откровенным идиотам, а не на форум программистов.
А вы хоть раз сами пробовали анализом заниматься? Или видели, как это другие делают?

Когда анализируешь данные, об оптимизации начинаешь думать только тогда, когда селект больше 15-20 МИНУТ выполняется. Данные за несколько лет (а не по одному документу, как обычно в OLTP), 20-30 соединений таблиц, вложенные подзапросы, outer apply и т.д... Догадываетесь, что могут сказать в этот момент остальные 1000 пользователей, которым надо товар отгружать, платежи учитывать и прочие нужные вещи делать?

Ivan DurakH5N1пропущено...

если учетная система не хранит исторических данных, то dwh и под единственную систему ценно. особенно если эта система какое-нить порно на 1с.
третий круг ...
ну тут еще есть вариант усовершенствавать единственную систему для этих целей.
Ну...
Вариант...
Хотел бы я поприсутствовать на совещании, где кто то предложит: "А давайте мы SAP допилим, чтобы он лучше хранил исторические данные..."

alex55555s_ustinovКогда анализируешь данные, об оптимизации начинаешь думать только тогда, когда селект больше 15-20 МИНУТ выполняется. Данные за несколько лет (а не по одному документу, как обычно в OLTP), 20-30 соединений таблиц, вложенные подзапросы, outer apply и т.д... Догадываетесь, что могут сказать в этот момент остальные 1000 пользователей, которым надо товар отгружать, платежи учитывать и прочие нужные вещи делать?
Повесить многопроцессорный сервер (да хотя бы всего с двумя ядрами) не так просто. И оракл и мс-скуль (ну и не только) умеют читать без блокировки всей таблицы, особенно если писатель запросов про это что-то знает.

В целом это просто наброс из серии "а я вот щас какую страшную историю расскажу!!!".

Собственно использование в качестве базы для всякого OLAP-а именно указанных БД немного говорит нам о надуманности вопроса "что могут сказать в этот момент остальные 1000 пользователей". Хотя да, какая-нибудь SAP может и виснет, по этим бегемотам я не спец. Но кто-ж заставляет сапу покупать? Только злобные буратины в собственном лице.
Вот что-что, а повесить (не в смысле остановить, а в смысле очень сильно замедлить и увеличить количество блокировок) как раз очень легко. :))

Вот интересно, а по какой из учетных систем ты спец? По 1С?
Ну тогда расскажи нам, как сейчас 1000 пользователей в одной базе 1С живет.

L_argos_ustinovНу тогда расскажи нам, как сейчас 1000 пользователей в одной базе 1С живет. У мну есть опыт общения с 1С БД ок. 1Тб. 1,5тыс. конкурентных пользователей.
Сервер: 80ядер, 0,5Тб ОЗУ .
Работало временами тяжко, но лучше, чем многие тут пугают. Много инфы было выведено в BI.
Почему то вспомнился их девиз - "Доступно и всерьез"...

Ivan DurakВ принципе стандартно жизненный цикл выглядит где-то так:
1 этап - Ну допилите уже вашу эту 1C/SAP/Siebel/Axapta/Saleforce whatever чтобы мне нормально отчетики показывала
2 этап - нет, хватит это терпеть, слишком долго - давайте мне выгрузку в эксель, сами запилим отчетик, прямо тут в экселе
3 этап - нет, хватит это терпеть, мы упарились руками эти эксели массажировать, давайте наймем раба - он нам автоматизирует
4 этап - ну и понеслось....
Причем четвертый этап как правило делится еще на несколько:
4.1 запилили отчетик на SQL на рабочей базе, и в процессе разработки / тестирования несколько раз подвесили систему на пол часа (+-)
4.2 (необязательный) хватит это терпеть, давайте добавим памяти / ядер / ssd дисков - при разработке очередного отчетика повесили систему на час... )))
4.3 хватит это терпеть - покупается отдельный сервер, делается асинхронная реплика базы и все отчетики делаются на копии базы, которая именуется гордым словом DWH. :)
4.4 добавляются разные задания по чистке данных и всяким пересчетам - и действительно появляется DWH.

Есть еще один вариант - начинают делать "правильную" DWH с правильной структурой данных, Slowly Changing Dimension, правильным софтом и железом и прочими плюшками настоящей DWH, потом начинают думать, как закачивать данные из работающей системы, потом начинают делать нужные отчетики (если доходят до этого этапа)... Но, как я слышал про несколько таких проектов - очень часто такие начинания завершаются фиаско...

L_argo очень часто такие начинания завершаются фиаско... А все потому, что это все по большому счету ненужно и без него бизнес все равно нормально функционирует. :)

Можно взять наугад любой завод, работающий хотя бы 30лет.
Какая там автоматизация ? Чаще всего примитивная, бумажная.
Почему ? Потому что автоматизация съест кучу денег и времени, а эффекта скорее всего никакого не даст. Будет только кратковременный вау-эффект.

Угу, берем такой завод.
И берем несколько заявок на запчасти, которые ремонтники выдают отделу закупок.
Если хорошенько поискать по складам - обычно минимум 30% запчастей из заявок пылиться уже несколько лет на складах. Но найти их крайне тяжело, так как все на бумажках и даже в бумажках названия - как придет в голову бухгалтерии.
Запасов таких на складе может быть на несколько миллионов (не рублей). И каждый год эта сумма обычно увеличивается. И в то же время у завода куча кредитов, по которым платятся нехилые проценты.

Но зато у завода есть куча "эффективных" менеджеров, которые вместо того, чтобы нормально наладить процесс, только и могут, что накричать на кладовщика...

alex55555softwarerодин сервер в одной базе, конечно, может обслуживать оба типа запросов, примерно как один человек может бегать одновременно спринты и марафоны. Но, начиная с какого-то уровня результатов, действительно целесообразно поделить такую нагрузку по двум разноплановым исполнителям.
Есть два варианта - работа "как всегда" и квалифицированная работа.

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

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

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

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

Ну и так, к слову, если бы наблюдавшиеся мной бегемоты слегка напряглись, то им вполне по силам сделать единую систему, без плохо стыкуемого зоопарка. И для DWH оставалось бы наполнение внешними данными, которые часто есть база для совсем независимой от самой конторы аналитики (типа биржевые данные или прогнозы по отраслям для инвестирования).
Это называется - имитация бурной деятельности.
Практически любая ситуация, требующая анализа - требует доступа к детальным, не агрегированным данным. Если у предприятия падает прибыль - невозможно сказать "прибыль, расти - раз, два!". Вернее, можно, но результат будет не очень.
Чтобы что-то менять - надо докапываться до факторов, которые можно изменить. А это всегда - конкретные заказы, инвойсы, товары и т.п.
И агрегированные данные при таком анализе мало чем помогают.

Жили-были мыши и все их обижали. Как-то пошли они к мудрому филину
и говорят:
— Мудрый филин, помоги советом. Все нас обижают, коты разные, совы.
Что нам делать?
Филин подумал и говорит:
— А вы станьте ёжиками. У ёжиков иголки, их никто не обижает.
Мыши обрадовались и побежали домой. Но по дороге одна мышка сказала:
— Как же мы станем ёжиками? — и все побежали обратно, чтобы задать
этот вопрос мудрому филину.
Прибежав, они спросили:
— Мудрый филин, а как же мы станем ёжиками?
И ответил филин:
— Ребята, вы меня ерундой не грузите. Я стратегией занимаюсь.