Simple is Beautiful.

컨테이너 별로 DB를 다르게 사용하는게 좋습니다.

컨테이너와 PostgreSQL을 함께 사용하는 경우 일반적으로 컨테이너별로 별도의 스키마를 사용하는 것보다 컨테이너별로 데이터베이스를 분리하는 것이 좋습니다.

각 컨테이너가 이상적으로 자체 데이터베이스 인스턴스를 포함하여 자체 독립 환경을 가져야 하기 때문입니다. 각 컨테이너에 대해 별도의 데이터베이스를 사용하면 데이터가 각 컨테이너 내에서 격리되고 안전하며 한 컨테이너의 데이터베이스에 대한 변경 사항이 다른 데이터베이스에 영향을 미치지 않도록 할 수 있습니다.

반면에 단일 데이터베이스 내에서 각 컨테이너에 대해 별도의 스키마를 사용하는 경우 두 컨테이너가 동일한 스키마에 액세스하거나 수정하려고 하면 데이터 유출 또는 충돌의 위험이 있습니다. 이로 인해 데이터 일관성 문제와 잠재적인 보안 취약성이 발생할 수 있습니다.

물론 밀접하게 관련되어 있고 데이터를 공유해야 하는 소수의 컨테이너가 있는 경우와 같이 별도의 스키마를 사용하는 것이 적합한 경우가 있을 수 있습니다. 이러한 경우 권한이 없는 사용자가 실수로 데이터를 유출하거나 수정하지 않도록 권한 및 액세스 제어를 신중하게 관리하는 것이 중요합니다.

docker-compose를 이용해 간단히 MongoDB ReplicaSet을 구성하는 방법에 대해 알아보도록 합니다.

참고 소스는 다음 git 저장소에서 확인할 수 있습니다: MongoDBReplicaSetTest

0. Docker Desktop 설치

Docker Container로 배포를 위해선 개발 환경에 docker가 설치되어 있어야 합니다. 공식 홈페이지로 이동해 Docker Desktop을 설치합니다: www.docker.com/products/docker-desktop

1. Replica set 구성을 위한 js 파일 작성.

MongoDB에서 ReplicaSet을 설정하기 위한 js 파일을 작성합니다.

// init/
config = {
  _id : "replication",
  members: [
    {_id:0,host : "mongo1:27017"},
    {_id:1,host : "mongo2:27017"},
    {_id:2,host : "mongo3:27017"},
  ]
}
rs.initiate(config);
rs.conf();

members를 보면 알 수 있듯이 mongo1, mongo2, mongo3의 세 개의 MongoDB를 사용할 예정입니다. 이번 예시에서는 mongo1 서버에서 해당 스크립트를 수행하도록 진행할 것입니다.

2. 쉘 스크립트 작성.

MongoDB 컨테이너가 올라오면 앞서 작성한 스크립트 파일을 수행 해 Replica set을 구성하도록 하는 쉘 스크립트를 작성합니다.

#init/setup.sh
sleep 5 | echo "Waiting for the servers to start..."
mongo mongodb://localhost:27017 /usr/src/configs/init/setReplication.js

3. dockerfile 작성

앞서 스크립트를 작성하면서 설명했듯이 mongo1 컨테이너에서는 우리가 작성한 스크립트가 실행되어야 합니다. 이를 위해 MongoDB 이미지를 가져와 컨테이너 실행 시 우리의 코드가 실행되는 새로운 이미지를 만들어 보도록 하겠습니다.

# dockerfile

FROM mongo

WORKDIR /usr/src
RUN mkdir configs
WORKDIR /usr/src/configs

COPY init/* init/

RUN chmod +x init/setup.sh

CMD ["/usr/src/configs/init/setup.sh"]

수행하는 내용은 간단합니다. mongo 이미지를 가져와 /usr/src/config 폴더를 만들고 그 안에 init 폴더를 그대로 복사합니다. 그리고 앞서 작성한 setup.sh 파일에 권한을 부여한 후 setup.sh를 실행시키는 게 전부입니다. 

4. docker-compose.yml 작성

이제 거의 다 끝나갑니다. 마지막으로 여러 mongodb 컨테이너를 동시에 실행시키고 ReplicaSet을 구성하기 위한 docker-compose.yml 파일을 작성합시다.

version: '3'
services:
  mongo1:
    image: mongo-rep:0.0.1
    build:
      context: .
      dockerfile: dockerfile
    volumes:
      - {SOMEWHERE_YOUR_VOLUME}/mongoRepl/mongo1:/data/db
    ports:
      - "27021:27017"
    networks:
      - mongo-networks
    command: mongod --replSet replication

  mongo2:
    image: "mongo"
    ports:
      - "27022:27017"
    volumes:
      - {SOMEWHERE_YOUR_VOLUME}/mongoRepl/mongo2:/data/db
    networks:
      - mongo-networks
    command: mongod --replSet replication
    depends_on:
      - mongo1

  mongo3:
    image: "mongo"
    ports:
      - "27023:27017"
    volumes:
      - {SOMEWHERE_YOUR_VOLUME}/mongoRepl/mongo3:/data/db
    networks:
      - mongo-networks
    command: mongod --replSet replication
    depends_on:
      - mongo2

networks:
  mongo-networks:
    driver: bridge

mongo2와 mongo3은 mongo 이미지를 그대로 가져와 사용합니다. 볼륨은 각각 자신이 설정한 볼륨 경로 내의 "mongoRepl/mongo2"와 "mongoRepl/mongo3"에 컨테이너 내부의 mongodb 데이터가 저장됩니다.

세 컨테이너는 depends_on으로 연결되어 있으며 bridge 네트워크를 사용해 서로 서비스 이름을 통해 통신할 수 있습니다. 추가적으로 mongo2와 mongo3은 replSet 명령어로 "replication"이라는 이름으로 ReplicaSet을 생성합니다. 이 이름은 앞서 작성한 js의 _id에 입력한 값과 동일해야 합니다.

mongo1은 다른 두 서비스와 달리 mongo 이미지를 그대로 사용하지 않고 앞서 작성한 dockerfile을 이용해 새로운 이미지를 빌드합니다. 이 서비스가 실행되면 다른 두 mongodb 서비스와 같이 ReplicaSet을 구성하게 됩니다.

이제 다음 명령어를 통해 docker-compose를 실행시켜 봅시다

$ docker-compose up -d

이제 ReplicaSet이 정상적으로 동작하는지 확인하기 위해 컨테이너에 접속해 봅시다. 먼저 컨테이너의 ID를 확인합니다.

$ docker ps -a

컨테이너 ID를 확인 후 아무 데나 접속해 봅니다.

$ docker exec -u 0 -it 51 mongo

위와 같이 "replication:PRIMARY" 혹은 "replication:SECONDARY"라고 표시되면 정상적으로 ReplicaSet이 구성된 겁니다.

앞서 포스팅 한 글 중에 다음과 같은 글이 있었습니다.

2020/10/22 - [Programming/Databse] - [ORACLE] ORA-12516 tns:리스너가 프로토콜 스택과 일치하는 처리기를 찾을 수 없습니다.

한동안 잠잠하더니 다시 문제가 생기기 시작해 확인하며 겪은 일을 포스팅합니다.

1. 다시 생긴 ORA-12516과 원인

똑같은 문제가 재차 발생했습니다. 과거의 기억을 끄집어 내 세션을 확인해보니 어느새 가득 찬 세션의 수를 볼 수 있었습니다.

문제 되는 세션을 확인하기 위해 다음 쿼리를 수행합니다.

SELECT S.machine,
       TO_CHAR (S.LOGON_TIME, 'YYYY/MM/DD HH24:MI:SS') LOGON_TIME,
       S.sid,
       S.serial#,
       P.PID ORACLE_PID,
       P.SPID OS_PID,
       S.STATUS,
       S.USERNAME ORACLE_USER,
       S.OSUSER OS_USER,
       S.TERMINAL,
       S.PROGRAM
FROM V$PROCESS P LEFT OUTER JOIN V$SESSION S ON P.ADDR = S.PADDR
WHERE P.BACKGROUND IS NULL AND P.PID > 1
ORDER BY S.machine, TO_CHAR (S.LOGON_TIME, 'YYYY/MM/DD HH24:MI:SS');

세션 리스트가 끝도 없이 쏟아져 나오는 상황입니다. 찬찬히 보니 뭔가 이상한 점이 있습니다. 대부분의 세션의 STATUS값은 이미 INACTIVE입니다.

2. Session Kill

INACTIVE 된 세션을 죽이고자 합니다. 다음 쿼리를 사용해서요.

--ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE
ALTER SYSTEM KILL SESSION '123,4' IMMEDIATE 

근데 세션이 수백 개가 넘어갑니다. 이 방법으로는 특정 세션을 죽일 순 있겠지만 해결책은 되지 못합니다.

3. 세션 타임 아웃 설정.

오라클 측에서 제공해주는 DCD(Dead Connection Detection) 기능 중에 EXPIRE_TIME이 있습니다. 

오라클 설치 경로로 이동해 sqlnet.ora 설정 파일에 설정해 줄 수 있습니다. 다음 경로로 이동해 sqlnet.ora 파일을 열어주세요.

%ORACLE_HOME%\NETWORK\ADMIN\sqlnet.ora

SQLNET.EXPIRE_TIME 항목을 설정해 줍시다. 전 SQLNET.EXPIRE_TIME= 60와 같이 설정해 두었습니다. 60분의 만료 시간을 두었습니다.

이후 리스너를 재시작하면 만료 시간이 적용됩니다. 다만, 이미 연결되어 있는 세션에는 적용되지 않음에 유의해 주세요.

오라클 데이터 베이스에서 이미 생성된 테이블에 컬럼을 추가하는 방법에 대해 알아봅니다.

1. 테이블에 컬럼 추가

ALTER TABLE users ADD email VARCHAR(32) NOT NULL;

users 테이블에 email 컬럼을 VARCHAR(32)로 생성하며 NULL을 혀용하지 않는다.

2. 테이블에서 컬럼 제거

ALTER TABLE users DROP COLUMN email;

users 테이블에서 email 컬럼을 제거한다.

Ubuntu 20.04에 설치된 pgAdmin4의 여러 설정을 변경하는 방법에 대해 알아봅니다.

다음 글을 참고해 Postgresql 및 pgAdmin4를 준비합니다.

• 2021/02/04 - [Programming/Databse] - [PostgreSQL] Ubuntu에서 Postgresql 업그레이드 하기.
• 2021/02/04 - [Programming/Databse] - [PostgreSQL] Ubuntu에 pgAdmin 설치하기

제 서버에선 NGINX가 돌고 있어서 pgAdmin4 설치 후 Apache Web Server 실행 도중 에러가 나 NGINX를 잠시 끈 상태로 설치를 했습니다.

계속 이렇게 둘 순 없어서 NGINX와 pgAdmin4를 동시에 사용할 수 있는 방법에 대해 알아봤습니다. 가장 먼저 Apache Web Server의 기본 동작 포트를 변경하도록 합니다.

> sudo vi /etc/apache2/port.conf

적당한 값으로 변경합니다. 다음으로 virtual host의 포트 정보도 변경해야 합니다.

> sudo vi /etc/apache2/sites-enabled/000-default.conf

앞서 변경한 값으로 맞춰줍니다. 이제 Apache Web Server를 재시작합니다.

> sudo service apache2 restart

그 후 http://your.domain.com:8080/pgadmin4로 접속합니다. 

정상 동작이 확인됩니다. 이제 NGINX 설정을 변경합니다.

> sudo vi /etc/nginx/conf.d/my-server.conf

** conf 파일의 위치 및 이름은 NGINX 구성에 따라 달라질 수 있습니다.

NGINX를 재시작합니다.

> sudo service niginx restart

이제 외부에서 http://your.domain.com/pgadmin4를 이용해 pgadmin4에 접속할 수 있습니다.

Postgresql을 위해 pgAdmin을 사용합니다. 이 글에선 Ubuntu 20.04에 pgAdmin을 설치하는 방법에 대해 알아봅니다.

1. pgAdmin이란

pgAdmin은 PostgreSql을 관리할 수 있는 PostgreSQL 전용 GUI 툴입니다.

psql과 같은 cli 클라이언트 툴을 사용하는데 불편해 GUI를 지원하는 툴이 개발되었으며 웹 버전과 데스크톱 버전으로 나뉘어 있습니다.

2. pgAdmin 설치

Ubuntu 20.04에 pgAdmin4를 설치해 보도록 합니다. 먼저 리포지토리를 위한 퍼블릭 키를 설치합니다. 

> sudo curl https://www.pgadmin.org/static/packages_pgadmin_org.pub | sudo apt-key add 

다음으로 리포지토리 설정 파일을 생성합니다.

> sudo sh -c 'echo "deb https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/$(lsb_release -cs) pgadmin4 main" > /etc/apt/sources.list.d/pgadmin4.list && apt update'

이제 pgAdmin4를 설치할 수 있습니다. 다음 명령어로 pgAdmin4를 설치합니다.

> sudo apt install pgadmin4

만약 데스크톱 버전 혹인 웹 버전 둘 중 하나만 사용하고 싶다면 다음 명령어 중 하나를 골라 설치하면 됩니다.

> sudo apt install pgadmin4-desktop
> sudo apt install pgadmin4-web 

만약 웹 버전이 포함된 패키지를 설치했다면 pgAdmin-web을 설치해야 합니다. 다음 명령어를 통해 설치를 진행합니다.

> sudo /usr/pgadmin4/bin/setup-web.sh

이메일 주소와 비밀번호를 입력해줍니다. 지금 입력한 이메일 주소와 비밀번호가 초기 로그인 계정입니다.

pgAdmin4는 기본적으로 아파치 웹 서버 위에서 구동됩니다. y를 눌러 진행하면 http://your.domain.com/pgadmin4에 에 pgAdmin4를 접속할 수 있습니다. 

Ubuntu 20.04에 설치된 PostgreSQL의 버전을 업그레이드하는 방법에 대해 알아봅니다.

1. 기존 설치된 PostgreSQL 관련 패키지 제거하기.

먼저 지워야 할 패키지를 확인합니다. 다음 명령어를 통해 설치된 PostgreSQL의 패키지 리스트를 확인해 줍니다.

> dpkg --get-selections | grep postgres

이제 확인된 구버전의 PostgreSQL을 모두 제거해 줍니다

> apt-get --purge remove postgresql-12 postgresql-client-12 postgresql-client-common postgresql-common postgresql-contrib

만약 다음과 같이 디렉터리가 비어있지 않다는 메시지가 보이면 강제로 삭제합니다.

> sudo rm -rf /etc/postgresql-common
> sudo rm -rf /var/lib/postgresql

다시 한번 다음 명령어를 입력해 남아있는 패키지가 있는지 확인합니다.

> dpkg --get-selections | grep postgres

2. 시스템 업그레이드

이제 가장 최신의 릴리즈인 PostgreSQL13을 설치하도록 하겠습니다. 설치에 앞서 제 우분투 버전은 20.04 임을 미리 안내해 드립니다. 아래의 예시는 모두 우분투 20.04를 기준으로 작성되었습니다.

먼저 시스템을 업그레이드해줍니다

> sudo apt-get update
> sudo apt -y upgrade

만약 업그레이드할 항목이 있어 리붓이 필요하다면 리붓까지 시켜줍니다

> sudo reboot

3. PostgreSQL 13 리포지토리 추가하기

시스템이 업데이트되었으면 이제 PostgreSQL 13을 위한 APT 리포지토리를 추가합니다.

> wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -  

다음으로 리포지토리에 대한 구성 파일을 생성합니다.

> sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

이제 패키지 리스트를 업데이트합니다.

> sudo apt-get update

4. PostgreSql 13 설치

이제 모든 준비가 끝났습니다 다음 명령어로 PostgreSQL 13을 설치합니다.

> sudo apt-get -y install postgresql

정상적으로 설치가 끝나면 Postgresql 서비스를 실행시켜줍니다.

> sudo service postgresql start
> sudo service postgresql status

정상적으로 동작하는 것을 확인할 수 있습니다.

** Ubuntu firewall에서 PostgreSql 허용하기

PostgreSql은 기본적으로 5432 포트를 사용합니다. 다음 명령어를 사용해 5432 포트를 허용해 줍시다.

> ufw allow 5432

다양한 종류의 NoSQL에 대해 알아봅니다.

이 글은 다음 글을 발췌 및 번역한 글입니다: do.co/3lFbfMU

1. 소개

대부분의 사람들은 데이터베이스를 생각할 때 행(row)과 열(column)로 구성된 테이블을 포함하는 전통적인 관계형 데이터베이스 모델을 생각합니다. RDBMS는 여전히 인터넷에서 가장 많은 데이터를 처리하지만 개발자들은 관계형 모델의 한계에 대한 해결방법을 찾으려 노력함에 따라 최근 몇 년간 관계형 모델을 대체할 수 있는 데이터 모델이 좀 더 보편화되었습니다. 이러한 비 관계형 데이터 베이스 모델은 NoSQL이라 불리며 각각의 고유한 장점, 단점, 사용 사례를 확인해 보도록 하겠습니다.

이 글에서는 좀 더 일반적으로 사용되는 몇 가지 NoSQL 데이터베이스 모델을 소개합니다. 장점과 단점 중 일부를 평가하고 데이터베이스 관리 시스템의 몇 가지 예시와 각각에 대한 잠재적 사용 사례를 제공합니다.

2. Document 기반 데이터베이스.

문서 기반(Document-oriented) 데이터베이스 또는 문서 저장소는 데이터를 문서 형태로 저장하는 NoSQL 데이터베이스입니다. 문서 저장소는 Key-Value 저장소의 한 유형입니다. 각 문서에는 고유한 식별자(Key)가 있으며 문서 자체가 값(Value)의 역할을 합니다.

이 두 모델의 차이점은 Key-Value 데이터베이스에서 데이터가 불투명하게 처리되고 데이터베이스가 그 안에 보관된 데이터를 알거나 신경 쓰지 않습니다. 어떤 데이터가 저장되는지 이해해야 하는 것은 애플리케이션에 달려있습니다. 하지만 문서 기반 데이터베이스에서는 각 문서에 일정 수준의 구조를 제공하는 일종의 메타 데이터가 포함되어 있습니다. 문서 기반 데이터베이스는 사용자가 문서에 포함된 메타 데이터 기반으로 검색할 수 있는 API 또는 쿼리 언어를 제공합니다. 또한 문서 내에 다른 문서를 중첩할 수 있으므로 복잡한 데이터 구조도 표현할 수 있습니다.

주어진 객체의 데이터가 여러 테이블이나 다른 데이터베이스에 분산될 수도 있는 관계형 데이터베이스와는 달리 문서 기반 데이터베이스는 주어진 객체의 모든 데이터를 단일 문서에 저장할 수 있습니다. 문서 기반 데이터베이스는 일반적으로 데이터를 JSON, BSON, XML, YAML로 저장하고 일부는 PDF 같은 이진 형식으로 저장할 수도 있습니다. 일부는 데이터 검색에 SQL 변형, 전체 텍스트, 고유한 쿼리 언어를 사용하고 일부는 다른 둘 이상의 쿼리 메서드를 사용하기도 합니다.

먼저 기반 데이터베이스는 최근 몇 년 사이에 인기가 매우 증가하였습니다. 유연한 스키마 덕분에 전자상거래, 블로그, 분석 플랫폼, 콘텐츠 관리 시스템에서 사용되었습니다. 문서 기반 데이터베이스는 확장성이 높은 것으로 여겨지며 일반적인 수평 확장 전력은 샤딩(Sharding)입니다. 구조가 다르고 복잡한 정보를 보관하는데 탁월합니다.

인기 있는 오픈소스 문서 기반 데이터베이스는 다음과 같습니다:

• MongoDB: 이 글이 쓰였을 땐 이 범용 분산 문서 기반 데이터 베이스인 MongoDB가 세계에서 가장 널리 사용되던 문서 기반 데이터베이스였습니다.
• Couchbase: 원래 Merbase로 알려졌으며 JSON 기반의 Memcached와 호환되는 문서 기반 데이터베이스로 알려졌습니다. 다중 모델 데이터베이스인 Couchbase는 Key-Value 데이터베이스로도 동작할 수 있습니다.
• Apache CouchDB: Apache SW Foundation의 프로젝트인  CouchDB는 데이터를 JSON문서로 저장하고 JS를 쿼리 언어로 사용하는 문서 기반 데이터베이스입니다.

3. Graph 데이터베이스.

그래프 데이터베이스는 문서에 데이터를 저장하고 데이터가 미리 정의된 스키마를 따르지 않는다는 점에서 문서 기반 데이터 모델의 하위 범주로 생각할 수 있습니다. 하지만 그래프 데이터베이스는 개별 문서 간의 관계를 강조해 문서 모델에 별도의 레이어가 추가된다는 점이 다릅니다.

그래프 데이터베이스의 개념을 더 잘 이해하기 위해선 다음 용어를 이해해야 합니다:

• Node: 노드. 노드는 그래프 데이터베이스에서 추적하는 개별 엔티티의 표현입니다. 관계형 데이터베이스의 레코드, 행(row) 문서 기반 데이터베이스의 문서 개념과 거의 같습니다. 예를 들어 음악을 녹음하는 아티스트의 그래프 데이터베이스에서 노드는 연주자나 밴드가 될 수 있습니다.
• Property: 속성. 속성은 개별 노드와 관련된 정보입니다. 위의 예를 다시 사용하면 보컬리스트, 재즈, 플래티넘 인증 음악가 등이 될 수 있습니다. 
• Edge: 그래프 또는 관계(Relationship)로 알려진 에지는 두 노드가 어떻게 관련되어 있는지를 나타내며 RDBMS와 문서 기반 데이터베이스와 구별되는 그래프 데이터베이스의 핵심 개념입니다. 에지는 방향이 지정되거나 지정되지 않을 수도 있습니다.
  • Undirected: 무방향성. 방향성이 없는 그래프에서 에지는 노드 간의 연결을 표시하기 위해 존재합니다. 이 경우 에지는 양방향의 관계로 생각할 수 있습니다. 한 노드가 다른 노드와 어떻게 관련이 있는지에는 암시적인 차이점이 없습니다.
  • Directed: 방향성. 방향성 그래프에서 에지는 관계가 시작된 방향에 따라 다른 의미를 가질 수 있습니다. 이 경우 에지는 단방향의 관계로 생각할 수 있습니다. 예를 들어 방향성 그래프에서 Sammy가 그룹을 위해 앨범을 제작한 경우 Sammy와 Seaweeds의 관계를 방향성을 통해 지정할 수 있지만 Seaweeds에서 Sammy로의 방향성의 의미는 앞의 경우와 동등하지 않습니다.

특정 작업은 관련 정보를 연결하고 그룹화하는 방식 때문에 그래프 데이터베이스를 사용하는 것이 훨씬 간단합니다. 이러한 데이터베이스는 일반적으로 데이터 포인트 간의 관계에서 무언가를 얻어야 하거나 엔드 유저가 사용할 수 있는 정보가 소셜 네트워크처럼 다른 사람과 연결에 의해 정해지는 경우에 사용됩니다. 주로 사기 감지, 추천 엔진, ID 및 액세스 관리 애플리케이션에서 사용됩니다.

인기 있는 오픈 소스 그래프 데이터베이스는 다음과 같습니다:

• Neo4j: 네이티브 그래프 저장 및 처리 기능을 갖춘 ACID 호환 DBMS입니다. 이 글이 작성될 때 Neo4j는 세계에서 가장 인기 있는 그래프 데이터베이스였습니다.
• ArangoDB: ArangoDB는 그래프, 문서 기반, Key-Value 데이터 모델을 하나의 DBMS로 통합하는 다중 모델 데이터 베이스이며 배타적인 그래프 데이터베이스가 아닙니다. SQL과 유사한 쿼리 언어인 AQL, 전체 텍스트 검색, 랭킹 엔진이 특징입니다.
• OrientDB: OrientDB는 그래프, 문서 기반, Key-Value, 객체 모델을 지원하며 또 다른 다중 모델 데이터베이스입니다. SQL 쿼리, ACID 트랜잭션을 지원합니다.

4. 마침.

지금까지의 글에서 현재 사용 중인 NoSQL 데이터 모델 중 몇 가지를 살펴보았습니다. 객체 기반 데이터베이스와 같은 일부 NoSQL 모델은 수년간 다양한 수준의 사용 사례를 보였지만 일부에서는 관계형 모델에 대한 사용 가능한 대안 수준으로만 남았습니다. 객체 관계형(Object-Relational) 데이터베이스나 시계열(Time-Series) 데이터베이스 등 다른 것들은 관계형과 NoSQL의 데이터 모델을 혼합하여 일종의 DB 스펙트럼의 두 끝점 사이의 중간 지대를 형성합니다.

데이터베이스의 NoSQL 범주는 매우 광범위하며 지금도 계속 발전하고 있습니다. NoSQL DBMS 및 그 개념에 대해 좀 더 자세히 알아보려면 NoSQL에 관련된 콘텐츠 라이브러리를 확인해 보는 것이 좋습니다.

다양한 종류의 NoSQL에 대해 알아봅니다.

이 글은 다음 글을 발췌 및 번역한 글입니다: do.co/3lFbfMU

1. 소개

대부분의 사람들은 데이터베이스를 생각할 때 행(row)과 열(column)로 구성된 테이블을 포함하는 전통적인 관계형 데이터베이스 모델을 생각합니다. RDBMS는 여전히 인터넷에서 가장 많은 데이터를 처리하지만 개발자들은 관계형 모델의 한계에 대한 해결방법을 찾으려 노력함에 따라 최근 몇 년간 관계형 모델을 대체할 수 있는 데이터 모델이 좀 더 보편화되었습니다. 이러한 비 관계형 데이터 베이스 모델은 NoSQL이라 불리며 각각의 고유한 장점, 단점, 사용 사례를 확인해 보도록 하겠습니다.

이 글에서는 좀 더 일반적으로 사용되는 몇 가지 NoSQL 데이터베이스 모델을 소개합니다. 장점과 단점 중 일부를 평가하고 데이터베이스 관리 시스템의 몇 가지 예시와 각각에 대한 잠재적 사용 사례를 제공합니다.

2. Key-Value 데이터베이스.

Key-Value 저장소라고도 불리는 Key-Value 데이터베이스는 연관 배열(Associative Array)을 관리하고 저장함으로써 동작합니다. Dictionary 또는 해시 테이블이라고도 하는 연관 배열은 키가 키에 연관된 값을 검색하기 위한 고유 식별자 역할을 하며 이 키와 값을 한쌍으로 이 쌍들의 모음으로 구성됩니다. 값은 정수 또는 문자열과 같은 간단한 개체부터 JSON구조와 같은 복잡한 개체 이르기까지 다양합니다.

사전 정의된 데이터 타입이 있는 행과 열의 테이블로 구성된 데이터 구조를 정의하는 관계형 데이터베이스와 달리 Key-Value 데이터베이스는 구조나 관계(Relation) 없이 데이터를 단일 컬렉션으로 저장합니다. 애플리케이션은 데이터베이스 서버에 연결한 후 키(예를 들면 the_meaning_of_life)를 정의하고 나중에 키로 검색할 수 있는 값(예를 들어 42)을 제공할 수 있습니다. Key-Value 데이터베이스는 내부에 보관된 모든 데이터를 불투명한 Blob로 처리합니다. 그 구조를 어떻게 이해하는지는 애플리케이션에 달려있습니다.

Key-Value 데이터베이스는 주로 성능이 뛰어나고 효율적이며 확장 가능하다고 설명됩니다. Key-Value 데이터베이스의 일반적인 사용 사례는 캐싱, 메시지 대기열(Queuing), 세션 관리 등입니다.

인기 있는 오픈소스 Key-Value 데이터 저장소는 다음과 같습니다:

• Redis: 데이터베이스, 캐시, 메시지 브로커로 사용되는 인메모리 저장소. 문자열, 비트맵, 스트림, 공간 인덱스까지 다양한 데이터 구조를 지원합니다.
• Memcached: 메모리에 데이터와 개체를 캐싱하여 데이터 기반의 웹사이트와 애플리케이션의 속도를 높이는데 자주 사용되는 범용 메모리 개체 캐싱 시스템.
• Riak: 고급 로컬 및 다중 클러스터 복제 기능이 있는 분산 Key-Value 데이터 베이스.

3. Columnar 데이터베이스.

Colimn orianted 데이터 베이스라고도 불리는 Colimnar(열 기반) 데이터베이스는 열(Column)에 데이터를 저장하는 데이터베이스 시스템입니다. 이는 기존의 관계형 데이터베이스와 비슷해 보일 수 있지만 열을 테이블로 그룹화하는 대신 각각의 열은 시스템 저장소의 별도의 파일 또는 영역에 저장됩니다.

열 기반 데이터베이스에 저장된 데이터는 레코드 순서로 나타납니다. 즉 한 열의 첫 번째 항목이 다른 열의 첫 번째 항목과 관련됩니다. 이 디자인을 사용하면 쿼리가 테이블의 모든 행을 읽고 메모리에 저장된 후 불필요한 데이터를 삭제할 필요 없이 필요한 열만 읽도록 할 수 있습니다.

각 열의 데이터는 동일한 유형이므로 다양한 저장 및 읽기 최적화 전략을 사용할 수 있습니다. 특히 많은 열 기반 데이터베이스 관리자는 하나의 열이 차지하는 공간을 최소화하기 위해 연속 길이 부호화(run-length encoding)와 같은 압축 전략을 구현합니다. 이는 쿼리가 더 적은 행(rows)을 이동하게 하므로 읽기 속도를 높일 수 있습니다. 그러나 열 기반 데이터베이스의 한 가지 단점은 각 열을 개별적으로 작성해야 하고 데이터가 종종 압축된 상태로 유지되기 때문에 성능이 좋지 않은 경향이 있다는 것입니다. 특히 증분(Incremental) 로드와 개별 레코드 읽기는 성능 측면에서 많은 비용이 들 수 있습니다.

열 기반 데이터베이스는 1960년대부터 사용되었습니다. 그러나 2000년대 중반 이후 열 기반 데이터 모델이 빠른 쿼리 처리에 적합하기 때문에 열 기반 데이터베이스가 데이터 분석에 널리 사용되기 시작했습니다. 또한 애플리케이션이 열에서 데이터 평균 또는 합계를 찾는 것과 같은 집계 기능을 자주 수행해야 하는 경우에도 열 기반 데이터베이스가 유리합니다. 일부 열 기반 데이터베이스 관리 시스템은 SQL 쿼리를 사용할 수도 있습니다.

인기 있는 오픈소스 열 기반 데이터베이스는 다음과 같습니다.

• Apache Cassandra: 확장성, 가용성, 성능을 극대화하도록 설계된 열 기반 저장소입니다.
• Apache HBase: 대용량 데이터에 대해 구조화된 스토리지를 지원하고 Hadoop과 함께 동작하도록 설계된 분산 데이터베이스입니다.
• ClickHouse: 분석 데이터 및 SQL 쿼리의 실시간 생성을 지원하는 내결함성(Fault tolerant) DBMS입니다.

4. 마침.

NoSQL 데이터베이스 중 Key-Value 데이터베이스와 열 기반 데이터베이스에 대해 알아보고 그중 일부의 예시를 들어보았습니다. 다음 글에선 문서 기반(Document oriented) 데이터베이스와 그래프 데이터베이스에 대해 알아보도록 하겠습니다.

다양한 종류의 NoSQL에 대해 알아봅니다.

이 글은 다음 글을 발췌 및 번역한 글입니다: do.co/3lFbfMU

1. 소개

대부분의 사람들은 데이터베이스를 생각할 때 행(row)과 열(column)로 구성된 테이블을 포함하는 전통적인 관계형 데이터베이스 모델을 생각합니다. RDBMS는 여전히 인터넷에서 가장 많은 데이터를 처리하지만 개발자들은 관계형 모델의 한계에 대한 해결방법을 찾으려 노력함에 따라 최근 몇 년간 관계형 모델을 대체할 수 있는 데이터 모델이 좀 더 보편화되었습니다. 이러한 비 관계형 데이터 베이스 모델은 NoSQL이라 불리며 각각의 고유한 장점, 단점, 사용 사례를 확인해 보도록 하겠습니다.

이 글에서는 좀 더 일반적으로 사용되는 몇 가지 NoSQL 데이터베이스 모델을 소개합니다. 장점과 단점 중 일부를 평가하고 데이터베이스 관리 시스템의 몇 가지 예시와 각각에 대한 잠재적 사용 사례를 제공합니다.

2. 관계형 데이터베이스와 한계.

데이터베이스는 논리적으로 모델링 된 정보 또는 데이터 클러스터입니다. DBMS는 데이터베이스와 상호작용하는 컴퓨터 프로그램입니다. DBMS를 사용하면 데이터베이스에 대한 액세스를 제어하고 데이터를 쓰고 쿼리를 실행하는 등 데이터 베이스 관리와 관련된 기타 작업을 수행할 수 있습니다. DBMS는 종종 데이터베이스라고 불리지만 정확하 하자면 두 용어는 서로 동등하게 쓰일 수 없습니다. 데이터베이스는 컴퓨터에 저장된 데이터뿐 아니라 모든 데이터의 모음이 될 수 있으며 DBMS는 데이터 베이스와 상호작용할 수 있는 특정 소프트웨어일 뿐입니다.

모든 DBMS는 데이터가 저장되고 액세스 되는 방식을 구조화하는 기본 모델이 있습니다. 관계형 데이터베이스 관리 시스템(RDBMS)은 관계형 데이터 모델을 사용하는 DBMS입니다. 이 모델에서 데이터는 RDBMS의 맥락에 따라 공식적으로 관계(Relation)라고 불리는 테이블로 구성됩니다. RDBMS는 일반적으로 데이터베이스 내 보관된 데이터를 관리하고 액세스 하기 위해 SQL(Structured Query Language)을 사용합니다.

역사적으로 관계형 모델은 데이터 관리에 가장 널리 사용되는 접근 방식이며 오늘날까지 가장 널리 사용되는 DBMS도 관계형 모델을 구현합니다. 하지만 관계형 모델에는 특정 사용 사례에서 문제가 될 수 있는 몇 가지 제약사항이 존재합니다.

예를 들어 관계형 데이터베이스를 수평적으로 확장하는 것은 어려울 수도 있습니다. 수평적 확장은 부하를 분산하고 더 많은 트래픽과 더 빠른 처리를 하기 위해 기존 스택에 더 많은 머신을 추가하는 관행입니다. 이는 일반적으로 RAM 또는 CPU를 더 추가하여 기존 서버의 하드웨어를 업그레이드하는 수직적 확장과 대조되는 경우가 많습니다.

관계형 데이터 베이스를 수평적으로 확장하는 것이 어려운 이유는 관계형 모델이 일관성을 보장하도록 설계되어 있다는 사실과 관련이 있습니다. 즉 동일한 데이터 베이스를 쿼리 하는 클라이언트는 항상 최신의 데이터를 보게 해야 합니다. 여러 시스템에 걸쳐 관계형 데이터 베이스를 수평으로 확장하는 경우 클라이언트가 A노드가 아닌 B노드에 데이터를 쓸 수 있고 처음 쓴 B노드와 다른 노드들이 연결되는 시간이 존재해 변경 사항이 반영되는 업데이트 지연이 발생할 수 있어 일관성을 보장하기 어려워집니다.

RDBMS의 또 다른 제한사항은 관계형 모델이 구조화된 데이터 또는 사전 정의된 데이터 타입과 일치하거나 최소한 미리 결정된 방식으로 구성되어야 데이터를 쉽게 정렬하고 검색할 수 있도록 설계되었다는 것입니다. 하지만 1990년 이후 개인용 컴퓨터의 확산과 인터넷의 부상으로 이메일 메시지, 사진, 비디오 등과 같은 비정형 데이터가 보편화되었습니다.

이러한 제한이 더욱 크게 부각됨에 따라 개발자들은 기존의 관계형 데이터 모델의 대안을 찾기 시작하였으며 이로 인해 NoSQL 데이터베이스의 인기가 높아졌습니다.

3. NoSQL이란?

NoSQL이란 이름 자체에 대해서는 다소 모호한 정의가 있습니다. "NoSQL"은 1998년 Carlo Strozzi가 단순히 데이터 관리에 SQL을 사용하지 않았기 때문에 NoSQL 데이터베이스란 이름으로 만들어졌습니다.

이 용어는 2009년 이후 Johan Oskarsson이 Cassandra와 Voldemort 같은 "오픈소스 분산 및 비 관계형 데이터베이스"의 확산을 논의하기 위해 개발자 모임을 조직하면서 새로운 의미를 갖게 되었습니다. Oskarsson은 모임 이름을 "NoSQL"이라 명명하였으며 그 이후로 이 용어는 관계형 모델을 사용하지 않는 모든 데이터베이스에 대한 포괄적인 용어로 사용되게 되었습니다. 흥미롭게도 Strozzi의 NoSQL 데이터베이스는 실제로 관계형 모델을 사용합니다. 즉 처음의 NoSQL 데이터베이스는 현재의 NoSQL 정의에 맞지 않습니다.

"NoSQL"은 일반적으로 관계형 모델을 사용하지 않는 DBMS를 나타내므로 NoSQL 개념과 관련된 몇 가지 운영 데이터 모델이 있습니다. 다음에는 이러한 데이터 모델을 여러 개 소개합니다만 이는 전체 목록이 아닙니다.

이러한 다양한 기본 데이터 모델이 있음에도 불구하고 대부분의 NoSQL 데이터베이스는 몇 가지 특성을 공유합니다. NoSQL 데이터베이스는 일반적으로 일관성을 희생해 가용성을 최대화하도록 설계되었습니다. 여기서 일관성의 의미는 모든 읽기 작업이 데이터베이스에 기록된 가장 최근 데이터를 반환해야 한다는 생각을 의미합니다. 강력한 일관성을 위해 설계된 분산 데이터베이스에서 드는 한 노드에 기록된 모든 데이터를 다른 모든 노드에서 즉시 사용할 수 있으며 그렇지 않으면 오류가 발생합니다.

반대로 NoSQL 데이터베이스는 주로 최종 일관성을 목표로 합니다. 최종 일관성은 새로 작성된 데이터가 반드시 즉시 사용할 수 있어야 하는 것은 아니지만 결국 데이터베이스의 다른 노드에서 사용할 수 있게 됨(보통 몇 ms내에)을 의미합니다. 이렇게 하면 데이터의 가용성이 향상되는 이점이 있습니다. 작성된 최신 데이터를 즉시 볼 수 없더라고 오류가 발생하지 않고 이전 버전의 데이터를 볼 수 있습니다.

관계형 데이터베이스는 미리 정의된 스키마에 정확하게 맞는 정규화된 데이터를 처리하도록 설계되었습니다. DBMS의 맥락에서 정규화된 데이터는 중복을 제거하는 방식으로 구성된 데이터를 말합니다. 즉, 데이터베이스가 가능한 가장 적은 저장공간을 차지하도록 하는 것을 의미하며 스키마는 데이터베이스의 데이터가 구조화되는 방식에 대한 개요입니다.

NoSQL 데이터베이스는 정규화된 데이터를 저리 할 수 있고 미리 정의된 스키마 내에서 데이터를 정렬하는 것도 가능하지만 각각의 데이터 모델은 일반적으로 관계형 데이터베이스가 강요하는 견고한 구조보다 훨씬 더 큰 유연성을 허용하고 있습니다. 이 때문에 NoSQL 데이터베이스는 반정형, 비정형 데이터를 저장하는데 더 나은 선택으로 유명합니다. 하지만 NoSQL 데이터 베이스에선 사전에 정의된 스키마가 존재하지 않기 때문에 데이터베이스 관리자가 애플리케이션에 가장 적합한 방식으로 데이터를 구성하고 액세스 하는 방법을 정의해야 한다는 점을 염두해 두어야 합니다.

4. 마침.

NoSQL 데이터베이스가 무엇이며 관계형 데이터베이스와 다른 점에 대해 간략하게 파악해 봤습니다. 광범위하게 다음 글부터는 광범위하게 구현된 NoSQL 데이터베이스 모델 중 일부를 살펴보도록 하겠습니다.