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

28.06.12

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

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование		По подписке [?]	Купить один файл
То же самое в формате Word .doc 27,00Kb 12	12	Скачать (1 SM)	Купить за 1 850 руб.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог:

После очистки документов размер сократился почти в 2 раза, после проверки с последней ценой еще % на 60.

В целом размер (документ установка цен номеклатуры + регистр сведений цены номенклатуры) сократился в 5 РАЗ!!!

+10 –

См. также

Поиск и анализ длительных вызовов - CALL, SCALL

HighLoad оптимизация Технологический журнал Системный администратор Программист Бесплатно (free)

Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.

24.06.2024 5140 ivanov660 12

Что не так с методом ЗаполнитьЗначенияСвойств

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

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024 9260 Evg-Lylyk 61

[Замер] Кто самый быстрый в конфигураторе?

HighLoad оптимизация Механизмы платформы 1С Системный администратор Программист Стажер Платформа 1С v8.3 Бесплатно (free)

Сравним «Регистры сведений» с «Сервисами интеграции» и узнаем, кто быстрее!

28.03.2024 5006 dsdred 23

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

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

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

13.03.2024 5097 spyke 28

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

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

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

13.03.2024 7573 vasilev2015 20

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

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

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

2 стартмани

15.02.2024 12422 241 ZAOSTG 80

115

Переход на Clickhouse для анализа метрик

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

Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать! В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.

1 стартмани

24.01.2024 5669 glassman 18

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

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

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

09.01.2024 14018 doom2good 49

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

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 385 28.06.12 17:24 Сейчас в теме

(8) hogik, Надо учить мат часть.
Запись в регистре сведений цены номенклатуры записываються с переодичностью - день.
Значит сама платформа будет ругаться, если записывать вторую цену в течении одного дня!!!
Просто большой справочник номеклатуры. А думаю не меньший справочник в комусе или озоне.
А дальше все зависит много от чего. Например, варианты:
1) мы по какомому алгоритму каждый день пересчитываем цены, например от курса ЦБ.
2) мы перепродаем товар других фирм, они нам шлют каждый день свой новый прайс.
и тд и тп.
Может у вас быть сразу все варианты? Все возможно.
Зачем нам хранить столько цен?
Вроде все логично, что бы потом можно было разобрать, почему была цена именно такая в момент покупки/продажи.

10. hogik 443 28.06.12 18:29 Сейчас в теме

(9)

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

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

11. Iaskeliainen 385 28.06.12 20:06 Сейчас в теме

(10) hogik, если тебе хочется пофлудить, найди другую тему.
Не нравиться, так и напиши. Только сначала прочитай о том, что комментируешь.

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

У нас, есть такая потребность сохранять все цены. Задача решена. Всё ОК.
У многих хуже и без таких сложных задач.
Например, не закрываются регистры, когда должны и таблицы итогов пухнут, но не кому до этого дела нет, пока место не кончиться.

12. hogik 443 28.06.12 21:30 Сейчас в теме

(11)
"Не нравиться, так и напиши."(с)
Очень нравится. ;-) Отличное решение. Я его, даже, и не обсуждаю.
Вам задан простой вопрос в развернутой форме. Флудом. :-)
Вы уверены, что требуется "сохранять все цены" таким "лобовым" способом?
Лично у меня вызвало недоумение не Ваше решение, а сама задача.

15. Iaskeliainen 385 29.06.12 09:28 Сейчас в теме

(12) hogik, спасибо за вопросы.
"Цены хранить в некоторой у.е. без пересчета" - не получается.

Я знаю что некоторые из поставщиков считают свой прайс от у.е. по курсу ЦБ или своего банка "+" какой то процент. Некоторые еще применяют метод устанения дребезга цен (это если новая цена отличается от старой всего на 1%, то оставить старую. Порог у каждого свой).
Идея конечно была привязаться и к этому, но после месяца анализа цен выяснилось, что они могут менять свои формулы расчета, в итоге из-за этого у нас тоже переставало работать коррекно. Понятно и так, что секретов нам не кто раскрывать не будет кто как считает.

16. zfilin 2352 05.07.12 18:34 Сейчас в теме

(8) hogik, Та, не. Вы количество записей на количество позиций номенклатуры (а может еще и на количество категорий цен) поделите, а потом уже на время. А-то со здоровой номенклатурой, если так "в лоб" делить, то не то что 29 раз в секунду, и больше может быть. =)

2. recon 39 28.06.12 13:15 Сейчас в теме

Эммм... Пометили на удаление документы и плакали наши цены ?

4. Поручик 4692 28.06.12 13:38 Сейчас в теме

Уменьшить размер базы помогает очистка регистра сведений СписанныеТовары от записей закрытого периода.

(2) Неактуальные цены почему бы не удалять?

7. Iaskeliainen 385 28.06.12 13:58 Сейчас в теме

(4) Поручик, у каждого своя специфика.
Анализ размеров таблиц показал, что проблемное место у нас "цены номенклатуры".
Возможно, со временем придется бороться и с другими таблицами.

5. Iaskeliainen 385 28.06.12 13:51 Сейчас в теме

(2) recon, Не внимательно читаем батенька.
"Еще не забываем очистить потом табличные части документов, тех которые уже были созданы."
Зачем же в итоге повторять текст статьи который выше написан.

3. tormozit 7229 28.06.12 13:17 Сейчас в теме

2 500 000 * 365 = 912 500 000,
Миллиард записей к концу года. Может быть автор преувеличивает?

6. Iaskeliainen 385 28.06.12 13:54 Сейчас в теме

(3) tormozit, примерно так и было.
Правда там выпадали выходные и праздничные дни.
Проблема возникла после 3 месяцев использования, новой системы хранения цен.
Но быстро была решена. См.текст публикации.

13. Psylocibine 29.06.12 08:08 Сейчас в теме

Интересное решение, не хочется даже вникать, зачем такое количество записей в базе, просто на заметочку возьму)
А как выявляли проблемные места? Что использовали для анализа таблиц?

14. Iaskeliainen 385 29.06.12 09:24 Сейчас в теме

(13) Psylocibine, можно поискать тут или в инете.
Я когда то давно позаимствовал идею подпилил для себя.

Думаю вам подойдут и то что предлогаю тут:
Для файловой - http://infostart.ru/public/82178/
Для SQL - http://infostart.ru/public/95193/