{"id":9797,"date":"2021-08-19T00:00:44","date_gmt":"2021-08-19T07:00:44","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=9797"},"modified":"2025-06-13T20:59:03","modified_gmt":"2025-06-14T03:59:03","slug":"searching-collections-with-full-text-search","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/searching-collections-with-full-text-search\/","title":{"rendered":"How to Use Full-Text Search across Couchbase Scopes & Collections"},"content":{"rendered":"

The Full-Text Search Service now offers<\/strong> better search performance and resource utilization across your cluster with the introduction of Scopes and Collections in Couchbase 7.0.<\/p>\n

Let’s take a quick step back: The 7.0 release of Couchbase Server<\/a> introduces the concept of Scopes and Collections<\/a> that enable you to namespace data within a Couchbase Bucket. Instead of all JSON<\/a> documents having to reside in a single shared namespace, Scopes and Collections provide you a built-in capability to group documents together rather than having to add manual attributes like `type` to a document.<\/p>\n

Let\u2019s explore how you can index and search the data in your Scopes and Collections using the Search Service in Couchbase<\/a>.<\/p>\n

How to Index Data for Search within a Single Collection<\/h2>\n

The Couchbase Full-Text Search (FTS) Service<\/a> works exactly the same as before when it comes to operating and defining new indexes on documents residing within a Bucket. With Scopes and Collections, all existing (pre-7.0) documents in a Bucket are sorted into the `_default` Scope and `_default` Collection. And existing indexes continue to index newer mutations and all queries work as usual.<\/p>\n

Once your team adopts Scopes and Collections, database users will start to namespace multi-schema documents into various Collections. Here\u2019s where Couchbase Full-Text Search changes with the 7.0 release.<\/p>\n

The Search Service supports index creations<\/a> on a single source Collection as well as on multiple source Collections as long as all the Collections belong to a single<\/strong> Scope.<\/p>\n

Essentially, the search indexes can span across multiple Collections but not across multiple Scopes<\/strong><\/em>.<\/p>\n

Example: Full-Text Search with a CRM<\/h3>\n

Let\u2019s delve into more details with the help of an example.<\/p>\n

Consider a CRM use case where your customer details are captured in a `Customers` Bucket and your Order details into an `Orders` Bucket.<\/p>\n

Let\u2019s assume that you\u2019ve organized various customers into different Scopes based on the geographical regions. For example, mapping all the customers from the Asia Pacific region to a specific Scope named `apac` and so on.<\/p>\n

The diagram below illustrates how you might organize your Buckets, Scopes and Collections for your CRM.<\/p>\n

<\/div>\n

\"An<\/p>\n

<\/div>\n

With Collections, indexing and searching data from a single source Collection is the most common and natural use case. It works similar to the existing Bucket-based index creation process. The only difference is that the user has to specify the Scope and Collection details while creating the index definition.<\/p>\n

If you\u2019re indexing the default Scope and Collection within a Bucket, then the index creation steps<\/a> look exactly the same as in the pre-Collection days.<\/p>\n

If you want to index a non-default Scope and\/or Collection(s), then you need to tick the checkbox for \u201cUse non-default Scope\/Collection(s)\u201d in the Couchbase Web UI. Once you complete this step, the index creation process asks you to enter the source Scope and Collection details, as in the diagram below.<\/p>\n

<\/div>\n

\"A<\/p>\n

<\/div>\n

Once you enable the non-default Scope\/Collection(s) checkbox, then you can choose the source Scope for the documents (see below). You may note that the Scope dropdown now lists all the available Scopes within your chosen Bucket (the CRM, in our example).<\/p>\n

<\/div>\n

\"Scope<\/p>\n

<\/div>\n

As shown in the screenshot above, you can select the Scope that the Collection belongs to from the dropdown list as shown above.<\/p>\n

Specifying Type Mappings<\/h3>\n

Once you select the Scope, you\u2019re all set to specify the type of documents you want to index.<\/p>\n

The convention is to specify the type of documents over the Type mappings, and this same type mapping definition pattern continues here too. Upon adding a new Type mapping, the user is given an option to specify the source Collection as shown below.<\/p>\n

<\/div>\n

\"Collection<\/p>\n

<\/div>\n

The user should be able to see all the available Collections in the aforementioned Scope (e.g., `emea`) as a dropdown list like above.<\/p>\n

Indexing All Document Types within a Given Collection<\/h4>\n

You can index every<\/em> type of document in a Collection by selecting the Collection name from the drop-down list for the type mapping name. See the image below for an example.<\/p>\n

<\/div>\n

\"Collection<\/p>\n

<\/div>\n

Indexing Multiple Document Types within a Collection<\/h4>\n

If the Collection hosts multiple document types, then you can specify any number of the interested type mapping names followed by the Collection name as shown below.<\/p>\n

<\/div>\n

\"multiple<\/p>\n

<\/div>\n

The above example would index document types like `deptOrders` and `inventoryOrders` from the Collection `customer1` under the Scope `emea`.<\/p>\n

Scaling Notes<\/h5>\n

Since your Bucket data is now sliced up to a higher granularity from Scopes and Collections, it\u2019s more likely that documents within each of your Collections will have a smaller cardinality.<\/p>\n

Depending on the specific of your Collections, you might not<\/em> need to use the default partition settings of `6` per index to power a smaller dataset.<\/p>\n

Using the appropriate partition count for a given amount of data helps support:<\/p>\n