August 18, 2023

QLDB Limitations that you should be aware of

The best time to establish protocols with your clients is when you onboard them.

Heading

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

Let’s examine QLDB’s restrictions in this post, which are primarily horizontal restrictions. If you haven’t read my earlier piece regarding QLDB’s introduction, click here.

QLDB limitations are classified as follows

  • Default quotas
  • Fixed quotas
  • Document size
  • Transaction size
  • Naming constraints

Default quotas

The default quotes include restrictions on the maximum number of active ledgers, active journal exports, and active journal data streams.

The default quotas are listed in tabular form below.

Fixed quotas

QLDB has the following fixed quotas per ledger in addition to default quotas. These quotas cannot be increased through the use of Service Quotas:

An active session is the equivalent concept in QLDB. A session is conceptually similar to a user login in that it manages data transaction requests to a ledger. An active session is one that is currently carrying out a transaction. It could also be a session that just finished a transaction and the service anticipates starting another one right away. QLDB allows for one active transaction per session.

Document size

A document encoded in the IonBinary format can be up to 128 KB in size. We are unable to provide an exact limit for the size of an IonText document because the conversion from text to binary varies greatly depending on the structure of each document. Because QLDB supports documents with open content, the size calculation varies depending on the structure of the document.

Transaction size

A transaction in QLDB can be up to 4 MB in size. The size of a transaction is determined by adding the following factors together.

Deltas

The document changes caused by all of the statements in the transaction. The total delta size in a transaction that affects multiple documents is the sum of each affected document’s individual delta.

Metadata

The transaction metadata generated by QLDB and associated with each affected document.

Indexes

If an index is defined on a table that is affected by the transaction, the index entry associated with it generates a delta as well.

History

Because all document revisions are persisted in QLDB, all transactions also append to the history.

Inserts : Every document that is added to a table has a copy added to its history table. A newly inserted 100 KB document, for example, generates at least 200 KB of deltas in a transaction. (This is an estimate that excludes metadata and indexes.)

Updates : Any document update, even if it is for a single field, creates a new revision of the entire document in history, plus or minus the update delta. This means that even a minor change in a large document will result in a large transaction delta. Adding 2 KB of data to an existing 100 KB document, for example, generates a new 102 KB revision in history. The total deltas in a transaction must be at least 104 KB. (Once again, this estimate excludes metadata and indexes.)

Deletes : Delete transactions, like updates, create a new document revision in the history. The newly created DELETE revision, on the other hand, is smaller than the original document because it contains no user data and only metadata.

Naming constraints

The following table describes naming constraints within Amazon QLDB.

Some of the reserved keywords are mentioned here.

In the following articles, we’ll learn more about QLDB’s use cases and where it fits best.

CodeStax.Ai
Profile
August 17, 2023
-
6
min read
Subscribe to our newsletter
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Share this article:

More articles