Describe internals, how es segments/source/fields are stored/merged and search-speed compared to normal-es

[ddorian]

Is _source saved in es? If yes, is it possible to disable it (and only store in cassandra) ?

[ddorian]

Now that I reread it, it says "elasticsearch on top of cassandra".
I think that mens _source is saved in cassandra columns, right ?
And how are es-indexes/segments stored ? Is the search time ~equal to normal es ? Is a segment stored in a sstable ?

Meaning more description of internals ?

[vroyer]

Hi,

Yes, _source is stored in cassandra, each field in a cassandra column stored in SSTable. Lucene files are still managed by the original elasticsearch code, and search features remain unchanged. During the fetch phase of a search, requested field are retreived from the underlying cassandra table through a CQL request.

If you update a cassandra cell, a secondary index rebuild the document from the updated row and index it in elasticsearch. Search then remain unchanged. Of course, to avoid duplicate results if your cassandra replication factor > 1, every document is indexed with a token fields (murmur3 of the partition key), and a token filter is added to every search request to avoid duplicate results. This filter is computed from the routing table of the coordinator node, see token_ranges.

Hope this help.
Thanks'.

[ddorian]

Do you do something like Datastax Solr does when doing global queries to remove duplicates ?

Due to the fact that you can have several replicas of the same document in your Solr data-center (RF > 1), a proper token range predicate is added to each query before sending it to execution. Each query returns documents with row keys within the appended token range(s). Token ranges are selected in such a way that each token range is handled by exactly one node. Therefore, there is no need for additional duplicate removal and merging the results is a simple and fast union.

I mean, you say you do, but on this page https://github.com/vroyer/elassandra/blob/master/cross-datacenter-replication.md you say:

Looking at cluster state with the elasticHQ plugin, you can notice that the total number of document is twice the one available in kibana. This is because all elassandra nodes are primary, so replicated data are indexed twice in a primary shards.

And isn't elasitcHQ doing just a count there ? Doesn't the count have automatic token filtering ?

Thanks

[vroyer]

ElasticHQ issue a stats request and get shards information including size on disk for primary shards, so no filtering is involved. Of course, this is erroneous in elassandra, because a shards may contains data for primary and non-primary token ranges.
Thanks.