Skip to main content

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.

BlockchainStageINSERTAMENDDISCONTINUE
historicalMutation ChecksBasic schema check.✕✕
Mutation ActionsAppend the record to the shard.✕✕
Post-MutationArchive 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.

BlockchainStageINSERTAMENDDISCONTINUE
historical(+)Mutation ChecksBasic schema check.Basic schema check.Basic schema check, generate tombstone record.
Mutation ActionsAppend 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-MutationArchive 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.

BlockchainStageINSERTAMENDDISCONTINUE
traditionalMutation ChecksBasic schema check.Basic schema check.Basic schema check, generate tombstone record.
Mutation ActionsAppend 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-MutationArchive 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>.

BlockchainStageINSERTAMENDDISCONTINUE
sparseMutation ChecksBasic 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 ActionsAppend 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-MutationArchive 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.

BlockchainFREQUENT INSERTIONSINFREQUENT INSERTIONSFREQUENT UPDATESINFREQUENT UPDATES
historical✓✕✕
historical(+)✓✓
traditional✓✓✓
sparse✓✓