After careful consideration, we decided to end support for Amazon FinSpace, effective October 7, 2026. Amazon FinSpace will no longer accept new customers beginning October 7, 2025. As an existing customer with an Amazon FinSpace environment created before October 7, 2025, you can continue to use the service as normal. After October 7, 2026, you will no longer be able to use Amazon FinSpace. For more information, see [Amazon FinSpace end of support](https://docs.aws.amazon.com/finspace/latest/userguide/amazon-finspace-end-of-support.html). 

# Dataviews for querying data


Dataviews allow you to place portions of your Managed kdb Insights object store database onto disk for faster read-only access from your kdb clusters. To your kdb process, the dataview looks like a kdb segmented database, with data placed across one or more disk mounts (volumes) and the object store. This lets you place frequently-queried data on a fast-access disk for more performant access while keeping the rest of the data in the object store layer for less frequent access. With dataviews, the golden copy of your database’s data still remains in the object store format. The data stored on disk for faster access is a copy.

![\[A diagram that shows how dataviews work.\]](http://docs.aws.amazon.com/finspace/latest/userguide/images/11-managed-kx/finspace-dataviews-intro-diagram.png)


Dataviews can be accessed from HDB and General purpose (GP) type clusters for read only access. The data within a dataview is accessible from the cluster as a kdb [segmented database](https://code.kx.com/q/database/segment/) that is automatically configured when you associate the dataview with the cluster. 

A segment is a mount point that can contain a portion of a database. Different segments could contain different data partitions, tables, or even columns. A kdb *par.txt * file that FinSpace automatically creates when you mount a database defines the segments.

The segments of this segmented database can reside on different kdb Insights disk volumes. A segment of your database can be any portion of it. For example, consider a database with contents as the following date-partitioned layout. 

```
/sym
/2023.10.01/trades/price
/2023.10.01/trades/time
/2023.10.01/trades/quality
/2023.10.01/trades/price
/2023.10.02/trades/time
/2023.10.02/trades/quality
/2023.10.02/trades/price
/2023.10.03/trades/time
/2023.10.03/trades/quality
/2023.10.03/trades/price
/2023.10.04/trades/time
/2023.10.04/trades/quality
/2023.10.05/trades/price
/2023.10.05/trades/time
/2023.10.05/trades/quality
/2023.10.05/trades/price
/2023.10.01/trades/.d
/2023.10.02/trades/.d
/2023.10.03/trades/.d
/2023.10.04/trades/.d
/2023.10.05/trades/.d
```

In this example, `trades` is a table and `time`, `quantity`, and `price` are columns. You can store the most recent day of data on a high throughput volume, two days prior to that on 250 MB/s/TiB volume, with the rest accessible as a segment from the object store layer. The following table shows the data and segments.


| Database contents | Segments | 
| --- | --- | 
|  /2023.10.05/trades/time /2023.10.05/trades/quality /2023.10.05/trades/price  |  **Segment**: **Dataview Segment 1** **Stored On**: Managed kdb Insights Volume 1 [High throughput – 1000 MB/s/TiB]  | 
|  /2023.10.04/trades/time /2023.10.04/trades/quality /2023.10.04/trades/price /2023.10.03/trades/time /2023.10.03/trades/quality /2023.10.03/trades/price  |  **Segment**: **Dataview Segment 2** **Stored On**: Managed kdb Insights Volume 2  [Medium Throughput – 250 MB/s/TiB]  | 
|  /2023.10.02/trades/time /2023.10.02/trades/quality /2023.10.02/trades/price /2023.10.01/trades/time /2023.10.01/trades/quality /2023.10.01/trades/price  |  **Segment**: **Dataview Default Segment** **Stored On**: Object store   | 

This gives you control to place copies of portions of your database on the appropriate type of disk for access, if you require higher performance access than what is available with the default object store storage.

In addition, having the ability to explicitly place data on different volumes when creating a dataview, the contents directly under the root (/) path of the database, such as `/sym` in this example, are always copied to the cluster’s local storage for fast access.

## Auto-updating vs static dataviews


When you create a dataview, you can specify from one of the following types of dataview.
+ **Auto-updating** –An auto-update dataview contains the most recent version of the data in the database. Its contents are automatically updated as new data is added to the database. 
+ **Static** – For a static dataview, the data within the view is not updated automatically as new data is added to the database. When creating a static dataview, you specify a database version identifier that is the changeset ID. The dataview will contain contents of the database as of that changeset ID. To refresh the contents of a static dataview, you need to update it. If you do not provide a changeset ID when updating a dataview, system picks the latest one by default.

## Dataview versions


When you create a dataview, it is assigned an initial version. Each update, whether automatic or manual, creates a new version of a dataview. A dataview version becomes active when it is mountable. A dataview version is released when it is not attached to any clusters and when it's no longer the latest active version.

## Data placement


For each volume, you specify a list of paths for the data that you want to place on the volume. This can be done by using the db paths. Your paths can include the wildcard characters — asterisk (\$1) and question mark (?). Here are a few examples of how you can use db paths for segment configuration. 
+ To specify a particular partition – `/2020.01.02/*` or `/2020.01.02*` 
+ To specify all partitions for Jan 2020– `/2020.01.*` or `/2020.01*`
+ To specify all partitions for 1st of each month in 2020 – `/2020.??.01` or `/2020.*.01` 
+ To specify all partitions – `/*` or `*`

## Data cardinality


You can create multiple dataviews for a single database. For example, you may wish to create one dataview based on an older version of the database for historical analysis, at the same time you may want an auto updating dataview for applications to query more recent data in your database. You can also use multiple dataviews with the same data in each, as a way to spread query load from a large number of clusters querying the data. You can create two different dataviews on the same changeset version.

## Consideration

+ Dataviews are only available for clusters running on a scaling group. They are not supported on dedicated clusters.
+ The paths placed on different volumes cannot overlap. For example, you could not place a path of `/2023.10.31/*` on one volume of a dataview and `/2023.10*` on another volume of the same dataview because the paths overlap. This constraint is because each volume is a different segment in the `par.txt` file on the database and contents of a segment can’t overlap.

# Managing kdb dataviews


The following sections provide a detailed overview of the operations that you can perform by using a Managed kdb dataview.

## Creating a kdb dataview


**To create a kdb dataview**

1. Sign in to the AWS Management Console and open the Amazon FinSpace console at [https://console.aws.amazon.com/finspace](https://console.aws.amazon.com/finspace/landing).

1. In the left pane, under **Managed kdb Insights**, choose **Kdb environments**.

1. From the kdb environments table, choose the name of the environment.

1. On the environment details page, choose the **Databases** tab.

1. On database details page, choose the **Dataviews** tab.

1. Choose **Create dataview**.

1. On the **Create dataview** page, enter a unique name for the dataview.

1. (Optional) Enter a description for your dataview.

1. Choose the availability zone that you want to associate with the dataview. Currently, you can only choose single availability zone.

1. Choose a how you want to update data in the dataview from one of the following options.
   + **Auto-update** – Adds the most recent version of the data in a database. The dataview is automatically updated as new data is added to the database.
   + **Static** – Add data based on the changeset ID that you specify. The dataview is not automatically updated as new data is added to the database. To refresh the contents of a static dataview, you need to update it and specify a new changeset ID. When you choose this, the **Read Write** option enables. 

   1. If you choose **Static**, specify the **Changeset ID** to indicate which version of data you want.

   1. 

      If you choose **Static**, you get the option to make dataviews writable. Select **True** if you want to make the dataview writable to perform database maintenance operations. By default, this value is set to **False**. For more information, read [this](finspace-managed-kdb-databases-dbmaint.md) section.

1. (Optional) For **segment configuration**, specify the database path of the data that you want to place on each selected volume. You can also enable **On demand caching** on the selected database path when a particular file or a column of a database is accessed.
**Note**  
Each [segment](finspace-managed-kdb-dataviews.md#segment) must have a unique database path for each volume.
Every data view has a default segment associated with it. The default segment is S3/object store segment. All database paths not explicitly specified to be on a volume are accessible from the cluster through this default segment.
The **Segment configuration** is required if **Read Write** is **True**. You can only add one segment for a writeable dataview. 
The **Database path** is disabled and defaults to **\$1\$1** when **Read Write** is **True** as you cannot have partial writeable dataviews on cache.

1. Choose **Create dataview**. The database details page opens and the table under **Dataviews** lists the newly created database along with its status.

   You can choose the dataview name from the list to view its details.

## Viewing kdb dataview details


**To view and get details of a kdb dataview**

1. Sign in to the AWS Management Console and open the Amazon FinSpace console at [https://console.aws.amazon.com/finspace](https://console.aws.amazon.com/finspace/landing).

1. In the left pane, under **Managed kdb Insights**, choose **Kdb environments**.

1. From the kdb environments table, choose the name of the environment.

1. On the environment details page, choose **Databases** tab.

1. From the list of databases, choose a database name. The database details page opens.

1. On the database details page, choose the **Dataviews** tab that shows a list of dataviews along with its status, availability zones where they were created, and their creation time.

1. From the list of dataviews, choose a name to view its details. The dataviews details page opens where you can view the following details.
   + **Dataview details** section – Displays the metadata of the dataview that you created.
   + **Configuration** tab – Displays the details about the dataview update mode and ID, and the availability zones ID.
   + **Active versions** tab – Displays a list of active versions of the dataview. Each update of the dataview creates a new version, including changeset details and the cache configurations. Each version triggers a workflow to cache database based on the cache configuration. A dataview version becomes active once the workflow finishes. 

     The dataview version is deactivated under the following conditions
     + It's not the latest active version.
     + No cluster is currently mounting this version.

     You can choose the **Version ID** to see details of each active version. 
   + **Clusters** tab – Displays a list of clusters that mounts the dataview.

## Updating a kdb dataview


**To update a kdb dataview**

1. Sign in to the AWS Management Console and open the Amazon FinSpace console at [https://console.aws.amazon.com/finspace](https://console.aws.amazon.com/finspace/landing).

1. In the left pane, under **Managed kdb Insights**, choose **Kdb environments**.

1. From the kdb environments table, choose the name of the environment.

1. On the environment details page, choose **Databases** tab.

1. From the list of databases, choose a database name. The database details page opens.

1. On the database details page, choose the **Dataviews** tab.

1. From the list of dataviews, choose a name and then choose **Edit**.

1. On the edit page, you can update the description for the dataview. If the dataview is **Static**, you can also update the **Changeset ID**.

1. Choose **Save changes**.

## Deleting a kdb dataview


Before deleting a dataview, make sure that it is not in use by any cluster. You can check this from the **Clusters** tab in the dataview details page.

**Note**  
This action is irreversible. Deleting a kdb dataview will delete all of its metadata.

**To delete a kdb dataview**

1. Sign in to the AWS Management Console and open the Amazon FinSpace console at [https://console.aws.amazon.com/finspace](https://console.aws.amazon.com/finspace/landing).

1. In the left pane, under **Managed kdb Insights**, choose **Kdb environments**.

1. From the kdb environments table, choose the name of the environment.

1. On the environment details page, choose the **Databases** tab.

1. From the list of databases, choose the one whose dataview you want to delete. The database details page opens.

1. On the database details page, choose the **Dataviews** tab.

1. From the list of dataviews, choose a name and then choose **Delete**.

1. On the confirmation dialog box, enter **confirm** to provide a written consent to delete the resource permanently.

1. Choose **Delete**.