Deployment topologies and scenarios

WebSphere Commerce Search indexes are created separately based on a specific master catalog. After you deploy the WebSphere Commerce Search index, you can separately manage and rebuild each index to refresh its data.

Performing a full reindexing rebuilds the entire search index, while a delta reindexing performs only incremental updates on the existing operational search index. Before you deploy your index, you must consider the index-building scenarios, depending on your WebSphere Commerce Search environment.

The following topologies are typical when you build a search index:
  • A production server with a dedicated index-building machine.
  • A staging and clustered search server.
Note: It is recommended that the same operating system is used across all search servers: that is, the master search server, subordinate servers, and search server cluster.

Examples: Deployment topologies and scenarios

The following sample topologies are available for small to large index sizes:
Important: In all scenarios, it is recommended to only index in an authoring or staging environment. That is, an environment that is used for quality assurance (QA) purposes, and if required, containing access to the production database. Otherwise, the runtime search performance or index integrity can be affected by indexing within a production environment.

Small or medium index size: WebSphere Commerce production server with a dedicated index-building machine

A dedicated index-building machine, which is known as the master, is used to build the index. The index is then replicated to other search machines, which are known as targets. The runtime search performance is not affected during index-building.

Note: Building the search index can still be a timely process, and might occasionally lead to inconsistencies between the database and search index. However, the runtime search performance is not affected during index-building due to the offset of the processing load to another machine.
The following diagram illustrates a typical WebSphere Commerce Search deployment for a small or medium index size:
Small or medium index size deployment
WebSphere Commerce EnterpriseWebSphere Commerce Professional

Recommended: Large index size: Staging propagation and clustered search servers

The index-building is performed on the WebSphere Commerce staging database and search staging machine. Business users can test their new data in the staging database with the updated index. After successfully completing their tests, the data is propagated from the staging database to the production database, and the index is replicated from the search staging machine to the search production machines using the master indexing server. This is the recommended approach, as this option imposes the least amount of risk to the production environment and provides a more flexible environment for making incremental changes.

The following diagram illustrates a typical WebSphere Commerce Search deployment for a large index size:
Large index size deployment

Timeline of events

The following diagram illustrates the timing of events you must consider when indexing with staging propagation:
Timeline of events when indexing with staging propagation
  1. A start time is passed as a parameter to the indexprop utility at the time the command is issued by an IT Administrator.
  2. This start time defines the period where cache invalidation starts. Typically, the start of the staging propagation operation.
  3. The indexprop utility monitors the progress of the index replication on all the search subordinate servers in production.
  4. After all of the index replications are completed successfully, the indexprop utility issues a cache invalidation instruction by inserting an entry of type restart into the CACHEIVL table, by using the provided start time parameter as the time to start performing cache invalidation.
For more information, see Indexing with staging propagation.