Hi,
Just to add to the conversation, I would also recommend ElasticSearch as a
great solution for the search side of things. There are also cases of
people using it as the sole data store. However, I believe caution should
be taken against such an approach since ES currently doesn't provide much
in the way of data recovery or transactions.
For this reason, ES is typically deployed in combination with a data
storage technology that does support these factors, such as Mongo. ES
allows you to define what's known as "rivers", and these pull data out of a
configured data source and into the index, thus providing the benefits of
its powerful search (which is literally insane).
In terms of making use of the rich inherent graph structure of the data at
the higher level, a GraphDB would make sense as suggested by Joel. One
GraphDB that might be worth a look is Titan, which has been developed by
the Tinkerpop guys I believe. Its a distributed graph database which also
(interestingly) supports ElasticSearch. It also abstracts over many data
stores/formats (including RDF) out-of-the-box. ES is a clever move IMO
because one of the challenges in graph search is jumping into the graph in
the first place, and it looks like they use the ES index to do this.
So, you could almost just use Titan for search, get all the benefits of
graph traversals etc., and have it manage your ES index too.
Regards,
Richard
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
