What is OCI NoSQL Database?

• A fully managed NoSQL database service offering:
  • On-demand throughput.
  • Storage based provisioning.
  • Supports JSON, Table and Key-Value data types.
  • Flexible transaction guarantees.
• Designed for predictable, single digit millisecond latency.
• Suitable for:
  • IoT
  • UX personalization.
  • Instant fraud detection.
  • Online display advertising.

Limits of OCI NoSQL Database

• Per table:
  • 40K read units.
  • 20K write units.
  • 5 TB storage.
  • 50 columns.
  • 5 indexes.
• Per tenant:
  • 30 tables.
  • 4 DDL ops/min.
  • 100K read units.
  • 40K write units.
  • 5 TB storage.

Events Emitted by OCI NoSQL Database

• Begin & End Alter Table
• Begin & End Change Table Compartment
• Begin & End, Create or Drop, Table or Index

Features of OCI NoSQL Database

• Fully Managed
• Zero Administration
• Fast Development Life Cycle
• Oracle performs:
  • Database Management
  • Storage Management
  • High Availability
  • Scalability
• High Performance & Predictability
• On-Demand Throughput & Storage Provisioning
• Simple APIs
• Data Modeling: Supports schema-based & schema-less (JSON) modeling.
• Data Redundancy: Data is stored across ADs & FDs.
• Data Security: Data is encrypted at-rest (AES-256) & in-transit (HTTPS).
• ACID-Compliant Transactions: Atomicity, Consistency, Isolation, Durability
  • Consistency can be relaxed to lower latency.
• JSON Support: Query JSON using SQL syntax.
• Partial JSON Updates
• TTL:
  • Set TTL on rows, after which they’re deleted.
  • Default TTL = 0 = No Expiry
  • Set TTL at table or row.
  • Update row TTL at any time before expiry.
• SQL Queries
• Secondary Indexes: Index any field.
• Supported Data Types

Concepts of OCI NoSQL Database

• Table:
  • A collection of rows.
  • Has specified storage & max size.
  • Has max read-write throughput.
  • Created using DDL (defines data types & primary keys).
  • Can be:
    • Unstructured: Rows are JSON docs.
    • Structured: Row types are defined & enforced.
    • Hybrid: Typed data with JSON data fields.
  • Must have one or more fields designated as primary key.
  • Primary & shard keys are designated at table creation & cannot be changed or dropped.
• Row: Key & data fields defined at table creation.
• Index:
  • Any data field with supported data type can be indexed.
  • JSON index is created using path expression into JSON data.
  • Consumes storage & throughput.
• 1 Write Unit = 1 KB/s write.
• 1 Read Unit = 1 KB/s eventually consistent read.
• 1 Storage Unit = 1 GB
• Distribution & Sharding:
  • Tables are sharded & replicated for availability & performance.
  • Data in table is automatically sharded based on a portion of the primary key, called the shard key.
  • Rows containing same values for all shard keys are guaranteed to be stored on the same shard.
  • Avoid shard keys that have low cardinality i.e. few unique values.
  • Only objects that share the shard key can participate in a transaction. If you require ACID transactions that span multiple records, choose a shard key appropriately.
  • Best practices:
    • Distribute shard keys uniformly.
    • Target queries to specific shard.
• Read Consistency:
  • Determines which copy of data is used to fulfill a read op.
  • 2 consistency levels:
    • EVENTUAL: Returns possibly outdated data. Faster than ABSOLUTE.
    • ABSOLUTE:
      • Guarantees that read returns most recently written data.
      • Costs more. Consumes double read units relative to EVENTUAL.
  • Consistency can be set at:
    • Either a NoSQL handle in code, affecting all reads using that handle.
    • Or optionally on individual read ops.
• Service endpoint is https://nosql.{region}.oci.oraclecloud.com.
• Identity Columns:
  • Special columns whose values are auto-assigned by Oracle.
  • Values are generated from a sequence generator.
  • Not supported from OCI console, only programmatically.

Table States & Life Cycles

• Table is UPDATING when:
  • Table limits are being changed.
  • Table schema is evolving.
  • Adding or dropping table index.