| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Составление SQL-запросов > Уникальность на сегментированной таблице |
| Автор: Paher 17.9.2013, 23:03 | ||||
| Доброго здоровья, уважаемые! Есть у меня в PostgreSQL базе таблица с миллионами строк. Для ускорения решил применить ее сегментирование(партицирование). Разделял по полю "date" по месяцам. Сделал следующее: таблица с триггером
функция на триггере
Собственно, вопроса два. 1) для самоуспокоения и просвещения. Во всех примерах в гугле динамические таблицы создаются после проверки их на существование. Я сделал через обработку исключения. На мой взгляд выгода в моем варианте в том, что при уже существующей таблице строка в нее записывается сразу, без проверки ее существования. Однако, возможно тут есть какие-то подводные камни, о которых я не знаю(например, затраты на возбуждение и обработку исключения болььше, чем проверка таблицы на существование). Просьба на них указать. 2) практический вопрос. Никак не получается сделать уникальным поле "uid" в рамках таблицы "packages". Получается только на каждой партиции. Возможно ли это, и если да, то как? |
| Автор: Zloxa 18.9.2013, 00:05 |
И как оно ваще - работает? Интересуюсь потому что знаком с ПГ лишь понаслышке. DDL должен бы коммитить транзакцию, а триггер должен бы работать в пределах транзакции. Известные мне системы не позволяют завершать транзакцию в теле триггера. Ну и вобще DDL в прикладной логике это моветон. PS http://www.postgresql.org/docs/9.3/static/ddl-partitioning.html, оказывается в PG действительно с секционированием тоска-тоска Походу - нет. Ответ на столько же очевиден, насколько легко гуглится А что ускоряете то? Быть может оно вам и в пень не вдулось. Секционирование добавляет перфомансу в весьма специфических случаях. В общем случае, оно скорее его уменьшает. |
| Автор: Zloxa 18.9.2013, 09:56 | ||||
что с транзакцией? Транзакцию триггер при создании новой таблицы рвет? Если это действительно так, это минус в карму постгру. Обратите внимание на то, что в примере, приведенном в документации, новая секция автоматом не создается. Обычно в этих случаях секции нарезают впрок. Повторюсь. DDL в прикладной логике - моветон. Повторяю.
не всякое чтение.
До определенного предела. Если у вас в выборке используются все данные по одному - двум месяцам, это действительно может дать профит. Но профиту будет тем меньше, чем больше месяцев попадает в эти выборки. Полный фулскан будет иметь оверхед. Межсекционный отбор, скажем, по товару, будет иметь существенный оверхед, даже если отбор идет по индексам. |
| Автор: Paher 18.9.2013, 11:00 | ||||
Если я правильно понял вопрос, то не рвет, транзакции работают правильно, с полным откатом по ROLLBACK Впрок по датам вряд ли получится предсказать, когда проект умрет и сколько надо сделать секций. А проект должен работать и без постоянной поддержки. Так что пришлось создавать динамически. Если коробит DDL в триггере, подскажите, как от него избавится тут вопрос был уже не в том, можно ли, а в том, где найти обяснение, почему нельзя, ведь для меня не так очевиден
Это все понятно, естественно, это обдумал до секционирования, мои запросы позволяют снизить оверхед при разделении. Опять таки в теории. Сейчас провожу эксперименты, какой вариант в действительности будет быстрее на одинаковых данных |
| Автор: Zloxa 18.9.2013, 11:39 | ||||
Я правильно понимаю что это означеат, что PG создает новую таблицу либо в контексте текущей транзакции, либо в автономной? Если так, пожалуй стоит забрать ранее выставленный минус в карму
По этой причине определяют регламент проведения технических работ в рамках которого донарезаются секции. Потому что индекс может обеспечивать уникальность лишь в пределах таблицы же. На сколкьо я понял из документации, секционирования как такового в ПГ не реализовано. Документация предлагает некий воркэраунд, который с помощью подручных, не в первую очередь для того предназначенных средств, позволяет воспроизвести эффект близкий к эффекту секционирования. Глобального индексирования с помощью приведенных средств добиться нельзя, о чем в документации указанно явно. |
| Автор: Paher 18.9.2013, 11:53 | ||||||
На мой взгляд все же предпочтительнее автоматизация вспомогательных рутинных процессов, хоть и некрасивыми средствами. Машина не ошибается, а человек - сплошь и рядом. Могут забыть, могут неправильно написать. И не всегда возможно объяснить, например, заказчику не технарю, почему он должен постоянно следить за базой и даже что-то там делать
Секционирование реализовано частично, например, чтение из секционированной таблицы не требует плясок с бубнами. А вот с записью - да, приходится костылей написывать
за это огромное спасибо, что-то я это проворонил |
| Автор: Zloxa 18.9.2013, 12:07 | ||||
Походу http://wiki.postgresql.org/wiki/Transactional_DDL_in_PostgreSQL:_A_Competitive_Analysis(и тут, похоже только оракля нот суппорт транзакшнал ДДЛ). Таки тут плюс в карму постгру. В документации на сей счет, правда, чойта не могу нагуглить.
Секционирование не реализовано. Реализовано наследование, ограниченное исполнение, триггеры, правила, средствами которых можно добиться функционала близкого к функционалу секционирования |