Blockchain Overview

Blockchains

bSQL blockchains are fundamental containers for data storage, manipulation, and retrieval. bSQL offers four different blockchains to build containers to your specific data needs. All containers offer the fundamental bSQL features:

• pseudo mutablity

  ↳ Only the state of a blockchain can be changed, history can never be overwritten.

• atomic mutations

  ↳ Indivisible and irreducible mutations prevent partial writes.

• bSQL compliant

  ↳ All blockchains are query compatible and come with a suite of performance enhancing commands.

Blockchain Types

• HISTORICAL → Optimized for historical data collection and logging. The historical blockchain is a bare-bone ledger optimized for fast insert speeds, large datasets, and non-primary key dependent data.

• HISTORICAL PLUS → Handles primary key dependent data and is optimized for infrequently updated data with inter-blockchain dependencies.

• TRADITIONAL → Provides traditional features such as primary and foreign keys as well as blockchain-specific attributes such as time series selection, validity, and lifetime tracking. This container was designed to manage relational data while providing fast access to mutation history.

• SPARSE → Provides the same functionality as a traditional blockchain but optimizes storage by only storing changed values.

Blockchain mutation logic

Each blockchain handles mutations differently. This section provides a reference for the mutation logic given different blockchain types. These concepts are helpful when understanding mutation logic:

• Data is append-only in the database files, not the indexes.
• If a page is full and no currently open transaction have written to it, it is sealed and hashed and sent to append only file locked by the OS. This process is called archiving.
• The non-locking system uses MVCC.

HISTORICAL

Historical blockchains don't allow AMEND or DISCONTINUE commands. A Historical blockchain is a bare-boned ledger, stripped of indexes and primary key constraints. Mutations are extremely fast because data will always be written to the end of the blockchain and no primary key checks are necessary.

Blockchain	Stage	INSERT	AMEND	DISCONTINUE
historical	Mutation Checks	Basic schema check.	✕	✕
	Mutation Actions	Append the record to the shard.	✕	✕
	Post-Mutation	Archive pages if applicable.	✕	✕

HISTORICAL(+)

Historical(+) blockchains allow both AMEND and DISCONTINUE commands. They use a primary key, secondary index to keep track of the current state of the blockchain. Because the indexes don't keep track of the record histories, they are more space efficient than the Traditional blockchain.

Blockchain	Stage	INSERT	AMEND	DISCONTINUE
historical(+)	Mutation Checks	Basic schema check.	Basic schema check.	Basic schema check, generate tombstone record.
	Mutation Actions	Append the record to the shard. Add the record ID to the primary key index, checking for uniqueness.	Append the record to the shard. Update the record ID primary key index, checking the old value exists.	Append a tombstone record to the shard. Update the record ID primary key index, checking the old value exists.
	Post-Mutation	Archive pages if applicable.	Archive pages if applicable.	Archive pages if applicable.

TRADITIONAL

Traditional blockchains use a primary key, secondary index to keep track of all blockchain states. This adds extra data pages to the system called cluster pages. ROLLBACK, SET TRANSACTION, and TIME-TRAVEL QUERIES benefit greatly from rapid access to record histories.

Blockchain	Stage	INSERT	AMEND	DISCONTINUE
traditional	Mutation Checks	Basic schema check.	Basic schema check.	Basic schema check, generate tombstone record.
	Mutation Actions	Append the record to the shard. Add the record ID to the primary key index. If the record was discontinued, add to the end of the corresponding cluster page and update the leaf.	Append the record to the shard. Add the record ID to the primary key index, the end of the corresponding cluster page and update the leaf.	Append a tombstone record to the shard. Add its record ID to the primary key index, the end of the corresponding cluster page and update the leaf.
	Post-Mutation	Archive pages if applicable.	Archive pages if applicable.	Archive pages if applicable.

SPARSE

Sparse blockchains use the same multi-version index, used by the traditional blockchain. The key difference between the two is how data is stored on the data page. In a sparse blockchain, updated data is inferred from its previous value and only changes are stored.

For example, if a user were to run following mutations:

INSERT example VALUES (1, 2, 3, 4);

AMEND example (first_column) VALUES (100);

In order, <1, 2, 3, 4> and <100> would be stored on the data page. When reading the full record, the two records are merged and resemble <100, 2, 3, 4>.

Blockchain	Stage	INSERT	AMEND	DISCONTINUE
sparse	Mutation Checks	Basic schema check don't generate values unless specified.	Basic schema check don't generate values unless specified.	Basic schema check generate full tombstone record.
	Mutation Actions	Append the partial record to the shard. Add the record ID to the primary key index. If the record was discontinued, add to the end of the corresponding cluster page and update the leaf.	Append the record to the shard. Add the record ID to the primary key index, the end of the corresponding cluster page and update the leaf.	Append a tombstone record to the shard. Add its record ID to the primary key index, the end of the corresponding cluster page and update the leaf.
	Post-Mutation	Archive pages if applicable.	Archive pages if applicable.	Archive pages if applicable.

Choosing a blockchain

The table below illustrates the basic methodology for choosing a blockchain to fit your database needs.

Blockchain	FREQUENT INSERTIONS	INFREQUENT INSERTIONS	FREQUENT UPDATES	INFREQUENT UPDATES
historical	✓		✕	✕
historical(+)	✓			✓
traditional	✓	✓		✓
sparse		✓	✓