webMethods API Portal guide
Background
Complex internal entities(fine grained parts of API definitions) are stored in an efficient, compressed binary form (as "binary large object", a.k.a. "BLOB" columns). That way, loading a complete entity is a single key-based database access, which is very fast. The drawback is however, that it is now no longer possible to perform complex SQL queries on Portal content via SQL. This is where Cloudsearch comes in: Cloudsearch holds indexes over the portal data, both indexes for attribute-based (including full-text) search and structural indexes that describe the relationships among Portal entities (for ex APIs and its resources).
How it works
Cloudsearch indexes are held completely in memory, making it possible to answer even complex queries (that would correspond to large joins across many tables) without any disk access. With Cloudsearch indexes it is now feasible to perform even complex structural queries over Portal content with good response times and with high throughput, which is needed in particular for the portal, which is built to allow a large number of concurrent users (a primarily read-only) access to the repository.
The relational database still holds all information there is about the Portal content - the data held in the index structures in Cloudsearch is just derived from the database content. This has the advantage that if for some reason the Cloudsearch indexes and the database content become out of sync or the index is corrupted in some way, it can be rebuilt from the database content, a process known as reindexing.
Which applications(Microservices) uses it.
Only the business server (API), portal (Copernicus) components make use of CIP and Cloudsearch, which have been further optimized to cover their specific use cases.
Othere applications document storage component (ADS), collaboration(ECP) uses a more traditional 3NF schema, still represents their data in the database BUT do not use the CloudSearch.