Release Notes for MariaDB ColumnStore 1.4.2

S3 Storage Manager

MariaDB ColumnStore now has the ability to use any object store that is Amazon S3 API compatible. The new Storage Manager uses a persistent disk cache for read/write operations so that it has minimal performance impact on ColumnStore. In some cases it will perform better than local disk operations.

Usage instructions:

1. Before running postConfigure, edit the storagemanager.cnf configuration file to specify the S3 connection parameters (as detailed in the S3 section of that file), and the local machine configuration (as detailed in the ObjectStorage and Cache sections). The configuration file is documented in-line. Enable the Storage Manager by setting ObjectStorage/Service to S3

2. Run postConfigure, and when promoted for type of storage, select the StorageManager option.

cpimport S3 Support

cpimport is a high-speed bulk data loading utility for ColumnStore. cpimport now includes command-line options for loading a CSV file from Amazon S3 (and compatible) buckets.

When these options are set, cpimport will use the path/filename provided to load an object from object storage instead of a local file. Current behavior is to download the entire file into memory before processing.

Expanded Data Type Support

• TIMESTAMP (with CURRENT_TIMESTAMP)

• BOOLEAN

• MEDIUMINT

Please note that for cpimport the current system time of the PM node is used.

MODA() Mode Average UDAF

The MODA() UDAF (User-Defined Aggregate Function) determines the mode average. MODA() has tie-break behavior to use the closest to the average, and then the smallest absolute value.

Statement-Based Replication Support

Statement-based replication into ColumnStore tables is supported by setting columnstore_replication_slave=on on the UM that will apply the replication data. Row-based replication events on ColumnStore replica (slave) tables will currently fail, generating an error viewable with SHOW SLAVE STATUS

Performance Enhancements

• The performance of BRM (Block Resolution Manager) snapshots has been increased for improved performance when committing data to ColumnStore.

• To reduce SSD wear and and increase write performance for large data sets containing many columns, ColumnStore now allocates disk as-needed, writing only real data and padding to fill the remainder of an 8KB block. ColumnStore previously wrote twice -- once to pre-allocate an empty file for each new extent (8 million item file for a column), and a second time to fill the file with real data.

• The outer "ORDER BY" of a query is now processed using ColumnStore's engine instead of MariaDB server. This uses a faster sorting algorithm for higher performance with larger result sets.

• Joins use a new hash algorithm which is significantly faster and requires significantly less initial memory to execute.

• Memory cleanup after query execution now occurs in a separate thread. This previously occurred in the main ExeMgr thread, which could delay execution of new queries.

InfiniDB Alias Eliminated

ColumnStore 1.2 and earlier included the InfiniDB engine as an alias. This alias has now been removed. All ColumnStore tables must now be created with the engine name "columnstore". All MariaDB system variables prefixed with "infinidb_" have now been removed.

vtable Replaced by Query Execution Handlers

vtable has been replaced with a set of query execution handlers: Select Handler, Derived Handler, and table API mode.

The vtable mode switch (infinidb_vtable_mode system variable) has been eliminated. Two new session variables have been added: columnstore_select_handler, columnstore_derived_handler

The Select Handler is the replacement for a vtable, and is the default query execution handler. It is expected to provide the fastest execution path for the whole query.

Select Handler lacks support for some vtable features, including:

• Cartesian JOIN

• Non-Equi JOIN

• INSERT .. SELECT

• SELECT INTO OUTFILE

If the Select Handler fails to execute a query, an error is returned. If a query fails under the Select Handler, set columnstore_select_handler=off for the session. This will cause the Server to hand-off query execution to the Derived Handler. The query must be restarted after the session variable has been set.

If the Derived Handler fails to execute a query, an error is returned. If a query fails under both the Select Handler and Derived Handler, set columnstore_select_handler=off and columnstore_derived_handler=off for the session. This will cause table API execution, an equivalent to disabled vtable mode in ColumnStore 1.2.x and earlier. The query must be restarted after the session variables have been set.

Deployment Methods

ColumnStore 1.4 is included with MariaDB Enterprise Server 10.4 on select Platforms.

ColumnStore is available for deployment from package tarball and repository. ColumnStore is not available for deployment from binary tarballs.

"Distributed Install" Method Eliminated

The "distributed install" method which pushed packages onto other nodes during postConfigure has been removed. ColumnStore packages must now be installed on all nodes prior to startup.

Configuration Path Changes

ColumnStore XML configuration files have moved to /etc/columnstore

MariaDB Enterprise Server configuration options for ColumnStore have moved to /etc/my.cnf.d/columnstore.cnf and the default MariaDB Enterprise Server my.cnf will load this file.

Data Directory Path Change

The ColumnStore data directory has moved to /var/lib/columnstore and is separate from the MariaDB Server data directory at /var/lib/mysql

Executable Path Changes

ColumnStore binaries have moved to /usr/bin or /usr/sbin, and the libraries are in the OS standard /usr library path. Some ColumnStore binaries have been renamed to avoid conflict, including:

User Account for Cross-Engine Joins

Cross-engine joins depend on TCP connection from ExeMgr to the Server process. Since the database root user in MariaDB Enterprise Server 10.4 authenticates only by UNIX socket, a dedicated user must be created to support cross-engine joins. The cross engine section of Columnstore.xml should be edited accordingly.

Can result in data loss

• DBRM files could be deleted during a failover scenario. (MCOL-2152)

Can result in a hang or crash

• Certain window function queries could crash the Server process. (MCOL-3434)

Can result in unexpected behavior

• group_concat() with DISTINCT concatenates even non-distinct values. (MCOL-2146)

• Wrong results could be returned for a complex query with subquery and window functions over decimal(12,4) column. (MCOL-3423)

• Pipe operator (|) could return wrong results. (MCOL-174)

• DIV operator could return wrong results. (MCOL-179)

• Comparison of padded strings could provide incorrect results. (MCOL-1559)

• CREATE TABLE could fail when table name contained space and certain characters; not A-Z a-z 0-9 _ (MCOL-2219)

• DISTINCT could be performed in incorrect order relative to Window functions and UNION (MCOL-3492)

• cpimport outputs value truncation warning when read buffer (-b) is set to 1 (MCOL-774)

• Cross-engine joins with query using DISTINCT could return NULL (MCOL-3588)

• Bulk write API writes were possible when writes were suspended. (MCOL-3576)

• Multi-column IN statements could produce incorrect results. (MCOL-3448)

• JOIN could significantly waste memory. (MCOL-1758)

• Memory leaks. (MCOL-3621)

• Plugin metadata was inconsistent. (MCOL-3681, MCOL-3669)

Related to install and upgrade

• Cosmetic typo in postConfigure output. Output upon success is now MariaDB ColumnStore Install Successfully Completed, System is Active (MCOL-1598)