Apache Solr is an open-source enterprise search server.
N/A
Elasticsearch
Score 8.5 out of 10
N/A
Elasticsearch is an enterprise search tool from Elastic in Mountain View, California.
$16
per month
LoadRunner Professional
Score 8.6 out of 10
N/A
A solution simplifies performance load testing for colocated teams. With project-based capabilities, so teams can quickly identify abnormal application behavior.
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 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 …
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.
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 …
Apache Solr is the closest competitor to ElasticSearch from a search engine perspective. ElasticSearch is simple and streamlined in it's configuration. When taken as a whole, Apache Solr is more robust as a storage engine from a developer perspective, ElasticSearch has the …
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 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 …
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 …
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 …
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 …
NEST library is excellent, excellent performance, and scalability (we used a cluster of 2 nodes, and most the queries completed in ms, some may take up to 2s.
Elasticsearch is widely popular and it's mostly free. Its ecosystem, ability to scale, ease to set up, integration with other systems, highly usable API make it really great compared to its competition.
Elasticsearch is DevOps friendly; it is easy for installation and management of a node/cluster. It is very friendly for developers by providing the REST API out of the box, reducing the development time.
Elasticsearch is based off of Apache Lucene. You get the same power as well as a JSON response. REST API is simple and easy to understand. Other options include XML responses which is much more complicated to parse at times.
For our application, ElasticSearch fulfilled all the criteria we were looking for. Something that's easy to scale and flexible. I think ElasticSearch works better that Solr with modern real-time search applications. Also, ElasticSearch is easy to integrate with. ElasticSearch …
Solr is the only other alternative product I've used. Elasticsearch in comparison is a much better product. The query language in elasticsearch along with the cluster management and sharding makes Elasticsearch a clear winner.
Ability to support JSON queries, Percolator, ease to set up and custom routing were some of the reasons why we decided to use Elasticsearch instead of Solr.
Solr spins up nicely and works effectively for small enterprise environments providing helpful mechanisms for fuzzy searches and facetted searching. For larger enterprises with complex business solutions you'll find the need to hire an expert Solr engineer to optimize the powerful platform to your needs. Internationalization is tricky with Solr and many hosting solutions may limit you to a latin character set.
Elasticsearch is a really scalable solution that can fit a lot of needs, but the bigger and/or those needs become, the more understanding & infrastructure you will need for your instance to be running correctly. Elasticsearch is not problem-free - you can get yourself in a lot of trouble if you are not following good practices and/or if are not managing the cluster correctly. Licensing is a big decision point here as Elasticsearch is a middleware component - be sure to read the licensing agreement of the version you want to try before you commit to it. Same goes for long-term support - be sure to keep yourself in the know for this aspect you may end up stuck with an unpatched version for years.
Micro Focus LoadRunner and its suite of tools, specifically VuGen works wonderfully for us for all web, http/https and web service calls. We've been able to build tests for near any scenario we need with relative ease. As long as we have crafted up requirements for our scenarios / scripts to managed scope, we've had high success working with scripting and data driving. Our main tests are web service calls - typically chained together to form a full scenario with transactions measuring the journey or a similar (measure along the way) journey through a browser. For web services we will use VuGen and browser we've shifted to Tru Client I have had little-to-no experience scripting against a thick client where a ui-driven test would be required. I know its possible but quite costly due to the need to run the actual desktop client to drive tests. We've been fortunate enough to leverage http calls to represent client traffic.
Easy to get started with Apache Solr. Whether it is tackling a setup issue or trying to learn some of the more advanced features, there are plenty of resources to help you out and get you going.
Performance. Apache Solr allows for a lot of custom tuning (if needed) and provides great out of the box performance for searching on large data sets.
Maintenance. After setting up Solr in a production environment there are plenty of tools provided to help you maintain and update your application. Apache Solr comes with great fault tolerance built in and has proven to be very reliable.
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.
These examples are due to the way we use Apache Solr. I think we have had the same problems with other NoSQL databases (but perhaps not the same solution). High data volumes of data and a lot of users were the causes.
We have lot of classifications and lot of data for each classification. This gave us several problems:
First: We couldn't keep all our data in Solr. Then we have all data in our MySQL DB and searching data in Solr. So we need to be sure to update and match the 2 databases in the same time.
Second: We needed several load balanced Solr databases.
Third: We needed to update all the databases and keep old data status.
If I don't speak about problems due to our lack of experience, the main Solr problem came from frequency of updates vs validation of several database. We encountered several locks due to this (our ops team didn't want to use real clustering, so all DB weren't updated). Problem messages were not always clear and we several days to understand the problems.
HP LoadRunner with new patches and releases sometimes makes no longer support older version of various protocols like Citrix, which makes the task time-consuming when using older versions of LoadRunner for some of the cases. So it should support older version as well while upgrading.
Configuring HP LoadRunner over the firewall involves lots of configuration and may be troublesome. So, there should be a script (power shell script for Windows or shell script for Linux users) to make it easy to use and with less pain.
I would like to see the RunTime Viewer of Vugen in HPLoadRunner based on the browser I selected in the run-time configuration to make it feel more realistic as a real user.
Licensing cost is very high when we need to perform a test on application for a specific group of users.
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.
Customer service is not that great. It's difficult to get hold of someone if an issue is supposed to be addressed on an urgent basis. No online chat service readily available.
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 will be a little less expensive and offer more customization and flexibility.
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 text-based search capabilities across large data sets, Elasticsearch is the way to go.
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.
The scripts created with traditional web/http protocol are not robust thus re-scripting is required after most every code drop. Troubleshooting and fixing the issue takes more time therefore in most cases we do re-scripting to keep it simple and save time.
In ideal world you would rather spend more time doing testing than scripting in that case mostly you could use an Ajax TruClient protocol. This type of script will only fail when an object in the application is removed or changed completely. This way of scripting will save you more time and helps you maintain the scripts with less re-work effort on a release basis. On the long run you will have a better ROI when you use Ajax TruClient protocol for scripting.