BlockChain 기술을 기반으로 Smant Contract 기능을 구현하기 위한 분산 컴퓨팅 플랫폼이다. Ethereum 네트워크의 모든 사람들의 동의하는 하나의 표준 컴퓨터 (Ethereum Virtual Machine, EVM)가 있습니다. Ethereum에 참여하는 모든 참가자들은 EVM의 상태 복사본을 보관하고 있습니다.

EVM 정의

Ethereum Virtual Machine(EVM)은 Ethereum 네트워크를 구성하는 Client를 실행하고 있는 수천 개의 연결된 컴퓨터에 의해서 유지되는 하나의 단일 개체를 의미합니다.

Ethereum 프로토콜은 EVM이 중단되지 않고 지속적으로 불변하는 작동을 유지하기 위한 목적으로 존재합니다. BlockChain의 상태는 언제나 하나의 정규 상태를 가지며, EVM은 블록에서 블록으로 새로운 유효 상태를 계산하는 규칙을 정의합니다.

Ethereum의 상태

Ethereum은 SmartContract를 기반으로 각 노드에 분산 유한 상태 머신 데이터로 볼 수 있습니다. Ethereum의 상태는 계정, 잔액, 기계 상태를 보유하고 있는 대규모 데이터 구조로서 미리 정의된 규칙에 다라서 블록에서 블록으로 변경할 수 있고 임의의 코드를 실행할 수 있습니다. 블록에서 블록으로 상태를 변경하는 규칙은 EVM에 의해서 정의를 합니다.

Ethereum의 상태 전이 함수

EVM은 입력이 주어지게 되면 결정론적인 출력을 생성합니다. $$ Y(S , T) = S' $$ 기존에 검증된 S와 새로 검증된 Transaction (T)을 Ethereum 상태 transation 기능 Y(S, T) 에 넣어 새로운 형태 S'을 생성합니다.

State

Ethereum의 맥락에서, State는 Modified Merkle Patricia Trie 라고 불리는 구조의 모든 계정의 Hash로 연결된 하나의 Single root hash 유지하고 있습니다.

Transactions

Transaction은 계정에서 암호로 서명된 데이터 입니다. Transaction은 호출된 메시지의 결과가 담겨 있는 transaction과 contract의 결과가 담겨있는 2가지 타입의 종류가 있습니다. Contract는 smart contract의 bytecode가 포함된 새로운 contract 계정이 생성됩니다. 다른 계정이 해당 계약으로 메시지를 호출할 때마다 해당하는 바이트 코드를 실행합니다.

Ethereum에서의 Account

Ethereum에서의 계정은 Ethereum 네트워크에서 거래를 보낼 수 있는 Ethereum(ETH) 잔액을 가진 대상을 말합니다. 계정은 사용자가 제어하거나 스마트 컨트랙트를 배포할 수 있습니다.

Ethereum에서는 2가지 타입의 계정이 존재합니다.

Ethereum의 Account 종류

• Externally-owned account (EOA)

  • 누구나 개인키로 컨트롤을 할 수 있는 계정

• Contract account

  • 네트워크에 배포된 컨트랙트를 의미합니다. 소스코드를 기반으로 통제가 가능한 계정을 말합니다.

두 개의 Account는 모두 ETH 토큰을 소유하거나 보낼 수 있으며, 배포된 contract와 상호작용 하는 것이 가능합니다.

Ethereum은 다음 4가지 종류의 필드 값을 가지고 있습니다.

• nonce
  • 외부에서 보낸 transactions를 구분하고 각 개수를 세기 위한 값
• balance
  • 계정이 소유하고 있는 wei의 양
• codeHash
  • [[EVM]] 에 올라가 있는 account code의 hash값을 의미합니다.
• storageRoot
  • storage hash 라고도 불리고 있습니다.
  • keccack256 알고리즘을 기본으로 하여 인코딩하여 저장합니다.

나를 해하지 않는 것은 나를 더 강하게 만든다. -니체-

나를 해하지 않는 것은 나를 더 강하게 만든다. 이 책을 하나로 관통하는 문장이라고 생각한다.

우리는 살아오면서 여러가지 사건, 사고를 겪는다. 그러한 과정에서 우리는 도파민의 영향을 받으며 살아간다. 우리는 도파민의 영향을 받아 보상 그 자체의 쾌락을 느끼는 과정 보다 보상을 얻기 위한 동기부여 과정에 더 큰 영향을 받으며, 우리에게 행복한 느낌을 가져다 준다. 하지만 그런 과정이 과하게 될 경우, 어떠한 것에 중독 이라는 현상으로 나타날 수 있다.

도파민에 중독이 되면 우리는 삶에서 조금 더 쉬운 방법으로 쾌락을 얻고자 하며, 그러한 과정에서 고통을 피하게 된다. 공부를 하였을 때, 성적이 나오지 않을 것을 두려워하여 공부를 안 하기도 하고, 솔직한 모습을 보였을 때, 상대방이 나에게 실망하여 거리를 두는 것이 두려워 거짓말을 하기도 한다. 심한 경우, 자신을 학대하거나 마약에 중독이 되는 경우도 발생할 수 있다.

책 속에 나오는 환자들의 사례를 보면 우리의 삶이 지구 반대편에 있어도 다른 환경에 비슷한 고민을 할 수 있다는 것을 알게 된다. 나라도 거짓말을 했을 것이고 나라도 포기했을 것 같은 내용들이 나온다.

하지만, 책에 나오는 환자들은 각자의 상황을 솔직하게 받아들임으로써 현실을 극복해 나간다. 때로는 중독이 되는 대상을 없애버리고, 중독에서 벗어나기 위한 상징을 두기도 하고 나아가 다른 사람에게 도움을 요청하며 자신의 모습을 있는 그대로 드러내며 받아들인다.

살다 보면 취업에 실패하거나, 돈이 없어 자녀에게 지원을 못 해주는 상황, 알코올 중독에 빠진 상황 등 다양한 고통이 올 수 있다. 이러한 어려움이 나타났을 때 고통을 받아들이고 솔직함의 용기를 가지고 나의 본 모습을 마주할 때, 어려움을 극복할 수 있는 나아가 한 걸음 더 나아갈 수 있는 기회가 될 수 있을 것이라고 생각하게 된다.

CouchDB Selector syntax

selector 문법의 경우 기본적으로 다음과 같은 형태를 가진다. MongoDB의 문법과 유사한 점이 있지만 특정한 기능의 경우 다른 문법을 가지는 경우가 있습니다.

{
    "selector": {
        "year": {"$gt": 2010}
    },
    "fields": ["_id", "_rev", "year", "title"],
    "sort": [{"year": "asc"}],
    "limit": 2,
    "skip": 0,
    "execution_stats": true
}

Selector 기본 문법

field 한 개 기반 조회

기본적인 Selector 문법의 경우, 하나 이상의 조회하고자 하는 필드의 정보가 필요합니다. 특정한 필드의 값을 조회하는 경우, 다음과 같은 형태의 json 데이터로 조회하는 것이 가능합니다.

{
    "director": "Lars von Trier"
}

위의 예시의 경우, diredtor 필드의 값이 Lars von Trier 인 경우를 찾아서 조회하는 문법입니다.

조금 더 복잡한 selector 표현의 경우, 연산자($regex, $eq, $gt, $gte, $lt, $lte 등)의 조합으로서 다음과 같은 표현이 가능합니다.

{
    "selector":{
        "title": "Live And Let Die"
    },
    "fields": [
        "title",
        "cast"
    ]
}

field 2개 이상 조회

하나 이상의 필드를 조합한 조회를 하려면 다음과 같은 형태를 작성합니다.

{
    "name":"Paul",
    "location": "Boston"
}

위 예시의 경우, name 필드의 값이 Paul, location의 값이 Boston인 경우를 조회합니다.

Subfield 조회

조금 더 복잡한 subfiled 조회는 다음과 같은 방법으로 조회하는 것이 가능합니다. 기본적으로는 json형태로 조회하며, 점 표기법을 사용하여 조회하는 것도 가능합니다.

{
    "imdb":{
        "rating" : 8
    }
}
or
{
    "imdb.rating" : 8
}

Operators

연산자들은 달러 표시 $를 name 필드 앞 단에 붙여서 구분하여 사용할 수 있습니다. 연산자는 2 종류의 연산자 타입을 가지고 있습니다.

• Combination operators
• Condition operators

일반적으로 Combination 연산자의 경우는 최상급의 선택 단계에서 적용이 되며, Condition 연산자의 경우에는 하나 이상의 selector로 조합하여 사용합니다.

Implicit Operators

2 종류의 implicit operator가 있습니다.

• Equality
• And

두 개의 연산자는 선언하지 않더라도 선언이 된 것으로 간주가 됩니다. 예를 들어

{
    "director": "Lars von Trier"
}

{
    "director": {
        "$eq": "Lars von Trier"
    }
}

위의 2개의 json 데이터는 결과적으로 같은 결과를 가져옵니다.

Explicit Operators

Equality와 And 연산을 제외한 모든 연산자는 명확하게 명시해야 합니다.

Combination Operators

Combination Operators는 selectors를 조합하는데 사용합니다. 대부분의 프로그래밍 언어가 제공하는 boolean 연산자처럼 $all, $elemMatch, $allMatch 등의 연산자는 Json 배열 또는 Json 데이터를 비교합니다.

Combination Operator는 하나의 인자를 받아서 사용합니다. 인자는 하나 혹은 배열 형태의 데이터를 사용합니다.

Combination Operators List

$and 연산자는 2개의 필드를 사용한다.

{
  "selector": {
    "$and": [
      {
        "title": "Total Recall"
      },
      {
        "year": {
          "$in": [1984, 1991]
        }
      }
    ]
  },
  "fields": [
      "year",
      "title",
      "cast"
  ]
}

Condition Operators

Condition Operators는 저장되어 있는 특정한 데이터의 값을 평가하는데 사용이 됩니다. 예를 들어서, $eq 연산자의 경우 저장된 데이터가 같은 값을 가지고 있는지 확인하는 기능을 합니다.

Condition Operators는 반드시 문서에 조회하고자 하는 Selector가 존재해야 합니다. $ne 연산자의 경우 데이터가 반드시 존재하고, 데이터 값이 같지 않음을 의미합니다.

Condition Operators List

Sort Syntax

sort 필드는 필드의 이름, 정렬 방향이 기본적인 배열 형태로 표현이 됩니다. 첫 번째로 오는 필드의 이름과 방향이 가장 먼저 정렬이 되는 기준이 되며, 뒤에 오는 순서대로 정렬 규칙이 적용이 됩니다.

asc 는 오름차순, desc는 내림차순 정렬을 하고자 할 때 사용합니다. 특정한 방향을 입력하지 않는 경우 기본적으로 오름차순으로 정렬이 됩니다..

[{"fieldName1": "desc"}, {"fieldName2": "desc" }]

정렬 기능을 사용하려면 다음과 같은 정보를 확인해야만 합니다.

• 최소한 하나의 정렬 필드를 selector에 포함 되어야 한다.
• 모든 정렬 필드가 동일한 index 값이 적용이 되어 있어야 한다.
• 정렬 배열의 각 객체에는 single key가 하나 존재해야 한다.

만약 single key를 가지고 있지 않는 경우, 정렬의 결과는 구현의 방향에 따라서 달라질 수 있습니다. 간단한 정렬 쿼리문의 예시는 다음과 같습니다.

{
    "selector": {"Actor_name": "Robert De Niro"},
    "sort": [{"Actor_name": "asc"}, {"Movie_runtime": "asc"}]
}

Filtering Fields

필터를 통해서 가지고 오는 정보의 필드를 정확하게 지정하는 것이 가능합니다. 이러한 과정을 통해서, 다음과 같은 2가지 이점을 가져올 수 있습니다.

• Application에서 요구하는 특정한 데이터를 제한적으로 가져올 수 있다.
• 응답 데이터의 사이즈를 줄일 수 있다.

특정한 필드를 포함한 응답 데이터의 경우, 자동적으로 _id 같은 metadata 필드 정보를 자동으로 포함하지 않고 반환합니다.

예시 형태는 다음과 같습니다.

{
    "selector": { "Actor_name": "Robert De Niro" },
    "fields": ["Actor_name", "Movie_year", "_id", "_rev"]
}

Pagination

Mango query는 bookmark 필드를 통해서 Pagination 기능을 지원합니다. 모든 _fine 응답은 bookmark 값을 포함합니다. 다음 query의 결과를 가져오기 위해서는 selector값을 동일하게 유지한 다음, 다음의 bookmark 값을 추가하여 가져올 수 있습니다.

Pagination의 결과가 마지막에 도달했는지 확인하는 법은 size_request - result의 결과가 < limit 값을 비교하여 더 이상 없는 것을 확인할 수 있습니다.

Execution Statistics

특정한 요청을 통해서 기본적인 통계 정보를 제공하고 있습니다. _explain endpoint 값을 포함하여 유용한 데이터 값을 제공 받을 수 있습니다.

Reference

• https://docs.couchdb.org/en/stable/api/database/find.html#find-selectors

서버 환경

• CPU: 1 cores (5 thread), 16 GB RAM
• Operation system: Oracle Linux 8

Type: Developer playground

System Requirements: RaspberryPi(2/3) - Minimal Requirements

Setup - Single org - 2 Nodes - 1 channel - 1 orderer Node

Type: Advanced Developer playground - Locally on a PC

System Requirements: Ubuntu 16.04LTS, 4GB RAM, 20GB HDD

Setup - 3 orgs - 6 Nodes - 2 channel - 3 orderer Node

Type: Developing an MVP for an organization

System Requirements: Ubuntu 16.04LTS, 8GB RAM, 30GB HDD

Setup - Multi orgs - n Nodes - Multi channel Setup - 3 orderer Node

방화벽 설정 정보

사전 설치 프로그램

AWS Blockchain manegement system에서 HyperLedger Fabric을 사용하고자 할 경우, Go언어의 버전을 1.14로 해서 사용하여야만 Chaincode 업로드가 가능

• Git
• Docker
• Go
• JQ

설치 과정

테스트 네트워크 설치

테스트 네트워크 설치 script download

curl -sSLO https://raw.githubusercontent.com/hyperledger/fabric/main/scripts/install-fabric.sh && chmod +x install-fabric.sh

테스트 네트워크 실행 도움말

./install-fabric.sh -h

실행 예시

./install-fabric.sh -h
Usage: ./install-fabric.sh [-f|--fabric-version <arg>] [-c|--ca-version <arg>] <comp-1> [<comp-2>] ... [<comp-n>] ...
        <comp>: Component to install one or more of  d[ocker]|b[inary]|s[amples]. If none specified, all will be installed
        -f, --fabric-version: FabricVersion (default: '2.5.4')
        -c, --ca-version: Fabric CA Version (default: '1.5.6')

Component를 선택해서 다운로드

특정한 component를 선택해서 다운로드 하기 위해서는 다음의 인자를 추가해서 다운로드 진행

• docker
  • Fabric container 이미지를 다운로드 받기 위해서 docker 사용
• podman
  • Fabric container 이미지를 다운로드 받기 위해서 podman 사용
• binary
  • Fabric binaries 다운로드 진행
• samples
  • github repository에 있는 fabric-samples 코드를 현재 디렉토리에 다운로드

실행 예시

./install-fabric.sh docker samples binary
or
./install-fabric.sh d s b

특정 버전의 Fabric 다운로드

특정한 버전을 다운로드 하기 위해서는 --fabric-version과 -ca-version 옵션을 사용해서 다운로드가 가능

짧게 옵션을 준다면 -f , -c로 사용이 가능

Fabric 특정 버전 다운로드 예시

./install-fabric.sh --fabric-version 2.5.4 binary

테스트 네트워크 실행

네트워크 실행 명령

./network up

네트워크 실행 시, ca, channel 정보, DB 정보 설정

예시 : ca를 설정하며 채널 이름은 mychannel 저장소는 couchdb를 사용하도록 설정

./network.sh up createChannel -ca -c mychannel -s couchdb

네트워크 종료

./network down

Chaincode 배포

packaging

Go언어로 개발이 된 chaincode 정보를 패키징을 진행

peer lifecycle chaincode package chaincode.tar.gz --path ${O_CHAINCODE_PATH} --lang golang --label ${O_CHAINCODE_LABEL}

• path : 프로젝트의 경로 설정

• lang : chaincode가 개발된 언어 정보 설정 [Go, Java, Javascript]

  예시의 명령어의 경우, Go로 개발된 chaincode를 패키징

• label: chaincode의 라벨 정보를 추가

install

패키징된 tar.gz 파일을 Hyperledger Fabric Peer에 설치하는 과정. Chaincode를 배포하기 위해서는 Channel에 속한 모든 Peer에 chaincode를 설치해줘야 한다.

peer 명령어를 사용하기 전, 다음과 같은 환경설정을 먼저 진행한다.

환경 설정

export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=localhost:7051

각각 TLS에 대한 설정, Hyperledger Fabric의 MSP 설정, Peer의 주소 설정 정보를 의미한다.

설치 명령어

peer lifecycle chaincode install [패키징된 파일 이름]

approve

설치가 된 Chaincode에 대해서 각각의 Peer들은 배포의 여부를 증명하는 과정을 필요로 한다.

peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name chaincode --version 1.0 --package-id $CC_PACKAGE_ID --sequence 1 --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem"

위와 같은 명령어를 통해 chaincode를 증명할 수 있는데, chaincode의 이름, 버전 정보, 시퀀스 넘버를 입력하여 증명하는 것이 가능하다.

commit

일정한 비율만큼 증명이 되었다면 다음과 같은 명령어를 통해서 commit을 진행하는 것이 가능하다.

peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name chaincode --version 1.0 --sequence 1 --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem" --peerAddresses localhost:7051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt" --peerAddresses localhost:9051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt"

참고

배포하기 위해 작성했던 script 파일 내용

#!/bin/bash

export PATH=${PWD}/../fabric-samples/bin:$PATH
export FABRIC_CFG_PATH=${PWD}/../fabric-samples/config/
export PATH=$PATH:/usr/local/go/bin

set_peer1() {
    export CORE_PEER_TLS_ENABLED=true
    export CORE_PEER_LOCALMSPID="Org1MSP"
    export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/../fabric-samples/test-network/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
    export CORE_PEER_MSPCONFIGPATH=${PWD}/../fabric-samples/test-network/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
    export CORE_PEER_ADDRESS=localhost:7051
}

set_peer2() {
    export CORE_PEER_LOCALMSPID="Org2MSP"
    export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/../fabric-samples/test-network/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
    export CORE_PEER_MSPCONFIGPATH=${PWD}/../fabric-samples/test-network/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
    export CORE_PEER_ADDRESS=localhost:9051
}

packaging() {
    PACKAGE_RESULT=$(peer lifecycle chaincode package omnione.tar.gz --path ${O_CHAINCODE_PATH} --lang golang --label ${O_CHAINCODE_LABEL})
    if [ $? -ne 0 ]; then
        echo "PACKAGE ERROR!!"
        exit 1
    fi
}

install_chaincode() {
    set_peer1
    PACKAGE_INSTALL_FIRST=$(peer lifecycle chaincode install omnione.tar.gz >install_result.txt)
    if [ $? -ne 0 ]; then
        echo "FIRST PEER CHAINCODE INSTALL ERROR"
        exit 1
    fi

    set_peer2
    PACKAGE_INSTALL_SECOND=$(peer lifecycle chaincode install omnione.tar.gz)
    if [ $? -ne 0 ]; then
        echo "SECOND PEER CHAINCODE INSTALL ERROR"
        exit 1
    fi
}

approve_chaincode() {
    set_peer2
    $(peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name omnione --version ${O_CHAINCODE_VERSION} --package-id ${CC_PACKAGE_ID} --sequence 6 --tls --cafile "${PWD}/../fabric-samples/test-network/organizations/ordererOrgan
    izations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem")

    set_peer1
    $(peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name omnione --version ${O_CHAINCODE_VERSION} --package-id ${CC_PACKAGE_ID} --sequence 6 --tls --cafile "${PWD}/../fabric-samples/test-network/organizations/ordererOrgan
    izations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem")
}

commit_chaincode() {
    set_peer1
    $(peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name omnione --version 1.2 --sequence 6 --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem" --peerAddresses localhost:7051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt" --peerAddresses localhost:9051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt")
}

print_help() {
    echo "$0 -p PATH -v VERSION -l LABEL [-i ID]"
    echo "<options>"
    echo "    -p PATH: chaincode project path"
    echo "    -i CHAINCODE_ID: chaincode id that you want to deploy. default is 'omnione'"
    echo "    -v VERSION: chaincode version"
    echo "    -l LABEL: label of chaincode"
    echo "    -h     : Show this message."
    echo "<exit code>"
    echo "    0: Success."
    echo "    1: Failure."
    exit 1
}

while getopts p:i:l:v: opts; do
    case $opts in
    i)
        O_CHAINCODE_ID=$OPTARG
        ;;
    p)
        O_CHAINCODE_PATH=$OPTARG
        ;;
    l)
        O_CHAINCODE_LABEL=$OPTARG
        ;;
    v)
        O_CHAINCODE_VERSION=$OPTARG
        ;;
    h)
        print_help
        ;;
    \?)
        print_help
        exit 1
        ;;
    :)
        print_help
        exit 1
        ;;
    *)
        print_help
        exit 1
        ;;
    esac
done

packaging
install_chaincode
approve_chaincode

Reference

• https://www.quora.com/What-are-the-minimum-hardware-requirements-to-run-a-blockchain-hyperledger-fabric-node-or-validator
• http://hyperledger-fabric.readthedocs.io/en/release-2.5/prereqs.html#

NoSQL 데이타 모델링이란, NoSQL에 저장할 데이터들의 구조를 설계하는 것을 의미한다.

기존의 RDBMS와는 근본적인 2가지 사상의 변경이 필요하다.

1. 객체 모델 지향에서 쿼리 결과 지향 모델링

   RDBMS 모델링 기법은 저장할 도메인 모델을 분석한 후, 관계를 식별하고 테이블을 이용하여 쿼리를 구현. 그에 따른 결과를 뽑아내는 방식이다.

   하지만, NoSQL의 경우에는 이 방법을 역순으로 진행해야 한다.

2. 정규화(Nomalization)에서 비정규화(Denormalization)

   RDBMS 모델링에서는 데이터의 일관성과 도메인 모델과의 일치를 위해 데이터 모델을 정규화한다.

   하지만, NoSQL의 경우 쿼리의 효율성을 위해서 데이터를 정규화하지 않고, 의도적으로 중복된 데이터를 저장하는 등의 데이터 모델 설계 방식으로 접근한다.

NoSQL 데이터 모델링 절차

1.도메인 모델 파악

저장하고자하는 도메인을 파악한다. NoSQL도 DB이고 저장할 데이터에 대한 명확한 이해가 없이는 제대로된 모델이 나올 수 없다.

2.쿼리 결과 디자인 (데이터 출력형태 디자인)

쿼리 결과를 디자인 한다. 도메인 모델을 기반으로 Application에 의해서 쿼리되는 결과값을 먼저 정한다. 필요로 하는 출력 형식을 기반으로 필요로 하는 쿼리를 선정하고 내용을 정리한다.

3.패턴을 이용한 데이터 모델링

NoSQL은 RDBMS에서 흔히 사용하는 Sorting, Grouping, Join 등의 기능을 사용할 수 없다. 그렇기 때문에 Put / Get으로만 데이터를 가지고 올 수 있는 형태로 NoSQL의 데이터 모델을 재 정의를 해야한다.

데이터를 가급적으로 중복으로 저장(Demoralization)하여 한 번의 요청으로 데이터를 가급적 많은 정보를 가져와 데이터를 읽어오는 횟수를 줄이도록 한다.

특히 Key 값을 활용하여 여러가지 기능을 만들 수 있다. 각각의 userID나 postID 등의 값을 : 등의 구분자를 활용하여 Join, Orderring 기능으로 사용하는 것이 가능하다.

4.최적화를 위한 필요 기능들을 리스트화

각 저장할 데이터의 형태에 따라서 Document Store, Ordered Key 형태 등을 적용하여 저장한다.

5.후보 NoSQL을 선정 및 테스트

데이터의 성격과 업무의 목적에 맞는 다수의 NoSQL을 선정하여 사용

6.데이터 모델을 선정된 NoSQL에 최적화 및 하드웨어 디자인

선정된 NoSQL을 기반으로 데이터 모델을 최적화. 이에 맞는 Application 인터페이스 설계와 하드웨어에 대한 디자인을 진행.

NoSQL 모델링 패턴

기본적인 데이터 모델링

1. Denormalization 같은 데이터를 중복해서 저장하는 방식. 테이블간의 Join을 없애 1 번의 IO로 데이터를 조회할 수 있게 만든다. Join 쿼리를 여러 번 수행하지 않기 때문에 성능의 향상과 쿼리 로직의 단순함 효과를 가져온다. 하지만 데이터를 중복해서 저장하기 때문에 일관성 문제가 발생할 수 있고 스토리지의 용량이 증가하게 된다.

2. Aggregation NoSQL이 Key만 같다면, 각 Row의 값이 규격화되지 않은 것을 이용하여 각각 틀린 구조의 데이터를 저장한다. 하나의 데이터에 모든 정보를 저장하므로 Join의 수를 줄여 Query 성능을 높인다.

3. Application Side Join 어쩔 수 없이 join을 시도해야하는 경우, Application 단에서 Join이 필요한 테이블의 수 만큼 IO를 진행한다. IO가 발생하는 횟수가 많아 부담이 될 수 있지만, 스토리지 사용량을 절약할 수 있다.

확장된 데이터 모델링

1. Atomic aggregation

여러 테이블에 업데이트를 시도할 경우, 데이터의 일관성에 문제가 발생할 수 있다. 이러한 문제를 방지하기 위해 테이블을 하나로 합쳐서 관리를 하는 모델링을 말한다. NoSQL도 하나의 테이블에 대해서는 Atomic operation을 보장하기 때문에 트랜잭션을 보장받을 수 있어, 하나의 트랜잭션에 여러 개의 테이블로 나눠서 데이터를 보관하고 있을 경우, 하나의 테이블로 관리하여 정보를 변경하도록 한다.

2. Index table

NoSQL은 RDBMS처럼 index가 없기 때문에, Key 이외의 속성값을 이용하여 조회를 하면, 전체 Table을 전부 조회하거나 아예 조회가 불가능하다.

이러한 문제를 해결하기 위한 방법으로 Index를 위한 별도의 Index Table을 만들어서 사용하는 경우를 말한다.

3. CompositeKey

하나 이상의 필드를 구분자를 이용하여 구분지어 사용하는 방법으로 RDBMS의 복합키 (Composite primary Key)와 같은 개념으로 볼 수 있다.

4. Inverted search index

이 기법은 모델링이라기 보다는 데이터 처리 패턴에 조금 더 가깝다. 인덱스를 사용하여 특정한 기준에 맞춰 데이터를 찾도록 원본의 데이터의 표현 또는 전체 검색을 할 때 사용 된다.

계층형 데이터 모델링

1. Tree Aggregation

하나의 단일 Document 형태로 Tree구조 혹은 간단한 그래프 구조를 나타내도록 하는 방식을 말한다. 한 번에 블로그 글을 조회하거나 하는 방식에 매우 효과적이지만 내용을 자주 변경하거나 임의로 엑세스 하는 과정이 들어가는 경우 비효율적인 저장 방식이다.

적용 가능 : Key-Value Stores, Document Databases

2. Adjacency Lists

Adjancency List는 각 노드가 직접적으로 부모 노드, 또는 자식 노드의 배열을 포함하여 서로 의존적이지 않는 형태의 그래프 모델링입니다.

부모나 자식 노드의 식별자를 활용하여 검색할 수 있다. 하나의 노드로 전체 하위 노드의 정보를 가져오는데는 비효율적인 방법이다.

적용 가능 : Key-Value Stores, Document Databases

3. Materialized Paths

Meterialized Paths는 트리 구조처럼 순회하는 것을 방지해주는 방법이다. 각 노드는 각자 부모 또는 자식노드를 특정지을 수 있도록 만들어져 있다. 이러한 방식의 구조는 이 방법은 계층 구조를 무계층 문서로 변환할 수 있기 때문에 전체 텍스트 검색 엔진에 특히 좋은 성능을 발휘합니다.

적용 가능 : Key-Value Stores, Document Databases, Search Engines

4. Nested Sets

Nested Sets은 트리 같은 구조에서 기본적으로 사용이 되는 방법이다. 관계형 DB에서 넓게 사용이 되지만, Key-Value와 Document DB 에서도 완벽하게 사용하는 것이 가능하다. 이러한 구조는 그림과 같이 트리 구조의 리프를 배열에 저장하고 시작, 끝 인덱스를 사용하여 각 리프의 범위에 매핑하는 방식이다.

데이터의 양이 변하지 않는 상황일 경우 유용한 구조가 될 수 있지만 자주 삽입, 변경, 삭제가 일어나는 데이터의 경우에는 부적절한 방법이다.

적용 가능 : Key-Value Stores, Document Databases

출처

• https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/
• https://www.analyticsvidhya.com/blog/2022/07/nosql-data-modeling-technique/
• https://bcho.tistory.com/666

사람에 따라 No SQL, Not Only SQL, Non-Relational Operational Database SQL로 엇갈리는 의견들이 있지만, 현재 Not Only SQL로 풀어 설명하는 것이 다수를 차지하고 있다.

기존의 RDBMS보다 더 융통성이 있는 모델을 사용하고 데이터의 저장 및 검색을 위한 특화된 매커니즘을 제공한다. 이를 통해서 NoSQL DB는 단순 검색 및 추가 작업에 있어서 매우 최적화된 Key-Value 저장 기법을 사용하여 응답속도, 처리 효율 등에 있어 뛰어난 성능을 보여준다.

RDBMS와 NoSQL의 차이

NoSQL이 DBMS라고 생각해서 RDBMS와 같은, 또는 떨어지지만 유사한 기능을 제공할것이라고 생각하면 큰 오산이다. NoSQL은 데이타를 저장한다. 그리고 Key에 대한 Put/Get만 지원한다. RDBMS로 치자면

Put : Insert into TABLE VALUES(KEY,value1,value2,…,valuen)

Get : Select * from TABLE where KEY=”key”

만 딱 지원한다. 물론 제품에 따라서 기능에 대한 지원 범위는 다르기는 하지만, 공통적으로 고민해야 하는 기능은

• Sorting (SQL의 Order By)
• Join (RDBMS에서 두개의 Table을 Foreign Key를 이용하여 join)
• Grouping (SQL문의 group by)
• Range Query (where key>”start” and key<”end” 와 같이 일정 범위내의 내용을 쿼리해오는 기능)
• Index (RDBMS에 Index를 지정하여 select query 성능을 높이는 기능)

이다. RDBMS에서는 너무나도 익숙하게 사용했던 기능들이기 때문에, 막상 이 기능들을 빼고 데이타를 다루고자 하면 매우불편하다.

NoSQL DB의 종류

NoSQL DB는 각 4가지 형태가 존재합니다. 각 DB는 형태에 따라 각자의 특성이 있어 상황에 맞게 DB를 선택을 해야한다.

NoSQL DB의 종류

• Kye-value
• Document based
• Column based
• Graph-based

1. Key-value store

Key와 Value 값으로 이루어진 데이터를 저장하며, 저장과 조회라는 원칙에 가장 충실한 형태의 DB이다.

Key-Value DB의 Key값은 고유한 값을 유지하고 있어야 하며, Value에 모든 데이터 타입을 허용하므로, 개발자들은 데이터 입력 단계에서 검증로직 구현을 제대로 구현해야 한다.

2. Document based store

Key-Value DB처럼 Key와 value 값을 저장하지만 Document는 Value값을 smi-structured entity (JSON, XML) 같은 표준 형식을 저장한다.

값을 저장하기 전에 schema를 별도로 정의하지 않으며, Document를 추가하면 그게 schema가 된다.

각 Document는 별도의 필드를 가질 수 있으며 개발자가 Application에서 데이터를 입력하는 단계에서 컬럼과 필드의 관리가 제대로 이루어지도록 보장하는 것이 중요하다. 예를 들면 필수 속성에 대한 관리도 Applicaiton 레벨에서 관리가 되어야 한다.

Document DB는 다음과 같은 목적으로 주로 사용된다.

1. 대용량 데이터를 읽고 쓰는 웹 사이트용 백엔드
2. 제품처럼 다양한 속성이 있는 데이터 관리
3. 다양한 유형의 메타데이터 추적
4. JSON 데이터 구조를 사용하는 Application
5. 비정규화된 중첩 구조의 데이터를 사용하는 Application

3. Column based store

RDBMS 같이 행에 중점을 두는 것이 아닌 열에 중점을 둔 방식.

비슷한 속성 값, 같은 특성을 가진 대량의 데이터를 계산해야 하는 데이터 웨어하우스 등에 적합한 방식

4. Graph based store

데이터를 노드로 표현하며 노드 사이의 관계를 엣지로 표현하는 방식의 DB.

RDBMS보다 퍼포먼스가 좋고 유연하며 유지보수가 용이함.

참고자료

• https://www.samsungsds.com/kr/insights/1232564_4627.html
• https://www.analyticsvidhya.com/blog/2022/07/nosql-data-modeling-technique/
• https://bcho.tistory.com/665

호텔을 운영 중인 코니는 최소한의 객실만을 사용하여 예약 손님들을 받으려고 합니다. 한 번 사용한 객실은 퇴실 시간을 기준으로 10분간 청소를 하고 다음 손님들이 사용할 수 있습니다. 예약 시각이 문자열 형태로 담긴 2차원 배열 book_time이 매개변수로 주어질 때, 코니에게 필요한 최소 객실의 수를 return 하는 solution 함수를 완성해주세요.

제한사항

• 1 ≤ book_time의 길이 ≤ 1,000

• book_time[i]는 ["HH:MM", "HH:MM"]의 형태로 이루어진 배열입니다.

  • [대실 시작 시각, 대실 종료 시각] 형태입니다.

• 시각은 HH:MM 형태로 24시간 표기법을 따르며, "00:00" 부터 "23:59" 까지로 주어집니다.

  • 예약 시각이 자정을 넘어가는 경우는 없습니다.
  • 시작 시각은 항상 종료 시각보다 빠릅니다.

풀이

전체 과정

1. 문자열을 비교할 수 있는 형태로 변환한다.
2. 입실 시간을 기준으로 정렬한다.
3. 순서대로 투숙 입실 시간이 직전 퇴실 시간 + 10분 보다 넘어 날 경우, 값을 하나씩 추가한다.

문자열 변환

int convertToInt(string s) {
  int hour = stoi(s.substr(0, 2));
  int minute = stoi(s.substr(3, 2));

  return hour * 100 + minute;
}

int convertToStratTime(string s) { return convertToInt(s); }

int convertToEndTime(string s) {
  int timeInfo = convertToInt(s);

  if (50 <= timeInfo % 100) {
    timeInfo += 100;
    timeInfo -= 50;
  } else {
    timeInfo += 10;
  }

  return timeInfo;
}

convertToInt 함수를 통해서 문자열을 비교할 수 있는 정수형으로 변환하였다. 투숙이 가능한 시간은 퇴실시간 + 10분이므로 종료시간의 경우, convertToEndTime 함수를 통해서 10분을 추가하여 반환하도록 한다.

정렬

sort(booking_info.begin(), booking_info.end());

저장한 pair의 first 값을 기준으로 오름차순으로 정렬한다.

비교 후 값 반환

  vector<pair<int, int>> room;

  for(pair<int, int> booking_time : booking_info) {
    vector<pair<int, int>> temp;
    int start = booking_time.first;

    for(pair<int, int> using_room : room) {
      if(start < using_room.second) {
        temp.push_back(using_room);
      }
    }

    room = temp;
    room.push_back(booking_time);
    answer = answer <= room.size() ? room.size() : answer;
  }

정렬한 vector를 순회하며 비교한다. 새로 들어오는 입실 시간과 기존에 저장이 되어있는 퇴실시간을 비교하여 입실이 가능한 정보만 저장하여 기존 정보를 저장하는 vector를 갱신한다.

최종적으로, vector의 사이즈를 결과로 반환한다.

전체 코드

#include <algorithm>
#include <string>
#include <vector>

using namespace std;


int convertToInt(string s) {
  int hour = stoi(s.substr(0, 2));
  int minute = stoi(s.substr(3, 2));

  return hour * 100 + minute;
}

int convertToStratTime(string s) { return convertToInt(s); }

int convertToEndTime(string s) {
  int timeInfo = convertToInt(s);

  if (50 <= timeInfo % 100) {
    timeInfo += 100;
    timeInfo -= 50;
  } else {
    timeInfo += 10;
  }

  return timeInfo;
}

int solution(vector<vector<string>> book_time) {
  int answer = 0;

  vector<pair<int, int>> booking_info;

  for (vector<string> time_info : book_time) {
    int startTime = convertToStratTime(time_info[0]);
    int endTime = convertToEndTime(time_info[1]);

    booking_info.push_back(make_pair(startTime, endTime));
  }

  sort(booking_info.begin(), booking_info.end());

  vector<pair<int, int>> room;

  for(pair<int, int> booking_time : booking_info) {
    vector<pair<int, int>> temp;
    int start = booking_time.first;

    for(pair<int, int> using_room : room) {
      if(start < using_room.second) {
        temp.push_back(using_room);
      }
    }

    room = temp;
    room.push_back(booking_time);
    answer = answer <= room.size() ? room.size() : answer;
  }
  return answer;
}

출처

• 프로그래머스

Hyperledger Fabric의 Chaincode를 개발할 상황이 생기면서 Go언어를 사용할 일이 생겼다. 한 번쯤 배우고 싶었던 언어이고 필요성이 생긴 만큼 간단한 API 서버 개발을 통해 Go언어에 익숙해지기 위해서 간단한 API 서버를 개발해봤다.

진행 과정

개발 환경 구축

사전 준비

• VS Code
• Docker
• Remote Development
• Postgre SQL

개발 과정

model 설정

package model

type Message struct {
    ID  string `json:"id"`
    Msg string `json:"msg"`
}

DB에 저장하기 위한 데이터 형태를 선언한 부분이다. 데이터는 ID 값과 메시지 값을 저장할 수 있게 선언했다.

db 연결 부분

package db

import (
    "database/sql"
    "fmt"

    model "example.com/practice/model"
    _ "github.com/lib/pq"
)

const (
    host     = "localhost"
    port     = 5432
    user     = "postgres"
    password = "postgres"
    dbname   = "postgres"
)

func connect() *sql.DB {
    psqlInfo := fmt.Sprintf("host=%s port=%d user=%s "+
        "password=%s dbname=%s sslmode=disable",
        host, port, user, password, dbname)

    dbcon, err := sql.Open("postgres", psqlInfo)

    if err != nil || dbcon.Ping() != nil {
        panic(err.Error())
    }

    return dbcon
}

func GetMessage(id string) []model.Message {
    db := connect()
    selectDynStmt := `SELECT id, msg FROM Message where "id"=$1`
    rows, err := db.Query(selectDynStmt, id)

    messages := []model.Message{}

    checkError(err)
    defer db.Close()
    defer rows.Close()

    for rows.Next() {
        var msg model.Message
        if err := rows.Scan(&msg.ID, &msg.Msg); err != nil {
            panic(err)
        }

        messages = append(messages, msg)
    }

    return messages
}

func SaveMessage(msg model.Message) sql.Result {
    db := connect()
    if db.Ping() != nil {
        panic(db.Ping().Error())
    }
    insertDynStmt := `insert into Message ("id", "msg") values($1, $2)`
    result, err := db.Exec(insertDynStmt, msg.ID, msg.Msg)
    checkError(err)
    defer db.Close()
    return result
}

func UpdateMessage(msg model.Message) sql.Result {
    db := connect()
    if db.Ping() != nil {
        panic(db.Ping().Error())
    }

    updateDynStmt := `update Message set "msg"=$1 where "id"=$2`
    result, err := db.Exec(updateDynStmt, msg.Msg, msg.ID)

    checkError(err)
    defer db.Close()

    return result
}

func DeleteMessage(id string) sql.Result {
    db := connect()
    if db.Ping() != nil {
        panic(db.Ping().Error())
    }

    deleteDynStmt := `delete from Message where "id"=$1`
    result, err := db.Exec(deleteDynStmt, id)
    checkError(err)

    defer db.Close()

    return result
}

func checkError(err error) {
    if err != nil {
        panic(err)
    }

}

PostgreSQL과 연결하고 간단한 CRUD 작업을 하는 부분입니다.

routing 설정

package router

import (
    "log"
    "net/http"

    db "example.com/practice/db"
    model "example.com/practice/model"
    "github.com/gin-gonic/gin"
)

func StartRouter() {
    router := gin.Default()

    router.GET("/message/:id", func(c *gin.Context) {
        id := c.Param("id")
        result := db.GetMessage(id)
        c.IndentedJSON(http.StatusOK, result)
    })

    router.POST("/message", func(c *gin.Context) {
        var newMessage model.Message

        if err := c.BindJSON(&newMessage); err != nil {
            log.Fatal("BIND JSON ERROR")
            return
        }

        result := db.SaveMessage(newMessage)
        c.IndentedJSON(http.StatusCreated, result)
    })

    router.PUT("/message", func(c *gin.Context) {
        var updateMessage model.Message

        if err := c.BindJSON(&updateMessage); err != nil {
            log.Fatal("BIND JSON ERROR")
            return
        }

        result := db.UpdateMessage(updateMessage)
        c.IndentedJSON(http.StatusAccepted, result)
    })

    router.DELETE("/message", func(c *gin.Context) {
        var deleteMessage model.Message

        if err := c.BindJSON(&deleteMessage); err != nil {
            log.Fatal("BIND JSON ERROR")
            return
        }

        result := db.DeleteMessage(deleteMessage.ID)
        c.IndentedJSON(http.StatusAccepted, result)
    })

    router.Run("localhost:8080")
}

간단한 REST API를 routing 하는 부분입니다.

참고

• 전체 소스 코드

에러는 2개의 Entity가 @OneToMany로 연결이 되었을 때, 조회를 하는 과정에서 발생했던 문제였다. 에러가 발생했던 코드와 두개의 Entity는 다음과 같은 형태였다.

Error가 발생했던 함수

  public ChartDataDto getChartDataById(Long id) throws ChartDataException {
    ChartData chartData = chartDataRepository.findById(id).orElseThrow(
        () -> new ChartDataException(ChartDataErrorCode.CANNOT_FOUND_CHART_DATA.getErrorCode(),
            ChartDataErrorCode.CANNOT_FOUND_CHART_DATA.getMsg())
    );
    log.info("chart_data information {}", chartData.toString());
    for (var dataCategory : chartData.getDataCategories()) {
      log.info("Category information : {}", dataCategory.getCategory().toString());
    }
    return new ChartDataDto(chartData);
  }

ChartData Entity

@Getter
@Entity
@NoArgsConstructor
public class ChartData {

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;

  @OneToMany(mappedBy = "chartData")
  private List<DataCategory> dataCategories;

  private int money;

  private String itemName;

  private String memo;

  private LocalDateTime localDateTime;

  @Builder
  public ChartData(Long id, int money, String itemName, String memo, LocalDateTime localDateTime){
    this.id = id;
    this.money = money;
    this.itemName = itemName;
    this.memo = memo;
    this.localDateTime = localDateTime;
    this.dataCategories = new ArrayList<>();
  }

  public void setDataCategory(List<DataCategory> dataCategory) {
    this.dataCategories = dataCategory;
  }

  public void updateChartData(ChartDataDto chartDataDto) {
    this.money = chartDataDto.getMoney();
    this.itemName = chartDataDto.getItemName();
  }

  public void addDataCategory(DataCategory dataCategory) {
    this.dataCategories.add(dataCategory);
  }

  public ChartData(ChartDataDto chartDataDto) {
    this.money = chartDataDto.getMoney();
    this.localDateTime = chartDataDto.getLocalDateTime();
    this.memo = chartDataDto.getMemo();
    this.itemName = chartDataDto.getItemName();
  }

  @Override
  public String toString() {
    return getClass().getSimpleName() + "(" +
        "id = " + id + ", " +
        "money = " + money + ", " +
        "itemName = " + itemName + ", " +
        "memo = " + memo + ", " +
        "localDateTime = " + localDateTime + ")";
  }
}

DataCategory Entity

@Builder
@Getter
@Entity
@AllArgsConstructor
@NoArgsConstructor
public class DataCategory {

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;

  @ManyToOne(fetch = FetchType.LAZY)
  private ChartData chartData;

  @ManyToOne(fetch = FetchType.LAZY)
  private Category category;

  public static DataCategory createDataCategory(ChartData chartData, Category category) {
    DataCategory dataCategory = new DataCategory();
    dataCategory.setCategory(category);
    dataCategory.setChartData(chartData);
    return dataCategory;
  }

  public static DataCategory createDataCategory(ChartData chartData) {
    DataCategory dataCategory = new DataCategory();
    dataCategory.setChartData(chartData);
    return dataCategory;
  }

  public static DataCategory createDataCategory(Category category) {
    DataCategory dataCategory = new DataCategory();
    dataCategory.setCategory(category);
    return dataCategory;
  }

  public void setChartData(ChartData chartData) {
    this.chartData = chartData;
    chartData.addDataCategory(this);
  }

  public void setCategory(Category category) {
    this.category = category;
    category.addDataCategory(this);
  }

  @Override
  public String toString() {
    return getClass().getSimpleName() + "(" +
        "id = " + id + ")";
  }
}

테스트를 하는 과정에서 chartData.getDataCategories() 함수를 실행하는 과정에서 발생했고 이런 문제가 발생했던 이유는 @ManyToOne(fetch = FetchType.LAZY) 때문이었다. ManyToOne(fetch = FetchType.LAZY) 를 ManyToOne(fetch = FetchType.EAGAR) 변경함으로써 에러를 해결할 수 있었다. 여기서의 FetchType은 LAZY와 EAGAR이 있으며 각각 지연로딩과 즉시로딩을 의미한다.

지연로딩(LAZY)

• 데이터를 조회할 때, 필요할 때 연관된 데이터를 불러오는 형태
• 연관된 엔티티를 프록시로 조회한다. 프록시를 실제로 사용할 때 초기화를 진행하면서 DB를 조회한다.

즉시로딩(EAGAR)

• 데이터를 조회할 때, 연관된 데이터를 한 번에 불러오는 형태
• Hibernate는 가능하면 SQL JOIN을 사용해서 한 번에 조회한다.