syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Laszlo Miklosik (JIRA)" <>
Subject [jira] [Commented] (SYNCOPE-1006) Performance and NoSql database support
Date Thu, 02 Feb 2017 14:59:51 GMT


Laszlo Miklosik commented on SYNCOPE-1006:

Thanks for the fast reply, sorry for being too direct, I didn't know about the proposals first
going through the mailing list :)

I will check the abstract persistence layer support to see what it would mean to add MongoDB.

It would make sense to benefit of the schema-less and flat structure of a document store.
That would mean no "joins" (or multiple collections involved) for getting attribute values,
thus dropping the table-emulated-map-style storage structure for attribute values. Would be
nice if this would be permitted by the abstraction you mentioned.

> Performance and NoSql database support
> --------------------------------------
>                 Key: SYNCOPE-1006
>                 URL:
>             Project: Syncope
>          Issue Type: Improvement
>            Reporter: Laszlo Miklosik
>              Labels: Improvement
> CRUD via the API and especially the search are very slow when you have e.g. 400.000 users
with 30-40 normal attributes in place.
> JPA and relational databases are not the optimal solution for the performance sensitive
problem of provisioning and Syncope's search query builder is a very complex/fragile piece
of code.
> I am using Syncope 1.1.5 at the moment but I expect no miracles from 1.2.10 or 2.x with
this amount of users and the same persistence solution.
> I am raising this ticket because I did not find performance related items planned in
the Syncope roadmap.
> - Do you consider switching the persistence layer to a document store (e.g. MongoDB)?
I think its schema-less nature would be ideal for storing flexible attributes and this way
the row/document count explosion problem would be avoided by design. 
> - Another possible performance improvement would be an async layer for the persistence
and/or the REST API as well. Maybe using e.g. Redis or other publish-subscribe solution for
this part?
> Thanks!

This message was sent by Atlassian JIRA

View raw message