Комментарии 17
По докладу Konotopov-1.pdf (pgconf.ru) складывается впечатление что там делают чтото свое
Но в любом случае
Когда смотришь документацию в деталях по Citus
Ingesting, Modifying Data (DML) — Citus 12.0 documentation (citusdata.com)
и цитаты Конотопова
Условия для OLTP 25 Требования
• Разбить данные и запросы равномерно по шардам
• Связанные данные локализовать в одном шарде
• Копию справочников разместить на каждом шарде Преобразование схемы:
• Первичные ключи распределенных таблиц и внешние ключи между двумя распределенными таблицами должны включать колонку объекта распределения
• Справочники сделать глобальными таблицами
• В запросах добавить фильтр по объекту распределени
понятно что нужно адаптировать платформу 1С под " and the select/insert statements both include the distribution column " . Сейчас не все важные метаданные (например Регистр бухгалтерии) позволяют шардирование
Очень водянисто. Если я правильно отжал воду, то автор банально предлагает включить партиционирование в БД. Вот такая мега-реструктуризаци. Аж потребовалась целая статья, что бы о ней сообщить, ну а заодно налить воды, вплоть до упоминания чата жпт и тому подобного.
Зачем столько текста о простейшей проблеме?
Если я правильно отжал воду, то автор банально предлагает включить партиционирование в БД. Вот такая мега-реструктуризаци. Аж потребовалась целая статья, что бы о ней сообщить,
Банально в платформе включить партицирование сейчас не получится. Даже если сделать свою конфигурацию на платформу без общих реквизитов, часть существенных метаданных (РегистрБухгалтерии, РегистрНакопления) партицировать не получится стандартными средствам.
вот простой пример.
Формально РегистрНакопления содержит поле Период по которому можно сделать партицирование. Но индексы, которые создает (и под которые оптимизированы запросы) выглядят так
А для партицирования нужно чтобы Partitioning column был обязательно ПЕРВЫМ в каждом индексе, иначе уже Truncate partition сделать не получится если там хотябы один индекс без этой колонки
Вы конечно можете поставить свои индексы на уровне СУБД, но запросы генерит платформа и в них уже вмешаться не получится
Поэтому шардинг это более простой выход для 1С, там тоже должна быть колонка для шардинга, но в зависимости от реализации структуру индексов можно сохранить
Полезная статья с грустной концовкой. Как раз стоит задача перелезть с 8.2 на 8.3 с базой 5Тб. Чешем репу.
Можете попробовать Оптимизация реструктуризации базы данных | 1С:Зазеркалье оптимизированный механизм который через Java. Тут он тоже описан. Вроде как заявленные ошибки исправили хотя могли появится и новые. Но для больших баз он может дать выигрыш если только правильно настроить СУБД как указано в статье.
Но опыт показывает что базы 5ТБ как правило содержат много архивных данных которые таскать не имеет смысла. Поэтому если почистить хотябы часть вот этим способом 1С БодиПозитив / Хабр - можно резко сократить время реструктуризации
P S Если не трудно напишите заметку к чему в итоге пришли
Напрашивается вариант:
1) делаем копию (её конвертируем хоть неделю) + включаем регистрацию изменений в рабочей базе для всех объектов
2) в технологическое окно переносим накопившиеся за неделю изменения рабочей базы в новую (та же ВыгрузкаЗагрузкаДанныхXML - можно запустить в несколько потоков, выбрав запросом изменения из таблиц обмена)
Надо тестировать - сколько времени займет перенос изменений. Если в 2 дня уложимся - можно успеть в новогодние праздники.
>включаем регистрацию изменений в рабочей базе для всех объектов
Если у Вас большие объемы, то механизм регистрации изменений в стандартной реализации БСП не обеспечивает параллельной выгрузки и загрузки. Кто нибудь сделает проведение за месяц и получите неперевариваемый объем.
Чистка средствами субд как описано в ссылке выше даст больше плюсов. Базу в любом случае нужно периодически освобождать от архивных данных, иначе с ростом объемов трудоемкость сопровождения будет постоянно расти. А тут есть причина
"не обеспечивает параллельной выгрузки и загрузки " - поэтому я и пишу: "выбрав запросом изменения из таблиц обмена ".
И выгрузка/загрузка своей обработкой.
К сожалению, чистить базу невозможно. Нет данных, которые можно удалить.
Обычно мы каждые 2 года сворачиваем базу (прямыми запросами). Но с появлением МДЛП и постоянными проверками Росздрава, половина базы - данные о маркировке, они нужны постоянно, за всю историю. Удалить можно в лучшем случае 25% от объема базы. Это погоды не сделает, зато создаст проблем.
Но с появлением МДЛП и постоянными проверками Росздрава, половина базы - данные о маркировке
Ну без партицирования (а на уровне платформы этого нет, и запросы этого не учитывают) Вы можете проверить пределы возможностей. Всего-то через пару лет будет 8-10 тб. Банальная реструктуризация какой то большой таблицы может не уложится в выходные, отборы по индексам преподнесут сюрпризы и много интересного. Угадаю - Вы еще на MS SQL счастливо работаете?
А этот переход https://habr.com/ru/articles/734366/ неизбежен, потому что как раньше уже не будет.
В бухучете есть много вещей которые не закрываются годами - например займы на десяток лет, амортизация ОС и т.д. Но как правило старое оставляют в архивной базе, а новое работает от остатков. Я уже не упоминаю о алгоритмах которых может накопится 5 версий за десяток лет .
Данные о маркировке это всего лишь история с ней можно по технологии шардинга работать. Бесконечная база это дорогое удовольствие, проблема в том что 1С не рассчитана на это технологически
Пробую фоновое обновление базы данных. Как раз для таких случаев. Но после перехода 8.2-8.3 база перестает запускаться: лезут ошибки, не хватает каких-то служебных таблиц, причем разных - в зависимости от того, на какой режим совместимости переходить.
И нет гарантии, что не вылезут проблемы при последующей работе.
Похоже, придется переходить через создание копии и перенос изменений.
Такое впечатление что он просто не завершился
А оптимизированный механизм пробовали? Фоновый это онлайн, это немного другое там куча ограничений известных и неизвестных
Для оптимизированного
Параметры устанавливали?
ConfLocation=C:\Program Files\1cv8\conf UpdateDBCfg=v2 JavaHome=C:\Program Files\Java\jre1.8.0_191 #Задание максимального размера доступной памяти для JAVA-процесса JavaOpts=-Xmx3072m
Оптимизированный механизм - он для "простых" реструктуризаций. При переходе 8.2-8.3 он не будет работать. Даже если бы работал - сыроват он для таких переходов. Более того, наблюдаю странную ситуацию на платформе 8.3.25.1445. По-умолчанию всегда включается v2 (в допустимых для него случаях). Параметр v1, даже установленный принудительно в conf или командной строке - игнорируется!
Реструктуризация — бесконечная история