Migrating To Kinetica 7.2

While any version of Kinetica can be upgraded to the latest version using KAgent, there are several aspects of upgrading that should be considered before doing so, as well as a number of steps that should be taken after installing Kinetica 7.2.

Database Clients

The native APIs are backward compatible with prior releases; any clients that make use of these interfaces do not need to be updated after installation.

To make use of the new array, JSON, & vector column types these interfaces should be upgraded.

See Native APIs for instructions on upgrading client APIs.

Database Drivers

The ODBC/JDBC interfaces are backward compatible with prior releases; any clients that make use of the ODBC or JDBC drivers do not need to be updated after installation.

To make use of the new array, JSON, & vector column types these interfaces should be upgraded.

See JDBC for instructions on upgrading drivers.

Core

Disk-Optimized Column Attribute

Previous releases of Kinetica supported the application of a disk-optimized attribute to a unrestricted-width string column, which would prevent the column from being loaded into an indexing service. This resulted in less disk usage at the cost of some features not being applicable to that column.

In Kinetica 7.2, this feature is no longer supported. The indexing service has been removed, and most features applicable to restricted-width string column will now be applicable to unrestricted-width string columns.

The removal of the indexing service may free up a great deal of storage.

It may be beneficial to profile the disk & memory usage of the database after upgrade to determine if any resizing of either is warranted.

Store-Only Column Attribute

Previous releases of Kinetica supported the application of a store-only attribute to a column, which would prevent the column from being loaded into memory. This resulted in the need to persist the intermediate results of queries that referenced store-only columns.

In Kinetica 7.2, this feature is no longer supported. Any accessed columns will be loaded into memory and the writing of intermediate query results is no longer required.

The backing storage for store-only columns has been removed, which may free up a great deal of storage.

It may be beneficial to profile the disk & memory usage of the database after upgrade to determine if any resizing of either is warranted.

AAW

If AAW is being used, ingests will need to be recreated and models redeployed. Also, the models' SDK should be upgraded.