Skip to content

Latest commit

 

History

History
168 lines (120 loc) · 8.8 KB

File metadata and controls

168 lines (120 loc) · 8.8 KB

데이터베이스

정보기술의 역사

  • 데이터 스토리지의 증가
  • 데이터 계산 속도의 발전

SQL(시퀄)과 NoSQL

  • SQL은 관계형 데이터베이스 관리 시스템에서 사용하는 언어
  • NoSQL 데이터베이스에서 SQL이 사용되지 않는다를 의미하기도 하며 SQL만 있는게 아니다라는 뜻을 담고 있음

데이터베이스 설계

  • 애플리케이션의 성격이 다르면 데이터베이스 유형도 달라져야 함에 따라 데이터 관리 시스템이 발전
전자상거래 어플리케이션 - 키-값 쌍을 이용한 데이터 모델
예금 / 출금 거래 - 관계형 데이터베이스 (예금계좌에서 인출해 다시 출금계좌에 입금하느 것을 단일 작업 그룹을 묶을 수 있음)
  • 초기 데이터 관리 시스템에 있던 일부 특징이 NoSQL 데이터베이스에 다시 등장

초기 데이터베이스 관리 시스템

  • 플랫 파일 데이터 관리 시스템
    • 구조화된 데이터 세트를 파일 하나로 만들어서 디스크나 자기테이프 같은 장기기억 저장 장치에 저장하는 방식
    데이터 관리 - 플랫 파일
    스토리지 - 자기테이프
    
    • 시스템의 물리적 제약에 적응 필요
    • 자기테이프에 데이터를 저장하는 방식 중 블록 저장 방식
      • 블록을 순차적으로 두고 그 사이에 갭이 있는 형태로, 테이브 드라이브에 있는 기록 헤드로 블록에 쓰면 데이터가 저장, 헤드 위를 테이프가 지나가면서 데이터를 읽음
    • 순차적 접근 방식
      • 특정 블록에서 시작해 차례대로 다음 블록을 읽음
      고객의 이름, 주소, 전화번호를 관리
      
      • 이 방식은 테이브에서 이동하는 양에 비례해 읽을 데이터 양을 최적화
    • 무작위 접근 방식
      • 테이프의 다른 위치에 있는 데이터에 접근해야 할 필요가 있을 경우
      여러 고객의 주소를 찾을 때 테이프에서 서로 다른 위치로 이동할 수 있어야 함
      
      • 헤드로 데이터 블록을 읽는 이동거리가 짧을 수록 효율적
      • 디스크 드라이브에서 효율적
    • 한계
      • 플랫 파일을 사용하는 프로그램이 데이터의 구조를 결정
        • 고객 ID로 정렬한 형태로 파일 구조를 결정했다면
        • 새 고객을 추가할 때 효율적이지만
        • 알파벳 순으로 고객 이름을 정렬하는데 비효율적
        • 즉, 고객 ID이외에 다른 방식으로 데이터에 접근하는 것이 비효율적
      • 개발자의 목적에 따라 중복 데이터의 발생 (파일 구조가 변하면 프로그래머들은 새 구조에 맞춰 프로그램을 수정해야하기 때문에 다른 사람이 만든 파일을 사용하지 않으려 할 수 있음)
      • 데이터의 종류에 따라 보안 요구 사항이 달라지기 때문에 복수의 파일로 나눠 만들지만, 데이터가 파일 여러 개에 각각 저장되어 있다면 이들 데이터 간의 일관성을 유지하기 어려움
  • 계층형 데이터 관리 시스템

    • 검색할 때 비효율성을 부모-자식 관계의 계층 구조로 데이터를 구성하여 검색 문제를 해결
    1번째 이미지
    • 계층형 데이터 관리 시스템의 구조
      • 계층형 구조는 루트 노드에서 시작하며, 루트 노드는 데이터 노드의 최상위 계층 (top layer)에 연결되고, 최상위 계층 레코드는 자식 레코드를 갖음
      • 자식 레코드에는 부모 레코드에 대한 정보가 있음
      • 해당 고객의 레코드를 찾을 때 유용, 즉 부모하나에 자식이 여러개일 때도 가능
    • 한계
      • 고객 한 명에 대출한개나 대출 세건이나 관리는 쉽지만, 고객 두명이 동시에 한 건의 대출에 묶일 경우 문제 발생 (자식이 여러 부모를 두는 구조)
        • 두 고객의 대출 정보를 복제해야함. 데이터를 복제하기 위해 저장 공간을 비효율적으로 사용
        • 데이터 변경 사항을 제대로 관리하지 않는다면 모든 복사본의 데이터 간 일과성을 훼손
        • 데이터를 집계하면서 오류가 발생할 수 있음
  • 네트워크 데이터 관리 시스템

2번째 이미지

  • 레코드 간 링크를 사용한다는 점은 계층형 모델고 비슷하지만, 부모 레코드가 하나뿐이라는 제약은 없음
  • 스키마와 데이터베이스 두 가지 필수 요소를 갖고 있음
  • 구조
    • 네트워크는 서로 연결된 데이터 레코드로 구성되어 있음
      • 노드 : 데이터 레코드
      • 에지 : 연결정보
      • 그래프 : 노드와 에지의 묶음 그래프
    • 다대다(many-to-many) 관계 표현 가능
    • 단반향 에지
      • A는 B를 가질 수 있지만 , C와 D는 B를 가질 수 없음 A -> B ↓ ↓ C D
  • 한계
    • 설계와 관리가 어려움
    • 노드 연결 구조에 따라 프로그램이 필요한 데이터 노드에 도달하기까지 방문하는 링크 개수가 달라질 수 있음

관계형 데이터베이스

  • 데이터와 데이터 간의 관계를 묘사하기 위해 관계형 대수학을 사용하는 형식 수학 모델에 기반을 두고 있음

  • 데이터 구조의 논리 구성물리적인 저장 구조와 분리함

  • 애플리케이션 사용자들이 데이터를 읽고 추가하고 갱신고 삭제하는 것을 허용하는 다수의 프로그램으로 구성된 애플리케이션

  • 매번 새 파일이 생성된 곳에 플렛 파일 테이터가 저장되고 이 데이터를 관리하기 위해 프로그래머가 프로그램을 개발해야 하는 것과 달리, 데이터 관리에 공통 언어를 사용하도록 설계

  • 구조

    • RDBMS를 구현하기 위한 최소 요구 사항
      • 스토리지 관리 프로그램
      • 메모리 관리 프로그램
      • 데이터 사전
      • 질의 언어
    • 위의 네가지가 합쳐져 데이터관리와 데이터 조회 서비스 제공
    • 관계형 데이터베이스 관리 시스템을 사용하는 애플리케이션 구조
      • 사용자 인터페이스
        • 사용자의 작업 처리를 지원하려고 설계
      • 비즈니스 로직
        • 계산을 수행하고 비즈니스 규칙을 확인하는 프로그램의 한 부분
      • 데이터베이스 코드
        • 데이터베이스에서 작업을 수행할 때 쓰임
    • 한계
      • 대규모 사용자를 지원하는 기업의 등장으로 대용량 데이터의 읽기와 쓰기 작업, 빠른 응답 시간, 높은 가용성 이 중요해졌음
      • 데이터베이스가 느려지면 더 많은 CPU, 추가 메모리, 더 빠른 장치를 장착해서 문제를 해결했으며, 비용이 많이 든 임시방편에 불과함
      • 서버에 장착할 수 있는 CPU와 메모리 개수도 한계가 있었으며, 최후의 방안으로 정규화작업을 실천(데이터베이스 스키마를 재설계) ※데이터 이상현상이 발생할 위험을 감수

NoSQL

  • 확장성
  • 비용
  • 유연성
  • 가용성

수만, 혹은 그 이상의 사용자에게 서비스를 제공하는 웹 애플리케이션을 구현하기 위해

확장성

  • 스케일 업
    • 기존 데이터베이스 서버에 프로세서, 메모리, 네트워크 대역퐁을 추가하거나 데이터베이스 관리 시스템의 선능을 향상
  • 스케일 아웃
    • 트래픽 부하에 따라 서버를 추가하는 것
    • 스케일 업보다 유연
    • NoSQL 데이터베이스는 관리자의 간섭을 최소한으로 하며 클러스터 하나에 서버 여러 개를 이용하도록 설계됨

비용

NoSQL 데이터베이스들은 오픈 소스 형태로 제공

유연성

관계형 데이터베이스 설계자들은 프로젝트를 시작할 때 어플리케이션 지원에 필요한 모든 테이블과 컬럼을 파악해야하지만 NoSQL 데이터베이스는 고정된 테이블 구조가 필요하지 않다

가용성

서버 하나가 중지되거나 유지보수 목적으로 서비스가 불가능 할 때 같은 클러스터에 있는 다른 서버가 작업량 전체를 떠맡을 수 있음