[database] NoSQL
NoSQL Database?
관계형 데이터베이스랑 다르게 스키마도, 관계도 없다. NoSQL에서는 레코드를 문서(documents)라고 부른다. SQL은 정해진 스키마를 따르지 않으면 데이터 추가가 불가능했다. 하지만 NoSQL에서는 다른 구조의 데이터를 같은 컬렉션에 추가가 가능하다. 문서(documents)는 Json과 비슷한 형태로 가지고 있다. 관계형 데이터베이스처럼 여러 테이블에 나누어담지 않고, 관련 데이터를 동일한 ‘컬렉션’에 넣는다. 여러 테이블에 조인할 필요없이 이미 필요한 모든 것을 갖춘 문서를 작성하는 것이 NoSQL이다. NoSQL에는 조인이라는 개념이 존재하지 않는다.
그러면 조인하고 싶을 때 NoSQL은 어떻게 할까?
컬렉션을 통해 데이터를 복제하여 각 컬렉션 일부분에 속하는 데이터를 정확하게 산출하도록 한다.
하지만 이러면 데이터가 중복되어 서로 영향을 줄 위험이 있다. 따라서 조인을 잘 사용하지 않고 자주 변경되지 않는 데이터일 때 NoSQL을 쓰면 상당히 효율적이다.
SQL vs NoSQL
어느것을 써야하는 정답은 없다. 필요에 따라 적절하게 선택해 사용한다.
| 관계형 데이터베이스 | NoSQL 데이터베이스 | |
|---|---|---|
| 최적의 워크로드 | 관계형 데이터베이스는 일관성이 뛰어난 온라인 트랜잭션 프로세싱(OLTP) 애플리케이션을 위해 설계되어 온라인 분석 프로세싱(OLAP)에 적합합니다. | NoSQL 데이터베이스는 낮은 지연 시간의 애플리케이션을 포함한 수많은 데이터 액세스 패턴에 맞도록 설계되었습니다. NoSQL 검색 데이터베이스는 반정형 데이터에서 분석을 위해 설계되었습니다 |
| 데이터 모델 | 관계형 모델은 데이터를 행과 열로 구성된 테이블로 정규화합니다. 스키마는 테이블, 행, 열, 인덱스, 테이블 간 관계, 기타 데이터베이스 요소를 정확하게 규정합니다. 데이터베이스는 테이블 사이의 관계에서 참조 무결성을 실현합니다. | NoSQL 데이터베이스는 키-값, 문서, 그래프 등 성능과 규모 확장에 최적화된 다양한 데이터 모델을 제공합니다. |
| ACID 속성 | 관계형 데이터베이스는 원자성, 일관성, 고립성 및 지속성(ACID, atomicity, consistency, isolation, and durability)의 속성을 제공합니다: 원자성은 완벽하게 실행하거나 혹은 전혀 실행하지 않는 트랜잭션을 필요로 합니다. 일관성은 트랜잭션이 커밋되면 데이터가 데이터베이스 스키마를 준수하도록 요구합니다. 고립성은 동시에 일어나는 트랜잭션들이 각기 별도로 실행되어야 함을 의미합니다. 지속성은 예기치 못한 시스템 장애 또는 정전 시 마지막으로 알려진 상태로 복구하는 기능을 필요로 합니다. |
NoSQL 데이터베이스는 흔히 수평으로 확장할 수 있는 보다 유연한 데이터 모델을 위해 관계형 데이터베이스의 일부 ACID 속성을 완화함으로써 조정합니다. 이로써 NoSQL 데이터베이스는 단일 인스턴스의 한계를 넘어 수평으로 확장해야 하는 사용 사례에서 높은 처리량, 낮은 지연 시간을 위한 탁월한 선택이 됩니다. |
| 성능 | 성능은 일반적으로 디스크 하위 시스템에 따라 다릅니다. 최고 성능을 달성하기 위해서는 쿼리, 인덱스 및 테이블 구조를 자주 최적화해야 합니다. | 성능은 일반적으로 기본 하드웨어 클러스터 크기, 네트워크 지연 시간 및 호출 애플리케이션의 기능입니다. |
| 확장 | 관계형 데이터베이스는 일반적으로 하드웨어의 계산 성능을 높이거나 읽기 전용 워크로드의 복제물을 추가함으로써 확장됩니다. | NoSQL 데이터베이스는 일반적으로 거의 무제한적인 범위에서 일관된 성능을 제공하는 처리량 제고를 위해 분산형 아키텍처를 사용해 액세스 패턴이 확장 가능하기 때문에 분할성이 있습니다. |
| API | 데이터를 저장 및 검색하기 위한 요청은 SQL(구조화 질의 언어)을 준수하는 쿼리를 사용하여 전달됩니다. 쿼리는 관계형 데이터베이스에 의해 구문 분석되고 실행됩니다. | 객체 기반 API를 통해 앱 개발자가 데이터 구조를 쉽게 저장 및 검색할 수 있습니다. 파티션 키를 사용하면 앱에서 키-값 페어, 열 세트 또는 일련의 앱 객체 및 속성을 포함하는 반정형 문서를 검색할 수 있습니다. |
| SQL | MongoDB(NoSQL) |
|---|---|
| 테이블 | 컬렉션 |
| 열 | 도큐먼트 |
| 컬럼 | 필드 |
| 기본 키 | ObjectId |
| 인덱스 | 인덱스 |
| 보기 | 보기 |
| 중첩된 테이블 또는 객체 | 포함 문서 |
| 배열 | 배열 |
SQL의 장단점
- 장점
- 명확히 정의된 스키마로 데이터 무결성 보장
- 관계를 이용해 데이터를 중복없이 저장
- 단점
- NoSQL에 비해 덜 유연하며 데이터 스키마를 미리 알고 정의해야 한다.
- Join으로 인해 복잡한 쿼리가 발생할 수 있다.
- Scale-up 방식으로만 확장 가능하다.
NoSQL의 장단점
- 장점
- 정의된 스키마가 없기 때문에 유연성이 뛰어나다.
- 데이터는 json 형태로 애플리케이션이 필요한 형식으로 저장되기 때문에 조회하는 속도가 빠르다.
- Scale-out 방식으로 확장이 가능하다.
- 단점
- 복제된 데이터에 변경이 생기면 여러 컬렉션과 도큐멘트를 수정해야 한다.
SQL 사용이 더 좋은 경우
- 관계를 맺고 있는 데이터가 자주 변경될 떄
- 스키마 변경이 없고 명확한 스키마가 필요할 때
NoSQL 사용이 더 좋은 경우
- 정확한 데이터 구조를 알 수 없거나 변경이나 확장이 필요할 때
- 조회는 많이 하지만 변경이 적은 경우
- 데이터베이스를 수평적(scale-out)으로 확장해야하는 경우
도큐먼트 작성법
shell을 이용해 도큐먼트를 조회하거나 업데이트 할 때, JSON형식으로 출력된다. JSON 형식으로 도큐먼트를 작성하기 위해서는 다음과 같은 조건을 만족해야 한다.
- {} 중괄호로 도큐먼트가 시작하고, 끝나야 합니다.
- 필드와 값이 콜론(:)으로 분리되어야 하며, 필드와 값을 포함하는 쌍은 쉼표(,)로 구분됩니다.
- 문자열인 필드도 쌍따옴표(““)로 감싸야 합니다.
// JSON을 이용한 올바른 도큐먼트 작성 예시
{
"_id" : "408339803",
"date" : ISODate("2019-02-04T05:00:00Z"),
"listing_id" : "1038163",
"reviewer_id" : "3600539"
"reviewer_name" : "Ibrahim"
}
JSON 형식은 읽기 쉽고 사용하기 편리하지만 파싱이 느리고 메모리 사용이 비효율적이다. 그리고 JSON은 기본 데이터 타입만 지원하기 때문에, 사용할 수 있는 데이터 타입에 제약이 있다. 그래서 BSON 형식이 도입됐다.
BSON은 컴퓨터 언어에 가까운 이진법에 기반을 둔 표현법이다. 따라서 JSON보다 메모리 사용이 효율적이고 빠르고 가볍고 유연하다. 또한 더 많은 데이터 타입을 사용할 수 있다. MongoDB는 JSON형식으로 작성된 것은 무엇이든 데이터베이스에 추가할 수 있고, 쉽게 조회할 수 있다. 그러나 그 내부에서는 BSON으로 데이터를 저장, 사용하고 있다.
MongoDB
CREATE
- show collections
- db.컬렉션이름.insert()
- db.컬렉션이름.find()
READ
- show dbs
- db.컬렉션이름.find().count()
- db.컬렉션이름.find()
- cursor.pretty() - cursor는 find 메소드를 실행해서 얻어낸 결과의 집합
- db.컬렉션이름.findOne()
UPDATE
- db.컬렉션이름.updateOne()
- db.컬렉션이름.updateMany()
- 연산자
- $inc
- $set
- $push
DELETE
비교 연산자
- $eq
- $gt
- $gte
- $ne
- $lt
- $lte
논리 연산자
- $and
- $or
- $nor
- $not