Working with Quantum Ledger Database
Quantum Ledger Database (QLDB) is a managed ledger database service provided by AWS and uses blockchain to provide a “transparent, immutable, and cryptographically verifiable transaction log.” The database is stored on a ledger, and within the ledger you can create tables which can be indexed. To access, create, and manipulate the data, you can run queries with PartiQL, which while similar to standard SQL does have some differences. On top of that QLDB does not implement all features of QLDB. One major difference QLDB has to other SQL structured databases like MySQL and PosgreSQL is the fact that there is no enforced schema. You can create indexes on fields, but you cannot enforce schema during writes. This can have advantages as well as disadvantages. As an advantage, you can insert data as JSON (albeit with single quotes for keys and values), making working with and manipulating data much easier. Data is structured similarly to a NoSQL database like DynamoDB, but can be queried like an SQL database with JOINs, etc. As a disadvantage, a single document can be inserted into a table multiple times, with only the documentId differing between entries. This means you must query the table explicitly before you insert a document. The official AWS documentation mentions this: “Because QLDB doesn’t enforce schema, you can insert the same document into a table multiple times. Each insert statement commits a separate document entry to the journal, and QLDB assigns each document a unique ID.”
Another feature that QLDB is missing is any sort of TTL. DynamoDB, for example, has this built in, where you can just select an attribute and DynamoDB automatically reaps the entry as the timer expires. Having TTL can be useful for something like session data, which you want to expire after a certain time period. A TTL feature is not exclusive to DynamoDB or other NoSQL databases – you can achieve something like this with MySQL and event schedulers. Functionality like this with QLDB would require an external lambda function triggered by a CloudWatch Event Rules, meaning custom code, custom queries, and latency. If your workload would have a lot of entries that would need to expire within a timeframe, this could count against your active sessions, transaction time, etc. You should consider this before using QLDB in these situations.
https://docs.aws.amazon.com/qldb/latest/developerguide/working.create.html#working.create.insert
https://www.tutorialspoint.com/how-to-create-a-record-in-mysql-database-subject-to-ttl-time-to-live-option
https://docs.aws.amazon.com/qldb/latest/developerguide/limits.html