Preface

Preface

This document is a guide intended for operators responsible for configuring, managing, and using GOLDILOCKS. Its purpose is to provide the fundamental concepts required for installing and administering GOLDILOCKS. It also describes key operational considerations that should be observed when using the GOLDILOCKS system.

Target Readers

The target readers of this document include:

Overview

This chapter provides an overview of the basic structure and key characteristics of GOLDILOCKS for new users. It describes the available deployment options, including standalone and cluster system architectures. It also explains the differences between these architectures and their respective use cases.

GOLDILOCKS Database Management System

The GOLDILOCKS database system consists of the following components:

GOLDILOCKS Architecture

To prevent failures in an application process from affecting the entire database system, the GOLDILOCKS database adopts a shared-memory-based multi-process architecture rather than a multi-threaded architecture. The overall architecture of the GOLDILOCKS database is shown in Figure 1.
Data is loaded into shared memory, while the gmaster process, which serves as the management daemon, performs overall database management tasks such as system boot-up, log flushing, and aging. It also ensures data durability by storing redo log files and data files on disk.
Applications that use the GOLDILOCKS database employ one of the following two access models.

GOLDILOCKS architecture

GOLDILOCKS architecture

In the D/A model, an application directly accesses and manipulates the database, which can make the database instance unstable due to frequent errors during the early development stages. Therefore, it is efficient to develop the application using the C/S model during the early stages and then switch to the D/A model in the final development stage.

GOLDILOCKS Cluster System Architecture

GOLDILOCKS can be used by configuring a standalone database or by binding multiple databases into a single cluster and managing the database in cluster units. In other words, when configured as a cluster system, a user can distribute and store table data into multiple nodes according to the desired sharding strategy. This guarantees high availability and improves throughput due to parallel processing.

The GOLDILOCKS cluster system guarantees ACID compliance for transactions that are cluster-wide. Therefore, it provides data reliability equivalent to that of transactions performed on a standalone server, even when any node belonging to the cluster system is involved in performing the transaction.

Each database within the GOLDILOCKS cluster system has a multi-process structure and data loading method similar to that of a standalone database. However, the cdispatcher process and cluster server (cserver) process are added. The cdispatcher process is for efficient communication between member nodes in the cluster, and the cluster server (cserver) process is for data storage and management on the cluster member nodes. Additionally, tablespaces and management areas for transaction management of the cluster system are added to the shared memory.

GOLDILOCKS cluster system architecture

GOLDILOCKS cluster system architecture

Characteristics of GOLDILOCKS Cluster

Features of Cluster

GOLDILOCKS cluster is a cluster system with a shared-nothing architecture and overcomes limitations in transaction performance and storage of an existing standalone system.

Constraint of Cluster

All SQL statements in the GOLDILOCKS cluster can be used in the same way as those in a standalone system, except for the following constraints.

PRIMARY KEY for the sharded table, UNIQUE constraint, and UNIQUE INDEX must include the sharding key.

The following is an example of a failure because the UNIQUE (name) constraint does not include the id column, which is the sharding key.

gSQL> 
CREATE TABLE t1 
(
    id   INTEGER PRIMARY KEY,
    name VARCHAR(128),
    UNIQUE (name)
)
SHARDING BY HASH(id);

ERR-HYC00(16380): UNIQUE or PRIMARY KEY must include all sharding key columns for cluster system

The constraint must be created to include the sharding key, such a UNIQUE ( id, name ) or UNIQUE ( name, id ) as follows.

gSQL> 
CREATE TABLE t1 
(
    id   INTEGER PRIMARY KEY,
    name VARCHAR(128),
    UNIQUE( id, name ) 
) 
SHARDING BY HASH (id);

Table created.

Non-deterministic statements must have a global secondary index to distinguish between identical rows across the cluster members.

The following is an example of an error that occurs when creating a table by force while omitting the global secondary index.

gSQL> CREATE TABLE t1 ( c1 INTEGER ) WITHOUT GLOBAL SECONDARY INDEX;

Table created.

gSQL> INSERT INTO t1 VALUES (1), (2), (3), (4), (5);

5 rows created.

gSQL> COMMIT;

Commit complete.

The following is an example of deleting three rows, which does not guarantee that the same rows will be deleted across all cluster members.

gSQL> DELETE FROM t1 FETCH 3;

ERR-42000(16423): does not support non-deterministic DML in the cluster system : global secondary index expected

The following example shows that the cluster members may not guarantee updating the same rows to the same value when using RANDOM(1, 100).

gSQL> UPDATE t1 SET c1 = RANDOM(1, 100);

ERR-42000(16423): does not support non-deterministic DML in the cluster system : global secondary index expected

The following is an example of updating a row at the current position using an updatable cursor. It requires a global secondary index to distinguish the same rows across cluster members.

gSQL> \var v1 INTEGER
gSQL> DECLARE cur1 CURSOR FOR SELECT c1 FROM t1 FOR UPDATE;

Cursor declared.

gSQL> OPEN cur1;

Cursor is open.

gSQL> FETCH cur1 INTO :v1;

V1
--
 1

1 row fetched.

gSQL> UPDATE t1 SET c1 = 1 WHERE CURRENT OF cur1;

ERR-42000(16423): does not support non-deterministic DML in the cluster system : global secondary index expected

It does not support deferrable constraints.

gSQL> ALTER TABLE t1 ADD CONSTRAINT t1_uk UNIQUE(id) DEFERRABLE;

ERR-HYC00(16388): does not support deferrable constraints in the cluster system : 
ALTER TABLE t1 ADD CONSTRAINT t1_uk UNIQUE(id) DEFERRABLE
                                    *
ERROR at line 1:

It does not guarantee that the same sequence will be used in the same order across different servers.

gSQL> SELECT seq1.NEXTVAL FROM dual;

NEXTVAL
-------
      1

1 row selected.

gSQL> SELECT seq1.NEXTVAL FROM dual;

NEXTVAL
-------
      2

1 row selected.
gSQL> SELECT seq1.NEXTVAL FROM dual;

NEXTVAL
-------
     21

1 row selected.
gSQL> SELECT seq1.NEXTVAL FROM dual;

NEXTVAL
-------
      3

1 row selected.