Amazon EMR vs Elasticsearch

• Amazon Elastic MapReduce works well for managing analyses that use multiple tools, such as Hadoop and Spark. If it were not for the fact that we use multiple tools, there would be less need for MapReduce.
• MapReduce is always on. I've never had a problem getting data analyses to run on the system. It's simple to set up data mining projects.
• Amazon Elastic MapReduce has no problems dealing with very large data sets. It processes them just fine. With that said, the outputs don't come instantaneously. It takes time.

Read full review

• As I mentioned before, Elasticsearch's flexible data model is unparalleled. You can nest fields as deeply as you want, have as many fields as you want, but whatever you want in those fields (as long as it stays the same type), and all of it will be searchable and you don't need to even declare a schema beforehand!
• Elastic, the company behind Elasticsearch, is super strong financially and they have a great team of devs and product managers working on Elasticsearch. When I first started using ES 3 years ago, I was 90% impressed and knew it would be a good fit. 3 years later, I am 200% impressed and blown away by how far it has come and gotten even better. If there are features that are missing or you don't think it's fast enough right now, I bet it'll be suitable next year because the team behind it is so dang fast!
• Elasticsearch is really, really stable. It takes a lot to bring down a cluster. It's self-balancing algorithms, leader-election system, self-healing properties are state of the art. We've never seen network failures or hard-drive corruption or CPU bugs bring down an ES cluster.

Read full review

• Sometimes bootstrapping certain tools comes with debugging costs. The tools provided by some of the enterprise editions are great compared to EMR.
• Like some of the enterprise editions EMR does not provide on premises options.
• No UI client for saving the workbooks or code snippets. Everything has to go through submitting process. Not really convenient for tracking the job as well.

Read full review

• Joining data requires duplicate de-normalized documents that make parent child relationships. It is hard and requires a lot of synchronizations
• Tracking errors in the data in the logs can be hard, and sometimes recurring errors blow up the error logs
• Schema changes require complete reindexing of an index

Read full review

• Positive: Helped process the jobs amazingly fast.
• Positive: Did not have to spend much time to learn the system, therefore, saving valuable research time.
• Negative: Not flexible for some scenarios, like when some plugins are required, or when the project has to be moved in-house.

Read full review

• We have had great luck with implementing Elasticsearch for our search and analytics use cases.
• While the operational burden is not minimal, operating a cluster of servers, using a custom query language, writing Elasticsearch-specific bulk insert code, the performance and the relative operational ease of Elasticsearch are unparalleled.
• We've easily saved hundreds of thousands of dollars implementing Elasticsearch vs. RDBMS vs. other no-SQL solutions for our specific set of problems.

Read full review