Check performance

[pawelebe]

Can you please verify if my undersanding of check function is correct:

• when graph is traversing nodes to find matching subject, each userset is triggering another db query
• it implies that for object with many usersets or with deep relations there will be lot of queries triggered, e.g. document which is shared with 100 groups will trigger around 100 SQL queries
• checks if subjects from object match subject from request is done locally (not in db itself)
• it means that if I e.g. share a document for a group with 100k members, then all of that 100k members will be fetched from db, and then checked locally if they match subject

If those assumptions are correct it may mean that performance may be degenerated with lot of relation for one object. Are there any plans to overcome that? Is it real problem? Are there any plans to introduce caching or resolve subjects on db (not locally after fetch from db)

[zepatrik]

First of all sorry for the late response.

Performance is really a key measure here, so it is always very important to find the points where we hit performance problems. There are already various ideas and plans for optimization, but we don't want to apply that prematurely. It would be awesome if you performance-test your specific data model and tell us at which point optimization is required.

Now to the current state. Your points are pretty accurate. Before #638 it would not be possible to do some things in the database, but once that is merged we can add the subject id check to the SQL query. But that will be done incrementally, and if you have specific problems or ideas, please open issues so we can discuss it.

[pawelebe]

We have plans to run some perf tests and see how it behaves for our use cases.

On the other note, I have seen that Keto may be used with postgresql and cockroachdb. Do you have any kind of comparison what may be advantages/disadvantages for both of those engines? My understanding is that cockroachdb is preferred, but why is so?

[zepatrik]

Currently there is no difference, apart from the database itself.
Cockroach offers distributed, multi-node cluster operation, which you need for running Keto globally in multiple data centers.
We will add some Cockroach specific code if needed for such a multi-region deployment, but we will push that back until we really need it.
If you don't plan to have a multi-region deployment anytime soon, go ahead with whatever database you prefer. If you want to have that soonish, I recommend starting with Cockroach right away.