WiredTiger Memrata support

WiredTiger supports Memrata KVS devices as a data-source.

To configure one or more Memrata KVS devices as WiredTiger data sources, take the following steps.

Building the WiredTiger Memrata Support

To build the Memrata support, add a link in the WiredTiger build directory to the installed location of the Memrata software. For example:

% cd wiredtiger
% ls /usr/local/memrata
kvs.h           libkvs.a        libkvs.so
kvs.h.4.2       libkvs.a.4.2    libkvs.so.4.2
% ln -s /usr/local/memrata memrata
% ./configure && make

Loading the WiredTiger Memrata Support

Second, change your application to load the Memrata shared library. The following example loads the Memrata shared library, configuring and naming two separate Memrata device pools. The first device pool is named dev1, the second device pool is named dev2. Device pool dev1 has two underlying Memrata devices, /dev/ssd0 and /dev/ssd1. Device pool dev2 has a single underlying Memrata device, /dev/ssd2.

#define MEMRATA_LIBRARY_PATH    "test/memrata/.libs/libwiredtiger_memrata.so""
ret = connection->load_extension(connection, MEMRATA_LIBRARY_PATH,
    "config=["
    "dev1=[kvs_devices=[/dev/ssd0,/dev/ssd1],kvs_open_o_truncate=1],"
    "dev2=[kvs_devices=[/dev/ssd2],kvs_open_o_truncate=1]]");

The kvs_devices configuration string takes a WiredTiger configuration list, that is, a comma-separated list of Memrata devices.

In this example, both device pools are configured to be truncated (that is, all previously existing contents discarded), when they are configured.

When loading a Memrata device, the following additional configuration strings are supported:

String	Type
kvs_devices	list of lists
kvs_parallelism	int
kvs_granularity	int
kvs_avg_key_len	int
kvs_avg_val_len	int
kvs_write_bufs	int
kvs_read_bufs	int
kvs_commit_timeout	int
kvs_reclaim_threshold	int
kvs_reclaim_period	int
kvs_open_o_debug	boolean
kvs_open_o_truncate	boolean

With the exception of the configuration string kvs_devices (which is WiredTiger specific), see the Memrata device documentation for details on their use.

Creating Memrata-backed objects

The device pool names are used as part of the URI specified to WiredTiger methods such as WT_SESSION::create or WT_SESSION::rename, separated from the object name by a single slash character.

Additionally, the memrata type configuration string must be included.

The following example creates a Memrata table named access in the device pool dev1, and then opens a cursor on the table:

WT_CURSOR *cursor;
WT_SESSION *session;

/* Create the access table. */
ret = session->create(
    session, "table:dev1/access", "key_format=S,value_format=S,type=memrata");

/* Open a cursor on the access table. */
ret = session->open_cursor(session, "table:dev1/access", NULL, NULL, &cursor);

When creating a Memrata-backed object with the WT_SESSION::create method, the following additional configuration strings are supported:

String	Type
kvs_open_o_debug	boolean
kvs_open_o_truncate	boolean

See the Memrata device documentation for details on their use.

For example, creating and truncating a table could be done as follows:

WT_SESSION *session;

/* Create and truncate the access table. */
ret = session->create(session, "table:dev1/access",
    "key_format=S,value_format=S,type=memrata,kvs_open_o_truncate=1");

Memrata notes

• Memrata devices do not support named checkpoints.
• Inserting a new record after the current maximum record in a fixed-length bit field column-store (that is, a store with an 'r' type key and 't' type value) does not implicitly create the missing records.
• Memrata devices do not support bulk load as a special case, and configuring cursors for bulk load has no effect.
• Memrata devices do not support compression of any kind.

Memrata limitations

• WiredTiger transactions cannot include operations on both Memrata devices and other stores.