Каталог решений - Секционирование таблиц и индексов в мире 1С

Зачем все это

Файловые группы! Секционирование таблиц и индексов! Размещение таблицы на нескольких дисках! Собственные индексы для таблиц и другие замечательные возможности СУБД, которые платформа 1С не поддерживает "из коробки".

Все это применяется во многих других системах, но не у нас, ведь мы используем более продвинутые технологии:

• Нет смысла разделять базу, таблицы или индексы на отдельные файлы для распределения по дискам, ведь в век SSD это пустая трата времени.

• База стала большой, неповоротливой и с множеством ошибок в данных? Начнем жизнь с чистого листа (ну или почти с чистого) — свертка базы все решает!

• Ускорение бэкапирования за счет отказа от сохранения исторических данных в базе — тоже не про нас. Ведь бэкапировать один файл базы удобнее.

• Проблемы блокировок и неактуальных статистик вообще к нам не относятся, потому что платформа 1С сама все оптимизирует.

Уже сейчас на просторах нашей Родины все чаще можно встретить внедрения информационных систем на базе 1С с активным количество пользователей более 1000, а размером баз более 1 ТБ. Я думаю (или очень сильно надеюсь), что именно при подобных внедрениях работа с базами 1С меняется, а это привносит новые требования как к самой платформе, так и к необходимым компетенциям администраторов и разработчиков. Одним из таких требований является иной подход к обслуживанию базы данных, который нельзя сделать стандартными средствами платформы 1С. Как вы могли догадаться, речь идет о секционировании таблиц и индексов.

Одним из самых важных требований к обслуживанию больших, высоконагруженных баз является эффективная структура индексов, которую нельзя полностью создать средствами платформы 1С. Но об этом мы уже говорили в предыдущей статье "Создаем свои индексы для баз 1С. Со своей структурой и настройками!", поэтому сейчас на этом заострять внимание не будем.

Ниже поговорим об использовании секционирования таблиц и индексов в базах 1С, плюсах и минусах, подводных камнях и целесообразности.

Все, что будет ниже, относится к клиент-серверному режиму работы и рассматривается в контексте Microsoft SQL Server. Но, фактически, может быть использовано и на PostgreSQL.