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

28.06.12

База данных - HighLoad оптимизация

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

Итог:

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

См. также

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    2975    spyke    26    

42

Быстродействие типовой 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    5107    vasilev2015    19    

37

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7634    158    ZAOSTG    67    

96

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5977    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8868    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    5105    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

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

11.10.2023    16183    skovpin_sa    14    

98
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. SergDi 28.06.12 12:01 Сейчас в теме
2,5 млн o_O ?
хорошая идея
8. hogik 443 28.06.12 17:04 Сейчас в теме
(1)(3)
Интереснее посчитать в другую сторону. ;-)
2 500 000 / 24 / 60 / 60 = 29 в секунду.
Цена используется в "Управление торговлей".
Если с такой скоростью меняется цена, то на это не сможет "реагировать" ни покупатель, ни продавец. Думаю, на самом деле цена не меняется, а записывается в базу многократно одинаковые значения. Что есть ошибка в алгоритме обработки цен и/или схеме базы данных.
9. Iaskeliainen 384 28.06.12 17:24 Сейчас в теме
(8) hogik, Надо учить мат часть.
Запись в регистре сведений цены номенклатуры записываються с переодичностью - день.
Значит сама платформа будет ругаться, если записывать вторую цену в течении одного дня!!!
Просто большой справочник номеклатуры. А думаю не меньший справочник в комусе или озоне.
А дальше все зависит много от чего. Например, варианты:
1) мы по какомому алгоритму каждый день пересчитываем цены, например от курса ЦБ.
2) мы перепродаем товар других фирм, они нам шлют каждый день свой новый прайс.
и тд и тп.
Может у вас быть сразу все варианты? Все возможно.
Зачем нам хранить столько цен?
Вроде все логично, что бы потом можно было разобрать, почему была цена именно такая в момент покупки/продажи.
10. hogik 443 28.06.12 18:29 Сейчас в теме
(9)

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

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

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

У нас, есть такая потребность сохранять все цены. Задача решена. Всё ОК.
У многих хуже и без таких сложных задач.
Например, не закрываются регистры, когда должны и таблицы итогов пухнут, но не кому до этого дела нет, пока место не кончиться.
12. hogik 443 28.06.12 21:30 Сейчас в теме
(11)
"Не нравиться, так и напиши."(с)
Очень нравится. ;-) Отличное решение. Я его, даже, и не обсуждаю.
Вам задан простой вопрос в развернутой форме. Флудом. :-)
Вы уверены, что требуется "сохранять все цены" таким "лобовым" способом?
Лично у меня вызвало недоумение не Ваше решение, а сама задача.
15. Iaskeliainen 384 29.06.12 09:28 Сейчас в теме
(12) hogik, спасибо за вопросы.
"Цены хранить в некоторой у.е. без пересчета" - не получается.

Я знаю что некоторые из поставщиков считают свой прайс от у.е. по курсу ЦБ или своего банка "+" какой то процент. Некоторые еще применяют метод устанения дребезга цен (это если новая цена отличается от старой всего на 1%, то оставить старую. Порог у каждого свой).
Идея конечно была привязаться и к этому, но после месяца анализа цен выяснилось, что они могут менять свои формулы расчета, в итоге из-за этого у нас тоже переставало работать коррекно. Понятно и так, что секретов нам не кто раскрывать не будет кто как считает.
16. zfilin 2337 05.07.12 18:34 Сейчас в теме
(8) hogik, Та, не. Вы количество записей на количество позиций номенклатуры (а может еще и на количество категорий цен) поделите, а потом уже на время. А-то со здоровой номенклатурой, если так "в лоб" делить, то не то что 29 раз в секунду, и больше может быть. =)
RustIG; Iaskeliainen; +2 Ответить
2. recon 38 28.06.12 13:15 Сейчас в теме
Эммм... Пометили на удаление документы и плакали наши цены ?
4. Поручик 4670 28.06.12 13:38 Сейчас в теме
Уменьшить размер базы помогает очистка регистра сведений СписанныеТовары от записей закрытого периода.

(2) Неактуальные цены почему бы не удалять?
7. Iaskeliainen 384 28.06.12 13:58 Сейчас в теме
(4) Поручик, у каждого своя специфика.
Анализ размеров таблиц показал, что проблемное место у нас "цены номенклатуры".
Возможно, со временем придется бороться и с другими таблицами.
5. Iaskeliainen 384 28.06.12 13:51 Сейчас в теме
(2) recon, Не внимательно читаем батенька.
"Еще не забываем очистить потом табличные части документов, тех которые уже были созданы."
Зачем же в итоге повторять текст статьи который выше написан.
3. tormozit 7136 28.06.12 13:17 Сейчас в теме
2 500 000 * 365 = 912 500 000,
Миллиард записей к концу года. Может быть автор преувеличивает?
6. Iaskeliainen 384 28.06.12 13:54 Сейчас в теме
(3) tormozit, примерно так и было.
Правда там выпадали выходные и праздничные дни.
Проблема возникла после 3 месяцев использования, новой системы хранения цен.
Но быстро была решена. См.текст публикации.
13. Psylocibine 29.06.12 08:08 Сейчас в теме
Интересное решение, не хочется даже вникать, зачем такое количество записей в базе, просто на заметочку возьму)
А как выявляли проблемные места? Что использовали для анализа таблиц?
14. Iaskeliainen 384 29.06.12 09:24 Сейчас в теме
(13) Psylocibine, можно поискать тут или в инете.
Я когда то давно позаимствовал идею подпилил для себя.

Думаю вам подойдут и то что предлогаю тут:
Для файловой - http://infostart.ru/public/82178/
Для SQL - http://infostart.ru/public/95193/
artbear; RustIG; hogik; +3 Ответить
Оставьте свое сообщение