syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò (JIRA) <>
Subject [jira] [Commented] (SYNCOPE-1006) Performance and NoSql database support
Date Tue, 07 Feb 2017 16:47:41 GMT


Francesco Chicchiriccò commented on SYNCOPE-1006:

Another option we could evaluate is to embed ElasticSearch in Syncope - see this [blog post|]
for an idea - and to leverage JPA entity listeners to update ElasticSearch indexes whenever
users, groups or any objects are created, updated or deleted.

At that point, a new implementation of [AnySearchDAO|]
could be provided, relying on the embedded ElasticSearch, rather than the current [JPAAnySearchDAO|]
which is querying the SQL views.

Finally, we should also provide instructions to setup an embedded ElasticSearch cluster, for
covering the case of Syncope HA deployments.

It seems that such JPA + ElasticSearch approach has some supporters (Hibernate provides even
a dedicate module for that).

> 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