History[03]

Vetica was founded by Michael Stonebraker and Andrew Palmer in 2005. It is derived from C-Store, which is a prototype developed by MIT, Brown, and few other universities in 2005. It was acquired by Hewlett Packard in 2011 and joined Micro Focus in 2017 due to the merger between Micro Focus and HP.

Checkpoints[04][05]

In Vertica, each node maintains checkpoints and transaction logs separately. The synchronization duration can be tuned by users as well. For a single-node failure, it can be recovered from other nodes. If the entire cluster fails, it can be recovered up to the earliest checkpoints when all nodes are good. New transaction log cannot be appended when a new checkpoint begins.

Compression[06]

Both Run-Length Encoding and Delta encoding are used in Vertica. RLE encoding is only used when the number of repetitions is large. Delta encoding works for INTEGER/DATE/TIME/TIMESTAMP/INTERVAL type, where the variations from the smallest value are stored instead of the real values to save more space.

Concurrency Control[07][08]

Vertica supports MVCC to achieve data consistency. Both current and previous status are stored and visible to transactions. Transaction isolations can be achieved since no conflict between the read and write operations exist. A shared-nothing MPP (Massively Parallel Processing) architecture is used in Vertica, which can avoid the overheads caused by locks.

Data Model[09]

Columnar store is used in Vertica to improve the performance of sequential access by sacrificing the performance of single access. Compared with row-oriented databases which has to scan the whole table, only few needed columns are retrieved based on given queries in Vertica, which can improve throughput by reducing disk I/O costs.

Foreign Keys[10]

Vertica allows users to use foreign key constraints. Foreign keys should be defined when tables are created or "ALTER TABLE" is used.

Indexes[11]

Indexes are not support in Vertica. Projections are used to improve query performance in Vertica.

Isolation Levels[12]

Read Committed and Serializable are used in Vertica. Read Committed is the default isolation level. Read Uncommitted and Repeatable Read are treated automatically as Read Committed and Serializable respectively in vertica.

Joins[13]

Both merge join and hash join are supported in Vertica. Merge join is faster in general and requires less memory, but data is required to be sorted before. Hash join requires more memory, but it is faster if the inner table can fit in the memory.

Logging[14]

There are two kinds of logs at each node in Vertica cluster. The dblog is used to keep track of the status only when the database boots. The other type called vertica.log is used to record the status of the node and the status of the whole cluster when Vertica runs.

Query Compilation

Query Execution[15]

Projections in Vertica have been used for query execution. Query optimizer is responsible for designing and selecting the suitable projections based on the given query plan. Various projections have different influence on query performance in terms of memory, CPU utilization, I/O, Network bandwidth ...

Query Interface[16]

Vertica supports query via SQL and its custom API. Vertica has good integrations with Hadoop, Spark, Kafka, and users could make queries via their interfaces. Moreover, Vertica also supports C++, Java, Python, R SDK.

Storage Architecture[17][18]

Hybrid data store are chosen in Vertica. Write Optimized Store(WOS) is about storing data in memory, which does not support compression and indexing. WOS is mainly designed for OLAP. Read Optimized Store(ROS) is about storing data on disk, where data is sorted and indexed, and compressed.

Storage Model[17]

Data is stored in Vertica in columnar format to improve query performance, since a lot of disk I/O can be avoided.

Storage Organization[19]

Different from other DBMS, containers are used in Vertica to store data,WOS (Write Optimized Storage) and ROS (Read Optimized Storage) are two existing types. Tuple Mover is used to move data between WOS and ROS.

Stored Procedures[20]

Stored Procedures are not support in Vertica. External Procedures such as R,C++ can be used in Vertica.

System Architecture[09][21]

Shared-nothing architecture is used in Vertica, where all nodes don't share anything in terms of memory and disk storage. Shared-nothing architecture are easier to scale, since there is no race or contention caused by locks. Moreover, Massively MPP(Massive Parallel Processing) architecture is used in Vertica, which can improve query performance such as increasing the throughput of joins when multiple machines are involved.

Views[05]

The projections in Vertica are similar to materialized view in other DBMSs. Various projections can be created on the same table so that some optimizations such as sorting data can be done for some specific queries in advance.