Apache Solr is an open-source enterprise search server.
N/A
iManage Insight
Score 8.0 out of 10
N/A
iManage Insight is an enterprise search tool formerly known as HP Autonomy Universal Search. iManage was divested by Hewlett-Packard in 2015. The newly formed iManage company is headquartered in Chicago.
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.
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.
It adheres to traditional Microsoft standards such as: fact-dump documentation with no coherent story or 'best practices' information, inability to automate common tasks, intentional obfuscation of its basic operations.
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.
There are about a dozen different config files to maintain, and the most important one is dynamically modified by Autonomy itself while it runs. Which means that it is impossible to automate the configuration or keep the configs in versioned source control. Even `cp *.cfg ~/cfgbak/` won't help you roll back a change, because it is never safe to restore a previous config. You'll be using `diff new.cfg old.cfg` a lot.
The Linux port is poorly thought out. The binaries are named *.exe. The StartService.sh scripts contain both `echo 'Are you sure you want to start the service? Hit ctrl-C to cancel''; read dummy` and, I kid you not, a `chmod a+x /path/to/my/binary.exe`.
Many features are poorly documented, leading to lots of back and forth with the support department just to answer basic questions like "what does this error code in my logs signify?"
It seems to reinvent the wheel, poorly, everywhere. E.g. the scheduled backup feature rolls through a user-defined finite list of directories in which to store backups. On day 0 it uses directory 0, on day 1 it uses directory 1, and after day N it rolls back and overwrites directory 0. Why would this be preferable to using a single directory and naming zip files based on the current timestamp?
Management wants to see ROI on the (hefty) cost of purchasing this software, and has mandated that we continue using it. We would prefer to switch immediately.
