0. YPermitin 683 05.11.18 15:40 Сейчас в теме

Создаем свои индексы для баз 1С. Со своей структурой и настройками!

Поговорим о неплатформенных индексах для информационных баз 1С. Об особенностях их использования, целесообразности и подводных камнях.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. Repich 168 05.11.18 16:06 Сейчас в теме
Насколько я понимаю, в случае использования нового режима реструктуризации, самодельные индексы в общем случае останутся на месте.
3. МихаилМ 05.11.18 16:38 Сейчас в теме
(1) можно таблицы подменять представлениями (например для использования общего кладра(фиаса)) .

(0) решена ли в Ваших разработках проблема долгого копирования данных (по 1000 записей) из старой таблицы в новую ?
8. YPermitin 683 05.11.18 19:31 Сейчас в теме
(3) Это не проблема неплатформенных индексов. Я бы вообще не назвал это проблемой.

Но есть известные пути ускорения реструктуризации на больших таблицах, когда такой путь "перезаливки" данных из старой таблицы в новую мешал обновлению информационной базы. Имеет ли смысл его здесь описывать.
6. YPermitin 683 05.11.18 19:29 Сейчас в теме
(1) на сколько я понимаю и "ДА" и "НЕТ".

Но подробнее не скажу, т.к. плотно не изучал работу новой реструктуризации. Была попытка использования в начале ее появления, но столкнулся с .... непреодолимыми проблемами на тот момент.
9. Repich 168 05.11.18 19:38 Сейчас в теме
(6) Мы в пятницу кстати натолкнулись на преодолимые проблемы, была проблема в конфигурации, которая для старого режима была вполне себе проходной, а вот для нового оказалась непреодолимой, в результате которой падала в exception.
14. herfis 264 06.11.18 10:44 Сейчас в теме
Я бы очень тщательно взвешивал за и против, принимая решение об использовании своих индексов. Даже при наличии хороших спецов по сиквелу. ИМХО, имеет смысл только на тяжелых продуктовых базах, где без тонких настроек не обойтись и которые на постоянном сопровождении у спецов с поставленной культурой разработки. База знаний, инструкции и т.п.
(1) Я бы на это не полагался. Случаи разные бывают, особенно учитывая что новый режим опционален.
dabu-dabu; Silenser; Fox-trot; YPermitin; +4 Ответить
15. YPermitin 683 06.11.18 10:47 Сейчас в теме
(14) Полностью поддерживаю Ваши слова.
Без знаний SQL Server за это дело лучше вообще не браться.
16. herfis 264 06.11.18 10:54 Сейчас в теме
(15)
Без знаний SQL Server за это дело лучше вообще не браться.

Проблема в том, что "знание SQL Server" - это примерно как "знание боевых искусств". Его всю жизнь получать можно :) Слишком много ньюансов и неоднозначных компромиссов, познание которых требует глубокой практики.
17. YPermitin 683 06.11.18 11:13 Сейчас в теме
(16) Главное не сдаваться :)

Так можно про любую сферу сказать, в т.ч. и 1С.
19. herfis 264 06.11.18 11:51 Сейчас в теме
(17) Ясен пень. Просто меня умиляют формулировки типа "ну, конечно нужно иметь знания SQL Sever". Насколько глубокие - вот вопрос из вопросов :)
(18) Это типа само собой входит в "знание SQL Server". Как и оверхед по дисковому пространству. Который даже в случае обычных индексов может быть очень существенным. Вы ведь не будете создавать доп-индексы на маленьких табличках? :) Про покрывающие индексы я вообще молчу.
YPermitin; ImHunter; +2 Ответить
20. YPermitin 683 06.11.18 11:57 Сейчас в теме
(19)
Ясен пен


Думаю, что тут надо по следующему принципу: если добавляешь свой индекс, то все последствия должен четко понимать: и дисковое пространство, и на сколько он будет востребован, будет ли эффективным или можно лучше; риски, если платформа 1С его снесет; и др.

Никто же не спорит.
21. herfis 264 06.11.18 12:30 Сейчас в теме
(20)
Никто же не спорит.

Так и я не спорю. И статья хорошая.
Просто ИМХО в таких статьях нужно больше запугивать расписывая возможные недостатки и жирнее намекать на необходимость получения дополнительных знаний :) Желательно со ссылками на хорошие профильные материалы.
Ведь целевая аудитория - кто? Те, кто вряд ли обладает достаточными знаниями и способен оценить степень их нехватки. Иначе зачем им эта статья?
22. YPermitin 683 06.11.18 12:42 Сейчас в теме
(21) Картинки к статье должно быть достаточно :)))
2. МихаилМ 05.11.18 16:31 Сейчас в теме
ddl триггеры появились в ms sql 2005. а статья в 2018 . ну лучше поздно...
7. YPermitin 683 05.11.18 19:29 Сейчас в теме
(2) Не думаю, что вопрос, почему такое никто не написал раньше, относится ко мне :)
4. nomadon 319 05.11.18 18:07 Сейчас в теме
Действия направленные против лицензионной политики преследуются законом?
5. YPermitin 683 05.11.18 19:26 Сейчас в теме
(4) Я не могу здесь Вам дать точный ответ на этот вопрос.
10. geron4 87 06.11.18 07:27 Сейчас в теме
(4) Никто Вас преследовать не будет, проблема может возникнуть, если Вы с Вашей конфигурацией обратитесь в 1С с какой-нить претензией, вероятно Вам откажут в помощи.
Fox-trot; +1 Ответить
13. palsergeich 06.11.18 10:26 Сейчас в теме
(10)
(4) 1с на обучении говорит что нельзя, но если прям ваще надо надо, то можно. Потому что иногда это единственный выход.
Но официально они это не одобряют.

Не совсем так, для оказания помощи они потребуют привести базу к типовому функционалу, потому что за кастомные механизмы они не отвечают
andron77777; +1 Ответить
12. palsergeich 06.11.18 10:19 Сейчас в теме
(4) 1с на обучении говорит что нельзя, но если прям ваще надо надо, то можно. Потому что иногда это единственный выход.
Но официально они это не одобряют.
11. SkyJack 06.11.18 10:16 Сейчас в теме
Большое спасибо за статью. Добавил в закладки.
18. ImHunter 21 06.11.18 11:40 Сейчас в теме
(0) Не описан еще один подвох.
СУБД будет тратить доп.ресурсы на актуализацию еще одного (добавленного) индекса при CRUD-операциях изменении данных в проиндексированной таблице.
23. Slava_prog 06.11.18 13:33 Сейчас в теме
Спасибо очень познавательно. Хотелось бы аналогичный материал для PostgreSQL
24. YPermitin 683 06.11.18 14:05 Сейчас в теме
(23) Все что здесь сказано относится и к PG, но с некоторыми оговорками (большими и маленькими).

На заметку взял, но заниматься PG не очень хочется :)
25. aximo 671 07.11.18 08:46 Сейчас в теме
(24) хорошая статья, напишите - на базах какого объема вы стали делать подобное?

по практическому опыту - у нас доросла торговая база до 7 млн. документов за 2 года - много это или нет. Потом, было принято решение сделать срез :)
26. YPermitin 683 07.11.18 10:52 Сейчас в теме
(25) от 100 ГБ и выше, в т.ч. и базы больше 1 ТБ.

Срез это больше как обезболивающее с побочными эффектами :)
Но не осуждаю! )
27. Darklight 15 08.11.18 14:29 Сейчас в теме

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

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

А вообще - я себе такую функционал представляю в рамках инструмента, за пределами конфигуратора. Размышляя о том, что нас может когда-нибудь ждать в 1С Предприятие 9 - мне видится логичным создания отдельного инструмента по мониторингу и тюненгу производительности + основные фишки, касающиеся администрирования ИБ и кластерной инфраструктуры тоже там же должны быть: этакий пылесос, совмещающий средства по настройке отдельных параметров в СУБД (ну там регламентное обслуживание хотя бы, ведение статистики и распараллеливание запросов...) + вот такие фишки по настройке индексов (включая сбор данных из СУБД по желаемым индексам), ну и заодно настройка сегментирования и файловых групп + некоторый функционал ЦУП по настройке анализу тех журнала, сбору счетчиков, здесь же и анализ журнала регистрации + ЦКК для анализа стабильности системы и возникших ошибок + средства администрирования кластера тоже надо включить в этот инструмент + управление лицензиями тоже здесь же + я бы ещё и управление пользователями правами пользователей тоже включил бы в этот инструмент + тут же должен быть контроль за внешними компонентами, внешними обработками и прочими программными модулями - что разрешено, что запрещено (поэлементно или с разрешёнными ЭЦП поставщиков - ну тут в основном имеются в виду программисты, которые это всё будут подготавливать) + инструментарий по настройке резервного копирования. И заниматься эти функционалом должны, по хорошему, не программисты, а специальные администраторы (баз данных) или эксперты по тех. вопросам. А в конфигурации, программистам дал бы возможность создавать, в метаданных как бы свои параметризованные источники данных (как виртуальные таблицы, а на языке СУБД - представления или даже процедуры, т.к. нужна поддержка временных таблиц) - тогда большая часть запросов к данным должна переместиться в такие источники, которые смог бы уже анализировать администратор баз данных в своём инструменте (собирая и анализируя статистику их использования) - и создавать нужные индексы. Да, управление агрегатами тоже бы вынес из конфигуратора в этот новый инструмент. Ну не должен программист решать такие тонкие нюансы производительности - в тех, компаниях, где это действительно актуально должен быть свой специалист по вопросам производительности СУБД и 1С, ну или хотя бы должен проводиться периодический внешний аудит.
И всё это должно быть в одном инструменте, реализованным не как конфигурация, а как часть платформы - но в виде отельного приложения с отдельным уровнем доступа.
YPermitin; +1 Ответить
28. YPermitin 683 08.11.18 15:01 Сейчас в теме
(27)
Представляю это почти каждый рабочий день ;-)


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

Для платформы 1С это нереально, т.к. задачи иные и уровень разработки другой.
Да и смысл делать все эти прослойки в самой платформе, если есть огромное количество отличных сторонних инструментов. Все что требуется от 1С - не мешать их использовать.
29. Darklight 15 08.11.18 15:21 Сейчас в теме
(28)1С может сама и не делать - а лицензировать создание таких инструментов другим разрабочтикам - с перекладыванием ответственности на них. Но платформа 1С: Предприятие (в отличии от Microsoft .NET) является коммерческим продуктом - и компания 1С, продавая её, делает на этом бизнес. Тому пример - разделение лицензий платформы (пока в серверной части) на МИНИ/ПРОФ/КОРП с разной стоимостью - чтобы заполнить разные сегменты рынка. Чтобы более дорогие лицензии были востребованы они должны включать в себя расширенный инструментарий, особенно тот, который как раз нужен потребителям в этом сегменте - чтобы у них был стимул переходить на более дорогие решения.
YPermitin; +1 Ответить
30. YPermitin 683 08.11.18 17:17 Сейчас в теме
(29) в этом случае - да, согласен.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Санкт-Петербург
зарплата от 130 000 руб. до 150 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 100 000 руб.
Полный день

Руководитель группы сервисов FRM на 1С
Москва
зарплата от 150 000 руб.
Полный день

Руководитель группы сервисов ЭДО, ЭЦП и криптографии
Москва
зарплата от 150 000 руб.
Полный день

Руководитель группы интеграций (1С)
Москва
зарплата от 150 000 руб.
Полный день