정보기술의 역사
- 데이터 스토리지의 증가
- 데이터 계산 속도의 발전
SQL(시퀄)과 NoSQL
- SQL은 관계형 데이터베이스 관리 시스템에서 사용하는 언어
- NoSQL 데이터베이스에서 SQL이 사용되지 않는다를 의미하기도 하며 SQL만 있는게 아니다라는 뜻을 담고 있음
데이터베이스 설계
- 애플리케이션의 성격이 다르면 데이터베이스 유형도 달라져야 함에 따라 데이터 관리 시스템이 발전
전자상거래 어플리케이션 - 키-값 쌍을 이용한 데이터 모델
예금 / 출금 거래 - 관계형 데이터베이스 (예금계좌에서 인출해 다시 출금계좌에 입금하느 것을 단일 작업 그룹을 묶을 수 있음)
- 초기 데이터 관리 시스템에 있던 일부 특징이 NoSQL 데이터베이스에 다시 등장
- 플랫 파일 데이터 관리 시스템
- 구조화된 데이터 세트를 파일 하나로 만들어서 디스크나 자기테이프 같은 장기기억 저장 장치에 저장하는 방식
데이터 관리 - 플랫 파일 스토리지 - 자기테이프- 시스템의 물리적 제약에 적응 필요
- 자기테이프에 데이터를 저장하는 방식 중 블록 저장 방식
- 블록을 순차적으로 두고 그 사이에 갭이 있는 형태로, 테이브 드라이브에 있는 기록 헤드로 블록에 쓰면 데이터가 저장, 헤드 위를 테이프가 지나가면서 데이터를 읽음
- 순차적 접근 방식
- 특정 블록에서 시작해 차례대로 다음 블록을 읽음
고객의 이름, 주소, 전화번호를 관리- 이 방식은 테이브에서 이동하는 양에 비례해 읽을 데이터 양을 최적화
- 무작위 접근 방식
- 테이프의 다른 위치에 있는 데이터에 접근해야 할 필요가 있을 경우
여러 고객의 주소를 찾을 때 테이프에서 서로 다른 위치로 이동할 수 있어야 함- 헤드로 데이터 블록을 읽는 이동거리가 짧을 수록 효율적
- 디스크 드라이브에서 효율적
- 한계
- 플랫 파일을 사용하는 프로그램이 데이터의 구조를 결정
- 고객 ID로 정렬한 형태로 파일 구조를 결정했다면
- 새 고객을 추가할 때 효율적이지만
- 알파벳 순으로 고객 이름을 정렬하는데 비효율적
- 즉, 고객 ID이외에 다른 방식으로 데이터에 접근하는 것이 비효율적
- 개발자의 목적에 따라 중복 데이터의 발생 (파일 구조가 변하면 프로그래머들은 새 구조에 맞춰 프로그램을 수정해야하기 때문에 다른 사람이 만든 파일을 사용하지 않으려 할 수 있음)
- 데이터의 종류에 따라 보안 요구 사항이 달라지기 때문에 복수의 파일로 나눠 만들지만, 데이터가 파일 여러 개에 각각 저장되어 있다면 이들 데이터 간의 일관성을 유지하기 어려움
- 플랫 파일을 사용하는 프로그램이 데이터의 구조를 결정
-
계층형 데이터 관리 시스템
- 검색할 때 비효율성을 부모-자식 관계의 계층 구조로 데이터를 구성하여 검색 문제를 해결
- 계층형 데이터 관리 시스템의 구조
- 계층형 구조는 루트 노드에서 시작하며, 루트 노드는 데이터 노드의 최상위 계층 (top layer)에 연결되고, 최상위 계층 레코드는 자식 레코드를 갖음
- 자식 레코드에는 부모 레코드에 대한 정보가 있음
- 해당 고객의 레코드를 찾을 때 유용, 즉 부모하나에 자식이 여러개일 때도 가능
- 한계
- 고객 한 명에 대출한개나 대출 세건이나 관리는 쉽지만, 고객 두명이 동시에 한 건의 대출에 묶일 경우 문제 발생 (자식이 여러 부모를 두는 구조)
- 두 고객의 대출 정보를 복제해야함. 데이터를 복제하기 위해 저장 공간을 비효율적으로 사용
- 데이터 변경 사항을 제대로 관리하지 않는다면 모든 복사본의 데이터 간 일과성을 훼손
- 데이터를 집계하면서 오류가 발생할 수 있음
- 고객 한 명에 대출한개나 대출 세건이나 관리는 쉽지만, 고객 두명이 동시에 한 건의 대출에 묶일 경우 문제 발생 (자식이 여러 부모를 두는 구조)
-
네트워크 데이터 관리 시스템
- 레코드 간 링크를 사용한다는 점은 계층형 모델고 비슷하지만, 부모 레코드가 하나뿐이라는 제약은 없음
- 스키마와 데이터베이스 두 가지 필수 요소를 갖고 있음
- 구조
- 네트워크는 서로 연결된 데이터 레코드로 구성되어 있음
- 노드 : 데이터 레코드
- 에지 : 연결정보
- 그래프 : 노드와 에지의 묶음 그래프
- 다대다(many-to-many) 관계 표현 가능
- 단반향 에지
- A는 B를 가질 수 있지만 , C와 D는 B를 가질 수 없음 A -> B ↓ ↓ C D
- 네트워크는 서로 연결된 데이터 레코드로 구성되어 있음
- 한계
- 설계와 관리가 어려움
- 노드 연결 구조에 따라 프로그램이 필요한 데이터 노드에 도달하기까지 방문하는 링크 개수가 달라질 수 있음
-
데이터와 데이터 간의 관계를 묘사하기 위해 관계형 대수학을 사용하는 형식 수학 모델에 기반을 두고 있음
-
데이터 구조의 논리 구성을 물리적인 저장 구조와 분리함
-
애플리케이션 사용자들이 데이터를 읽고 추가하고 갱신고 삭제하는 것을 허용하는 다수의 프로그램으로 구성된 애플리케이션
-
매번 새 파일이 생성된 곳에 플렛 파일 테이터가 저장되고 이 데이터를 관리하기 위해 프로그래머가 프로그램을 개발해야 하는 것과 달리, 데이터 관리에 공통 언어를 사용하도록 설계
-
구조
- RDBMS를 구현하기 위한 최소 요구 사항
- 스토리지 관리 프로그램
- 메모리 관리 프로그램
- 데이터 사전
- 질의 언어
- 위의 네가지가 합쳐져 데이터관리와 데이터 조회 서비스 제공
- 관계형 데이터베이스 관리 시스템을 사용하는 애플리케이션 구조
- 사용자 인터페이스
- 사용자의 작업 처리를 지원하려고 설계
- 비즈니스 로직
- 계산을 수행하고 비즈니스 규칙을 확인하는 프로그램의 한 부분
- 데이터베이스 코드
- 데이터베이스에서 작업을 수행할 때 쓰임
- 사용자 인터페이스
- 한계
- 대규모 사용자를 지원하는 기업의 등장으로 대용량 데이터의 읽기와 쓰기 작업, 빠른 응답 시간, 높은 가용성 이 중요해졌음
- 데이터베이스가 느려지면 더 많은 CPU, 추가 메모리, 더 빠른 장치를 장착해서 문제를 해결했으며, 비용이 많이 든 임시방편에 불과함
- 서버에 장착할 수 있는 CPU와 메모리 개수도 한계가 있었으며, 최후의 방안으로 정규화작업을 실천(데이터베이스 스키마를 재설계) ※데이터 이상현상이 발생할 위험을 감수
- RDBMS를 구현하기 위한 최소 요구 사항
- 확장성
- 비용
- 유연성
- 가용성
수만, 혹은 그 이상의 사용자에게 서비스를 제공하는 웹 애플리케이션을 구현하기 위해
- 스케일 업
- 기존 데이터베이스 서버에 프로세서, 메모리, 네트워크 대역퐁을 추가하거나 데이터베이스 관리 시스템의 선능을 향상
- 스케일 아웃
- 트래픽 부하에 따라 서버를 추가하는 것
- 스케일 업보다 유연
- NoSQL 데이터베이스는 관리자의 간섭을 최소한으로 하며 클러스터 하나에 서버 여러 개를 이용하도록 설계됨
NoSQL 데이터베이스들은 오픈 소스 형태로 제공
관계형 데이터베이스 설계자들은 프로젝트를 시작할 때 어플리케이션 지원에 필요한 모든 테이블과 컬럼을 파악해야하지만 NoSQL 데이터베이스는 고정된 테이블 구조가 필요하지 않다
서버 하나가 중지되거나 유지보수 목적으로 서비스가 불가능 할 때 같은 클러스터에 있는 다른 서버가 작업량 전체를 떠맡을 수 있음