Between Solr and ElasticSearch, there is a constant struggle to pick the best one. ElasticSearch is part of ELK and ties in well with LogStash and Kibana which makes it great for logs and big data stuff. Add some logs and see which works best for your particular access methods …
We have considering AWS search and Elastic search but decide to go with Solr as we need high speed and flexible query, and so far it meets all our requirement so we still continue with Solr.
We tried to use both Elasticsearch and Swiftype with Drupal 8 but there are currently no good modules that integrate Drupal with those solutions. So Solr was really the only option for a Drupal 8 web site. It's not as easy to learn or use as Swiftype, but in the end I think it …
Before using Solr, we used a self-made search engine. Solr has helped us increase our capacity to serve our customers the results they are looking for easily without breaking down. Our previous platform was not dynamic enough to accommodate our growing traffic or smart enough …
Azure Search is not as mature as Apache Solr at this point. So the range of query flexibility is less than Solr. Also, when indexing content goes beyond 1 TB, it might become costly for Azure Search.
We switched from search indexes stored in mysql to soar and it's made a world of difference for our growing businesses. The relational databases are very poor for handling the complex data searches require and Solr delivered all the tools we need to get the performance our end …
Apache Solr in general stacks up very well to its competitors, it provides much of the same features and performance and has the benefits of being an open-source project with an active contributor base that works consistently and improves the platform. Depending on your setup …
We tryed to promote Redis as cache solution for application, in order to replace Apache Solr, but it won't go well. Redis best pratices requires some more computer resources. With Elastic Search, the use case was another, and don't compete with Apache Solr.
Elasticsearch has a steep learning curve, but it is the best in terms of customization and use cases it can cover most of the business needs. The other tools might be easier to integrate with and start seeing results, but you will end up having issues when you need customized …
Elasticsearch is relatedly cheaper the splunk. Opensearch is good and we migrated some data into it but the critical data stays in elasticsearch as it has formal support.
They all have their specific pros and cons. Elastic was actually initially brought in to provide less expensive functionality to Splunk, and Splunk use cases. Grafana was brought in to provide less expensive visualizations compared to Splunk and Elastic...I would recommend …
Elasticsearch is the most well-known and supported free data platform that we identified. We are taking advantage of community knowledge and practices. In terms of flexibility and breadth of use cases no other competitor came close to Elasticsearch. We've tried Solr in the past …
Elasticsearch brings the capacity to grow data ingest and provides 24/7 visibility into critical services across IT and Business teams. With Elasticsarch, specialized support teams can easily view all the relevant information by using real-time dashboards, and can immediately …
Elasticsearch and Solr are both based on Lucene, but the user community for Elasticsearch is much stronger, and setting up a cluster is easier. Splunk is very well suited for Log indexing and searching but is not nearly as flexible as Elasticsearch. Couchbase is a great NoSQL …
Search and analytics capabilities of Elasticsearch are superior to its competitors. Being open source, it is a cheaper and faster solution than other competitors. Installation is straightforward and it can be potentially deployed anywhere and everywhere! There is no need for …
Faster, better, more efficient. There was no comparison in Elasticsearch vs LEM. AlienVault was decent but too expensive for what it does compared to Elastic. The only competitor I'd consider as in the same ballpark in the SIEM world is Splunk. Save yourself the money and get a …
I think Elasticseach works less great compared to Splunk. Mainly the way the Splunk search head works is vastly superior to the way the Elasticsearch query language works. Furthermore, the Splunk architecture is in my opinion easier to roll out and scale-up. Splunk also has a …
Elasticsearch is very well packed in a broad set of features, ranging from customization capabilities to security and add-ons, and also comes with a great visualization tool named Kibana. Most of the competitors are strong in some of these areas, but I know of no other that's …
Almost no one uses Solr anymore--most have migrated to Elasticsearch. I've never tried it myself but I heard Solr is much more difficult to configure and because it doesn't use a REST API, it locks you into Java and XML. XML--ick! Lucene: Elasticsearch is built using Lucene …
From my perspective, there is nothing currently on the marker better than Datadog, but unfortunately, that's a pricey product, Elasticsearch deliver us part of Datadog functionalities being cheaper. Fluentd as a service (provided by the company behind Fluentd) looks like a …
Previously, we used Microsoft SQL Server's full-text search. Elasticsearch is faster and that includes searching and indexing and re-indexing the catalog of products.
With Elasticsearch you can integrate a lot of data sources. It can act as a small DataLake where you can put different kinds of data and extract important insights. With Splunk, additional to elevated costs of licensing and hardware, you need to have expert engineers to address …
All database systems have things they are good at, and things they aren't as good at. Riak/SOLR is great as a K/V store, but SOLR cannot handle requests as fast as ElasticSearch. In fact, SOLR is the reason we had to migrate to ElasticSearch. Redis is great at SET operations …
ES does not compete with the above packages but compliments them. By automating and mining logs, you are able to get a sense of the business process, marketing data or whatever else you need to capture and mine. The potential energy stored within Elasticsearch makes it a great …
Elasticsearch is the most powerful and easy to use platform in this market. It's open source which makes enhancements very possible and also makes customization something that is commonplace. We're able to create custom modules to pull data from both log and config files, which …
As far as we are concerned, Elasticsearch is the gold standard and we have barely evaluated any alternatives. You could consider it an alternative to a relational or NoSQL database, so in cases where those suffice, you don't need Elasticsearch. But if you want powerful …
When we first evaluated Elasticsearch, we compared it with alternatives like traditional RDBMS products (Postgres, MySQL) as well as other noSQL solutions like Cassandra & MongoDB. For our use case, Elasticsearch delivered on two fronts. First, we got a world-class search …
Apache Solr and Elasticsearch are both open-source enterprise search software solutions that allow users to search and retrieve data within an organization. Both software options integrate with tools like databases or intranets where information can be collected or displayed. Businesses of all sizes use both Apache Solr and Elasticsearch.
Features
Apache Solr and Elasticsearch both provide essential enterprise search features, including data retrieval and display. Despite this, both software options have a few standout features that set them apart from each other.
Apache Solr offers robust text search features that allow users to search for materials by their content. Apache Solr has many contributors to its open-source code. Developers and code committers for Apache Solr are selected from that community of contributors. This approach to development means bugfixes and updates are frequent, and features can be developed quickly. Lastly, Apache Solr provides detailed documentation for developers, including multiple examples.
Elasticsearch is lightweight to the extent that a business can install and run the Elasticsearch in a matter of minutes. Similarly, Elasticsearch configuration is based on JSON, which makes file configuration simple, if a little inflexible in terms of documentation. JSON compatibility also makes Elasticsearch a great choice when working with JSON applications. Elasticsearch focuses on complex querying and filtering, though it also offers basic text search. Lastly, Elasticsearch is designed for the cloud and supports clustering, leading to a highly scalable option.
Limitations
Though Apache Solr and Elasticsearch have robust sets of features, they both have a few limitations that are important to consider.
Apache Solr offers text search features but is limited when it comes to more complex querying and filtering. Lack of complex querying can make Apache Solr a poor choice for applications that need non-text search features. Additionally, Apache Solr is a heavier software option compared to Elasticsearch, which can make installation more challenging for lightweight applications.
Elasticsearch is open-source in that all users have access to the source code. However, unlike many open-source technologies, all changes to the code must be approved by Elastic developers. As a result, Elasticsearch provides the financial benefits of open-source software but doesn’t offer the same level of community development as Apache Solr. Additionally, though Elastisearch provides complex search features, its text search features are more limited compared to Apache Solr.
Pricing
Apache Solr and Elasticsearch are both open-source technologies, meaning their source code is available for free. Despite this, both software options also have vendors that provide cloud hosting services. Pricing for Apache Solr and Elasticsearch is dependent on factors such as the vendor, support needs, and amount of indexed nodes. Apache Solr pricing usually starts around $10.00 per month, while Elasticsearch starts around $16.00 per month.
Very effective for end-user searching applications and for generating search results. Also very well suited to those looking for high reliability and performance. If [you're doing] fuzzy searching or if you are working on a smaller end-user application or an internal application that does not require high performance and flexible/adapting searching then it may not be necessary to use Solr.
Elasticsearch is really well suited for searching text (Natural Language Processing) and you can fine tune the searches and scoring very well. I like the ability to find Significant Terms in the Index, where you can find aggregations that are really relevant to a specific search. It also allows for queries to lead to new queries via aggregations which is great for navigating your data. It is less suited to doing more complex aggregations where slices of data are required to be processing using guassian normalizations. And doing searches which join different documents is very very hard, and requires serious thought on how to denormalize data.
Faceted navigation and field collapsing/grouping : filtering and quick results were what we needed for our websites. Our customers needed to have this functionalities for good and efficient results.
We tested them with our customers' registered searches (they received all new goods matching with their registered searches by emails and/or mobile push). Results were incredible by comparison with our old system (old MySQL requests).
Note : we didn't put all our data in Solr. Just what we need for searching uses. Other data stayed in our MySQL database.
Auto-suggest : our old auto-suggest wasn't performing well. With Apache Solr, our new one was worked really well ! The suggestions came quickly and suggestions were good.
We also extended auto-suggestion with geo-spatial data and it worked well.
Hit highlighting : we used this functionality and we didn't have problem and nasty surprise.
Keep all data status during data upgrading (see next details for improvements)
Setting Java memory thresholds can be a pain for those not accustomed to things like Eden Space & Old Generation which can lead to over allocation, or more likely, under allocation. Apache Solr had a similar issue. It would be nice if the program would take an extra step and dogfood it's own advice by analyzing the system & processes to return a solid recommendation for that configuration. The proper configuration information is outlined in the documentation, it would be nice if that was automated.
The only health check that ElasticSearch reports back is a "red" status without any real solid information about what is going on, though its usually memory thresholds or disk I/O. I am currently on ElasticSearch 1.5 so that may have changed for newer versions. When the status goes "red", I as the administrator of the software, feel like I lose control of whats going on which should rarely happen. Something more verbose would eliminate that.
This is more of a critique of the ElasticStack in general. The whole top to bottom stack is starting to get feature creep with things that are better suited in other software and increasing the barrier for entry for people to get started with setting up a robust logging infrastructure. ElasticSearch as a storage search engine, is pretty streamlined, but I can see that the tools that comprise the ELK Stack are going to require a certification with constant study at some point. During major release for Logstash a while back, it literally took a month to learn a new language because Elastic completely changed the syntax. For a medium sized organization of only a couple of admins, that is a pretty high bar where time is money. They really should work on refining/automating the tools & search engine they have, instead of shoehorning/changing things on to an already rock solid foundation.
It takes some time to deploy and currectly maintein it. And also, to learn how to use and integrate in the enviroment as well. Once you get theses steps done, it usability is very simple, and almost of the time it don't require no further attention on it. Even for maintence, if you deploy it on a cluster mode, it is very reliable and easy to take one host down.
To get started with Elasticsearch, you don't have to get very involved in configuring what really is an incredibly complex system under the hood. You simply install the package, run the service, and you're immediately able to begin using it. You don't need to learn any sort of query language to add data to Elasticsearch or perform some basic searching. If you're used to any sort of RESTful API, getting started with Elasticsearch is a breeze. If you've never interacted with a RESTful API directly, the journey may be a little more bumpy. Overall, though, it's incredibly simple to use for what it's doing under the covers.
We've only used it as an opensource tooling. We did not purchase any additional support to roll out the elasticsearch software. When rolling out the application on our platform we've used the documentation which was available online. During our test phases we did not experience any bugs or issues so we did not rely on support at all.
We switched from search indexes stored in MySQL to soar and it's made a world of difference for our growing businesses. The relational databases are very poor for handling the complex data searches require and Solr delivered all the tools we need to get the performance our end users are demanding.
Elasticsearch is the most well-known and supported free data platform that we identified. We are taking advantage of community knowledge and practices. In terms of flexibility and breadth of use cases no other competitor came close to Elasticsearch. We've tried Solr in the past be we encountered issues which were deal-breaking for us. MongoDB - it just did not pass our evaluation parameters as a main data platform. We still use it for smaller purposes, though.
It's enabled us to deliver fast, relevant search results on our new website. The site is still in beta and being actively developed so our complete ROI is still unknown.
It integrates very well with Drupal so it has saved us from having to develop a custom solution.
I am not in finance and I suspect even if I was this would be hard to measure. But for sure, Elasticsearch has enabled us to have the most flexible data model in the industry for our customer's data, and in doing so we have attracted many many technical customers and got much of their $$$.
One problem with Elasticsearch is that because it runs on the JVM, there can be some stop-the-world JVM garbage collections happening that can take down nodes and reduce indexing speed. The solution for that tends to be "let's just upgrade the CPU on that machine". And before you know it you are paying $$$ because this'll happen with 40+ machines.
On the other hand, I do think that ES is more efficient than other systems and so it requires fewer nodes to keep it highly tolerant and available, so we probably saved some money that way.