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.
I recommend Splunk on-call is more suited where there are high incident queues; multiple teams need to be involved in handling a P1 severity issue. Multiple levels of escalation are needed environment where automated action is required. I recommend the solution for large-scale & medium-scale business units. For small-scale business units, I see the functional value is less.
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.
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.
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.
VictorOps support has proven excellent for us. Because it is such a widely used tool, there is a lot of documentation on usage, and a large community of users to lean on. Also, many engineers have had experience working with VictorOps already, and the tool is so easy to setup / manage that much support isn't really necessary.
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.
Splunk On-Call integrates better with our Splunk Cybersecurity and Reporting products due to the same family tree of the same eco system. We were previously using built-in on-call from individual applications and while adequate, they were difficult to manage and support SLA varied greatly across different applications. In addition we also used xMatters which did not integrate well with SAP products nor Citrix products so we were still using more than a single on-call product which was solved by implementing Splunk On-Call
