계기

SQL이라고는 학교의 Database, 벡엔드 수업에서 접했던 게 전부였다. 정보처리기사 자격증을 준비하며 수업을 대강 들었던 과거의 나를 반성하게 되었다. 처음 접하는 내용이었고, 직접적인 흥미보다는 데이터 베이스는 꼭 들어야한다는 주변의 추천에 어영부영 듣게 된 것도 있었다. 그러다 보니 시험을 위한 단기 기억은 오래가지 못했고 애매하게 단어와 개념만 대강 기억났다. 정처기 책에서 모든 내용을 요약된 표와 그림으로 보고 있자니 알고 있던 것과 전혀 이어지지 않았다. 간당간당한 지식으로 패스를 외쳤던 호기로운 전공생이 더 이상 얄팍한 기억으로 문제를 풀지 못하게 되었을 때에는 큰 충격을 받았다. 그 길로 데이터 베이스책과 SQL 책을 구매하고 뒤져가며 공부를 했다. 완전히 이해하지 못한 부분도 남아있었지만 SQL 쿼리는 키워드 몇 개만 찾아보면 문제 없이 활용하게 되었다.

이 책을 읽게된 계기는 Firebase에 대해 공부할 일이 생겼기 때문이었다. 몇 장 넘기지도 않아 NoSQL이라는 단어가 나왔다. 간간히 접한 정보로 NoSQL에 MongoDB 같은 것들이 있다는 것을 알고는 있었지만, 명확히 무엇인지 확실히 알지 못했다. 이게 왜 NoSQL인지, NoSQL은 SQL과는 얼마나 어떻게 다른지, SQL을 사용할 때 고려사항이 NoSQL도 동일한지. 그래서 Firebase 보다 NoSQL에 대한 이해가 우선이라 생각했다.

중간 후기

  • 23.03.30
    • 책을 사온 지는 꽤 되었는데, 2장을 넘어가지 못하고 있다. 처음 듣는 용어의 향연이라 하나하나 짚어가면서 읽고 있어서 그런지 속도가 더딘게 답답하다. 용어를 명확하게 짚고 가지 않으면 나중에는 진짜 하나도 못 알아들을 것 같아서 필기를 하면서 적고 있다. 하지만, 점점 집중력이 떨어지는지 필사 수준으로 받아적고 있는 기분이다.
    • 생각보다 경험해봤던 것들 중에 NoSQL가 있었다. 졸업 프로젝트에서 컨텐츠를 저장하기 위해 혹은 서버와 통신하기 위해 Json 파일 형태로 변형해 사용했던 경험이 있었다. 명확히 NoSQL인지는 모르겠지만, SaaS 게임 서버와 연결하기 위해 사용했던 것들이 NoSQL 방식의 DB를 활용하기 위해서였다면 NoSQL이 생각보다 멀리있는 개념은 아니라는 생각이 들었다.

읽기만 하기 억울해 옮기는 정리

NoSQL

  • No sql, Not Only sql 이라는 이름에 대한 여러 설이 있다.

  • 일반적으로는 탈 관계형 데이터베이스를 기조로 한다.

    • 객체-관계 불일치를 해소하기 위해 나왔다고 봐야한다.

  • NoSQL의 조건은 다음과 같다. 하지만 모든 조건을 지키는 것은 아님.

    1. 오픈소스
    2. 비관계형 DB
    3. 클러스터를 대비
    4. 특정시기: 21세기 초, 웹 환경에 맞는 필요에 의해 개발된 프로그램

  • 주요 NoSQL 분류

    • 키-값 DB
    • 문서 DB
    • 칼럼 패밀리 DB
    • 그래프 DB

    위에서 키-값, 문서, 칼럼 패밀리는 집합 지향(aggregate orientation)성을 가지고 있다. 관계지향 DB에서 각 Attribute값들이 원자성을 띄는 것에 반해, 집합 지향 DB에서는 튜플의 집합보다 복잡한 구조의 데이터를 단위로 활용한다. 이 책에서는 이 복잡한 구조의 데이터를 집합이라고 서술하였다.

집합

  • 데이터 조작 & 일관성 관리의 단위
  • 원자적 단위
  • 데이터 저장소와 통신 단위
  • 키-값, 문서, 칼럼 패밀리 DB와 적합
  • 복제&샤딩의 단위

관계형 DB(SQL)의 릴레이션과 집합이 다른점은 집합은 릴레이션과 달리 저장소와 상호작용하는 단위로 활용된다. 이런 집합의 개념을 모르는 것을 집합 무지라고 하는데, 대표적으로 관계형 DB와 그래프 DB가 있다.

키-값 모델 & 문서 데이터 모델

  • 강력한 집합지향적 모델
  • 많은 집합으로 구성된다.

차이

  • 키-값 모델: 집합 구조 불투명. 키를 통해 접근.
    • 집합 구조 불투명: 집합 내에 무엇이든 저장가능(시스템적 크기 제한 정도만).
  • 문서 모델: 집합 구조 확인 가능. 집합 필드를 통해 접근.
  • 하지만 점점 서로 비슷해져 간다고 한다. 키-값 형식으로 검색하기 위해 문서DB에 ID필드를 넣기 때문

요약

  • 키-값 모델: 키를 통해 집합을 찾는 형태
  • 문서 모델: 문서 내부 구조를 기초로 어떤 형태의 쿼리를 시행하는 형태

칼럼 패밀리 저장소

  • 칼럼 패밀리 모델

    • 두 단계 집합 구조

      • 첫번째 키, 행 ID: 관심집합을 찾는데 사용
      • 두번째 단계, 칼럼: 행 전체에 접근 가능.

      => 예를 들면 get('1234','name'); 행 1234의 name 칼럼 값.

    • 칼럼을 칼럼 패밀리로 구조화

      • 행-지향: 행은 집합, 칼럼 패밀리는 그 집합 안의 유용한 데이터 덩어리
      • 열-지향: 행은 모든 칼럼 패밀리의 레코드 연결, 칼럼 패밀리는 각 레코드의 행.
      • DB가 데이터의 공통 그룹을 알고 있다 => 데이터 접근 시 활용
      • 문서 DB도 구조선언을 하지만 문서가 한 단위 => 칼럼 패밀리 DB는 2차원(문서 DB와 차이)

    • 칼럼을 자유롭게 추가 가능

  • Case 1. 빅테이블

    • 일종으 두 단계로 된 맵
    • 칼럼 저장소라 부르기도 하는 데, 전혀 다른 의미
      • 칼럼 저장소: 칼럼 그룹을 저장하는 단위로만 사용.
      • 빅테이블 : 칼럼 그룹을 단위로 사용. => 이를 칼럼 패밀리 DB라 호칭.

  • Case 2. 카산드라

    • 좁은 행: 많은 행에 걸쳐 몇 개 안되는 동일한 칼럼
      • 칼럼 패밀리: 레코드 타입 정의
      • 각 행: 레코드
      • 각 칼럼: 필드
    • 넒은 행: 수 많은 칼럼을 가지고, 행마다 아주 다른 칼럼을 가짐.
      • 칼럼 패밀리: 리스트 모델을 만듦, 칼럼 정렬 순서 정의 가능
      • 각 칼럼: 리스트의 요소

+ Recent posts

티스토리툴바