В общем, переписал всю систему, работает уже больше месяца, вроде все хорошо и все довольны :)
Теперь вместо нескольких суток самый-самый большой упр.учет считается примерно час, плюс процессинг куба еще где-то полчаса-час.
К тому же система стала легко масштабируемой: любые дополнения и изменения прозрачны и вносятся легко и быстро.
Попробую описать понятней, что было и что сейчас.
Было:
- десяток т.фактов, объединенных union all
- на
каждую разноску был написан большой-большой запрос вида (здесь и скрывалось зло):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
insert into BigFacts
(...)
select ...
from
(select ... from Facts_2010 union all
...
select ... from Facts_2013) as f,
Clients c, Products p, ClientTypes ct, ......
where f.ClientId = c.id
and f.ProdId = p.id
...
<тут еще с десяток условий с or, and, in ()..., обслуживающий только один вид разносок>
group by ...
таких запросов было порядка 20-30. Плюс, если не было нужных отгрузок (например, клиенту Петрову
не отгружалась продукция группы "А" в феврале, а затраты были), мы смотрели отгрузки в прошлом (
до февраля) и вешали затраты на те прошлые отгрузки. Т.е. те же самые 20-30 запросов переписывались снова, но в конце вместо
1.
and f.Date between @date1 and @date2
было
а если отгрузок не было и в прошлом, то смотрели "в будущее" до текущего момента.
Т.е. одни и те же запросы повторялись по 3 раза с небольшими изменениями. И чтобы что-то добавить/скорректировать, приходилось долго все искать и перепроверять.
А сейчас в переписанном варианте подход совсем другой.
Сначала идет много подготовительных шагов с простыми запросами, потом собственно сам расчет (тоже оч.простой запрос).
Все разноски мы разбиваем на группы по клиентам и продукции. Для этого ввели справочник таких групп для клиентов и справочник для продукции примерно такого вида:
GroupIdClientId
GroupIdProdId
Для разноски вида "Расход 50тыр. Менеджер Петров, продукция группы А" мы заполняем группы по клиентам: выбираем всех клиентов, у которых менеджер Петров - это будет группа 1. У клиентов с менеджером Иванов будет группа 2 и т.д., пока не переберем все возможные группы в разносках (по менеджерам, по регионам, по сетям...).
То же по продукции: заполняем справочник групп на каждую группу продукции в разносках, перечисляя коды этой продукции.
Ну и в запись разноски добавляем два поля с кодами этих групп.
Вставка фактов занимает, как оказалось, совсем немного времени, когда запрос простой:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
insert into BigFacts
(...)
select ...
from
(select ... from Facts_2010 union all
...
select ... from Facts_2013) as f,
ClientGroups cg, ProdGroups pg, <разноски> r
where f.ClientId = cg.ClientId
and f.ProdId = pg.ProdId
and r.ClientGroupId = cg.GroupId
and r.ProdGroupId = pg.GroupId
and <условие выборки по датам: настоящее, прошлое, будущее>
т.е. этот запрос выше так же повторяется 3 раза, но это не 60 тяжеленных запросов (как раньше), а всего 3. Точнее даже 1, но динамический.
Плюс я все-таки использую курсоры, чтобы не вставлять весь миллиард записей сразу, а вставляю их по месяцам.
В общем, дополнительные подготовительные шаги рулят :) Лучше потратить "лишнее" время на подготовку данных и раскладывание по полочкам, чтобы потом использовать простые запросы с минимумом условий. Чем ковыряться в сырых данных с помощью тяжеленных запросов с кучей условий.
ПС. И этот час занимает
полный пересчет самого тяжелого упр.учета. Если пересчитывать только какие-то изменения, то время будет уходить еще меньше. Но для перестраховки пока пересчитываем все заново.
Новая система с достаточным кол-вом подготовительных шагов позволяет легко внести изменения в алгоритм. Так что если возникнет необходимость, ее можно будет легко дополнить и сделать пересчет только того, что изменилось.
