History[03]

In 2009, Amit Vij and Nima Neghaban founded GIS Federal, developed a database software they called GPUdb.

In March 2016, the name of the company was changed to GPUdb to match the name of the software.

In September 2016, the name of the company and the product was changed to Kinetica.

Compression[06][07]

Kinetica supports data compression by individual column. Dictionary encoding can be applied to individual columns of restricted-length (charN) type, int type, or long type. During the query execution and data modification, Kinetica can temporarily decompressed a copy and discard the copy later.

Data Model[05][08]

Kinetica supports the relational data model.

Foreign Keys[09]

Kinetica supports foreign keys. A table in Kinetica can have several foreign keys. The foreign key is a tuning option for joining tables. It acts as a relational index from a source table to corresponding records in a target table. Foreign key can be added during or after table creation.

Hardware Acceleration[05][10]

Kinetica makes use GPU to perform equijoins (sort-merge), predicate joins (nested loop), fixed-length string processing, aggression/window function and rendering. Because GPUs are good at handling SIMT (single instruction multiple thread) and simple data structure.

To make use of GPUs more efficiently, Kinetica encourages data locality to minimize data movement from CPU to GPU.

Indexes[09][11]

Kinetica uses primary key index, relation index and column index to improve data access performance.

A primary key index is created by default when a table is created with a primary key specified. The primary key index is hash-based and optimizes the performance of equality-based filter expressions.

A relational index is created as the result of applying a foreign key to a column.

A column index can be applied to a column in a table or view to improve the performance of operations applied to that column in an expression.The column index is implemented as a b-tree, which provides performance improvements for both equality-based and range-based filter criteria on individual columns. Column indexes can also be applied to the primary key columns.

Joins[10][12]

Kinetica supports the SQL concept of joining data sets. Since Kinetica makes use of GPU acceleration, tables being joined together must either be replicated or be sharded on the columns being used to join the tables to avoid data copying. Besides, distributed joins, or joins that connect sharded tables on columns other than their shard keys, are not supported.

Query Compilation

Query Execution[10][08]

Kinetica would do query plan before query execution to build the optimal query. It can also make use of the users' supplied query hints and existed column indexes to improve the query plan.

Kinetica distributes plan fragments to each chunk. The results are merged hierarchically into a final result.

Query Interface[13][14]

Kinetica is an ODBC-compatible database, supporting ANSI SQL-92 compliant syntax. Further, its native API can be accessed via RESTful HTTP endpoints using either JSON or Avro Serialization methods.

Storage Architecture[05][08]

To optimize throughput and delivery fast query process, Kinetica runs completely in-memory. It make use of RAM and VRAM ( the memory for GPU cards). Hot data would be kept in VRAM to optimize data access and avoid data movement between RAM an VRAM. Kinetica needs a warm phase to load data from disk to memory.

Stored Procedures[15]

Kinetica supports the concept of user-defined functions (UDF) via a mechanism similar to stored procedures, being a user-defined sequence of operations on a specified data set.

Kinetica supports distributed UDF and non-distributed UDF.When distributed, there will be one OS process per processing node in Kinetica. When non-distributed there will only be a single OS process.

System Architecture[05][10][08]

Kinetica is a distributed database system. It main node structure is called rank. Since Kinetica is GPU acceleration, each rank is paired with a GPU. The first rank is head rank, which is a HTTP server to receive RESTAPI request from clients, keep metadata. Other ranks are called workers, keep columnar data in-memory and process query on owned GPUs.