gifts2017

Оптимизация размера базы данных

Опубликовал Матти Нюкянен (Nykyanen) в раздел Администрирование - Оптимизация БД (HighLoad)

В базе Управление Торговлей 10 хранилось много цен, порядка 2,5 млн новых записей ежедневно. Встал вопрос оптимизации размеров ИБ.

Как обычно все гениальное просто!

Так как данные хранились 2 раза в документе и регистре, а все стандарные функции работают именно с регисрами, появилась мысль не хранить цены в документах, а просто отображать то что уже есть в регистре. Второй "+" ни чего конвертировать не надо.

Копируем документ "Установка цен номенклатуры" убиваем табличную часть.

Добавляем табличную часть в которую будет выводиться регистр сведений набор записей "ЦеныНоменклатуры".

При открытии формы добавляем

Если не ЭтоНовый() Тогда
   ЦеныНоменклатуры.Отбор.Регистратор.Установить(Ссылка);
   ЦеныНоменклатуры.Прочитать();
Иначе
   ЦеныНоменклатуры.Отбор.Регистратор.Установить(Документы.УстановкаЦенНоменклатуры1.ПустаяСсылка());
КонецЕсли;

После записи в форме

Если ЦеныНоменклатуры.Отбор.Регистратор.Значение= Документы.УстановкаЦенНоменклатуры1.ПустаяСсылка() Тогда
   ЦеныНоменклатуры.Отбор.Регистратор.Установить(Ссылка);
КонецЕсли;

Для Каждого
Запись из ЦеныНоменклатуры Цикл
   Запись.Регистратор = Ссылка;
   Запись.Период = Дата;
КонецЦикла;

ЦеныНоменклатуры.Записать();

 

Еще не забываем очистить потом табличные части документов, тех которые уже были созданы. Что бы место освободилось.

 

Добавляем красивости:

1) Можно разрешить редактирование регистра из документа с внесением информации о корректировках в журнал регистрации или в регистр истории, если таковой имеется.

2) Если у вас было несколько типов цен, то в документе раньше показывалась одна строка с несколькими типами цен, можно сделать запросом и выводить в подобную таблицу. Не знаю насколько это актуально, мне кажется проще провести сортировку по номенклатуре при открытии.

Что еще можно сделать:

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

Итог:

После очистки документов размер сократился почти в 2 раза, после проверки с последней ценой еще % на 60.
В целом размер (документ установка цен номеклатуры + регистр сведений цены номенклатуры) сократился в 5 РАЗ!!!

Скачать файлы

Наименование Файл Версия Размер
То же самое в формате Word 12
.doc 27,00Kb
28.06.12
12
.doc 27,00Kb Скачать

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Serg Kondrasgov (SergDi) 28.06.12 12:01
2. Олег Кострицын (recon) 28.06.12 13:15
Эммм... Пометили на удаление документы и плакали наши цены ?
3. Сергей Старых (tormozit) 28.06.12 13:17
2 500 000 * 365 = 912 500 000,
Миллиард записей к концу года. Может быть автор преувеличивает?
4. Сергей Ожерельев (Поручик) 28.06.12 13:38
Уменьшить размер базы помогает очистка регистра сведений СписанныеТовары от записей закрытого периода.

(2) Неактуальные цены почему бы не удалять?
5. Матти Нюкянен (Nykyanen) 28.06.12 13:51
(2) recon, Не внимательно читаем батенька.
"Еще не забываем очистить потом табличные части документов, тех которые уже были созданы."
Зачем же в итоге повторять текст статьи который выше написан.
6. Матти Нюкянен (Nykyanen) 28.06.12 13:54
(3) tormozit, примерно так и было.
Правда там выпадали выходные и праздничные дни.
Проблема возникла после 3 месяцев использования, новой системы хранения цен.
Но быстро была решена. См.текст публикации.
7. Матти Нюкянен (Nykyanen) 28.06.12 13:58
(4) Поручик, у каждого своя специфика.
Анализ размеров таблиц показал, что проблемное место у нас "цены номенклатуры".
Возможно, со временем придется бороться и с другими таблицами.
8. Владимир (hogik) 28.06.12 17:04
(1)(3)
Интереснее посчитать в другую сторону. ;-)
2 500 000 / 24 / 60 / 60 = 29 в секунду.
Цена используется в "Управление торговлей".
Если с такой скоростью меняется цена, то на это не сможет "реагировать" ни покупатель, ни продавец. Думаю, на самом деле цена не меняется, а записывается в базу многократно одинаковые значения. Что есть ошибка в алгоритме обработки цен и/или схеме базы данных.
9. Матти Нюкянен (Nykyanen) 28.06.12 17:24
(8) hogik, Надо учить мат часть.
Запись в регистре сведений цены номенклатуры записываються с переодичностью - день.
Значит сама платформа будет ругаться, если записывать вторую цену в течении одного дня!!!
Просто большой справочник номеклатуры. А думаю не меньший справочник в комусе или озоне.
А дальше все зависит много от чего. Например, варианты:
1) мы по какомому алгоритму каждый день пересчитываем цены, например от курса ЦБ.
2) мы перепродаем товар других фирм, они нам шлют каждый день свой новый прайс.
и тд и тп.
Может у вас быть сразу все варианты? Все возможно.
Зачем нам хранить столько цен?
Вроде все логично, что бы потом можно было разобрать, почему была цена именно такая в момент покупки/продажи.
10. Владимир (hogik) 28.06.12 18:29
(9)

"Надо учить мат часть."(с)
МатЧасть - это 1С и её регистры? :-)
Я обратил Ваше внимание на задачу - как она есть.
А не как она сделана в некой системе (конфигурации).

"что бы потом можно было разобрать, почему была цена именно такая в момент покупки/продажи"(с)
Если проводить анализ цен в "мировом" масштабе, то в базе можно сохранять еще больше, чем 2.5 миллиона записей в день. ;-) А в момент "покупки/продажи" используется конкретная цена продажи "соотнесенная" с ценой конкретной закупки. Реальная цена продажи и закупки не может меняться с такой скоростью. Сумма конкретной продажи может меняться, например, из-за скидки, формы оплаты, объема закупки и т.д. Но, эта информация не о цене, а о конкретной сделке. И хранится она, надеюсь, в другом месте.
А если требуется провести анализ (сравнение) цен конкретной сделки Вашей конторы с ценами на рынке вообще, то совершенно не требуется их хранить, например, с ежедневным пересчетом по курсу ЦБ. Т.е. это другая задача, алгоритм, схема базы данных...
11. Матти Нюкянен (Nykyanen) 28.06.12 20:06
(10) hogik, если тебе хочется пофлудить, найди другую тему.
Не нравиться, так и напиши. Только сначала прочитай о том, что комментируешь.

"А не как она сделана в некой системе (конфигурации)." - в публикации написано "В базе Управление Торговлей 10".
Цена покупки/продажи, скидка сохраняется, в документе.
Если тебе хочется, можешь <<проводить анализ цен в "мировом" масштабе">>.

У нас, есть такая потребность сохранять все цены. Задача решена. Всё ОК.
У многих хуже и без таких сложных задач.
Например, не закрываются регистры, когда должны и таблицы итогов пухнут, но не кому до этого дела нет, пока место не кончиться.
12. Владимир (hogik) 28.06.12 21:30
(11)
"Не нравиться, так и напиши."(с)
Очень нравится. ;-) Отличное решение. Я его, даже, и не обсуждаю.
Вам задан простой вопрос в развернутой форме. Флудом. :-)
Вы уверены, что требуется "сохранять все цены" таким "лобовым" способом?
Лично у меня вызвало недоумение не Ваше решение, а сама задача.
13. Дмитрий Леонов (Psylocibine) 29.06.12 08:08
Интересное решение, не хочется даже вникать, зачем такое количество записей в базе, просто на заметочку возьму)
А как выявляли проблемные места? Что использовали для анализа таблиц?
14. Матти Нюкянен (Nykyanen) 29.06.12 09:24
(13) Psylocibine, можно поискать тут или в инете.
Я когда то давно позаимствовал идею подпилил для себя.

Думаю вам подойдут и то что предлогаю тут:
Для файловой - http://infostart.ru/public/82178/
Для SQL - http://infostart.ru/public/95193/
artbear; Rustig; hogik; +3 Ответить
15. Матти Нюкянен (Nykyanen) 29.06.12 09:28
(12) hogik, спасибо за вопросы.
"Цены хранить в некоторой у.е. без пересчета" - не получается.

Я знаю что некоторые из поставщиков считают свой прайс от у.е. по курсу ЦБ или своего банка "+" какой то процент. Некоторые еще применяют метод устанения дребезга цен (это если новая цена отличается от старой всего на 1%, то оставить старую. Порог у каждого свой).
Идея конечно была привязаться и к этому, но после месяца анализа цен выяснилось, что они могут менять свои формулы расчета, в итоге из-за этого у нас тоже переставало работать коррекно. Понятно и так, что секретов нам не кто раскрывать не будет кто как считает.
16. Александр Лапшин (zfilin) 05.07.12 18:34
(8) hogik, Та, не. Вы количество записей на количество позиций номенклатуры (а может еще и на количество категорий цен) поделите, а потом уже на время. А-то со здоровой номенклатурой, если так "в лоб" делить, то не то что 29 раз в секунду, и больше может быть. =)
Rustig; Nykyanen; +2 Ответить