Yugabyte의 Developer Advocate로서 SingleStore와 비교하는 방법에 대해 몇 가지 질문이 있습니다. 간단한 것이 많이 있습니다. YugabyteDB는 오픈 소스이고 PostgreSQL 기능과 호환되며 분산 SQL 데이터베이스입니다. SingleStore가 분산 SQL 범주에 속하지 않는지 확인하기 위해 SQL에 대한 첫 번째 문서에서 언급되고 Oracle의 전설적인 SCOTT 스키마가 된 이전 EMP/DEPT인 간단한 SQL 스키마를 시도하고 싶었습니다. 살펴보고 싶으면 YugabyteDB Managed 무료 클러스터를 생성할 수 있으며 자습서는 최신 버전을 생성하고 고급 쿼리를 사용하는 데 도움이 될 것입니다.

오해의 소지가 있는 몇 가지 오류가 발생했기 때문에 유사한 상황에 도움이 되도록 이 블로그 게시물을 작성하고 있지만 SingleStore에 있는 SQL 기능 목록not supported을 보면 시간을 절약할 수 있습니다.

SingleStore 평가판 만들기

온라인 지침에 따라 제공된 평가판 라이선스로 memsql(SingleStore의 내부 이름)을 시작했습니다.

docker run -i --init \
    --name memsql-ciab \
    -e LICENSE_KEY="TheLicenceProvidedForTrial0AAAAAAAAAAAEAAAAAAAAACgwNAIYMiZ83R94l1DqqMjt4gqo48F2p4Mm6gAXAhhfuPPKuSmfu3srHlVhoZ2Kspm2o1gz5Y0AAA==" \
    -e ROOT_PASSWORD="admin_p455w0rd" \
    -p 3306:3306 -p 8080:8080 \
    memsql/cluster-in-a-box

docker start memsql-ciab

웹사이트는 위의 명령줄을 생성하기에 정말 사용자 친화적입니다. 개발자는 오픈 소스에 익숙하고 라이센스 키를 입력해야 하는 경우 일반적으로 친숙하지 않습니다. 평가판 라이센스로 docker 명령줄을 생성하는 것이 좋습니다.

여기에 연결하고 DEPT 테이블 생성을 실행합니다.

CREATE TABLE dept (
  deptno integer NOT NULL,
  dname text,
  loc text,
  description text,
  CONSTRAINT pk_dept PRIMARY KEY (deptno asc)
);

운 좋게도 이 구문은 많은 경우에 SQL 표준과 매우 다를 수 있는 MySQL과 호환됩니다.

그런 다음 EMP 테이블을 만들고 싶습니다.

CREATE TABLE emp (
  empno integer generated by default as identity (start with 10000) NOT NULL,
  ename text NOT NULL,
  job text,
  mgr integer,
  hiredate date,
  sal integer,
  comm integer,
  deptno integer NOT NULL,
  email text,
  other_info json,
  CONSTRAINT pk_emp PRIMARY KEY (empno hash),
  CONSTRAINT emp_email_uk UNIQUE (email),
  CONSTRAINT fk_deptno FOREIGN KEY (deptno) REFERENCES dept(deptno),
  CONSTRAINT fk_mgr FOREIGN KEY (mgr) REFERENCES emp(empno)
);

이것은 다음과 같이 실패합니다.

ERROR 1064 ER_PARSE_ERROR: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'generated by default as identity (start with 10000) NOT NULL, ename text NOT ' at line 1

표준 SQLgenerated by default as identity을 MySQL 사용자가 사용하는 auto_increment로 대체합니다.

CREATE TABLE emp (
  empno integer  NOT NULL auto_increment,
  ename text NOT NULL,
  job text,
  mgr integer,
  hiredate date,
  sal integer,
  comm integer,
  deptno integer NOT NULL,
  email text,
  other_info json,
  CONSTRAINT pk_emp PRIMARY KEY (empno),
  CONSTRAINT emp_email_uk UNIQUE (email),
  CONSTRAINT fk_deptno FOREIGN KEY (deptno) REFERENCES dept(deptno),
  CONSTRAINT fk_mgr FOREIGN KEY (mgr) REFERENCES emp(empno)
);

이것은 다음과 같이 실패합니다.

ERROR 1706 ER_MEMSQL_FEATURE_LOCKDOWN: Feature 'FOREIGN KEY on COLUMNAR table' is not supported by SingleStore.

이제 OLTP에 적합한 ROWSTORE 테이블로 테이블을 다시 생성해 보겠습니다.

DROP TABLE dept;
CREATE ROWSTORE TABLE dept (
  deptno integer NOT NULL,
  dname text,
  loc text,
  description text,
  CONSTRAINT pk_dept PRIMARY KEY (deptno asc)
);
CREATE ROWSTORE TABLE emp (
  empno integer  NOT NULL auto_increment,
  ename text NOT NULL,
  job text,
  mgr integer,
  hiredate date,
  sal integer,
  comm integer,
  deptno integer NOT NULL,
  email text,
  other_info json,
  CONSTRAINT pk_emp PRIMARY KEY (empno),
  CONSTRAINT emp_email_uk UNIQUE (email),
  CONSTRAINT fk_deptno FOREIGN KEY (deptno) REFERENCES dept(deptno),
  CONSTRAINT fk_mgr FOREIGN KEY (mgr) REFERENCES emp(empno)
);

이제 또 다른 오류가 여전히 참조 무결성을 방지합니다.

ERROR 1706 ER_MEMSQL_FEATURE_LOCKDOWN: Feature 'FOREIGN (non-SHARD) key to a sharded table' is not supported by SingleStore.

따라서 참조된 테이블을 샤딩할 수 없습니다. 문제 없습니다. 어쨌든 이것은 참조 테이블입니다. REFERENCE로 생성하겠습니다.

DROP TABLE dept;
CREATE ROWSTORE REFERENCE TABLE dept (
  deptno integer NOT NULL,
  dname text,
  loc text,
  description text,
  CONSTRAINT pk_dept PRIMARY KEY (deptno asc)
);
CREATE ROWSTORE TABLE emp (
  empno integer  NOT NULL auto_increment,
  ename text NOT NULL,
  job text,
  mgr integer,
  hiredate date,
  sal integer,
  comm integer,
  deptno integer NOT NULL,
  email text,
  other_info json,
  CONSTRAINT pk_emp PRIMARY KEY (empno),
  CONSTRAINT emp_email_uk UNIQUE (email),
  CONSTRAINT fk_deptno FOREIGN KEY (deptno) REFERENCES dept(deptno),
  CONSTRAINT fk_mgr FOREIGN KEY (mgr) REFERENCES emp(empno)
);

그러나 다시 실패합니다.

ERROR 1706 ER_MEMSQL_FEATURE_LOCKDOWN: Feature 'FOREIGN (non-SHARD) key to a sharded table' is not supported by SingleStore.

자체 참조fk_mgr FOREIGN KEY (mgr) REFERENCES emp(empno) 때문이라고 생각할 수 있지만 제거해도 동일한 오류가 발생합니다. 두 외래 키를 모두 제거해 보겠습니다.

CREATE ROWSTORE TABLE emp (
  empno integer  NOT NULL auto_increment,
  ename text NOT NULL,
  job text,
  mgr integer,
  hiredate date,
  sal integer,
  comm integer,
  deptno integer NOT NULL,
  email text,
  other_info json,
  CONSTRAINT pk_emp PRIMARY KEY (empno),
  CONSTRAINT emp_email_uk UNIQUE (email)-- ,
  -- CONSTRAINT fk_deptno FOREIGN KEY (deptno) REFERENCES dept(deptno),
  -- CONSTRAINT fk_mgr FOREIGN KEY (mgr) REFERENCES emp(empno)
);

(-- 뒤의 공백은 MySQL에서 필수입니다)

이것은 다른 제약 조건에서 실패합니다.

ERROR 1895 ER_MEMSQL_UNIQUE_KEY_IMPLICIT_SHARD_KEY: The unique key named: 'emp_email_uk' must contain all columns specified in the primary key when no shard key is declared

전역 고유 제약 조건도 지원되지 않습니다. 이것은 기본적인 SQL 기능입니다. 실생활에서 대부분의 테이블에는 생성된 기본 키 외에 하나 이상의 고유한 자연 키가 있습니다. 이중화를 방지하는 유일한 방법이기 때문에 고유성을 적용하는 것이 중요합니다. 이는 오류 발생 시 애플리케이션이 네트워크 오류가 커밋 전후에 발생했는지 알지 못하는 클라우드 네이티브 고가용성 애플리케이션에서 매우 중요합니다. 기본 키는 종종 애플리케이션에서 생성됩니다. 자연키만이 이중 삽입을 방지할 수 있습니다.

제한이 너무 많아서 두 테이블이 모두 REFERENCE인 경우에만 간단한 CREATE를 실행할 수 있습니다.

DROP TABLE dept;
CREATE ROWSTORE REFERENCE TABLE dept (
  deptno integer NOT NULL,
  dname text,
  loc text,
  description text,
  CONSTRAINT pk_dept PRIMARY KEY (deptno asc)
);
CREATE ROWSTORE REFERENCE TABLE emp (
  empno integer  NOT NULL auto_increment,
  ename text NOT NULL,
  job text,
  mgr integer,
  hiredate date,
  sal integer,
  comm integer,
  deptno integer NOT NULL,
  email text,
  other_info json,
  CONSTRAINT pk_emp PRIMARY KEY (empno),
  CONSTRAINT emp_email_uk UNIQUE (email),
  CONSTRAINT fk_deptno FOREIGN KEY (deptno) REFERENCES dept(deptno),
  CONSTRAINT fk_mgr FOREIGN KEY (mgr) REFERENCES emp(empno)
);

*드디어 작동합니다. 하지만... 샤딩된 테이블이 없기 때문에 더 이상 분산 데이터베이스에 있지 않습니다. *

끼워 넣다

샤딩되지 않은 테이블에서 계속해서 샘플 행을 삽입합니다.

INSERT INTO dept (deptno,  dname,        loc, description)
     VALUES    (10,     'ACCOUNTING', 'NEW YORK','preparation of financial statements, maintenance of general ledger, payment of bills, preparation of customer bills, payroll, and more.'),
            (20,     'RESEARCH',   'DALLAS','responsible for preparing the substance of a research report or security recommendation.'),
            (30,     'SALES',      'CHICAGO','division of a business that is responsible for selling products or services'),
            (40,     'OPERATIONS', 'BOSTON','administration of business practices to create the highest level of efficiency possible within an organization');

INSERT INTO emp (empno, ename,    job,        mgr,   hiredate,     sal, comm, deptno, email, other_info)
     VALUES   (7369, 'SMITH',  'CLERK',     7902, '1980-12-17',  800, NULL,   20,'[email protected]', '{"skills":["accounting"]}'),
            (7499, 'ALLEN',  'SALESMAN',  7698, '1981-02-20', 1600,  300,   30,'[email protected]', null),
            (7521, 'WARD',   'SALESMAN',  7698, '1981-02-22', 1250,  500,   30,'[email protected]', null),
            (7566, 'JONES',  'MANAGER',   7839, '1981-04-02', 2975, NULL,   20,'[email protected]', null),
            (7654, 'MARTIN', 'SALESMAN',  7698, '1981-09-28', 1250, 1400,   30,'[email protected]', null),
            (7698, 'BLAKE',  'MANAGER',   7839, '1981-05-01', 2850, NULL,   30,'[email protected]', null),
            (7782, 'CLARK',  'MANAGER',   7839, '1981-06-09', 2450, NULL,   10,'[email protected]', '{"skills":["C","C++","SQL"]}'),
            (7788, 'SCOTT',  'ANALYST',   7566, '1982-12-09', 3000, NULL,   20,'[email protected]', '{"cat":"tiger"}'),
            (7839, 'KING',   'PRESIDENT', NULL, '1981-11-17', 5000, NULL,   10,'[email protected]', null),
            (7844, 'TURNER', 'SALESMAN',  7698, '1981-09-08', 1500,    0,   30,'[email protected]', null),
            (7876, 'ADAMS',  'CLERK',     7788, '1983-01-12', 1100, NULL,   20,'[email protected]', null),
            (7900, 'JAMES',  'CLERK',     7698, '1981-12-03',  950, NULL,   30,'[email protected]', null),
            (7902, 'FORD',   'ANALYST',   7566, '1981-12-03', 3000, NULL,   20,'[email protected]', '{"skills":["SQL","CQL"]}'),
            (7934, 'MILLER', 'CLERK',     7782, '1982-01-23', 1300, NULL,   10,'[email protected]', null);

아무 문제없이 작동합니다.

그러나 직원이 있는 부서를 삭제해 보겠습니다.

> delete from dept where deptno=10;

Query OK, 1 row affected (372 ms)

> select * from dept;
+---------------------------------------------------------------------------------------------------------------------------+
| deptno                       | dname                        | loc                          | description                  |
+---------------------------------------------------------------------------------------------------------------------------+
| 20                           | RESEARCH                     | DALLAS                       | responsible for preparing ...|
| 30                           | SALES                        | CHICAGO                      | division of a business tha...|
| 40                           | OPERATIONS                   | BOSTON                       | administration of business...|
+---------------------------------------------------------------------------------------------------------------------------+

3 rows in set (110 ms)

> select deptno, count(*) from emp group by deptno order by 1;
+-------------------------------------------------------------+
| deptno                       | count(*)                     |
+-------------------------------------------------------------+
| 10                           | 3                            |
| 20                           | 5                            |
| 30                           | 6                            |
+-------------------------------------------------------------+

3 rows in set (75 ms)

아무것도 샤딩되지 않은 상태에서 외래 키를 만들 수 있었지만 아무 것도 보호하지 못하므로 쓸모가 없습니다. 이제 존재하지 않는 부서에 일부 직원이 있습니다.

Cross-shard 트랜잭션의 모든 ACID 속성과 함께 모든 SQL 기능을 배포하는 Spanner 기반 데이터베이스와 마찬가지로 SingleStore가 분산 SQL 데이터베이스가 아님을 확인하기 위해 이 작업을 수행했습니다. 그러나 SingleStore는 사용 사례가 있으며 클라우드 네이티브 NewSQL 데이터베이스, 특히 기본 열 저장소 덕분에 분석에서 주요 행위자입니다.