Summary:

- This link isn't really for ElasticSearch as a data store

- ElasticSearch is distributed. Its benefits are realised when it is used that way.

- ElasticSearch requires more than half the node count as master nodes to avoid split brain issue.

- if you have great deal of data but limited resources, ElasticSearch might not be good.

- Under the same question but in a different answer, a user talks about how big a memory hog ElasticSearch is.

{  "t": <time>,  

   "d": {
     "id": <object_id>,
     "resource": "walls",
     "action": "update",
....  

   } 

}

1. { 'd.builder_id': <curr_user_id>, 'd.resource': 'walls', 'd.action': 'update', 'd.user_id': { '$ne': <curr_user_id>' }}

2. {'d.wall_id': { '$in': [<wall_1>,<wall_2>...]}, 'd.resource': 'wishes', 'd.user_id': {'$ne': <curr_user_id>}}

We then sort the results by time.

I built the following indexes.

['d.builder_id', 'd.resource', 'd.action', 'd.user_id', 't']

['d.wall_id', 'd.resourc'e, 'd.user_id', 't']

The first index works for the first OR query. But the second, not so much.

This is because each mongo query can only use 1 index.

The next is because the 2nd clause in the OR query uses $in, thus it cannot reference a contiguous series of entries in an index, hence Mongo cannot use it.

The other way is to run (say) 100 mongo queries, 1 for each wall that should have been in the $in query, and merge them based on time (using the merge operation in a merge sort). This is too painful.

We can also change the query to not use $in and just fetch all wish events for all walls, then filter document by document. But that's probably the slowest way to do it, based on the profiling.

The other alternative is to write to a separate collection. Or write to a separate postgres instance. Or use elasticsearch.

Going to do some reading up on elasticsearch.

I think we need to move away from MongoDB.