Skip to content

Latest commit

 

History

History
71 lines (58 loc) · 5.64 KB

NoSQLvsSQL_MongoDB.md

File metadata and controls

71 lines (58 loc) · 5.64 KB

1. MongoDB에서 테이블을 동적으로 생성하는 것에 대한 생각

  • MongoDB에서는 테이블 대신 **컬렉션(Collection)**을 사용하며, 데이터를 삽입할 때 컬렉션이 자동으로 생성됩니다. 즉, 동적으로 컬렉션(테이블)을 생성하는 것이 자연스럽습니다.
  • 장점:
    • 유연성: 사전에 스키마를 정의하지 않고, 데이터를 저장할 때 컬렉션을 동적으로 생성할 수 있습니다.
    • 빠른 프로토타이핑: 데이터 구조가 자주 변하는 경우에도 쉽게 적응할 수 있어 빠르게 개발할 수 있습니다.
  • 단점:
    • 구조 관리 어려움: 컬렉션이 무분별하게 생성되면 데이터 구조 관리가 복잡해지고, 성능 최적화가 어려울 수 있습니다.
    • 성능 문제: 너무 많은 컬렉션이 생성되면 서버 부하가 커지고, 인덱스 관리도 복잡해질 수 있습니다.

2. MongoDB의 도큐먼트 중첩과 SQL 비교

  • MongoDB에서는 도큐먼트(Document) 안에 다른 도큐먼트를 중첩시킬 수 있습니다. 이는 SQL의 테이블 안에 테이블을 넣는 것과 비슷한 개념처럼 보일 수 있지만, 실제로는 SQL에서는 **조인(JOIN)**을 통해 관계를 관리합니다.
  • MongoDB의 도큐먼트 중첩은 데이터를 한 번의 쿼리로 쉽게 가져올 수 있고, 관련 데이터를 한곳에 저장할 수 있다는 장점이 있습니다. 반면, SQL은 테이블을 나누어 정규화한 후, 필요할 때 조인을 사용해 데이터를 연결합니다.

3. MongoDB와 SQL 용어 차이

MongoDB 용어 SQL 용어 설명
컬렉션 (Collection) 테이블 (Table) 유사한 데이터를 모아둔 그룹
도큐먼트 (Document) 레코드 (Row) 한 개의 데이터 단위, JSON과 유사한 형태로 저장
필드 (Field) 열 (Column) 각 도큐먼트나 레코드 내의 개별 데이터 항목
스키마리스(Schema-less) 고정 스키마 스키마를 정의하지 않고 자유롭게 데이터 추가/수정 가능 vs 고정된 구조 필요
  • MongoDB는 스키마리스로 유연하게 데이터를 저장할 수 있으며, 도큐먼트마다 서로 다른 필드 구조를 가질 수 있습니다. SQL은 고정된 스키마를 사용하여 모든 레코드가 동일한 구조를 따라야 합니다.

4. 스키마와 스키마리스

  • 스키마는 테이블의 구조와 제약 조건을 정의하는 설계도로, SQL 기반 DB는 고정된 스키마에 따라 데이터를 저장합니다. 즉, 테이블의 열과 데이터 타입이 미리 정의되어 있으며, 데이터 구조가 변경되면 스키마를 수정해야 합니다.
  • MongoDB와 같은 NoSQL DB스키마리스이므로, 도큐먼트가 자유롭게 서로 다른 구조를 가질 수 있으며, 데이터를 추가하거나 수정할 때 스키마 변경 없이 가능해 유연성을 제공합니다.

1. SQL 기반 데이터베이스에서의 스키마 예시

CREATE TABLE users (
    user_id INT PRIMARY KEY AUTO_INCREMENT,    -- 고유 ID (자동 증가)
    username VARCHAR(255) NOT NULL,            -- 사용자 이름 (NULL 불가)
    email VARCHAR(255) UNIQUE,                 -- 이메일 주소 (중복 불가)
    password VARCHAR(255) NOT NULL,            -- 비밀번호 (NULL 불가)
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,  -- 생성 날짜 (현재 시간 자동 입력)
    is_active BOOLEAN DEFAULT TRUE             -- 활성화 상태 (기본값 TRUE)
);

2. MongoDB에서의 스키마리스 구조 (NoSQL)

{
    "_id": 1,
    "username": "john_doe",
    "email": "john@example.com",
    "password": "hashed_password",
    "created_at": "2023-10-07T10:00:00Z",
    "is_active": true
}

{
    "_id": 2,
    "username": "jane_doe",
    "email": "jane@example.com",
    "address": "123 Main St",
    "phone": "555-1234",
    "is_active": false
}

5. 차원의 저주와 스키마리스의 유연성

  • **차원의 저주(Curse of Dimensionality)**는 데이터 차원이 많아질수록 발생하는 문제를 말합니다. SQL에서 MongoDB의 유연성을 따라가려면 수많은 열을 생성해야 하고, 이는 관리와 성능 측면에서 어려움을 초래할 수 있습니다.
  • MongoDB는 필요에 따라 필드를 추가하고 구조를 동적으로 변경할 수 있기 때문에, 차원의 저주 문제를 피하고 데이터 구조를 효율적으로 관리할 수 있습니다.
  • SQL에서는 정규화동적 속성 모델링 같은 방법을 통해 복잡한 데이터 구조를 관리하지만, 이러한 방식은 MongoDB의 유연성에 비해 복잡도가 높고 성능에도 영향을 미칠 수 있습니다.

결론:

MongoDB는 스키마리스 구조 덕분에 매우 유연하게 데이터를 저장하고 관리할 수 있지만, SQL은 고정된 스키마를 사용해 데이터 구조를 더 엄격하게 관리합니다. MongoDB의 도큐먼트 중첩과 같은 유연성을 SQL에서는 제공하기 어렵기 때문에, 많은 열을 추가하는 것이 필요할 수 있고, 이는 차원의 저주와 같은 문제로 이어질 수 있습니다.