Секционирование таблиц и индексов в мире 1С

Публикация № 975144

Администрирование - Производительность и оптимизация (HighLoad)

1C 8 SQL Server индексы неплатформенные оптимизация производительности недокументированные возможности секционирование сегментирование обслуживание СУБД

Говорим о секционировании таблиц и индексов для баз 1С. Способы применения, подводные камни и прочее.

Зачем все это

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

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

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

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

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

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

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

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

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

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

 
 Вопросы лицензирования

Принцип работы

Что же такое секционирование и для чего оно используется? В общих чертах, секционирование - это разбиение таблиц и индексов на некоторые блоки, в качестве которых может выступать файловая группа (логическое разделение) или файл (физическое разбиение). Блоки могут быть разных размеров, находиться на разных дисках и иметь различные специфичные для них настройки. Как обычно, вся самая подробная информация о секционировании SQL Server находится в официальной документации, мы же рассмотрим несколько примеров его использования с описанием плюсов и минусов этого подхода.  

Разделяй и властвуй

 

Для SQL Server создание секций выполняется в несколько этапов. Опустим этап проектирования и рассмотрим по шагам простой пример.  У нас есть информационная база 1С "Partitioning", структура метаданных которой состоит из 2 документов, 4 регистров накопления и 4 справочников.

Схема метаданных

Структура метаданных дана просто для информации, все примеры будут на 1 или 2 таблицах. Как можно догадаться, примеры с секционированием будут выполнены на регистрах "Продажи_Секции" и "ТоварыНаСкладах_Секции". На стороне SQL Server эти объекты представлены несколькими таблицами. Нас интересуют только физические таблицы для упрощения примеров. Таблицы итогов и служебные таблицы секционировать не будем.

Метаданные Поле 1С Поле SQL
Имя таблицы
РегистрНакопления.ТоварыНаСкладах_Секции Период _Period
_AccumRg84 Регистратор _RecorderTRef
  Регистратор _RecorderRRef
НомерСтроки _LineNo
Активность _Active
ВидДвижения _RecordKind
Склад _Fld85RRef
Номенклатура _Fld86RRef
Количество _Fld87
РегистрНакопления.Продажи_Секции Период _Period
_AccumRg69 Регистратор _RecorderRRef
  НомерСтроки _LineNo
Активность _Active
Подразделение _Fld70RRef
Контрагент _Fld71RRef
Сумма _Fld72

Все таблицы базы содержат данные с 2010 до 2019 года, чтобы наглядно продемонстрировать действия секционирования.

Создание файловых групп

Для начала создадим логические блоки базы данных - файловые группы. Сделать это можно как с помощью SQL-скрипта, так и с помощью графического интерфейса в SQL Managment Studio (SSMS).

USE [master]
GO
ALTER DATABASE [Partitioning] ADD FILEGROUP [FG1]
GO
ALTER DATABASE [Partitioning] ADD FILEGROUP [FG2]
GO
ALTER DATABASE [Partitioning] ADD FILEGROUP [FG3]
GO

В результате, кроме основной файловой группы PRIMARY имеем три дополнительных: FG1, FG2, FG3.

Созданные файловые группы

Файловые группы необходимы для распределения данных по ним с помощью секционирования. За файловой группой может стоять как отдельный файл или группа файлов.

Добавление файлов

Файловые группы есть, но они нигде не используются. Добавим отдельные файлы для каждой файловой группы.

USE [master]
GO
ALTER DATABASE [Partitioning] ADD FILE ( 
	-- Настройки размещения и автоувеличение файла
	NAME = N'Partitioning_FG1', 
	FILENAME = N'D:\DBs\Partitioning_FG1.ndf' , 
	SIZE = 1024KB , 
	FILEGROWTH = 10%) 
	-- Принадлежность файла к файловой группе
	TO FILEGROUP [FG1]
GO
ALTER DATABASE [Partitioning] ADD FILE ( 
	NAME = N'Partitioning_FG2', 
	FILENAME = N'D:\DBs\Partitioning_FG2.ndf', SIZE = 1024KB, FILEGROWTH = 10%) 
	TO FILEGROUP [FG2]
GO
ALTER DATABASE [Partitioning] ADD FILE ( 
	NAME = N'Partitioning_FG3', 
	FILENAME = N'D:\DBs\Partitioning_FG3.ndf', SIZE = 1024KB, FILEGROWTH = 10%) 
	TO FILEGROUP [FG3]
GO

Теперь каждая файловая группа ассоциирована с отдельным физическим файлом. Эти файлы также сразу же доступны в файловой системе.

Определение функции и схемы секционирования

Тут начинается самое интересное. Нам необходимо определить как данные в таблице или индексах будут распределяться между секциями. Для этого используются функции секционирования. Как упоминалось выше, таблицы содержат данные с 2010 по 2019 год. Допустим, нам нужно распределить данные по годам между секциями по такому принципу:

Файловая группа Фильтр данных
FG1 до 2010 года включительно
FG2 с 2011 по 2014 год включительно
FG3  с 2015 по 2018 год включительно
PRIMARY с 2019 года по текущий момент

Создать функцию секционирования можно только с помощью SQL-скрипта. В нашем случае он будет выглядеть так.

USE [Partitioning]
GO

CREATE PARTITION FUNCTION [ByDatePartitionFunction] 
	-- Тип колонки исходной таблицы, по которой
	-- будет выполняться секционирование
	(datetime2(0))
-- Указание к какой области интервала значений
-- принадлежит аргумент в части "FOR VALUES"
AS RANGE LEFT 
-- Платформа 1С хранит даты с некоторым смещением,
-- которое обычно установлено в 2000 лет, чтобы
-- иметь возможность хранить пустую дату "01.01.0001"
-- из 1С в виде "01.01.2001" на стороне SQL Server.
-- Поэтому здесь все даты в 4-ом тысячелетии :)
FOR VALUES (
	N'4010-12-31T23:59:59.000', 
	N'4014-12-31T23:59:59.000', 
	N'4018-12-31T23:59:59.000'
)
GO

Тип колонки секционирования соответствует типы поля "_Period" в таблице регистра. Через SSMS можно увидеть новый объект в разделе "Хранилище".

Функция секционирования

Но функции еще недостаточно, чтобы применить секционирование на практике. Нам еще нужна схема секционирования, которая с помощью функции свяжет секции таблицы или индекса с файловыми группами. Выше в таблице было описание как такое сопоставление должно быть сделано, нам осталось лишь написать скрипт.

USE [Partitioning]
GO

CREATE PARTITION SCHEME [ByDatePartitionScheme] 
-- Используемая функция секционирования
AS PARTITION [ByDatePartitionFunction] 
-- Файловые группы указаны в том порядке,
-- в котором указаны значения фильтров
-- при создании функции секционирования
TO ([FG1], [FG2], [FG3], [PRIMARY])
GO

В списке объектов базы созданную схему можно также заменить в разделе "Хранилище".

Схема секционирования

И так, функция и схема секционирования готовы, осталось применить их на таблицах / индексах.

Применяем секционирование

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

  • "ТоварыНаСкладах_Секции" (таблица "_AccumRg84")
  • "Продажи_Секции" (таблица "_AccumRg69")

Обе таблицы имеют кластерный индекс, поэтому будет достаточно применить схему секционирования к нему и всем некластеризованным индексам (которых у каждой таблицы по 1 для полей "Регистратор" + "НомерСтроки"). Для этого необходимо пересоздать индексы с явным указанием схемы секционирования. Вот полный скрипт для таблицы "_AccumRg84". Для "_AccumRg69" скрипт будет аналогичным, только имя таблицы и индексов нужно поменять.

USE [Partitioning]
GO

CREATE UNIQUE CLUSTERED INDEX [_AccumRg84_1] ON [dbo].[_AccumRg84]
(
	[_Period] ASC,
	[_RecorderTRef] ASC,
	[_RecorderRRef] ASC,
	[_LineNo] ASC
)WITH (
	-- Пересоздать индекс заново, если существует
	DROP_EXISTING = ON, 
	-- Включить инкрементальную статистику
	-- Об этом в статье далее
	STATISTICS_INCREMENTAL = ON)
-- Указываем схему секционирования и колонку таблицы,
-- к которой эта схема применяется
ON [ByDatePartitionScheme](_Period)
GO

CREATE UNIQUE NONCLUSTERED INDEX [_AccumRg84_2] ON [dbo].[_AccumRg84]
(
	[_RecorderTRef] ASC,
	[_RecorderRRef] ASC,
	[_LineNo] ASC
	-- Для секционирования в индексе должен присутствовать столбец секционирования
	-- поэтому стандартный платформенный индекс приходится изменять
	[_Period] ASC
)WITH (
	DROP_EXISTING = ON, 
	STATISTICS_INCREMENTAL = ON)
ON [ByDatePartitionScheme](_Period)
GO

Для упрощения составления скрипта можно использовать возможности SSMS по генерации DDL-команд для существующих объектов (таблицы и индексы). Сформированные автоматически скрипты можно использовать как шаблоны. Результатом скрипта будет разбиение таблиц и ее индексов на секции. Проверим результат для таблицы "_AccumRg84" и ее кластерного индекса с помощью этого скрипта.

Номер секции Количество строк в секции
1 (FG1) 4111890
2 (FG2) 1059512
3 (FG3) 82034
4 (PRIMARY) 536

Итог: основные таблицы регистров разбиты на секции с учетом файловых групп базы данных. Но для чего мы все это делали и что делать дальше?

 
 Примечание! Какое бывает секционирование и что такое сегментирование

Итак, поехали!

Какие проблемы решает

Выше мы настроили секционирование и даже проверили работает ли оно. Данные таблиц и индексов были распределены между файловыми группами (в нашем случае фактически между отдельными файлами), но какая от этого польза? Далее мы рассмотрим несколько простых кейсов, когда секционирование Вам может помочь.

Гибкое управление данными

В нашем примере есть три секции + одна стандартная. Предположим, что первая секция, хранящая данные регистров до 2011 года, должна сохраняться в системе в качестве архивных данных, при этом нужно снизить затраты дискового пространства для нее.

Поскольку к этим данным выполняется редкое обращение, то можно использовать сжатие PAGE для таблицы и индексов на этой секции. Сэкономим место на архивных данных, при этом сохраним уровень производительности при работе с остальными секциями (использование сжатия требует доп. ресурсов CPU).

ALTER INDEX _AccumRg84_1 
-- При указании секции для сжатия обязательно
-- указывать перестроение всех секций (REBUILD PARTITION=ALL )
ON _AccumRg84 REBUILD PARTITION=ALL 
-- При сжатии указываем номер секции
WITH (DATA_COMPRESSION = PAGE ON PARTITIONS(1)) 

Проверим результат с помощью этого скрипта.

Таблица Объект Номер секции Сжатие
_AccumRg84 _AccumRg84_1 1 PAGE
_AccumRg69 _AccumRg69_1 1 PAGE

Кроме сжатия, для отдельных секций доступны:

  • Перенос данных, что может быть актуальным при переносе данных из OLTP в OLAP
  • Операции обслуживания
  • Операции бэкапирования
  • И др.

Тема обширная и рассмотреть ее в одной публикации невозможно, поэтому если Вам это интересно, то рекомендую почитать MSDN. Точкой старта может быть официальная документация, которую можно прочитать здесь.

Повышение эффективности дисковой подсистемы

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

Например, есть две файловые группы FG1 и FG2, которые используют два отдельных файла. У нас простой пример и все файлы находятся в одном каталоге, на одном диске. Но никто не мешает распределить файлы по разным дискам, тем самым ускорив операции ввода-вывода с ними. Подобный подход разбиения базы по дисковой подсистеме может дать значительный прирост производительности в зависимости от назначения системы и выполняемых в ней SQL-запросов.

Часто даются рекомендации по переносу базы tempdb на отдельный диск для улучшения производительности, т.к. это позволяет снизить конкуренцию за дисковые ресурсы между основной базой данных и tempdb. Представьте какие возможности у Вас появятся для оптимизации операций ввода-вывода, если основную базу можно будет расположить на нескольких дисках.

Оптимизация стратегии бэкапирования

В этом случае все сводится к простому правилу - бэкапировать нужно лишь то, что меняется. Если файловая группа FG1 не меняется уже 6 лет, то зачем делать ее регулярный бэкап?

Бэкап всех данных!

 

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

USE [Partitioning]
GO
declare @readonly bit
SELECT @readonly=convert(bit, (status & 0x08)) 
FROM sysfilegroups WHERE groupname=N'FG1'
if(@readonly=0)
	ALTER DATABASE [Partitioning] MODIFY FILEGROUP [FG1] READONLY
GO

Теперь при попытке изменить данные в старом периоде через 1С появится ошибка на уровне СУБД. Это необходимо учитывать и делать проверки на уровне решения 1С.

 

Ошибка для файловых групп только для чтения

 

Вернемся к формированию бэкапа. Допустим, изначально для базы использовалась полная модель бэкапирования, ежедневно ночью был настроен бэкап полный и лога транзакции каждые 30 минут. Появилась проблема, что из-за большого объема базы полный бэкап выполняется длительное время и мешает работе пользователей и регламентных заданий. Примерный скрипт для формирования полного бэкапа может быть таким.

BACKUP DATABASE [Partitioning] 
TO  DISK = N'D:\DBs\Backup\Partitioning.bak' 
WITH NOFORMAT, NOINIT,  
NAME = N'Partitioning-Полная База данных Резервное копирование', 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10, CHECKSUM
GO

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

BACKUP DATABASE [Partitioning] 
	-- Перечисляем файловые группы для создания резервной копии
	FILEGROUP = N'PRIMARY',  
	FILEGROUP = N'FG2',  
	FILEGROUP = N'FG3' 
TO  DISK = N'D:\DBs\Backup\Partitioning.bak' WITH NOFORMAT, 
NOINIT,  
NAME = N'Partitioning-Полная База данных Резервное копирование', 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10, CHECKSUM
GO

Конечно, работать с такими бэкапами нужно немного иначе, но особых проблем с восстановлением данных не будет. Например, если была повреждена архивная файловая группа FG1, то ее восстановить проще всего, т.к. установлен режим только для чтения.

RESTORE DATABASE [Partitioning] 
FILE = N'Partitioning_FG1' 
FROM  DISK = N'D:\DBs\Backup\FG1.bak' 
WITH  FILE = 1,  NOUNLOAD,  STATS = 10
GO

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

USE [master]

-- Создаем резервную копию заключительного фрагмента журнала транзакции
-- и устанавливаем состояние базы в "NORECOVERY"
BACKUP LOG [Partitioning] TO  DISK = N'D:\DBs\Backup\Last_LogBackup.bak' 
	WITH NOFORMAT, NOINIT, NAME = N'Last_LogBackup', 
	NOSKIP, NOREWIND, NOUNLOAD,  NORECOVERY ,  STATS = 5

-- Восстанавливаем состояние базы на указанный момент времени (параметр STOPAT)
RESTORE DATABASE [Partitioning] FROM  DISK = N'D:\DBs\Backup\WeeklyBackup.bak' 
	WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5
RESTORE LOG [Partitioning] FROM  DISK = N'D:\DBs\Backup\LogBackup1.trn' 
	WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5
RESTORE LOG [Partitioning] FROM  DISK = N'D:\DBs\Backup\LogBackup2.trn' 
	WITH  FILE = 1,  NOUNLOAD,  STATS = 5,  
STOPAT = N'2019-02-08T16:15:13' -- Момент времени для восстановления
GO

Тема стратегии бэкапирования достаточно обширна. Для более подробной информации можно почитать здесь о восстановлении файловых групп и файлов, а общую информацию о стратегиях вот тут, а также есть старая статья на Инфостарт от Дмитрия Николайчука.

Что может быть лучше, чем быстрый бэкап :)

Улучшение процедур обслуживания

Для ускорения процедур обслуживания индексов и статистик можно выполнять операции на отдельных секциях.

Например, у нас есть 4 секции, причем одна из них вообще в режиме "Только для чтения". Чтобы уменьшить время обслуживания можно применить скрипт только к последней, "горячей" секции.

USE [Partitioning]
GO
ALTER INDEX [_AccumRg69_1] ON [dbo].[_AccumRg69]
-- Указание конкретной секции для перестроения
-- В обычных ситуациях выполняется перестроение всех
-- секций, что аналогично указанию "REBUILD PARTITION = ALL"
REBUILD PARTITION = 4
GO

Окей, с индексами все понятно, но как же статистика? Иногда обслуживание всех статистик может занимать даже больше времени, чем обслуживание индексов. При этом гистограмма распределения значений по таблице / индексу, чем в принципе и является статистика, не рассчитывается для каждой отдельной секции. Но решение все же есть. Начиная с версии SQL Server 2014 появилась так называемая инкрементальная статистика, которая может пересчитываться по секциям.

По умолчанию объекты базы данных не поддерживают инкрементальную статистику, потому что платформа 1С не включает их явно. Включить данный вид статистики для индекса можно при создании / перестроении.

CREATE UNIQUE CLUSTERED INDEX [_AccumRg69_1] ON [dbo].[_AccumRg69]
(
	[_Period] ASC,
	[_RecorderRRef] ASC,
	[_LineNo] ASC
-- Включение инкрементальной статистики для индекса
-- Кстати, мы это уже делали в одном из предыдущих скриптов :)
)WITH (DROP_EXISTING = ON, STATISTICS_INCREMENTAL = ON)
ON [ByDatePartitionScheme](_Period)
GO

Для того, чтобы выполнить пересчет для конкретной секции нужно воспользоваться следующим приемом.

UPDATE STATISTICS [dbo].[_AccumRg69]([_AccumRg69_1])
-- Указываем конкретную секцию для обновления статистики
WITH RESAMPLE ON PARTITIONS(4);

Для подробной информации о работе инкрементальной статистики и ее "внутренней кухне" рекомендую изучить статью "SQL Server 2014 : New incremental statistics", а также на MSDN. В них есть подробное описание как работает инкрементальная статистика, в каких случаях ее стоит использовать, ограничения и др. Если у Вас в базе огромные таблицы, то инкрементальная статистика может быть настоящим спасением при оптимизации обслуживания.

Подобные подходы актуальны для очень больших таблиц. На сколько это ускорит обслуживание? Ответ на этот вопрос можете дать только Вы, проанализировав объем данных и возможности своей инфраструктуры. К сожалению, инкрементальная статистика не решает проблему снижения эффективности статистики при росте таблиц, но это уже другая история (если интересно, то можно написать в других статьях).

Проблемы блокировок

С тех пор, как платформа использует свой "костыль" в виде менеджера управляемых блокировок и режим изоляции транзакций Read Commited Snapshot Isolation (RCSI), то проблемы блокировок на уровне SQL Server стало значительно меньше. Однако проблема эскалации блокировок все еще актуальна, т.к. она не решается использованием управляемых блокировок.

Проблема заключается в том, что при модификации большого объема данных таблицы в рамках одной транзакции SQL Server для оптимизации использования памяти может укрупнить область блокировки до уровня секции таблицы или всей таблицы.

Подробно этот пункт рассматривать не будем. Скажу лишь кратко, что с помощью секций можно снизить влияние эскалации блокировок. Вместо блокировки на всю таблицу может быть заблокирована одна секций, но это грубое описание.

Отличное описание есть на сайте Вячеслава Гилева, за что ему большое спасибо.

Плюсы и минусы

Все имеет свои плюсы и минусы, и секционирование тут не исключение.

Плюсы:

  • Гибкое управление данными, за счет действий над отдельными секциями (сжатие, перенос на отдельный диск, перенос данных на другие инстансы, бэкапирование и др.)
  • Ускорение операций обслуживания (перестроение индексов и обновление статистик по секциям).
  • Повышение производительности запросов для некоторых ситуаций. Эту ситуацию мы не рассматривали, но происходит это за счет:
    • Исключение обращений к секциям, которые не соответствую фильтрам запроса.
    • За счет разнесения секций на отдельные диски. 

Минусы:

  • Сложность администрирования и поддержки, т.к. требуются дополнительные компетенции.
  • Сложность при разработке баз данных, т.к. секционирование должно учитываться при модификации базы.
  • Как ни странно, секционирование может вызвать проблемы производительности в некоторых запросах. Например, из-за дополнительной операции соединения наборов данных из разных секций. Это стоит учитывать при планировании инфраструктуры и написания SQL-запросов.

Мы не будем отдельно останавливаться на каждом пункте, т.к. тогда статья станет очень большой и превратиться в книгу.. Более подробную информацию Вы всегда можете узнать на MSDN. Главное что нужно понять, что секционирование не является простым решением, поэтому перед его использованием нужно взвесить все плюсы и минусы. Особенно это важно в контексте платформы 1С, где нет полной власти над базой данных (она как бы есть, но ее как бы нет :)).

Проблемы в мире 1С

В контексте платформы 1С секционирование имеет свои особенности и подводные камни, а именно:

  • Лицензионное соглашение фирмы "1С" запрещает использовать недокументированные возможности. Только Вы ответственны за то, что делаете. Сам факт нарушения соглашения может как минимум вылиться в отказ в технической поддержки.
  • Проблемы при обновлении конфигурации, а именно реструктуризации таблиц.
    • Поскольку платформа 1С ничего не знает о секциях, то при реструктуризации все настройки таблиц и индексов будут сброшены на стандартные и секции будут "затерты".
    • При обновлении платформы 1С на новую версию или отказ от совместимости в конфигурации может привести к значительным изменениям на уровне базы, что может противоречить сделанными Вами изменениям. Например, ранее платформа хранила тип "Хранилище значений" с помощью SQL-типа "IMAGE". В одной из версий платформы этот тип был заменен на "VARBINARY". Если такие ситуации не обнаружить, то в лучшем случае реструктуризация прервется с ошибкой, а в худшем случится потеря данных.
  • Архитектура таблиц метаданных в большинстве решений противоречит основным требованиям секционирования.
    • Типовые конфигурации в большинстве таблиц имеют разделитель данных с типом "numeric", который включен во все индексы. Если Вы используете разделитель, то может понадобиться секционировать не просто по периоду, а по периоду с учетом разделителя. Проблема в том, что SQL Server поддерживает только указание одного поля секционирования. Решение тут - создавать виртуальное поле, о котором 1С ничего знать не будет, но этот подход мы сейчас не будем описывать. Если кому-то интересно - пишите в комментариях.
    • Не все типовые индексы можно просто так взять и секционировать, потому что не все они содержат поле секционирования, а это обязательное условие. Выше был пример, когда для включения секционирования пришлось добавлять поле "Период" в индекс по регистратору.
    • И многие другие специфические проблемы, с которыми можно столкнуться.
  • Топорное построение SQL-запросов платформой "1С" сводит на нет выигрыш в производительности для запросов по большим таблицам. Например, выше выполнено секционирование таблицы "_AccumRg84". Обслуживание ускорили, архивные данные сжимаем и поставили только для чтения, а бэкапы теперь выполняются гораздо быстрее. Но вот исключение обращений к архивным секциям в запросах не работает. Выполняя такой запрос из 1С мы ожидали, что будет прочитана только секция в файловой группе "PRIMARY". Вот текст запроса и план его выполнения.
exec sp_executesql N'
SELECT
CAST(COUNT_BIG(T1._RecorderRRef) AS NUMERIC(12))
FROM dbo._AccumRg84 T1
WHERE ((T1._Period >= @P1) AND (T1._Period <= @P2))
'
-- Все даты преобразуются к типу datetime2(3),
-- фактически период хранится с типом datetime2(0)
,N'@P1 datetime2(3),@P2 datetime2(3)'
,'4019-01-01 00:00:00','4019-01-31 23:59:59'

План запроса платформы 1С

Обратите внимание, что запрос секционированный и фактически обработано 4 секции, что не правильно. Все дело в том, что платформа по неведомой причине преобразовывает все параметры дат в SQL-запросах к типу "datetime(3)", хотя в таблицах даты хранятся с типом "datetime(0)". Для SQL Server это важно, т.к. происходит неявное преобразование типов и СУБД не может использовать секции. Если убрать преобразование дат и сразу поставить нужный тип "datetime(0)", то ситуация кардинально изменяется.

exec sp_executesql N'
SELECT
CAST(COUNT_BIG(T1._RecorderRRef) AS NUMERIC(12))
FROM dbo._AccumRg84 T1
WHERE ((T1._Period >= @P1) AND (T1._Period <= @P2))
'
-- Убираем преобразование типов к datetime2(3)
,N'@P1 datetime2(0),@P2 datetime2(0)'
,'4019-01-01 00:00:00','4019-01-31 23:59:59'

Исправленный запрос платформы 1С

Как можно заметить, запрос остается секционированным, но прочитана всего 1 секция. Это может быть критическим для больших операций чтения, например для Table Scan. Ведь прочитать одну секцию вместо 4 все же лучше.

 
 Крик души

Первую проблему с лицензионным соглашением мы решить не в силах, можно с ней только жить и принять. Проблему с архитектурой таблиц метаданных и особенными запросами платформы решить можно, но это уже выходит за рамки статьи. Ниже лишь кратко продемонстрируем решение проблемы с реструктуризациями, чтобы в один прекрасный момент не потерять секции. Если Вам интересно как исправить запросы платформы 1С или архитектуру таблиц метаданных на стороне БД пишите в комментариях, может это будет стимул для новой статьи.

Костыли и палки

В статье "Создаем свои индексы для баз 1С. Со своей структурой и настройками!" мы говори про создание и поддержку неплатформенных индексов для баз 1С. Для решения проблем удаления собственных индексов при реструктуризации использовались глобальные триггеры, перехватывающие события создания таблиц и индексов платформой и добавляющие свои нужные действия (создание индексов, изменение параметров индексов и таблиц и др.).

Этот же подход подойдет и для сохранения настроек секционирования, но с некоторыми особенностями.

CREATE TRIGGER [CustomSettingsMaintenance_OnIndexCreate]
ON ALL SERVER 
AFTER CREATE_INDEX
AS

BEGIN
	SET NOCOUNT ON;

	-- В случае возникновения ошибок продолжаем работу
	SET XACT_ABORT OFF;

	DECLARE @SchemaName SYSNAME,
		@TableName SYSNAME,
		@DatabaseName SYSNAME,
		@IndexName SYSNAME;

    SELECT @TableName = EVENTDATA().value('(/EVENT_INSTANCE/TargetObjectName)[1]','SYSNAME')
    SELECT @SchemaName = EVENTDATA().value('(/EVENT_INSTANCE/SchemaName)[1]','SYSNAME')
	SELECT @IndexName = EVENTDATA().value('(/EVENT_INSTANCE/ObjectName)[1]','SYSNAME')
	SELECT @DatabaseName = EVENTDATA().value('(/EVENT_INSTANCE/DatabaseName)[1]','SYSNAME');

	-- Здесь запускаем скрипт перестроения индекса с учетом схемы секционирования 
	-- Для индексов, которые не содержат поле секционирования, также выполняем
	-- их перестроение с добавлением этого поля. Если необходимо, то
	-- включаем инкрементальную статистику.
	-- Дополнительно можно учитывать файловые группы только для чтения и отключать
	-- эту настройку на время реструктуризации.

	-- Возвращаем значение по умолчанию для ситуаций с ошибками в транзакции
  	SET XACT_ABORT ON;

END

С помощью глобального триггера отлавливаем события изменения индексов и перестраиваем их с учетом параметров секционирования. Подробнее об этом подходе можно прочитать на GitHub и в соседней статье.

Это конец

Вот и все. На самом деле ничего сложного, если понимать для чего это нужно.

Нужно ли это использовать на практике? Решать только Вам, но если хоть один из пунктов к Вам относится, то секционирование точно не для Вас:

  • Используется файловый режим работы информационной базы
  • Нет никаких проблем производительности и стабильности информационной системы
  • Считаете большой ошибкой выход за пределы экосистемы платформы 1С
  • Вы сотрудник фирмы “1С” 

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

Другие ссылки

Тема секционирования не новая, на Инфостарт она уже рассматривалась и было бы правильно добавить ссылки на эти материалы.

P.S. Некоторый полезный материал Вы можете найти здесь. Если есть что добавить / исправить - пишите в комментариях или делайте Issue / Pull Request в репозитории. Подобный опыт всегда интересен.

P.P.S. Весь материал только для ознакомления, Вся ответственность только на Вас!

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Gilev.Vyacheslav 1867 11.02.19 00:36 Сейчас в теме
Одну важную вещь я бы выделил: секционирование надо делать до того как база сильно распухнет, задуматься стоит на пороге 30-50 миллионов строк в таблице, когда таблица будет терабайтовая ни какого технологического окна на продуктиве не хватит.
А таблицы второстепенной важности типа "версии" вообще в другую базу на другой сервер стараться выносить.
Yakud3a; stsasha87; A_Max; YPermitin; +4 Ответить
3. YPermitin 9896 11.02.19 08:01 Сейчас в теме
(1) согласен. Лучше раньше, чем поздно. И лучше поздно, чем никогда :)
10. nicxxx 239 11.02.19 13:02 Сейчас в теме
Поменять тип колонки _period на datetime2(3)?
11. YPermitin 9896 11.02.19 13:09 Сейчас в теме
(10)
а datet


Видимо немного не в ту ветку.

Нет, я бы тип в исходной таблице не стал менять из-за возможных побочных эффектов.
Не хочу озвучивать решение кратко, т.к. тогда меня могут понять неправильно, а после этого раскритиковать за неадекватность :)

Но вообще решений несколько.
54. hazyaka 17.06.20 11:01 Сейчас в теме
(1)а как вы это делаете? ВЫнести на другой сервер?
2. Dream_kz 111 11.02.19 07:45 Сейчас в теме
Если Вам интересно как исправить запросы платформы 1С или архитектуру таблиц метаданных на стороне БД пишите в комментариях, может это будет стимул для новой статьи.

Пишите еще, технические статьи очень интересны

Маленький вопрос, а с разделением документов по секциям все будет не так "просто" как с регистрами?
YPermitin; +1 Ответить
4. YPermitin 9896 11.02.19 08:05 Сейчас в теме
(2) спасибо. Больших различий нет, т.к. в них тоже есть период (Дата документа). Но если задача построить секции по более сложному принципу, то нюансы могут появится.

Но это не гарантировано, надо по конкретной задаче смотреть.
5. a.m.minakov 11.02.19 09:35 Сейчас в теме
Получается, что после каждого обновления, необходимо настраивать секционирование заново?
YPermitin; +1 Ответить
6. YPermitin 9896 11.02.19 09:40 Сейчас в теме
(5) Да, но:
1. Только при тех обновлениях, которые приводят к реструктуризации секционированной таблицы.
2. И только если не позаботиться о скриптах обслуживания, которые могут все сделать автоматом на стадии реструктуризации (см. в конце статьи описание принципа).

То есть да, усложнение сопровождения конечно будет. Но при должном подходе это не создаст проблемы, главное чтобы был специалист, который в этом разбирается.
7. capitan 1771 11.02.19 10:02 Сейчас в теме
8. nicxxx 239 11.02.19 12:30 Сейчас в теме
Ключевой момент- преобразование datetime. Если эту проблему не решить, то запросы так и продолжат тормозить. Но ее решение подразумевает вмешательство в работу платформы, что не каждому под силу. Давайте дружно попросим Орефкова заняться этим вопросом?))
9. YPermitin 9896 11.02.19 12:52 Сейчас в теме
(8) Решение на самом деле есть даже без дизасемблирования. Я хотел о нем написать, но боюсь тогда статья стала бы на столько большой, что к концу читатели бы впали в кому.

Может быть в следующий раз :)

Ну и плюс секционирование не обязательно через DateTime. Может у вас есть поле numeric(10,0), по которому нужно секционировать таблицу. В этом случае все будет работать как надо.
Aleskey_K; support; +2 Ответить
16. Magov 22.02.19 17:34 Сейчас в теме
(9)
еле есть даже без дизасемблирования. Я хотел о нем написать, но боюсь тогда статья стала бы на столько большой, что к концу читатели бы впали в ком

Намекните пожалуйста, хоть в какую сторону посмотреть. Интересует именно DateTime.
12. nicxxx 239 11.02.19 13:10 Сейчас в теме
Тогда пишите статью:)
torbeev; A_Max; +2 Ответить
13. YPermitin 9896 11.02.19 13:15 Сейчас в теме
14. Andreynikus 1363 12.02.19 23:50 Сейчас в теме
Отличная статья, спасибо!
YPermitin; +1 Ответить
15. YPermitin 9896 13.02.19 07:09 Сейчас в теме
17. GreenDragon 25.02.19 13:52 Сейчас в теме
Дайте угадаю... Enterprise?
YPermitin; +1 Ответить
18. YPermitin 9896 25.02.19 14:08 Сейчас в теме
(17) он самый, кровавый и беспощадный энтерпрайз.
19. GreenDragon 25.02.19 15:21 Сейчас в теме
(18) В тегах что ли укажите, а то каждый раз разочарование. В 10-й раз смотрю один и тот же фильм с надеждой на другую концовку...
YPermitin; +1 Ответить
20. YPermitin 9896 25.02.19 15:23 Сейчас в теме
(19) не хотел никого расстроить :)

Про лицензирование специально не писал, т.к. это сложная тема на самом деле. Но сделал ремарку в начале.
21. nvv1970 03.03.19 01:26 Сейчас в теме
Автор проверял секционирование в продакшене на SQL2016+ ?
Я наверно сам проверял, но уже не помню результат.))) (Не в 1С - активно применяю секционирование, были таблицы в пару миллиардов)

Ссылку на проблему оставлю это здесь: https://partners.v8.1c.ru/forum/topic/1748333
В частности, внешний источник 1с не в состоянии правильно работать с select запросами секционированных таблиц из-за специфической типизации параметра функции секционирования. Совместимость внешней базы "2014 и ниже" - спасает.
Проблема связана с изменениями в типе datatime2 c 2016 версии. Ссылки на партнерке приведены. В документации в BOL/MSDN про это кажется не написано, а "суслик есть".

Секционирование, сжатие данных (тема деградации записи не раскрыта) - это мощнейший инструмент.
Но нужно помнить, что используя его в 1С вы обрекаете владельца базы на то, что в какой-то момент они будут вынуждены выгружать ДТ и заливать его в чистую базу, т.к. без вас никто ни в чем не разберется. Поэтому "до террабайта - и так сойдет, а там будем резать, обменами переливать" и т.п. )))
Если вы не локальный DBA, а специалист со стороны, то никого эти прекрасные технологии не интересуют. К сожалению (

Есть еще более простые способы деления таблиц - это view. Часть таблицы выносится во внешнюю базу. Триггерами решается вопрос изменения данных. Все несложно, пока нет реструктуризации таблицы. Но и реструктуризация тоже решается.
YPermitin; +1 Ответить
22. YPermitin 9896 03.03.19 08:17 Сейчас в теме
(21)
Не в 1С - активно применяю секционирование, были таблицы в пару миллиардов

Спасибо за содержательный комментарий!

Автор проверял секционирование в продакшене на SQL2016+ ?

Проверял секционирование на 2016/2017 редакции. Основными проблемами с датами остается CAST'инг, но это все же особенность 1С. Можно ухитриться и обойти, но проблемы сопровождения станут актуальными. Поэтому секционирование для баз 1С все же пока работает как "костыль", который требует особого ухода :)

Изменения в 2016 в части datetime2 (https://docs.microsoft.com/ru-ru/sql/database-engine/breaking-changes-to-database-engine-features-in-sql-server-2016?view=sql-server-2017) действительно могут привести к неработоспособности запросов к секционированным таблицам, но эта проблема также решаем, но через "особые подходы в разработке". Печаль, но что делать.

Секционирование, сжатие данных (тема деградации записи не раскрыта) - это мощнейший инструмент.

Это все привело бы к слишком большой статье. Есть мнение что она уже такая :) Но проблема раскрыта в других источниках.
Пока что да, если нет спеца по БД, то делать все это опасно, поэтому если это не кровавый энтерпрайз, то усложнять сопровождение я бы не стал.

Есть еще более простые способы деления таблиц - это view.

Классика :) Этот способ простой и пока что единственный способ повысить эффективность работы статистики, которая может снижаться из-за ограничения в 200 шагов в гистограмме распределения.
Использовал на практике несколько раз, эффективность доказана. А реструктуризации можно решить, в самых сложных случая в "ручном режиме".

Вообще, если Вы имеете дело с НЕ 1Сной базой, то большинство тех сложностей, что появляются при использовании 1С, просто отпадают, т.к. настройки сделать проще и сопровождать тоже. Но появляются другие вопросы :)
Не завидую всем DBA, которые обслуживают большие базы 1С :) Но держитесь! :)
Gilev.Vyacheslav; +1 Ответить
23. nvv1970 03.03.19 11:57 Сейчас в теме
(22) у меня есть религиозное убеждение, что dba 1c не существуют, но есть программисты отличное разбирающиеся в администрировании бд, но им этим некогда заниматься. Просто это всегда только лишь хобби. И за это никто не платит. Мы призраки.
24. YPermitin 9896 03.03.19 12:47 Сейчас в теме
(23) все, о чем я писал здесь, используется. Оплачивается или нет, возможно, зависит от бизнеса.

Никакой мифологии и призраков. Это реалии нагруженных БД. Знание того что и как работает как-раз отличает инженера от не инженера.
28. VVi3ard 50 10.04.19 17:25 Сейчас в теме
(23) Они не существуют там где они не нужны.
И вполне себе существуют и оплачиваются там где они нужны.

Если у вас ларек с шаурмой то DBA вам не нужен.
Если вы крупная торговая сеть с 4000 филиалов то DBA у вас есть (и не один).
YPermitin; +1 Ответить
29. YPermitin 9896 10.04.19 18:09 Сейчас в теме
(28)
ни не существуют


Никто не спорит, думаю многие с вами согласятся.
Да и в статье нет этому противоречий.
25. VVi3ard 50 10.04.19 11:06 Сейчас в теме
Не до конца понял пример с
"FROM dbo._AccumRg84 T1
WHERE ((T1._Period >= @P1) AND (T1._Period <= @P2))"

У вас в примере просмотр индекса, а вы сравниваете с сканированием таблицы.

Если в плане будет сканирование таблицы то оно будет всегда по всем секциям на то оно и сканирование.

В вашем примере просмотр индекса, он должен одинаково работать и на одной таблице и на секционированной у вас даже в примере видно 2896 чтений строк в обоих случаях.

Если опустить обслуживание и ReadOnly секции, а так же не лезть в дебри эскалации (потому что эскалация это жопа не зависимо от секционирования) то секционирование нужно только в одном случае:
У вас есть диски не объеденные в массив под СХД (Система Хранения Данных).


Любая высоконагруженная система по любому крутится на СХД где под контролером спрятано 30-40 дисков часть из которых ССД.
И она сама прекрасно распараллеливает нагрузку по всем дискам.

Если забрать у СХД 20 дисков, налепить из них 5 массивов и замапить на секции то эффективность системы будет хуже. Т.к. большую часть времени большая часть дисков под секциями которые меняются и читаются редко будет простаивать.


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

Только не в век SSD а в век интеллектуальных СХД.

Секционирование это удел не hiload а скорее временный костыль для средних объемов, когда на хорошее железо быстрые диски и контроллеры денег еще нет, а данных уже много и нагрузка большая.
YPermitin; +1 Ответить
26. YPermitin 9896 10.04.19 12:09 Сейчас в теме
(25) спасибо за столь содержательный комментарий!

Пока отвечу кратко, но если нужно будет, то и подробнее отпишусь.

Пример был для того, чтобы показать, что из-за излишних преобразований типов платформой 1С в параметрах SQL Server не может эффективно использовать секции. Ему приходится обрабатывать все секции, а не только ту, которая попадает под условие фильтра. Запросы в приемере одинаковые, за исключением преобразования типов, поэтому и количество строк одно и то же. Как это обойти - тема отдельная.

По поводу сканирования вы правы. Тут я допустил неточность. Я хотел сказать, что при сканировании кластерного индекса могут быть затронуты не все секции. Тут дальше нужно описывать в каких случаях оптимизатор может это применять и т.д.

Вы слишком много сразу опустили, ведь секционирование куда более мощный иснтрумент, чем просто разбиение базы на файлы. В статье я написал и про бэкапы, обслуживание и т.д. Вообщем , секционирование может стать костылем как и все остальное, если его костыльно использовать.

А про век SSD в начале статьи - так это сарказм был :) Троллинг так сказать.

В целом я согласен, что секционирование не для всех. Но что это костыль - громко сказано.

Про интелектуальные СХД тема очень хорошая, но она секционирование не исключает.

P.S. Если не сложно, можете написать что вы из технологий СХД используйте.
27. VVi3ard 50 10.04.19 17:23 Сейчас в теме
Пример был для того, чтобы показать, что из-за излишних преобразований типов платформой 1С в параметрах SQL Server не может эффективно использовать секции


Я все равно не понимаю что значит не эффективно использовать секции?
Если условия запроса позволяют выполнить поиск по диапазону индекса то поиск будет одинаково работать и на обычной таблице и на секционированной.
Я не знаю ситуаций когда наличие секционирования дало бы преимущество в выборке данных. (В очень редких случаях если совпадают параметры секций соединяемых таблиц, SQL может оптом взять всю секцию, но это все крайне редко бывает, да и без секций такие запросы хорошо работают по диапазонам)

Я возможно ошибаюсь и действительно имеет смысл разбивать единый массив дисков на много мелких под секции?

Ваш пример показал что есть влияние приведения параметра к типу, но при этом работа одна и та же была выполнена т.е. ничего не изменилось по факту после исключения приведения к типу.


Вы слишком много сразу опустили, ведь секционирование куда более мощный иснтрумент, чем просто разбиение базы на файлы. В статье я написал и про бэкапы, обслуживание и т.д. Вообщем , секционирование может стать костылем как и все остальное, если его костыльно использовать.


По части обслуживания мне дополнить нечего, по ней я согласен с вами.
Но в одних моментах мы упрощаем эксплуатацию в других усложняем (это про то как с 1С работает).


Про интелектуальные СХД тема очень хорошая, но она секционирование не исключает.


А какой смысл раскидывать по дискам если все эти диски "виртуальные"? Выделять на СХД под виртуальные диски массивы из реальных дисков не выгодно.
Да, выиграем на обслуживании, но при этом ухудшим работу СХД.


P.S. Если не сложно, можете написать что вы из технологий СХД используйте.


Мы не используем, используют наши клиенты, у них что то серьезное от Oracle используется за много млн. на SSD.

Но даже если брать дешевые СХД (естественно SAN) в которых 10-20 HDD + 16 GB RAM кэша + 10 SSD то уже там выгоднее доверить распределение нагрузки контроллеру.

Да даже банальный рейд 10 из 6 дисков выгоднее чем просто разбить на 2 raid 5 по 3 диска. При том что конфигурация 2 raid 5 позволит создать только 2 независимые секции.

Но что это костыль - громко сказано.

Обосную почему костыль.
Всегда лучше отдать все диски контроллеру. Чем забирать их у контроллера и самому по ним раскидывать данные.

Мне сложно представить ситуацию когда 4 секции (1 горячая + 3 холодных разной степени) в каждой из которых по 6 дисков будут работать быстрее чем 18 дисков под один диск.

Единственный вариант это когда мы уже уперлись в пропускную способность СХД, т..е условно больше 48 дисков СХД не держит и тогда мы устанавливаем вторую СХД и секции выносим на нее.

Итог:
С первой частью статьи где вы описываете плюсы обслуживания я полностью согласен. Затраты времени на регламенты можно сократить в десятки раз. При этом даже не нужно на разные диски секции разносить, но желательно указать ReadOnly что бы не получилось так что необслуживаемые секции будут активно меняться.

Со второй частью про производительность мне согласится сложно. Использовать секционирование для ускорения, идея крайне сомнительная, и раскрыта в статье не достаточно, пример с CAST интересный и познавательный, но практический смысл не понятен.
(еще стоит упомянуть что параллельное использование секций(ускорение работы) доступно только в Enterprise редакции)
YPermitin; +1 Ответить
30. YPermitin 9896 10.04.19 18:18 Сейчас в теме
(27)
еще стоит упомянуть что параллельное использование секций(ускорение работы) доступно только в Enterprise редакц


Не вижу никаких противоречий всего вышесказанного и статьи.

Про производительность мог бы сделать примеры, но стоит ли. Статья изначально была нацелена на то, чтобы показать что для баз 1С секции использовать можно, что это даст и какие могут быть сложности. Пример CAST это как-раз сложность с 1С.

Еще больше дополнять статью смысла нет, ведь тогда это будет уже не статья, а документация. А для этого лучше идти на MSDN. Возможно более глубокие эксперименты с секциями и их влиянием на планы запросов можно оформить в виде статьи на Хабр, но тут это вряд ли будет интересно.

В любом случае, спасибо Вам за полезную информацию. Возможно в будущем подробнее опишу работу SQL Server с секциями, можно и для разных конфигураций дисковой подсистемы.

Или, Вы можете написать :)
31. morin 20 21.04.19 14:20 Сейчас в теме
Спасибо автору за труд!
Кто-нибудь решал вопрос секционирования в PostgreSQL? Очень мало материала на эту тему.
YPermitin; +1 Ответить
32. YPermitin 9896 21.04.19 14:23 Сейчас в теме
(31) спасибо!

На PG тоже можно, но нет времени описать это подробней. Кто знает, может в скором времени что-то появится здесь...
https://github.com/YPermitin/PGTools

Но пока не точно :) Все таки SQL Server пока на коне, а для двух СУБД сразу эксперементировать надо много времени.
33. zhichkin 774 29.05.19 18:29 Сейчас в теме
А что Вы скажете про отфильтрованные индексы в контексте повышения производительности ?
Было бы интересно узнать в сравнении с секционированием.
Может быть в каких-то случаях можно / удобнее / лучше использовать отфильтрованные индексы ?
YPermitin; +1 Ответить
34. YPermitin 9896 29.05.19 19:14 Сейчас в теме
(33) сравнивать было бы не совсем правильно, т.к. назначение у них разное.

А так, отфильтрованные индексы - отличная возможность повысить эффективность запросов в некоторых случаях. Например в статье про индексы был пример с отфильтрованным индексом для пометки удаления.
Благодаря отфильтрованным индексам можно сделать тюнинг запросов с минимальными затратами дискового пространства и временем их обслуживания.
zhichkin; +1 Ответить
35. muskul 30.05.19 02:45 Сейчас в теме
как говориться ничего не понятно, но очень интересно
YPermitin; +1 Ответить
36. YPermitin 9896 30.05.19 07:02 Сейчас в теме
(35) главное попробуйте, поэксперементируйте. И все будет ок :)
37. 3vs 31.05.19 17:27 Сейчас в теме
Юрий, пишите свою платформу! :-)
YPermitin; +1 Ответить
38. YPermitin 9896 31.05.19 17:56 Сейчас в теме
(37) А Вы купите у меня ИТС, лицензию сервера и клиентских лицензий на 1000 пользователей? :)
39. 3vs 31.05.19 19:13 Сейчас в теме
(38)Да у нас пользователей-то человек 10... :-)
Это к крупняку, вроде газпромов, торговых сетей...
YPermitin; +1 1 Ответить
40. acanta 31.05.19 19:37 Сейчас в теме
(38) Если найдется столько клиентов, то вам этого насколько хватит?
41. YPermitin 9896 31.05.19 20:26 Сейчас в теме
(40) это же шутка :)

Один в поле не воин.
3vs; acanta; +2 Ответить
43. 3vs 31.05.19 20:30 Сейчас в теме
(41)Да, к сожалению, время одиночек прошло...
Надеюсь, писатели платформы 1С прислушаются к вашим рекомендациям!
42. 3vs 31.05.19 20:27 Сейчас в теме
(40)Я про то, что с таким опытом как у Юрия можно было бы засандалить платформу для высоко нагруженных систем я те врежу! :-)
44. acanta 31.05.19 20:48 Сейчас в теме
(42) нет, нельзя. Но можно пойти в ВУЗ и собрать 20 дипломов и 20 курсовых в одну кандидатскую диссертацию, если правильно выбрать темы. А затем оформить результат как разработку от НИИ и продать сети франчайзи.
45. 3vs 31.05.19 21:03 Сейчас в теме
(44)Меня вот только удивляет, почему в Штатах развиваются
open source глобальные проекты, которыми пользуется весь шарик,
а у нас такого не наблюдается...
1С на подопытных обкатает очередной сервис и начинает денег просить,
Postgres pro делали-делали бесплатную версию для 1С и бац, прикрыли,
покупайте энтерпрайз...
YPermitin; +1 Ответить
46. acanta 31.05.19 21:06 Сейчас в теме
(45) 1с принимает выпускников вузов, умеющих программировать на любом из известных языков программирования для того чтобы они НЕ программировали вообще никак.
48. YPermitin 9896 31.05.19 21:07 Сейчас в теме
(46) это уже теория заговоров :)
49. acanta 31.05.19 21:12 Сейчас в теме
(48) не совсем, скорее логика. Нафига серьезным западным конторам столько быдло и говнокодеров из рашки, которые и по русски то с ошибками пишут, сколько их ежегодно выпускают вузы нашей необьятной. Если у нас все люди с высшим образованием бы начали кодить на аксессе или макросах екселя, имидж Майкрософт был бы много хуже чем сейчас имидж 1с.
47. YPermitin 9896 31.05.19 21:07 Сейчас в теме
(45)
прайз


Это логичный ход, с самого начала было понятно.
50. 3vs 31.05.19 21:15 Сейчас в теме
(47)А мелочи что делать, которой лишний жёсткий диск купить денег напросишься...
52. YPermitin 9896 02.06.19 09:25 Сейчас в теме
(50)
ск купить денег напросишься


Как и всегда, выкручиваться...
Excel, Access, кредиты и т.д. Печаль....
53. 3vs 02.06.19 09:55 Сейчас в теме
(52)Таки - да!
Работаем на том, что пока жужит Excel, 1С Бух. 1С ЗП.
Пока кто-то не умрёт первым или железо или сисадмин... :-)
Впрочем, во втором случае это будет уже головная боль директора... :-)
YPermitin; +1 Ответить
51. acanta 31.05.19 22:06 Сейчас в теме
(45) понимаете, если препод в вузе будет давать темы для разработки, которых нет ни в каком интернете, все станет значительно проще.
Или как вариант темы для практического использования на любом ближайшем предприятии "хоть завтра".
Лучше конечно и то и другое.
Оставьте свое сообщение

См. также

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Если вы используете SQL Server 2016 или более позднюю версию, то у вас есть возможность использовать встроенную систему мониторинга, которая позволяет отслеживать самые базовые метрики выполняемых запросов и статистику ожиданий (потребления ресурсов). Эта информация позволяет быстро получить самые ресурсоемкие запросы с их планами и агрегированной статистикой выполнения.

26.04.2019    11715    Aleksey.Bochkov    7    

Анализ проблем производительности по динамике мониторинга RAS 1C

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

07.10.2020    3041    ivanov660    12    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

Производительность и оптимизация (HighLoad) v8 ДО Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    3687    Nykyanen    16    

Описание почти всех событий технологического журнала

Технологический журнал v8 Бесплатно (free)

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    8245    YPermitin    30    

Опыт миграции из собственного датацентра в облако AWS Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Хотя данная публикация и не имеет прямого отношения к 1С, она может быть интересна тем, кто занимается крупными базами данных на MS SQL Server. Описывается опыт миграции баз данных в облако AWS в компании glassdoor.com, где я занимался этим проектом. Это первый драфт текста, получившийся довольно скомканным - в процессе буду дополнять.

29.07.2018    11629    Aleksey.Bochkov    9    

SQL для 1С: пишем правильно, красиво, сложно

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Многие программисты боятся работать с Null, считая, что от этих данных в запросах нужно избавляться. О том, как с помощью Null-полей в запросе решать востребованные в учете задачи по выборке данных, на конференции Infostart Event 2019 Inception рассказал ведущий разработчик ГК WiseAdvice Дмитрий Дудин.

14.08.2020    9981    dmurk    30    

Нестандартные блокировки при работе с OLAP-нагрузкой

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    1999    Филин    7    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

В статье обсудим пример практической настройки конфигурации «Мониторинг производительности» для автоматической классификации ошибок по группам/кластерам на данных текстов описания ошибок. Используем механизм векторной модели текстов и косинусное сходство между ними.

25.06.2020    2872    ivanov660    12    

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    30067    MrWonder    42    

Выбор процессора для 1С: конец споров или начало?

Производительность и оптимизация (HighLoad) Бесплатно (free)

Периодически занимаясь исследованиями производительности я повидал много решений. Делюсь некоторыми выводами на основании теста Гилева и собственных мыслей.

25.05.2020    12439    starik-2005    232    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

Обычно предметом оптимизации являются заранее определенные ключевые операции, т.е. действия, время выполнения которых значимо для пользователей. Причиной недостаточно быстрого выполнения ключевых операций может быть неоптимальный код, неоптимальные запросы либо же проблемы параллельности. Если выясняется, что основная доля времени выполнения ключевой операции приходится на запросы, то осуществляется оптимизация этих запросов. При высоких нагрузках на сервер СУБД в оптимизации нуждаются и те запросы, которые потребляют наибольшие ресурсы. Такие запросы не обязательно связаны с ключевыми операциями и заранее неизвестны. Но их также легко выявить и определить контекст их выполнения, чтобы оптимизировать стандартными методами.

24.05.2020    7718    DataReducer    22    

Учимся готовить кроликов с редиской: опыт применения Rabbit MQ и Redis в интеграционных проектах

Производительность и оптимизация (HighLoad) Интеграция Бесплатно (free)

При построении мощных производительных отказоустойчивых решений для интеграции во всем мире активно используются технологии обработки очередей сообщений с помощью брокера RabbitMQ и кэш-сервера Redis. О практическом опыте использования этих технологий при построении ИТ-ландшафта, включающего системы на 1С, на конференции Infostart Event 2019 Inception рассказал Сергей Наумов.

12.05.2020    5841    SergeyN    2    

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

05.08.2015    61647    Sergey.Noskov    119    

Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей

Производительность и оптимизация (HighLoad) Бесплатно (free)

Проводить мониторинг производительности вручную, выявляя закономерности в куче графиков и десятках таблиц, довольно сложно. Но это не значит, что разбираться с инцидентами нужно только после жалоб от пользователей. О том, как обучить нейронную сеть и заставить ее оповещать о проблемах, на конференции Infostart Event 2019 Inception рассказал начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков.

27.04.2020    4242    ivanov660    5    

Пример поиска ошибок в технологическом журнале

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

Примеры bash - скриптов для поиска ошибок в технологическом журнале.

23.04.2020    2996    vasilev2015    7    

Фреймворк "Мониторинг производительности". Руководство пользователя

Производительность и оптимизация (HighLoad) Бесплатно (free)

Описание и руководство "Мониторинг производительности": краткое описание конфигурации, сборник из статей, примеров - собрано в одном файле.

21.04.2020    3629    ivanov660    3    

Долго открывается конфигуратор Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    41251    Gilev.Vyacheslav    1    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    12178    YPermitin    0    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    13414    informa1555    31    

Многострочный контекст событий

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

Разбор технологического журнала с группировкой событий по первой или последней строке многострочного контекста.

31.03.2020    3202    vasilev2015    9    

Повышенная нагрузка на диски сервера баз данных SQL Server Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

С проблемой повышенной нагрузки на диски (дисковые хранилища и массивы, далее просто диски), сталкиваются почти все администраторы и специалисты технической поддержки при эксплуатации средних и крупных информационных систем на базе SQL Server (от 50 активных пользовательских сессий). Но всегда ли правильно идет интерпретация проблемы, попробуем разобраться на нескольких практических примерах.

15.03.2015    40728    gallam99    17    

Анализ взаимоблокировок

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

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

20.03.2020    5326    vasilev2015    26    

Многопоточность

Практика программирования Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    7403    kaliuzhnyi    43    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    67603    yuraos    112    

Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

Математика и алгоритмы Производительность и оптимизация (HighLoad) Бесплатно (free)

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

02.03.2020    5575    ildarovich    7    

Делаем быстрее POSTGRESQL COUNT (*)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Laurenz Albe "POSTGRESQL COUNT(*) MADE FAST". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/postgresql-count-made-fast/

28.02.2020    2887    w.r.    1    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

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

21.06.2013    55306    Антон Ширяев    117    

Простое обнаружение проблем производительности в PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Hans-Jürgen Schönig "DETECTING PERFORMANCE PROBLEMS EASILY IN POSTGRESQL". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/detecting-performance-problems-easily-in-postgresql/ Актуально для всех 1С ников, перешедших с MS SQL на Postgres

20.02.2020    4584    w.r.    4    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    10136    Evil Beaver    13    

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

Производительность и оптимизация (HighLoad) Бесплатно (free)

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    11660    a.doroshkevich    20    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    54905    Gilev.Vyacheslav    46    

Оптимизатор запросов. Вторая часть

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Продолжение статьи об оптимизаторе запросов. Во второй части мы попробуем создать свой оптимизатор и попутно разберемся с такими вопросами, как: хранение файлов; индексы; статистика.

23.01.2020    6546    darkdan77    59    

Улучшаем производительность 1С. Рекомендации

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

23.01.2020    8113    Kaval88    26    

Атака сервера кнопонажималкой

Нагрузочное тестирование Инструментарий разработчика Бесплатно (free)

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    6102    nixel    22    

Параллельные вычисления в 1С 8 Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    30170    gallam99    19    

Активный 2019 год на Инфостарт

О сообществе О жизни Бесплатно (free)

О прошедшем 2019 годе в 100 и 500 словах.

26.12.2019    6069    YPermitin    24    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    12039    ivanov660    16    

Самые распространенные заблуждения об индексах в мире 1С

Администрирование данных 1С Администрирование СУБД Бесплатно (free)

"Магия" индексов привела к множеству заблуждений об их работе. Попробуем развеять некоторые из них в контексте 1С.

28.11.2019    21396    YPermitin    50    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    42787    madmpro    32    

История роста и работы команд 1С в условиях HighLoad и BigData

Автоматизация ИТ-компании Производительность и оптимизация (HighLoad) Бесплатно (free)

Современные потребности бизнеса заставляют программистов 1С решать все более сложные задачи. А главные требования, которым необходимо соответствовать, – вовремя поставлять ценности высокого качества. С какими сложностями приходится сталкиваться в работе программистам в динамично развивающейся брокерской сфере, и как их решают, на конференции Infostart Event 2018 Education рассказал начальник отдела интеграции БКС Технологии Сергей Артемов.

11.11.2019    7779    user826155    11    

Обслуживание баз данных. Не так просто, как кажется

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    18215    YPermitin    28    

Набор скриптов для знакомства с SQL Server

Производительность и оптимизация (HighLoad) Администрирование СУБД Бесплатно (free)

Поговорим о скриптах, которые помогут быстро ознакомиться с состоянием SQL Server, в том числе с вопросами производительности.

30.09.2019    22551    YPermitin    15    

Управление индексами и секциями в 1С Промо

Практика программирования Администрирование данных 1С v8 1cv8.cf Россия Бесплатно (free)

Одним из основных факторов производительности 1С: Предприятие 8 является верная структура индексов СУБД - это аксиома. Но также существует одно из заблуждений - что это все сложно. В Ei разработан не имеющий аналогов инструмент позволяющий вывести работы с индексами и секциями на новый визуальный (интерактивный) уровень, позволяющий забыть о длинных инструкциях по созданию изменению индексов.

17.11.2011    22642    German    33    

Мониторинг высоконагруженной системы

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    9195    Repich    5    

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Администрирование данных 1С Zabbix v8 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    18958    Sloth    24    

Подбор оборудования для информационных систем на платформе 1С

Интеграция Производительность и оптимизация (HighLoad) Бесплатно (free)

При подборе оборудования по рекомендациям с сайта ИТС возникает противоречие: проводить ли нагрузочные тесты, чтобы определить возможную нагрузку, или достаточно просто взять данные из таблиц статистики? О том, какую тактику применить в том или ином случае, на конференции INFOSTART EVENT 2018 Education рассказал начальник отдела разработки компании IBS Филиппов Евгений.

09.09.2019    9260    jf2000    8    

Руководство по SQL: Как лучше писать запросы (Часть 2)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    7667    w.r.    2    

Руководство по SQL: Как лучше писать запросы (Часть 1)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    11111    w.r.    19    

Использование Union вместо OR

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

22.08.2019    4092    w.r.    35    

Тюнинг производительности запросов в PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Brady Holt "Performance Tuning Queries in PostgreSQL ". Оригинал доступен по ссылке https://www.geekytidbits.com/performance-tuning-postgres/

31.07.2019    8371    w.r.    5