И вот делаю историзацию графиков в 1С. Графиков около 4000, каждый имеет около 40 строк(периодов-месяцев) и каждый пересчитывается один раз в месяц. Количество рассчитываемых колонок около 40. По подсчетам, при закрытии всех графиков получиться чуть больше 3 миллионов с четвертью записей в регистре сведений.
Насколько проблематично(время) работать с таким больших регистром, если он будет использоваться постоянно? Может у кого-то есть другие варианты решения, а то неохота время убивать? Спасибо


Рег. сведений 40 ресурсов, 4 измерения, подчинен регистратору.

1С 8.1 на PostgreSQL, Xeon 8 ядер(2,33Ггц), 4Гб ОЗУ – сервер

40 ресурсов.

Что ж вы там храните то?

40 ресурсов может быть только в учете ядерных реакций, наверняка нужно от них избавляться

Пересчеты по валюте, амортизация всяких комиссий, сам расчет, хорошая часть для МСФО и т.д.

Сам впервые ужаснулся :)

(0) сделай 5 измерений и 1 ресурс + перечисление с 40 значениями, которые будешь соват в пятое измерение. 40 ресурсов - это нечто за гранью добра и зла

+(4) а еще лучше - справочник

И вообще это все больше похоже на функционал регистров расчета

(4) Так тоже думал, но придется проделывать не очень удобные "махинации" с запросами

(6) А кто-то работал с 40 видами расчета? и выдержит ли он таких нагрузок?

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

(9)+ Насколько, мне известно, ресурсы не индексируются.

Ну, а то что их (ресурсов) много, достаточно вспомнить старые системы на DBF, где сплошь и рядом использовались таблицы по 255 колонок. И, вообще, быстренько наполнить регистр модельными данными и посмотреть как ведут себя запросы и куски кода, отвечающие за изменение данных регистра. Заодно и нам рассказать...

(0) Ничего страшного вроде нет. MS SQL бы справился. Postgre - не знаю.
Попробовать-то недолго.

(11) (12)
И так, регистр сведений имеет 4 измерения и 40 ресурсов, подчинен одному регистратору.

Логика:
1 измерение – контрагент
2 измерение – договор
3 измерение – график
4 измерение – период в графике

40 ресурсов – число 15.2

Тестовые данные:
Контрагентов – 100
Договоров на каждого контрагента – 10
Графиков на каждый договор – 4
Периодов в каждом графике – 50

Ресурсы  заполняются  случайными числами.

Условие:
В графиках каждый текущий и последующие периоды пересчитываются, то есть в первом периоде в движениях будет 40 строк, во втором – 39 и т.д., итого на график – (50+1)*25 = 1275 движений в рег. сведений.

100*10*4* 1275 = 5 100 000 движений

по моему ничего не пропустил...

Результаты будут позже

если кинете ваш тест, могу на своем серваке (он чуть послабее) потестировать
как тут http://gilev.blogspot.com/2010/09/db2-express.html

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

ЗЫ: если кто-то предложит свой вариант – можно протестировать

по идее, грузит только количество измерений, ака ключевых полей. а ресурсы - только место и траффик, если все запрашивать.

да, но результаты неутешительны...

Посоветую 5 измерений. Где 5-е измерение это номер ресурса (01-40), тогда ресурс будет один. Написать выборку и группировки будет быстрее.
Проверь, в Oracle такое решение работало в 5-10 раз быстрее. Правда никогда не выводилось по больше 20 000 записей. А база была за 300 миллионов записей.

Может и тут так же будет?

(18)придется и такое попробовать

добавить  глобальную функцию на серваке глПолучитьТаблицуИПеревернуть