Секционирование. Для чего и как?06.06.2024, 12:46. Показов 1565. Ответов 13
Приветствую!
Объясните, пожалуйста, популярно (желательно — на примерах) — что такое секционирование, для чего оно нужно и как правильно организовывается? Я так понимаю, это метод разделения данных на группы/секции/разделы/части — чтобы можно было быстрее получать данные из такой конкретной группы.
0
|
|
| 06.06.2024, 12:46 | |
|
Ответы с готовыми решениями:
13
Postgresql. Секционирование таблицы по хэшу. Как происходит? СЕКЦИОНИРОВАНИЕ Секционирование |
|
1305 / 359 / 97
Регистрация: 14.10.2022
Сообщений: 1,090
|
|||||||
| 07.06.2024, 11:30 | |||||||
Сообщение было отмечено Jack Famous как решение
Решение
Эээ...
Ну, секционирование в MSSQLSERVER присутствует в двух вариантах. Олдскульном, когда таблица, которую нужно разделить на части горизонтально - разделяется на несколько одинаковых по формату таблиц, с некоторыми дополнениями в констрейнтах, которые выносятся в разные таблицы, которые могут располагаться вплоть до того, что в разных БД, и даже на разных серверах, а исходная таблица заменяется на view: https://learn.microsoft.com/ru... oned-views Причем это доступно во всех версиях MS SQL, как бы не начиная с 4.0, т.е. "всегда было" (не поручусь, но ЕМНИП). И т.к. при этом речь идет о различных таблицах - можно делать всё, что можно делать с таблицами. И лишь на уровне вью всё это эмулирует настоящую таблицу, впрочем, не слишком убедительно. На мой взгляд это как раз и есть "подлинное" секционирование, без разных там фиговых листков. И есть "настоящее" секционирование, когда таблицу можно, горизонтально же, порезать на куски, и эти куски расположить на отдельных файловых группах. При этом внешне таблица выглядит целенькой, но с ее кусками можно делать всякие интересные штуки. Например - горячие данные, за последний месяц - разместить на быстром носителе, а исторические - на емком, но медленном. Или сжать исторические данные в колумнстор-архив, если структура таблицы позволяет. Они в 12 раз меньше места занимать будут. По-моему, можно какие-то секции расположить на read-only файловых группах, и получить защиту изменений нативным образом (не пробовал, так что может и вру, но вроде что-то читал). Самое прикольное, что можно делать - это грузить данные, балком, например, в отдельностоящую табличку, а потом этой самой табличкой подменить какую либо секцию в исходной табличке. Удобно для организации хранилищ, в которых с оной стороны, нужно грузить [десяток-сотню] миллионов записей, но чтобы вставка в таблицу производилась мгновенно, в течение 0,1 сек. У нас так несколько "живых витрин" реализовано. Нет, сама выгрузка/загрузка длится, возможно часы. Но данные оказываются в продуктовых таблицах мгновенно, и пользователь, до последнего момента, работает с "данные продакшн на 2024-06-04 20:25:04, загруженные 2024-06-05 00:00:01", а потом, сразу "данные продакшн на 2024-06-05 03:25:04, загруженные 2024-06-05 06:00:01", без перерывов и блокировок (эдакий супер-снепшот). Куча ограничений и дорого, конечно, но позволяет, т.с. Ну т.д. В основном секционирование применяют, чтобы ускорить выборку данных. Это действительно возможно, если в запросе на секционированой таблице явным образом указан ключ секционирования в предикате равенства, и запрос скомпилирован таким образом, что это не интерпретируется энжином как переменная, ну т.е. что-то типа:
В этом случае энжин исключит незадействованные секции и будет искать только в секции, которой принадлежит значение этого ключа. И запрос станет работать быстрее. Ну или значение ключа секционирования указано явно, литералом. (Есть еще варианты, при которых срабатывает партишн элиминейшн, но там углуПляться надо). Потом, если партиции лежат на файловых группах, расположенных на физически разных стораджах - чтение ускоряется, т.к. происходит в несколько потоков, по разным каналам. Во всех остальных случаях - работа с партиционированной таблицей - МЕДЛЕННЕЕ, чем с обычной. Короче, инструмент очень интересный, но использовать нужно в полном сознании, что и зачем делаешь. И то - по пальцам огребешь неоднократно. Добавлено через 3 минуты Такова селяви.
1
|
|||||||
| 07.06.2024, 11:45 [ТС] | ||
|
uaggster, большое спасибо! Суперподробно и понятно!
0
|
||
|
1305 / 359 / 97
Регистрация: 14.10.2022
Сообщений: 1,090
|
|
| 07.06.2024, 11:48 | |
|
Эээ... не понятен вопрос.
Начни с научпопа: https://habr.com/ru/articles/464665/
1
|
|
| 07.06.2024, 11:53 [ТС] | |
|
uaggster, хорошо) ещё раз спасибо. Вернусь, как разберу(не сегодня).
0
|
|
| 25.06.2025, 11:31 [ТС] | |
|
Приветствую!
Я вернулся ![]() Вводные: • таблица на примерно ярд строк и 50 полей • высоконагруженная, постоянно активная, отключать/блокировать можно только на незначительное время (секунды) • всегда ночью и иногда днём происходит обновление огромных блоков данных по заданному полю (числовой ключ поставщика) Передо мной стоит следующая задача: • максимально ускорить процесс "обновления" основной таблицы, минимизируя используемые ресурсы Как будто, для этого должно прекрасно подойти секционирование или же переключение буферной таблицы на новую без секционирования. То, что мне нужно в схеме секционирования прописать все ключи поставщика и их не должно быть больше 15 000 я понимаю. Прошу поделиться своим практическим опытом по этому вопросу. Возможно, лучший вариант мной вообще тут не рассмотрен.
0
|
|
|
1305 / 359 / 97
Регистрация: 14.10.2022
Сообщений: 1,090
|
||
| 25.06.2025, 15:46 | ||
|
Обычно, под "высоконагруженная" понимается вариант нагрузки, когда добавляются, изменяются и удаляются записи с высокой частотой в куче коннектов. Когда, например, данные только читаются, пусть даже и с высокой частотой или большими порциями, или, например, только вставляются - это НЕ высоконагруженная, даже если речь идет о значительных объемах передаваемой информации. (просто потому, что 2-3 вариант нагрузки парируется с помощью кэширования, и "это другое"). У вас точно "высоконагруженная"? Больше 20 тысяч транзакций в секунду?
0
|
||
| 25.06.2025, 16:20 [ТС] | ||
|
0
|
||
|
1305 / 359 / 97
Регистрация: 14.10.2022
Сообщений: 1,090
|
|
| 25.06.2025, 16:42 | |
|
А если просто и без изысков обновлять/заливать и всё такое - какие проблемы наблюдаются?
Просто, начинать выкрутасничать имеет смысл, когда без выкрутасов уже не получается! Например: Вот нужно вам, например, миллион записей обновить. Вы обновляете их в лоб. Висит длинная транзакция, и система блокируется на 5 минут. Если это приемлемо - то не является проблемой и решать это не нужно. Предположим, это проблема. Ну, давайте запакетируем обновление, и будем обновлять циклом/курсором пакетами в 10000 записей. Оборотная сторона медали - нужно городить курсор, и фиксировать обновление частями. Неприемлемо, потому что, например нужно откатить всё сразу в случае ошибки? Ну, давайте еще что-нибудь придумаем. Но, на каждом этапе мы должны понимать, что платить придется дороже. Итак? С чем боремся? Какую проблему решаем, и проблема ли она?
0
|
|
| 25.06.2025, 16:55 [ТС] | |
|
uaggster, уважаю структурный подход — продуктивно)
1. Проблема есть. Состоит в том, что загрузка занимает много времени. Хотелось бы быстрее, но без физического разделения таблицы на несколько частей и соответствующего переписывания инструментов для отбора и анализа. Предполагаю, что в этом может помочь секционирование. 2. Таблица с проблемой не моя и не мне там делать. Я бы поменял многое и, скорее всего, физически разделил таблицу и создал новый арсенал инструментов для работы с пакетом новых таблиц. 3. Заполнение/обновление/удаление уже идёт пакетами по 100 тыс строк. Каждая операция обёрнута в явную транзакцию (предполагаю, что это может ускорить процесс и сократить лог). Откатить всё, в таком случае, тоже не является проблемой — можно запомнить определённые маркеры и откатиться по ним. Собственно, вопрос в том, может ли помочь секционирование для вставки и как? Собрать данные в буферную таблицу, одинаковую с целевой и вставлять/переключать частями посекционно, очищая целевую секцию перед этим?
0
|
|
|
1305 / 359 / 97
Регистрация: 14.10.2022
Сообщений: 1,090
|
||
| 26.06.2025, 08:48 | ||
|
1. Создаете таблицу, тождественную по структуре целевой, на той файлгруппе, где размещена загружаемая секция. На таблице также необходимо создать констрейнт, который соответствует ограничению ключа секции. 2. Заливаете в эту таблицу данные. 3. Заливаете в эту таблицу данные из целевой секции, которые нужно сохранить при заливке. Ну, т.е., например, у вас в секции хранится информация о 100 тыс., например, счетов. Вы заливаете еще 10 тыс, которые частично должны заместить хранящиеся. Вот, заливаете все 10 тыс., а потом ДОливаете из целевой секции те записи, которые потом "должны остаться на месте", соответственно, не трогая тех, которые уже загрузили в новую таблицу. 4. Создаете и строите индексы на новой табличке, эквивалентные индексам целевой таблицы. Обратите внимание, что индексы должны быть выровненные. 5. Очищаете (truncate) секцию в целевой таблице. 6. Переключаете таблицу в секцию. Кстати, если вам, по какой-то причине нужна предыдущая версия данных, то можно не транкейтить, а переключить старую секцию в другую пустую таблицу.
1
|
||
| 26.06.2025, 09:38 [ТС] | |
|
uaggster, сообщение не дописано) спасибо большое!
А есть ли у вас проверенный скриптик для создания полной копии таблицы — со всеми индексами, ограничениями и прочим? Поделитесь, если есть возможность, пожалуйста)
0
|
|
|
1305 / 359 / 97
Регистрация: 14.10.2022
Сообщений: 1,090
|
||||||||||||||||
| 27.06.2025, 09:29 | ||||||||||||||||
|
Это кусок неадаптированного текста (просто вырвал кусок из процедуры)
Создает копии таблиц из схемы dbo, чьи имена перечислены в таблице [load].[tables_to_load] Ключом секционирования является код филиала, и, соответственно, секция таблицы размещается на файловой группе [FКодФилиала]. Создаются 2 таблицы: Имя_таблицы_in - в нее грузятся данные перед подменой, out - туда вышибаются существующие данные (у нас в процессе загрузки вычисляется дельта (агрегаты) и складируется в лог, поэтому какое то время нужны и подменяемые и подменяющие данные). Но можно не так, out не создавать, можно просто транкейт секции в целевой таблице. Кликните здесь для просмотра всего текста
А вот так переключаемся: Кликните здесь для просмотра всего текста
А вот это - создание констрейнтов. Констрейнты создаем уже после загрузки. Кликните здесь для просмотра всего текста
2
|
||||||||||||||||
| 27.06.2025, 13:58 [ТС] | |
|
uaggster, большое спасибо!
Непростая задачка, конечно
0
|
|
| 27.06.2025, 13:58 | |
|
Помогаю со студенческими работами здесь
14
Секционирование Для чего нужно писать в int main() в скобках всякие args потом объявлять переменные, и прочее. Для чего если можно в сборках это все обьявлять. Для чего нужен Seed() и для чего его override? Секционирование таблиц Про секционирование Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
Ритм жизни
kumehtar 27.02.2026
Иногда приходится жить в ритме, где дел становится всё больше, а вовлечения в происходящее — всё меньше. Плотный график не даёт вниманию закрепиться ни на одном событии. Утро начинается с быстрых,. . .
|
[В процессе разработки] SDL3 для Web (WebAssembly): Сборка библиотек SDL3 и Box2D из исходников с помощью CMake и Emscripten
8Observer8 27.02.2026
Недавно вышла версия 3. 4. 2 библиотеки SDL3. На странице официальной релиза доступны исходники, готовые DLL (для x86, x64, arm64), а также библиотеки для разработки под Android, MinGW и Visual Studio. . . .
|
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами
8Observer8 20.02.2026
Содержание блога
Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .
|
Конвертировать закладки radiotray-ng в m3u-плейлист
damix 19.02.2026
Это можно сделать скриптом для PowerShell. Использование
. \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json>
Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом.
# Check if. . .
|
|
Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI
Eddy_Em 18.02.2026
Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так:
https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347
Основана на STM32F303RBT6.
На борту пять. . .
|
Камера Toupcam IUA500KMA
Eddy_Em 12.02.2026
Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
|
И ясному Солнцу
zbw 12.02.2026
И ясному Солнцу,
и светлой Луне.
В мире
покоя нет
и люди
не могут жить в тишине.
А жить им немного лет.
|
«Знание-Сила»
zbw 12.02.2026
«Знание-Сила»
«Время-Деньги»
«Деньги -Пуля»
|