Core concepts and terminology in Amazon QLDB - Amazon Quantum Ledger Database (Amazon QLDB)

Core concepts and terminology in Amazon QLDB

This section provides an overview of the core concepts and terminology in Amazon QLDB, including ledger structure and how a ledger manages data. After you read this section, see Working with data and history and follow the examples that walk you through the process of creating tables, inserting data, and running basic queries.

As a ledger database, QLDB differs from other document-based databases when it comes to the following key concepts.

Ledger structure

Fundamentally, QLDB data is organized into tables of Amazon Ion documents. More precisely, tables are collections of document revisions. A document revision represents a single iteration of the document's full dataset. Because QLDB stores the complete change history of your data, a table contains not only the latest revision of its documents, but also all prior iterations. For details on revisions, see Updating and deleting documents and Querying revision history.

Note

For brevity, this guide often refers to document revisions as simply documents. This shorthand term keeps a consistent meaning because we typically think in terms of documents when inserting, updating, and deleting elements of a collection. However, when querying document history, it's important to specify that we are referring to revisions.

Write transactions

When an application needs to modify data in a document, it does so in a database transaction. Within a transaction, data is read from the ledger, updated, and committed to the journal. The journal represents a complete and immutable history of all the changes to your data. QLDB writes one or more chained blocks to the journal in a transaction. Each block contains entry objects that represent the document revisions that you insert, update, and delete, along with the PartiQL statements that committed them.

The following diagram illustrates this journal structure.


                Amazon QLDB journal structure diagram showing a set of chained blocks that
                    make up a strand, and the sequence number and block hash of each block.

The diagram shows that transactions are committed to the journal as blocks that contain document revision entries. Each block is hashed and chained to subsequent blocks for verification. Each block has a sequence number to specify its address within the strand.

Note

In Amazon QLDB, a strand is a partition of your ledger's journal. QLDB currently supports journals with a single strand only.

For information about the data contents in a block, see Journal contents in Amazon QLDB.

Querying your data

QLDB is intended to address the needs of high-performance online transaction processing (OLTP) workloads. A ledger provides queryable views of your data based on the transaction information that is committed to the journal. Similar to views in relational databases, a view in QLDB is a projection of the data in a table. Views are maintained in real time, so that they're always available for applications to query.

You can query the following views using PartiQL SELECT statements:

  • User—The latest non-deleted revision of your application-defined data only (that is, the current state of your data). This is the default view in QLDB.

  • Committed—The latest non-deleted revision of both your data and the system-generated metadata. This is the full system-defined table that corresponds directly to your user table.

In addition to these views, you can query the revision history of your data by using the built-in History function. The history function returns both your data and the associated metadata in the same schema as the committed view.

Data storage

There are two types of data storage in QLDB:

  • Journal storage—The disk space that is used by a ledger's journal. The journal is append-only and contains the complete, immutable, and verifiable history of all the changes to your data.

  • Indexed storage—The disk space that is used by a ledger's tables, indexes, and indexed history. Indexed storage consists of ledger data that is optimized for high-performance queries.

After your data is committed to the journal, it is materialized into the tables that you define. These tables enable faster and more efficient queries. When an application reads data, it accesses the tables and indexes that are stored in your indexed storage.

Next steps

To help you understand how to use a ledger with your data, see Working with data and history in Amazon QLDB. This guide explains how these concepts work in QLDB, using sample data and query examples for context.

To get started quickly with a sample application tutorial using the QLDB console, see Getting started with the Amazon QLDB console.

For a list of the key terms and definitions described in this section, see the Amazon QLDB glossary.