I think a database still makes sense. What we put on top of that is the
AFAIK, that is what most of these social networks do, some of them use a
database (e.g.: MySQL) but also different other things on top of it
to avoid unnecessary hits. Usually these social networks are OK with
eventual inconsistency. In our case, I'm not sure if we want to allow that.
From a database perspective there are some tricks like partitioning
In addition with a good and smart cache layer on top of it.
But yes, that is not something trivial to do considering the amount of data
we can be managing. Hope we can start doing some prototypes soon and see
how it goes.
On Thu, Mar 23, 2017 at 12:35 PM, Marek Posolda <mposolda(a)redhat.com> wrote:
I was wondering about the use-case when users manage permissions to
their own objects. It seems that proper support for this can be very
challenging for the amount of DB space.
For example: I have 1000 documents and I have 1000 users. I want to be
able to define fine-grained permissions and be able to define that user
"john" is able to see document-1 and document-2, but not document-3 etc.
So I can end with up to:
count of users * number of documents = 1000 users * 1000 documents =
1000000 permission records in DB
When authorization scopes (actions) come into play and I want to specify
that "john" is able just to "read" document-1 when "alice"
is able to
"read", "update" and "comment" on document-1, I may end up
million objects in DB (assuming I have 5 actions).
We can do something like divide documents into "groups" and grant the
permission just per group. But for example Google allows to group things
(you can put more photos into one photoalbum and share whole photoalbum
with user "john"), but also define fine-grained permission (share just
single photo with user "john").
My estimation is, that using for JPA for save such data is likely not
feasible. And I bet that Google is really using something different :-)
Maybe we need to restore Mongo or some other similar DB type for manage
this stuff? Or is it something where the "Nearby policy evaluation" can
help and permissions data would rather need to be saved by the
keycloak-dev mailing list