23 Nov
2015
23 Nov
'15
12:50 p.m.
+1 for the non-RDBMS approach for AS and Stats. Makes sense for transient
and maybe loosly-structured (e.g. event parameters) information.
+1 for using Solr with a separate core, unless some technical limitation
exists, since I would prefer avoiding bloating XWiki more than it already
is and increasing complexity.
Thanks,
Eduard
On Mon, Nov 23, 2015 at 11:48 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Note that one reason I started this thread is because
we want to rewrite
the AS (see
http://design.xwiki.org/xwiki/bin/view/Proposal/AcitvityStreamRefactoring62)
and IMO if we do this we should not continue to store the events in main
store (RDBMS).
We also know that stats can be a bit slow and it also doesn’t make sense
IMO to store them in the main store.
So my main goal is to see if we agree on these 2 points.
Thanks
-Vincent
On 21 Nov 2015 at 12:01:31, vincent(a)massol.net (vincent(a)massol.net(mailto:
vincent(a)massol.net)) wrote:
Hi devs,
I think that for data that are both not critical and high volume we
should use
ElasticSearch instead of saving them in our RDBMS.
So the idea would be to have an embedded ES in XWiki by default (using
the
permanent directory to store its data) and admins could configure XWiki
to use a separate ES instance (very similar to what we do with SOLR).
Whenever a user modifies/creates/deletes/does operations on
XObjects/etc, this is
sent to ES.
The AS UI queries ES to display the data.
The Stats UI does the same.
Pros:
- scalability
- performance
- extensibility. It’s easy to evolve the schema in ES, and we can easily
have
several formats (as was proven by the Active Installs code)
I’d like to start a POC in my “free” time.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs