Leonid KudryavtsevЧасто структура учетных систем банально не удобна для составления сложных отчтетов. Время работы сложных отчтов до десятков минут вполне обычное явление.

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

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

Плюсы:
И учетную систему (OLTP) сильно не нужно ломать/уложнять
И "отчетчики" могут иметь данные в "приятной" структре

С одной стороны, совокупная сложность и стоимость вроде должна возрастать (3 системы вместо одной: OLTP, ETL, DWH), с другой стороны, сложность разработки/сопровождения и учетной системы (OLTP) меньше (т.к. выкидывается часть сложного отчетного функционала) и сложность разработки/сопровождения отчетов меньше. Если выгоды упрощения OLTP + DWH перевешивают стоимость создания ETL, то экономический резон уже появляется. Т.к. стоимость "OLTP без сложных отчетов" + ETL + DWH вполне может быть меньше, чем "OLTP с жутко навороченной отчетной системой."

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

IMHO & AFAIK по опыту
Все так, но вы забываете еще об одном минусе, когда OLTP и сложные отчеты "в одном флаконе".

Предположим, у нас есть:
L_argo 1С БД ок. 1Тб. 1,5тыс. конкурентных пользователей.
Сервер: 80ядер, 0,5Тб ОЗУ.
Работало временами тяжко , но лучше, чем многие тут пугают.
и в какой то не очень счастливый момент запускается 2-3 тяжелых отчета каждый на полчаса - час.
Я подозреваю, что пользователям станет не просто тяжело, а очень тяжело ...

Leonid Kudryavtsevs_ustinov...Я подозреваю, что пользователям станет не просто тяжело, а очень тяжело ...

На одном из проектов и 2-3 разных OLTP и OLAP система были на одном сервере. Когда дошли до ситуации из-за OLAP пользователям OLTP "очень тяжело", настроили Oracle Resource Manager. Если запрос выполнялся дольше 0.5 Сек - ему понижался приоритет, если дольше 15 секунд - приоритет полностью срезался до уровня плинтуса.

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

Настройка Oracle Resource Manager проблему решила полностью.

Note: На правах рекламы Oracle Resource Manager )))
Да, прикольно. )))
Но я так понимаю, для такого управления ресурсами все равно надо было разносить OLTP и OLAP по разным базам?
Или Oracle Resource Manager смотрел на длительность запроса независимо ни от чего? Но тогда ведь могли пострадать OLTP системы...

alex55555s_ustinovЗапасов таких на складе может быть на несколько миллионов (не рублей). И каждый год эта сумма обычно увеличивается. И в то же время у завода куча кредитов, по которым платятся нехилые проценты.
Ну и зачем нам тут втирать про убожество современных манагеров?
s_ustinovЭто называется - имитация бурной деятельности.
Ну знаток, чо...
s_ustinovПрактически любая ситуация, требующая анализа - требует доступа к детальным, не агрегированным данным.
А кто тебе сказал, что какие-то данные удаляются?
s_ustinovЯ подозреваю, что пользователям станет не просто тяжело, а очень тяжело ...
Так надо не подозревать, а реальные данные по тормозам иметь. Запускаем несколько тяжёлых отчётов и проверяем время базовых операций OLTP.

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

А по поводу реальных данных по тормозам...
Предположим, есть торговая фирма. Приходит начальник отдела продаж и говорит - мы продумываем варианты, как нам развить направление поставок под заказ. И надо посмотреть некоторые данные.
Например, вывести список заказов по каждому из клиентов, у кого за последние 2 года было как минимум 4 месяца, в которых были достаточно крупные (больше 5000 долларов) заказы заказных товаров (товар не является складским, на момент заказа в наличии на складах не более 10% от требуемого количества, подобных товаров в заказе должно быть не менее двух позиций и не менее 10 штук заказных товаров в заказе), при этом нам надо видеть сумму предоплаты по каждому заказу покупателя и разбивку по товарным группам (с суммами) для каждого заказа отдельно для складских товаров и отдельно для заказных.

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

Так вот, я почему то уверен, что у вас или не было подобных задач (начальство предпочитает принимать решения "на интуиции" или "и так все всё знают"), или же вы при возникновении подобных задач начинаете рассказывать байки, что нужно ТЗ по всем правилам, которое вы рассмотрите и включите в план на следующий месяц ну или что то в таком духе. :)
Иначе вы бы не рвались решать аналитические задачи на рабочей OLTP базе.

alex55555s_ustinovНапример, вывести список заказов по каждому из клиентов, у кого за последние 2 года было как минимум 4 месяца, в которых были достаточно крупные (больше 5000 долларов) заказы заказных товаров (товар не является складским, на момент заказа в наличии на складах не более 10% от требуемого количества, подобных товаров в заказе должно быть не менее двух позиций и не менее 10 штук заказных товаров в заказе), при этом нам надо видеть сумму предоплаты по каждому заказу покупателя и разбивку по товарным группам (с суммами) для каждого заказа отдельно для складских товаров и отдельно для заказных.
Ну я выше концепцию показал уже. Выбираем эти самые "заказные" товары, которых мало, а потом уже от них пляшем в сторону сумм и прочего. В итоге всё будет быстро.
s_ustinovПодобных запросов понадобится сделать пару - тройку десятков за несколько дней
Ну сколько там дней - это уже вопрос об идиотизме начальства. Хотят всё убить - ну вот вам OLAP и сами рисуйте свои запросы, убивайте ими производительность. Зато быстро.
s_ustinovОптимизировать такие запросы смысла нет - они одноразовые.
Оптимизация бывает двух типов - когда кто-то ранее написал "по быстрому" и это поделие переделывается, и второй тип - сразу пишут немного думая о сути. Так вот второй тип, пусть немного напрягая начальство со сроками (на самом деле не сильно, и даже иногда вообще незаметно из-за небольших затрат на модификацию готового отчёта для его расширения), даст хороший результат и для общей производительности системы. А если есть желание платить поменьше да получать всё "сей момент" - ну вот и будет таким желающим тормоз на тормозе. То есть вопрос опять упирается в тупость наверху.
s_ustinov Готовыми агрегированными данными не воспользуешься - данные в таких разрезах никому раньше не были интересны.
Открою страшную тайну - в БД можно делать временные таблицы, прямо в процессе создания отчёта .
s_ustinovинформации о том, будут тормоза или нет, и если будут, то какие - тоже нет - именно таких запросов к базе никто раньше не делал.
Вся информация есть. Вся. Абсолютно вся.

Но это если решением задачи занимается грамотный специалист, а не студент или аналитик, никогда не занимавшийся вопросами оптимизации.
s_ustinovИначе вы бы не рвались решать аналитические задачи на рабочей OLTP базе.
Я не рвусь, я просто констатирую - возможность есть. Поэтому я задаю детский вопрос - что лучше, простая и понятная система или несколько сложных и непонятных? И выбираю первый вариант. Хотя да, для его создания нужен специалист. А ему нужно платить, да. А далее каждый сам решает - будет он оплачивать несколько дорогих спецов или вместо них будет финансировать зоопарк из кучи систем с миллионом студентов для их обслуживания.
"Эффективный менеджер" + "грамотный специалист" = "команда мечты"


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

Меня вот другое ваше высказывание заинтересовало.
alex55555s_ustinovинформации о том, будут тормоза или нет, и если будут, то какие - тоже нет - именно таких запросов к базе никто раньше не делал.
Вся информация есть. Вся. Абсолютно вся.
Нельзя ли как то раскрыть это утверждение?
Даже если на сервере работает один пользователь, который выполняет один запрос (влияния на производительность запросов других пользователей нет) - время выполнения запроса и нагрузка на сервер СУБД очень сильно зависит от количества записей, которые сервер должен обработать на каждом этапе выполнения.
Как именно вы, глядя на текст запроса, но не выполняя запрос , предсказываете, сколько записей будет удовлетворять некоторым условиям? Например, из миллиона строк заказов сколько будут удовлетворять условию "товар не является складским, на момент заказа в наличии на складах не более 10% от требуемого количества" - тысяча, 10 тысяч или может 500 тысяч? При условии, что такой запрос раньше никогда не выполнялся.
Прямое подключение к ноосфере? Или интуиция?

H5N1s_ustinovНельзя ли как то раскрыть это утверждение?
Даже если на сервере работает один пользователь, который выполняет один запрос (влияния на производительность запросов других пользователей нет) - время выполнения запроса и нагрузка на сервер СУБД очень сильно зависит от количества записей, которые сервер должен обработать на каждом этапе выполнения.
Как именно вы, глядя на текст запроса, но не выполняя запрос , предсказываете, сколько записей будет удовлетворять некоторым условиям? Например, из миллиона строк заказов сколько будут удовлетворять условию "товар не является складским, на момент заказа в наличии на складах не более 10% от требуемого количества" - тысяча, 10 тысяч или может 500 тысяч? При условии, что такой запрос раньше никогда не выполнялся .
Прямое подключение к ноосфере? Или интуиция?

ну на самом деле у взрослой субд все же есть cost based оптимизатор и статистики. по таблицам храниться селективность полей, соответственно оптимизатор в некоторых случаях вполне способен предсказать порядок какой выйдет из джоина и фильтра по предикатам. но когда там десятки джоинов, сложность возрастает и по факту в тяжелых запросах оптимизатор начинает жестко тупить и начинаются танцы с переписыванием запроса и хинтами.
Да, оптимизатор может на основе индексов и статистик сделать некоторые предсказания и оптимизировать запрос. Но ему для этого нужны эти самые индексы и статистики. А их в подобных случаях часто нет. Просто никто данные в таком разрезе не анализировал.
Более того, задача оптимизатора - выбрать близкий к оптимальному план выполнения запроса, а не точно рассчитать "трудоемкость" запроса. И даже если он идеально выполнит свою задачу - выберет самый оптимальный план - мы все равно не будем знать, сколько именно времени будет выполняться запрос.

alex55555s_ustinovОсновная идея понятна - если бизнес желает видеть некоторые данные в течении часа - двух (время написания и выполнения запроса) - они тупые.
В общем - да. Затраты на выделенное хранилище исключительно для ублажения мальчиков, которым вынь да положь - да, это про откровенно тупых.
s_ustinovПредлагаю на этом прекратить обсуждение DWH и OLAP
Ну как хочешь.
s_ustinovКак именно вы, глядя на текст запроса, но не выполняя запрос
Во первых - я уже выполнял кучу запросов, во вторых, я немного знаю про механизмы их выполнения, ну и в третьих, если даже я чего-то не знаю про данные, то я узнаю это одним запросом (не убивающим сервер, разумеется) .

alex55555 в БД можно делать временные таблицы, прямо в процессе создания отчёта.

alex55555 Я не рвусь, я просто констатирую - возможность есть.



Есть очень хороший анекдот на эту тему:

Девушка идет по улице. Видит - посреди газона стоит парень в водолазном костюме и косит траву.
- Слушай, зачем ты так оделся? Жара ведь, упаришься...
- Мы, комсомольцы, не привыкли бегать от трудностей! Мы их сначала сами себе создадим, а потом с ними героически боремся!
- Хватит херней страдать - пошли лучше потрахаемся...
- Ну пошли, но только стоя, в гамаке и противогазе!

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

alex55555Вообще есть одна сущность - текущее количество денег. И по ней есть история. А уж как там отдельная операция трактуется - плевать , ибо в сумме они все дают точный результат на конкретную дату. Хотя при этом могут быть дополнительные таблицы для учёта деталей авансирования и прочих сторно/отмен, но они лишь расшифровывают смысл одной записи в таблице "счёт". То есть отчёт по счёту в большинстве случаев делается по одной таблице, а за расшифровками лезем лишь когда отчёт по некому контрагенту требует расшифровки смысла его операций, но тогда и количество операций будет небольшим, что опять не даёт нагрузку на БД.
Сразу видно "грамотного специалиста". Явно с большим опытом создания подобных отчетов...

Например, нужен очень простой с виду отчет за некоторый период:
- Покупатель
- Заказ
- Номер отгрузки (в рамках заказа)
- Дата отгрузки
- Сумма продажи (финальная, с учетом всех корректировок)
- Маржа
- Срок оплаты (дни), зафиксированный в инвойсах. (Средневзвешенный, может быть несколько разных инвойсов - предварительный, финальный, инвойсы могут быть отменены, у одного инвойса может быть несколько сроков оплаты - при этом надо учитывать только инвойсы, по которым "закрывалась" задолженность, сроки платежа, указанные в отсторнированных инвойсах, надо игнорировать)
- Фактический срок оплаты (Тоже средневзвешенный, может быть отрицательным, если была предоплата)
- Просрочка платежа (опять же - средневзвешенная только по инвойсам, по которым фактически закрывалась задолженность, отсторнированные не учитываем)

То есть вполне может быть следующая ситуация:
Выставили предварительный инвойс с двумя сроками платежа - 5 банковских дней 90% суммы и 10 % после выставления финального инвойса. Пришла оплата 90%. Потом выставили финальный инвойс с немного другой (уточненной) суммой, чем в предварительном инвойсе, по нему заплатили оставшуюся часть денег (которая не равна 10% предварительного инвойса, так как общая сумма поменялась). Еще через некоторое время покупатель выставил претензию, отсторнировали финальный инвойс и выставили новый инвойс с откорректированной (уменьшенной) суммой, но деньги не вернули, а зачли в счет оплаты по другому инвойсу и другому заказу. И для того другого инвойса сроком поступления денег необходимо считать не дату кредит ноты, которой закрыли часть задолженности, а дату фактического платежа.
Пример, кстати, реальный. )))

Расскажи, как правильно делать такой отчет без "трактовки отдельных операций"?

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

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

Ну тебе я советовать что-то представить не буду. Бесполезно.

Лучше еще раз процитирую:
alex55555Leonid KudryavtsevПо памяти, для отчетов обычно получается очень сложная связь начисления/счета - оплаты. С учетом всяких сторнировок, отмен, авансов, зачетов авансов и прочего и прочего (как с одной так и с другой стороны).
Вообще есть одна сущность - текущее количество денег. И по ней есть история. А уж как там отдельная операция трактуется - плевать, ибо в сумме они все дают точный результат на конкретную дату. Хотя при этом могут быть дополнительные таблицы для учёта деталей авансирования и прочих сторно/отмен, но они лишь расшифровывают смысл одной записи в таблице "счёт". То есть отчёт по счёту в большинстве случаев делается по одной таблице, а за расшифровками лезем лишь когда отчёт по некому контрагенту требует расшифровки смысла его операций, но тогда и количество операций будет небольшим, что опять не даёт нагрузку на БД.
Я надеюсь, "грамотные специалисты" умеют читать?
Так вот, в сообщении Leonid Kudryavtsev говорилось про отчеты в целом. Я понимаю, что у тебя нет большого опыта создания отчетов. Поэтому просто поверь на слово - если фигурируют слова "начисления/счета - оплаты" - очень часто речь идет не только о суммах.
И часто вот тут то и вылазит "очень сложная связь".
Я надеюсь, это не слишком сложная мысль для "грамотного специалиста"?