Комментарии 26
> Ничего основанного на функциях.
Это НЕВЕРНО! Если сделать условие партицирования с использованием функции и при выборке использовать именно эту-же функцию в том-же виде, то postgress отлично отфильтрует только нужные партиции для анализа.
Это НЕВЕРНО! Если сделать условие партицирования с использованием функции и при выборке использовать именно эту-же функцию в том-же виде, то postgress отлично отфильтрует только нужные партиции для анализа.
Всегда удивляло, что PostgreSQL на рекламных постерах всегда говорит о том, что все есть из коробки — и partitions и replication и.т.д, но как дело доходит до использования, то пожалуйста, напишите триггеры, то сделайте бэкап и rsync'ом перекиньте его на другой сервер, чтобы нормально работало, поставьте еще pgpool и вот по мелочам как-то так все набирается, что не очень радует.
Из коробки — так из коробки давайте!
P.S, потихоньку мигрирую c SQL Server
Из коробки — так из коробки давайте!
P.S, потихоньку мигрирую c SQL Server
Partitioning в PostgreSQL, к сожалению, весьма ограниченный и неудобный. Пользоваться можно, но с оговорками.
Я его пока удачно приспособил только для данных похожих на логи, которые копятся со временем, редко читаются, и должны удаляться по истечении какого-то срока (но при этом все-равно требуют транзакций и не могут писаться в простые файлы).
В этом случае удобно чистить хвост.
Пробовал прикрутить к среднего размера таблицам (пока до 100 миллионов записей, то есть еще не требуют разбиения, но могут в перспестиве вырасти в 10-100 раз), в которых ожидал видимый эффект от разбивки данных по годам и клиентам (горячими являются только 1-2 последних года, и запросы почти всегда только по одному клиенту. Но на данный момент накладные расходы планировщика запросов привели к ухудшению производительности на десяток процентов, вместо улучшения.
Думаю, когда таблицы вырастут раз в 10, эффект уже должен проявиться.
Напрягает еще ограничение на количество разделов — во всех источниках не рекомендуют иметь более чем несколько десятков партиций. А если я только задумаюсь делить данные по клиентам и по годам (что мне казалось очень логичным, учитывая отсутствие пересечений между ними, ну, почти всегда), то количество разделов легко вырастает за пределы рекомендуемого.
Я его пока удачно приспособил только для данных похожих на логи, которые копятся со временем, редко читаются, и должны удаляться по истечении какого-то срока (но при этом все-равно требуют транзакций и не могут писаться в простые файлы).
В этом случае удобно чистить хвост.
Пробовал прикрутить к среднего размера таблицам (пока до 100 миллионов записей, то есть еще не требуют разбиения, но могут в перспестиве вырасти в 10-100 раз), в которых ожидал видимый эффект от разбивки данных по годам и клиентам (горячими являются только 1-2 последних года, и запросы почти всегда только по одному клиенту. Но на данный момент накладные расходы планировщика запросов привели к ухудшению производительности на десяток процентов, вместо улучшения.
Думаю, когда таблицы вырастут раз в 10, эффект уже должен проявиться.
Напрягает еще ограничение на количество разделов — во всех источниках не рекомендуют иметь более чем несколько десятков партиций. А если я только задумаюсь делить данные по клиентам и по годам (что мне казалось очень логичным, учитывая отсутствие пересечений между ними, ну, почти всегда), то количество разделов легко вырастает за пределы рекомендуемого.
> накладные расходы планировщика запросов привели к ухудшению производительности на десяток процентов
У меня данные лежат по дням за последний год, каждый день — несколько миллионов записей (грубо говоря, логи траффика). При правильно сделанном индексе (в статье есть пример) запрос цепляет по две-три партиции максимум. Не затруднит вас показать create script?
У меня данные лежат по дням за последний год, каждый день — несколько миллионов записей (грубо говоря, логи траффика). При правильно сделанном индексе (в статье есть пример) запрос цепляет по две-три партиции максимум. Не затруднит вас показать create script?
На простых запросах проблем нет, и оно действительно цепляет пару разделов (партиций). На логах у меня тоже отлично работает, как я выше написал.
А в больших таблицах с данными у меня, к сожалению, много JOIN-ов со связанными таблицами, и планировщик в определенный момент решает, что ему сначала выгодней сделать JOIN по одной из связей (в принципе логично так как выборка будет маленькая), и только потом фильтровать по времени. А разбивка на партиции производится по времени, и тут логика работы планировщика для одной таблицы уже не совсем подходит. У меня не было времени еще разбираться детальнее, я только пробные эксперименты проводил, из которых и сделал вывод о спорных результатах для моего конкретного случая.
Пример показать не могу — нужно воспроизводить на каких-то искуственных данных, которые можно показывать, и отлаживать на них же.
А в больших таблицах с данными у меня, к сожалению, много JOIN-ов со связанными таблицами, и планировщик в определенный момент решает, что ему сначала выгодней сделать JOIN по одной из связей (в принципе логично так как выборка будет маленькая), и только потом фильтровать по времени. А разбивка на партиции производится по времени, и тут логика работы планировщика для одной таблицы уже не совсем подходит. У меня не было времени еще разбираться детальнее, я только пробные эксперименты проводил, из которых и сделал вывод о спорных результатах для моего конкретного случая.
Пример показать не могу — нужно воспроизводить на каких-то искуственных данных, которые можно показывать, и отлаживать на них же.
> Напрягает еще ограничение на количество разделов — во всех источниках не рекомендуют иметь более чем несколько десятков партиций.
А можно вот здесь поподробнее. Получается, что партиции по диапазону id, как описано в статье, создавать нельзя? Они ведь будут только прибавляться со временем и рано или поздно достигнут того самого «рекомендованного предела в несколько десяткой партиций»? Хотелось бы услышать еще мнение rdruzyagin на эту тему.
Интерес не праздный. У меня есть практическая задача разделить огромную таблицу, где в куче лежат данные от всех клиентов, по id клиента. То есть создавать для каждого нового клиента новую партицию, чтобы поиск по его данным происходил только внутри его партиции. Получается, что это не очень хорошая идея?
Заранее спасибо!
А можно вот здесь поподробнее. Получается, что партиции по диапазону id, как описано в статье, создавать нельзя? Они ведь будут только прибавляться со временем и рано или поздно достигнут того самого «рекомендованного предела в несколько десяткой партиций»? Хотелось бы услышать еще мнение rdruzyagin на эту тему.
Интерес не праздный. У меня есть практическая задача разделить огромную таблицу, где в куче лежат данные от всех клиентов, по id клиента. То есть создавать для каждого нового клиента новую партицию, чтобы поиск по его данным происходил только внутри его партиции. Получается, что это не очень хорошая идея?
Заранее спасибо!
В самом конце официальной документации www.postgresql.org/docs/9.4/static/ddl-partitioning.html написано:
… Партиционирование с применением этих техник будет работать хорошо, вероятно, до 100 разделов (партиций); не пытайтесь его использовать с несколькими тысячами разделов.
All constraints on all partitions of the master table are examined during constraint exclusion, so large numbers of partitions are likely to increase query planning time considerably. Partitioning using these techniques will work well with up to perhaps a hundred partitions; don't try to use many thousands of partitions.
… Партиционирование с применением этих техник будет работать хорошо, вероятно, до 100 разделов (партиций); не пытайтесь его использовать с несколькими тысячами разделов.
Создавать конечно же можно. Даже если у вас там десятки миллионов записей, и в каждой партиции по миллиону — выходит несколько десятков партиций всего. Это не так много.
Отдельная партиция на каждого клиента — звучит несколько избыточно, на мой взгляд. Даже если у вас клиентов миллионы, я думаю, что партиционирование по диапазону все равно удастся уложить во вменяемые рамки, со счетом до десятков партиций. Вряд ли клиенты у вас миллионами каждый месяц в сервис приходят. Такое объективно реально для соцсети крупной, наверное, но в таких случаях всегда много «мертвых» юзеров, которые нет смысла держать в «горячих» партициях.
В общем, зависит от конкретной задачи. Что у вас там за данные, в каком количестве они лежат для отдельного клиента, сколько всего клиентов, насколько критична «онлайновость» вот прям всех данных. Под критичностью я не имею ввиду потребность коммерции раз в год какой-то аналитической выгрузки, такое можно и из архивов достать где-нибудь на стендбае или инстансе отдельном.
В целом, коллега верно ниже упомянул про ограничения, связанные с планировщиком, поэтому я бы начал с того, что посмотрел на задачу повнимательнее. Опишите, что и как, подумаем.
Отдельная партиция на каждого клиента — звучит несколько избыточно, на мой взгляд. Даже если у вас клиентов миллионы, я думаю, что партиционирование по диапазону все равно удастся уложить во вменяемые рамки, со счетом до десятков партиций. Вряд ли клиенты у вас миллионами каждый месяц в сервис приходят. Такое объективно реально для соцсети крупной, наверное, но в таких случаях всегда много «мертвых» юзеров, которые нет смысла держать в «горячих» партициях.
В общем, зависит от конкретной задачи. Что у вас там за данные, в каком количестве они лежат для отдельного клиента, сколько всего клиентов, насколько критична «онлайновость» вот прям всех данных. Под критичностью я не имею ввиду потребность коммерции раз в год какой-то аналитической выгрузки, такое можно и из архивов достать где-нибудь на стендбае или инстансе отдельном.
В целом, коллега верно ниже упомянул про ограничения, связанные с планировщиком, поэтому я бы начал с того, что посмотрел на задачу повнимательнее. Опишите, что и как, подумаем.
познайте pg_partman. Вместо заката солнца вручную (что хорошо для понимания как оно внутри работает, но создает ад на продакшене) нужно всего-то дёрнуть три функции.
А почему вы вместо секционирования используете партиционирование, притом, что теги однозначно говорят, что правильный вариант вам известен?
Признаюсь честно, я задумывался, какой из терминов выбрать и даже совещался с коллегой, профессиональным посгресовым DBA. Секционирование — это, строго говоря, правильный вариант, но он показался нам более академическим и слабо употребляемым среди специалистов в профессии. Я лично в своей практике не припомню, чтобы кто-то в профессиональной среде использовал «секционирование» или «секция». Поэтому я решил выбрать более распространенный и широкоупотребимый вариант «партиционирование».
Но ведь это получается поощрение неграмотности, пусть даже у неё есть немало причин. Это как если бы в какой-то тусовке было принято кофе исключительно в женском роде писать.
Не уверен, что это именно неграмотность. Язык больше похож на живой организм, чем на прибитый гвоздями свод правил. Например ru.wikipedia.org/wiki/Кансайский_диалект
Почему неграмотности? Понимается при этом же одна суть процесса. Просто слова разные. Вот повсеместное называние процесса аутентификации авторизацией, это по мне и есть пример неграмотности.
Почему неграмотности?
Потому что «секционирование» было принято как термин многие годы назад (скорее всего ещё при СССР) как отражающее суть — разделение базы на части (секции) и присутствует во всех учебниках (по крайней мере в тех, что мне попадались). Секция в русском языке на тот момент уже была и есть до сих пор.
Слова «партиция», из которого должно получиться «партиционирование» в русском языке нет.
Соответственно (1) добавляем «-онирование» к бессмысленному набору букв (2) и получившееся нечто добавляем как дубликат уже имеющегося термина.
С чего бы менять один километровый термин на столь же длинный и хуже звучащий? Только от незнания что первый уже есть.
Хотя знаю ещё уверенных, что русскоязычный термин должен описывать
Язык больше похож на живой организм
Правильно и тут как раз случай обратной связи по цепочке «теорию не читал, терминов не знаю -> лезу в документацию -> есть только английская -> думать как перевести partitioning лень или от нехватки опыта получаю «частицирование» и подобные ужасы -> решаю звать как слышится -> слышу как другие тоже зовут «партиционированием» -> верю, что так и должно быть».
Примерно таким образом, благодаря возможности «голосовать» за варианты перевода отдельных слов, в словарях лингвалео творился тихий ужас — большинство учащихся голосовало за первое (читайте: «наголосованное») в списке значение даже если видело, что в попавшемся тексте слово несёт совершенно иной смысл. Я минут 15 выяснял, зачем отец заведомо неподходящий вариант плюсанул. Ответом было «ну так его 100 000 плюсануло, а второй по списку — только 12 000».
Вы попробуйте своих знакомых опросить, слышали ли они слово «секционирование» и, если да, то через сколько лет после знакомства с базами данных — уверен, вы удивитесь итогу.
Язык сущность живая, развивающиеся. От того, что кто-то когда-то ввел этот термин совсе не значит, что это данность пришедшая свыше. И да, в языке побеждает вариант который лучше приживается (читаем, используется большим количеством людей). И тут пальма явно за «партицированние». И очень может оказаться, что через Х лет в словаре мы будем видеть рядом с «секционирование» — устар. (привет индУстрия/индустрИя). Вас же не смущает термин «драйвер». Который вполне академично употреблялся в начале восьмидесятых точно (вероятнее всего и более рано, но мне такие документы в руки не попадались).
Главное, что под обеими этими словами понимался один и тот же техпроцесс, а не как это сейчас с авторизация/аутентификация.
Главное, что под обеими этими словами понимался один и тот же техпроцесс, а не как это сейчас с авторизация/аутентификация.
а не как это сейчас с авторизация/аутентификация
Когда учился в школе учителя переживали за слова-паразиты («ну», «типа»), сейчас даже более серьёзные проблемы мало кого волнуют. Через Х лет вы в словаре можете увидеть «авторизация — (олдовое) вочай аутэтификацыю». Грамотность, увы, не та область где стоит идти за неспособными ошибаться леммингами, даже если обрыв пока ещё не виден.
Просто поверьте на слово, я не выбирал «партиционирование», чтобы поощрять неграмотность. Коллеги-организаторы PG Day, которые знают мое маниакальное стремление «вылизать» каждый текст до блеска, чтобы ни одной опечатки, дефиса вместо тире или лишней запятой не проскользнуло, подтвердили бы этот факт. Есть люди, которые всерьез считают, что томик Розенталя у меня является настольной книгой (и не далеки от истины, хотя бумажной копией я не владею).
Я считаю, что есть неграмотность (ниже очень хороший пример про аутентификацию или, как вариант, ненавистный мне «функционал»), а есть — сленг и вошедшие в обиход термины. Партиционирование я отношу ко второй категории. В разговорном языке (а статья все-таки написана на «простом» языке, а не академическом) много неточностей и несоответствий формальным правилам, заимствованных иностранных слов и терминов. Не вижу в этом ничего криминального.
Я считаю, что есть неграмотность (ниже очень хороший пример про аутентификацию или, как вариант, ненавистный мне «функционал»), а есть — сленг и вошедшие в обиход термины. Партиционирование я отношу ко второй категории. В разговорном языке (а статья все-таки написана на «простом» языке, а не академическом) много неточностей и несоответствий формальным правилам, заимствованных иностранных слов и терминов. Не вижу в этом ничего криминального.
А партицирование может работать с update? Такое подобие горячего\ холодного хранилища? При переключении флага active\not_active строка попадает либо в одну либо в другую партицию?
дополню, функцией random_string, которая тут используется
https://gist.github.com/robcowie/e6438369c205c75103ba5e94e09a2f70
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Партиционирование в PostgreSQL – Что? Зачем? Как?