A view is a queryable filter of a table, collection, or another view. A view can also be referred to as a result set.
Views can be organized into five categories:
result_table option specifiedFiltered views can be updated to insert the missing data points for a series from the underlying table, using /update/records/byseries.
A view can be used in place of a table for queries, allowing query chaining, by filtering the views created by previous operations.
As they are result sets, and given the need to minimize memory usage, views are given a default time-to-live, after which they will expire and be removed from memory. Each access of the view causes the remaining time-to-live to be reset. Thus, a view accessed more frequently than its time-to-live will effectively remain in memory indefinitely.
Views have the same naming criteria as tables.
As mentioned previously, one of the ways views can be created is by filtering
an existing table using the /filter endpoint; for example (in Python):
gpudb.filter(
table_name = my_table,
view_name = my_new_view,
expression = "x > 0"
)
An aggregate group-by view holds a new copy of the results from an
/aggregate/groupby operation and is similar to other copied-data views,
e.g., projection and union views. Some
limitations to note:
sum(store_only_integer))result_table_persist option upon creation, the view will become a
table and no longer have this restrictionQuery Chaining in Kinetica is defined as performing one of the endpoint operations listed at the top of the page on a view. Kinetica allows access to all intermediate views after each query. This means that each view can be used to support multiple subsequent operations. Also, given a long sequence of queries, a trace can be performed through the progression of each query to help refine analysis.
As an example, consider an analysis that consisted of three queries chained in sequence. If, at the end of the chain, the expected results were not returned, the result of the second query can be examined. If that query consisted of several records that were expected in the final analysis, it could be deduced that a problem exists with the third query.
Here's an example of creating a view using /filter and then query chaining off of that view:
gpudb.filter(
table_name = my_table,
view_name = my_new_view,
expression = "x > 0"
)
gpudb.filter(
table_name = my_new_view,
view_name = my_second_view,
expression = "y > 0"
)
A filtered view has a relatively lower memory footprint compared to an aggregate group-by view, join view, projection view, and union view.
Join views have a variable memory footprint depending on the type of join. Kinetica will attempt to create the most efficient join view as possible. The different types of join view and their relative memory usage can be found on Joins.
Aggregate group-by views, projection views, and union views copy data from their source data sets, thus their memory footprint can be quite large compared to a join view or a filtered view. However, because the data is copied, there's no reliance on lookups between connected join data sets or scanning the mask on filtered data sets, resulting in faster queries.