10장. 유연하고 체계적
이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: translation-feedback@oreilly.com
관계형 데이터베이스의 강점 중 하나는 데이터 구조를 강제할 수 있다는 점입니다. 관계형 데이터베이스에서는 테이블을 정의하고 해당 테이블 내에 문자열, 날짜, 숫자와 같은 기본 데이터 유형을 적용하는 열을 정의한 다음 테이블 간의 관계를 정의하여 데이터를 제한합니다. 관계형 데이터베이스의 공용어인 SQL은 이렇게 잘 구조화된 관계형 데이터를 애플리케이션에서 소화할 수 있는 형식으로 변환하기 위한 도구입니다. 관계형 데이터베이스의 초창기에는 데이터 유형이 단순했고 사람들은 구조를 위해 관계형 데이터베이스를 찾았습니다. 이는 SQL:1999의 등장으로 바뀌기 시작했습니다. SQL:1999의 큰 도약은 유형이 기본 요소일 필요 없이 기본 요소의 복합체일 수도 있다는 점입니다. 이를 통해 테이블 열에 배열, 중첩 테이블, 심지어 사용자 정의 유형까지 저장할 수 있게 되었습니다. 네트워크, 암호화, 전체 텍스트 검색, 지리공간 애플리케이션 등을 지원하기 위해 특수 데이터 유형이 등장했습니다.
하지만 관계형 데이터베이스가 데이터를 구성하는 유일한 방법은 아닙니다. 다음은 관계형 모델에 대한 몇 가지 대안으로, 흔히 NoSQL 또는 Not-only-SQL 데이터베이스라고 합니다:
- 키/값 저장소
- 데이터는 키/값 쌍의 집합으로 저장되며, 여기서 키는 고유 식별자 역할을 합니다. 지원은 검색, 삽입, 수정 및 삭제로 제한되는 경우가 많습니다.
- 문서 저장소
- 이것은 파일 시스템과 유사합니다. 각 문서(레코드)는 그 자체로 복잡한 객체입니다. 저장 형식은 종종 독점적인 경우가 많으며 문서 간의 관계는 거의 또는 전혀 없습니다.
- 그래프 데이터베이스
- 이는 계층적 데이터 또는 네트워크 데이터를 구성하고 저장하는 간단한 방법입니다. 이진 트리, 회로도, 거리 지도를 생각해보세요. 데이터는 노드에 존재하고 엣지는 노드와 노드를 연결(연관)합니다.
- 와이드 컬럼 스토어
- 데이터는 열과 행에 저장되지만 열과 열의 이름은 행마다 다를 수 있습니다.
대부분의 NoSQL 데이터베이스의 공통점은 SQL:1992 이상의 표준을 지원하지 않는다는 것입니다. 또한 더 빠른 운영과 확장성을 위해 데이터 일관성과 데이터 무결성을 희생합니다. 반대로, NoSQL 운동에서 지적된 몇 가지 단점을 해결하기 위해 SQL 표준은 XML/XPath, JSON Path, JSON과 같은 비관계형 데이터 유형에 대한 지원을 점차적으로 추가해 왔습니다.