In Jive 6.0, Content and Places search is provided by a search service that is separate from the core Jive installation. The Cloud Search Service is hosted in Jive datacenters and provides infinite scale, continuous improvements and advanced social context through Jive Find. The Cloud Search Service is available for Jive 6 instances running in customer premises as well as those hosted in Jive datacenters. For customers who prefer not to use the cloud Search Service, an alternative On-Premise Search Service implementation is available.
- General Questions
- Cloud Search and Jive Find
- How do I configure Jive to use the search option I want?
- What configuration options are available for search in 6.0?
- Can on-premise search be HA?
- Is there any form of encryption or tokenization of index data?
- What High-Availability options are available for the search and ingress replication services?
- In event of search service failure, where does ingress replicator store indexing requests?
- In the event of a Search service outage, where do web app nodes store indexing requests?
- Does the internal Search service support HTTPS?
- Do all Search endpoints have to be in the same LAN?
- What are the latency and bandwidth requirements for Search?
- Why don't Places and/or Content show up in Search results?
What search deployment options are available?
- Customers deploying Jive on-premise have the option to connect their instance to the Jive Cloud Search Service or to install their own copy of the On-Premise Search alternative. (See How do I configure Jive to use the search option I want? below.)
- Customers hosted in Jive datacenters use the Cloud Search Service by default. Hosting the On-Premise Search Service is available by special request. Hosted 6.0 customers must file a support ticket specifically requesting the On-premise Search alternative if they want to use that option.
- Jive Cloud customers always use the Cloud Search Service.
What does it mean that search in Jive 6.0 is a service?
In contrast to previous versions of Jive in which the search infrastructure was embedded inside the core Jive application, in Jive 6.0 the Content and Places search infrastructure is separate and other parts of Jive 6.0 communicate with it over a precisely defined application interface. This separation makes it possible to have multiple compatible implementations of the search service and also to make improvements to the Cloud Search Service in a way that is completely transparent to the rest of Jive.
How does People Search work?
In Jive 6.0, the infrastructure that supports People Search is embedded inside the core Jive application. This is similar to how all search worked in previous versions of Jive. However, the relevance algorithms in People Search have been improved in Jive 6 to ensure that matches on a name field are higher than matches in other profile elements.
How does search work in general?
This is better outlined here: Search in 4.x, 5.x, and 6.x (and cloud)
Cloud Search and Jive Find
What are the benefits of the Cloud Search Service?
Cloud Search provides the following benefits:
- Infinite scale. By leveraging a cloud-based big data infrastructure, the search service can scale to any level while providing full redundancy.
- Continuous improvement. Because search is deployed as a separate service, it can be improved at any time without disruption to the operation of Jive itself. Just as with familiar web search tools, the relevance of Jive search results simply get better over time.
- Jive Find. Using patent-pending technology for incorporating dynamic data in search rankings, Jive’s search service incorporates social information for improved search relevance. See What is Jive Find and how does it work? below for more information.
How does the Cloud Search Service work?
The Jive Cloud Search Service is a modern multi-tenant search service built on advanced big data technologies such as Hadoop, HBase and Katta.
How is data separated in the Cloud Search Service?
The Cloud Search Service rigorously follows best practices for data separation. All data is written, stored and accessed with a tenant-ID unique to the owner of the data and no access to data for a given tenant-ID is permitted unless a client also presents a secret key for verification in accordance with OAuth. All communication is over https.
What is Jive Find and how does it work?
Jive Find provides improved search relevance by incorporating social information into search. Search rankings are tailored for individuals based on dynamic signals derived from activity within Jive.
More precisely, as users use Jive, data is generated about activity such as views, creates, responses, and likes. These activities are processed in the Jive Recommender service and summarized into a form that can be used by Jive Search to enhance the relevance of search results. When a user searches for content or places, items that are considered "close" to the user (based on the activities performed by the user or other individuals connected to the user) are given a boost in the search rankings. This personalizes search results for each user. The details of how user activity translates into levels of boost will change over time as the system is optimized.
Where is the Cloud Search Service?
The Cloud Search Service is served from Jive datacenters in Phoenix, Arizona and Amsterdam, The Netherlands.
How do I configure Jive to use the search option I want?
- Customers hosted in Jive datacenters default to using the Cloud Search Service. If a customer wants to have an instance of the On-premise Search Service hosted for them, they should inform the Jive support & hosting teams by filing a ticket.
- To use Cloud Search with a Jive instance deployed on premise, the steps are
- File a ticket with Jive requesting access; every IP address connecting to Jive search needs to be granted access
- Select the Cloud Search option in the search configuration screen in the admin console
- To use the On-Premise Search service with a Jive instance deployed on premise, the steps are
- Install the On-Premise Search Service
- Select the the On-Premise Search option in the search configuration screen in the admin console and provide the location of the service you installed
- It is possible to switch between Search Service implementations at any time. For example, a customer that initially used the On-Premise Search alternative could later switch to using Cloud Service. Note that after any change a content index rebuild must be initiated.
For details on installation and other administrative operations see the: Jive 6.0 Community Administrator Documentation
What configuration options are available for search in 6.0?
The search service implementations available with Jive 6.0 are designed to be plug-and-play. Other than the basic setup options, no configuration options are available.
Can on-premise search be HA?
Yes. In addition to a single node configuration, the On-premise Search Service can be configured to run across multiple nodes in an active/active configuration. Details will be provided in a forthcoming paper on deploying Jive on premise with HA. Note that even in a single node configuration, losing the search service results in a temporary loss of service but no data loss. When the search service comes back online access to search resumes and indexing jobs catch up. If the search index becomes corrupted, a rebuild can be performed.
Is there any form of encryption or tokenization of index data?
No. The search service does not work with encrypted data.
What High-Availability options are available for the search and ingress replication services?
Please refer to the High-Availability documentation: http://docs.jivesoftware.com/jive/6.0/community_admin/index.jsp?topic=/com.jivesoftware.help.sbs.online_6.0/admin/HighAvailabilityIntro.html
In event of search service failure, where does ingress replicator store indexing requests?
Indexing requests are stored in a configurable location in the index replicator's file system.
In the event of a Search service outage, where do web app nodes store indexing requests?
Web app nodes store indexing requests in their file system.
Does the internal Search service support HTTPS?
No. We expect the on-premise search service to be deployed in a secure environment.
Do all Search endpoints have to be in the same LAN?
Although Search endpoints are not required to be on the same LAN, the deployment topology expects them to be.
What are the latency and bandwidth requirements for Search?
Bandwidth requirements vary with the amount of content created and the Search load, but it's low. The most bandwidth needed is during an index rebuild when bandwidth usage is highest. Latency is only a concern if it negatively impacts search performance.
Why don't Places and/or Content show up in Search results?
If places and/or content don't show up in Search results, and you see the following error in the On-Premise search service logs, then you have a corrupt entity store database. This database is used for highlighting search results, and is not part of the search index itself. This may have been caused by the Search service process being killed unexpectedly.
2013-01-09 08:20:24,018 [qtp1620711584-26] WARN org.eclipse.jetty.servlet.ServletHandler - /searchIndexRebuild/entries
java.lang.Error: double get for page 8721
To resolve this error:
1. Stop the Search service.
2. Delete all files with names starting with "entityStore" in the Search service data directory. The default path is /usr/local/jive/services/search-service/var/data/contentSearch/entityStore*
3. Start the Search service.
4. Initiate a Content search index rebuild.
Note: You may see unhighlighted Search results until Jive completes the index rebuild.