lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson" <erickerick...@gmail.com>
Subject Re: performance/scalability issues re filtering of protected search results
Date Mon, 10 Nov 2008 20:06:01 GMT
This has been discussed more than a few times, I suggest you take
a look at the searchable archive for things like privileges, access
privileges, etc. You'll find lots of information faster that way...

Best
Erick

On Mon, Nov 10, 2008 at 2:52 PM, Michael Wechner
<michael.wechner@wyona.com>wrote:

> Hi
>
> We have about 1 mio documents and growing within a hierarchical order (3 to
> 20 deep) and about 3000 people accessing these nodes, whereas some people
> have access to certain branches and other people to other branches and some
> branches are shared. The access control of these nodes is changing every day
> and also contains shortcuts  which allows people to glimpse into parts of
> branches which they otherwise do not have access to.
>
> Currently we have one index for all nodes, which is ok
> peformance/scalability wise, but before displaying the results we need to
> filter based on the access privileges each user has, which is very bad
> peformance wise, because it might be that the first 10K hits are all
> protected re this user and hence it can take a very long time that one
> finally finds a result that the user is actually allowed to see.
>
> We were thinking about introducing an index for each user which only
> contains the documents a user is actually is allowed to see, but this
> doesn't scale well either if the user number is growing.
>
> Any hints how other people are approaching such a situation would be very
> much appreciated.
>
> Thanks
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message