Skip site navigation (1) Skip section navigation (2)

Re: Зацените т

From: "Andrey N(dot) Oktyabrski" <ano(at)antora(dot)ru>
To: Ilia Kantor <ilia(at)obnovlenie(dot)ru>
Cc: pgsql-ru-general(at)postgresql(dot)org
Subject: Re: Зацените т
Date: 2006-07-07 19:16:35
Message-ID: 44AEB313.1080701@antora.ru (view raw or flat)
Thread:
Lists: pgsql-ru-general
Ilia Kantor wrote:
>>> Когда-то я делал похожую вещь.
>>> А именно - поле (или поля) проверки доступа.
>>>
>>> Поле состояло из массива int[], содержащего ID нужных групп доступа.
>> Это довольно громоздко - массивы. Я именно хотел сделать так, чтобы
>> девелОперы пользовались - читай чтоб выглядело более-менее привычно, и
>> чтобы оверхед поменьше был.
> Много групп - несколько прав, вложенные группы. 
> Как у тебя такое сделать?
Я когда планировал, осознавал что ограничения есть и представлял себе 
как они выглядят :-) Простой пример: в freebsd есть UFS ACLs. Как часто 
этим пользуются? В подавляющем большинстве случаев достаточно 
традиционной системы разграничения доступа. Так и здесь. То, что не 
лезет в эту модель, будет просто реализовано другими средствами.

Однако, не так уж и много ограничений. Несколько прав есть, вложенные 
группы есть. Нет только "много групп" - вместо них три (юзер, группа и 
все остальные). Причём, заменить в случае необходимости одного юзера на 
список юзеров и один row_acl на массив из них не так уж сложно.

>>> Для того, чтобы оптимизер мог сделать правильный план, пришлось писать
>>> собственную статистику по таким полям (т.е по int[]).
>> У меня вроде оптимизёр пользуется индексом, проверял. Кстати, забыл там
>> в README пример создания индекса показать:
>> CREATE INDEX obj_acl_idx ON obj USING gist (acl gist_row_acl_ops);
> Да, но тут небольшая проблема. Когда ты делаешь сложный SQL-запрос, то
> оптимизатор должен подсчитать предполагаемое количество результатов каждого
> джойна и каждой выборки (селективность).
> 
> ГИСТ-индексы в простейшем случае создаются без функции, которая подсчитывает
> селективность, с заглушкой - типа всегда 1% от таблицы.
Что это за функция? Где можно взять пример? Как её подключить - есть 
штатные средства, или постгрес хачить? Если второе, скорее всего не 
возьмусь, ибо дело неблагодарное.

> Если ты делаешь сложный запрос, а результатов на самом деле 90%, то
> оптимизатор в отсутствии правильной функции и статистики, составит неверный
> план.
> 
> Хуже всего, когда (в моем случае) есть ряд групп, которые почти всевластны
> (95% рядов удовлетворяют запросу) и ряд групп, которые обладают правом на
> некоторые объекты (1% рядов или меньше).
> 
> Скорее всего, и у тебя возможна такая ситуация, она довольно типична для
> прав.
Надо думать и пробовать моделировать. Если в это упрусь, думать ещё - 
как обойти техническую проблему административными средствами.

> Тогда оптимизатор создает неверный план для всевластных групп (думает что
> 1%, а там все 99%) и, например, использует Nested Loop в неправильную
> сторону (думает что 20 рядов, а там 20000). Результат плачевный, запросы
> просто писать нельзя.
Да, звучит логично и печально :-( Но построчное разделение прав всё-таки 
нужно, а в обозримом будущем обещают только постолбцовое (которое, 
кстати, и мне сильно поможет запретить чтение чего не положено из 
таблицы). Так что деваться некуда - либо что-то придумывать, либо менять 
инструменты. Перед тем как сделать второе, надо доказать что первое 
невозможно :-)

>>> Однако, как внедрить ее в VACUUM/ANALYZE - неясно, а разработчикам на
>>> сие накакать, видимо (никто не помог).
Может, просто не было предусмотрено такое в постгресе?

In response to

pgsql-ru-general by date

Next:From: Andrey N. OktyabrskiDate: 2006-07-09 07:42:55
Subject: Re: Зацените т
Previous:From: Andrey N. OktyabrskiDate: 2006-07-07 14:30:26
Subject: Re: Зацените т

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group