0. YPermitin 4043 10.02.19 23:22 Сейчас в теме

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

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

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

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


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

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

Но вообще решений несколько.
2. Dream_kz 93 11.02.19 07:45 Сейчас в теме
Если Вам интересно как исправить запросы платформы 1С или архитектуру таблиц метаданных на стороне БД пишите в комментариях, может это будет стимул для новой статьи.

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

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

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

То есть да, усложнение сопровождения конечно будет. Но при должном подходе это не создаст проблемы, главное чтобы был специалист, который в этом разбирается.
7. capitan 1248 11.02.19 10:02 Сейчас в теме
8. nicxxx 230 11.02.19 12:30 Сейчас в теме
Ключевой момент- преобразование datetime. Если эту проблему не решить, то запросы так и продолжат тормозить. Но ее решение подразумевает вмешательство в работу платформы, что не каждому под силу. Давайте дружно попросим Орефкова заняться этим вопросом?))
9. YPermitin 4043 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 230 11.02.19 13:10 Сейчас в теме
Тогда пишите статью:)
torbeev; A_Max; +2 Ответить
13. YPermitin 4043 11.02.19 13:15 Сейчас в теме
14. Andreynikus 1244 12.02.19 23:50 Сейчас в теме
Отличная статья, спасибо!
YPermitin; +1 Ответить
15. YPermitin 4043 13.02.19 07:09 Сейчас в теме
17. GreenDragon 25.02.19 13:52 Сейчас в теме
Дайте угадаю... Enterprise?
YPermitin; +1 Ответить
18. YPermitin 4043 25.02.19 14:08 Сейчас в теме
(17) он самый, кровавый и беспощадный энтерпрайз.
19. GreenDragon 25.02.19 15:21 Сейчас в теме
(18) В тегах что ли укажите, а то каждый раз разочарование. В 10-й раз смотрю один и тот же фильм с надеждой на другую концовку...
YPermitin; +1 Ответить
20. YPermitin 4043 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 4043 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С :) Но держитесь! :)
23. nvv1970 03.03.19 11:57 Сейчас в теме
(22) у меня есть религиозное убеждение, что dba 1c не существуют, но есть программисты отличное разбирающиеся в администрировании бд, но им этим некогда заниматься. Просто это всегда только лишь хобби. И за это никто не платит. Мы призраки.
24. YPermitin 4043 03.03.19 12:47 Сейчас в теме
(23) все, о чем я писал здесь, используется. Оплачивается или нет, возможно, зависит от бизнеса.

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

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


Никто не спорит, думаю многие с вами согласятся.
Да и в статье нет этому противоречий.
25. VVi3ard 48 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 4043 10.04.19 12:09 Сейчас в теме
(25) спасибо за столь содержательный комментарий!

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

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

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

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

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

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

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

P.S. Если не сложно, можете написать что вы из технологий СХД используйте.
27. VVi3ard 48 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 4043 10.04.19 18:18 Сейчас в теме
(27)
еще стоит упомянуть что параллельное использование секций(ускорение работы) доступно только в Enterprise редакц


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

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

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

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

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

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

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

А так, отфильтрованные индексы - отличная возможность повысить эффективность запросов в некоторых случаях. Например в статье про индексы был пример с отфильтрованным индексом для пометки удаления.
Благодаря отфильтрованным индексам можно сделать тюнинг запросов с минимальными затратами дискового пространства и временем их обслуживания.
zhichkin; +1 Ответить
35. muskul 30.05.19 02:45 Сейчас в теме
как говориться ничего не понятно, но очень интересно
YPermitin; +1 Ответить
36. YPermitin 4043 30.05.19 07:02 Сейчас в теме
(35) главное попробуйте, поэксперементируйте. И все будет ок :)
37. 3vs 31.05.19 17:27 Сейчас в теме
Юрий, пишите свою платформу! :-)
YPermitin; +1 Ответить
38. YPermitin 4043 31.05.19 17:56 Сейчас в теме
(37) А Вы купите у меня ИТС, лицензию сервера и клиентских лицензий на 1000 пользователей? :)
39. 3vs 31.05.19 19:13 Сейчас в теме
(38)Да у нас пользователей-то человек 10... :-)
Это к крупняку, вроде газпромов, торговых сетей...
YPermitin; +1 1 Ответить
40. acanta 64 31.05.19 19:37 Сейчас в теме
(38) Если найдется столько клиентов, то вам этого насколько хватит?
41. YPermitin 4043 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 64 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 64 31.05.19 21:06 Сейчас в теме
(45) 1с принимает выпускников вузов, умеющих программировать на любом из известных языков программирования для того чтобы они НЕ программировали вообще никак.
48. YPermitin 4043 31.05.19 21:07 Сейчас в теме
(46) это уже теория заговоров :)
49. acanta 64 31.05.19 21:12 Сейчас в теме
(48) не совсем, скорее логика. Нафига серьезным западным конторам столько быдло и говнокодеров из рашки, которые и по русски то с ошибками пишут, сколько их ежегодно выпускают вузы нашей необьятной. Если у нас все люди с высшим образованием бы начали кодить на аксессе или макросах екселя, имидж Майкрософт был бы много хуже чем сейчас имидж 1с.
47. YPermitin 4043 31.05.19 21:07 Сейчас в теме
(45)
прайз


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


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

Вакансии

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

Руководитель проектов 1С
Санкт-Петербург
Полный день


Бизнес-архитектор 1С, ведущий консультант
Санкт-Петербург
Полный день

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