소프트웨어 프로젝트에서 특정 데이터 유형에 대해 선택할 DB

데이터베이스 유형만이 고려해야 할 유일한 주제는 아닙니다. 애플리케이션의 활성 사용자 수가 얼마나 되는지 등 고려해야 할 다른 많은 문제가 있습니다. 모든 곳에서 강력한 일관성이 필요한가요? 어떤 경우에는 최종적인 일관성으로 충분할까요? "깊이 들어가면 들어갈수록 더 복잡해진다"는 말처럼 정답이 없는 질문이 너무 많습니다. 따라서 이 글은 데이터베이스 유형에만 초점을 맞추고 있다는 점에 유의하시기 바랍니다.

커피 한 잔을 마시며 이 글을 읽어보세요.

일반 데이터베이스 분류

먼저 데이터베이스에는 관계형(SQL)과 비관계형(NoSQL)의 두 가지 주요 유형이 있다는 것을 알아두는 것이 좋습니다.

• SQL 데이터베이스는 관계형 방식으로 구조화되어 있으므로 테이블에 데이터를 저장하고 테이블 간의 관계를 유지합니다.
• 관계형 데이터베이스와 달리 NoSQL(Not only SQL) 데이터베이스는 구조화가 잘 되어 있지 않으므로 더 많은 적응성과 유연성을 허용합니다.

위에서 언급한 두 가지 유형 외에 인메모리 데이터베이스가 한 가지 더 있습니다. 이는 데이터가 물리적으로 저장되는 위치와 관련이 있기 때문에 관계형 또는 비관계형으로 분류할 수 없습니다. 모든 데이터베이스는 디스크나 메모리에 저장될 수 있습니다.

데이터베이스 유형

1. 관계형

제 생각에는 가장 인기 있는 데이터베이스 유형입니다. 레코드 간의 관계를 유지하려는 구조적 데이터에 잘 작동합니다. 데이터베이스 구조는 스키마로 설명됩니다.

주요 장점은 트랜잭션(데이터 무결성을 보장하고 ACID 규칙을 따르는 데 도움이 됨)과 많은 복잡한 쿼리를 처리할 수 있다는 점입니다.

언제 선택해야 하나요?

예를 들어 구조적으로 자주 변경되지 않고 영구적으로 저장해야 하는 데이터를 보관할 때 유용합니다:

• CRM(고객 관계 관리),
• 주문 관리,
• ERP (엔터프라이즈 리소스 계획),
• 데이터 웨어하우징 또는 재고 관리,
• 회계 또는 재무.

예시:

Amazon Aurora, Microsoft Azure SQL 데이터베이스, PostgreSQL, MySQL.

관계형 데이터베이스는 많은 새로운 애플리케이션에 충분하지 않으며 둘 이상의 데이터베이스가 필요합니다. 이 글의 다음 부분에서는 비관계형 데이터베이스에 대해 집중적으로 다뤄보겠습니다.

2. 키-값

각 데이터 값을 고유 키로 저장합니다. 즉, 해시 맵에서와 마찬가지로 단일 키로 데이터에 액세스합니다. 관계형 데이터베이스와 달리 스키마나 레코드 간의 관계를 강제하지 않습니다. 이러한 데이터베이스의 대부분은 일반적으로 업데이트 작업을 지원하지 않습니다. 데이터를 수정하려면 기존 집합 전체를 덮어써야 합니다.

언제 선택해야 하나요?

빠르게 읽기/쓰기하려는 데이터(자주 업데이트하지 않는 데이터)에 유용합니다:

• 실시간 입찰, 광고 게재,
• 데이터 캐싱,
• 세션 관리,
• 쇼핑 카트,
• 고객 기본 설정 또는 프로필 관리

예시:

멤캐시드, 아마존 다이너모DB, Azure 코스모스 DB, 레디스.

3. 문서

문서 모음을 저장합니다. 모든 문서에는 단순한 값일 수도 있고 목록이나 하위 컬렉션과 같은 복잡한 요소일 수도 있는 데이터가 있는 필드가 포함되어 있습니다. 모든 문서는 동일한 내용을 나타내더라도 서로 다른 구조를 가질 수 있다는 것을 아는 것이 중요합니다(각 문서는 고유하며 시간이 지남에 따라 진화합니다). 예를 들어 첫 번째 고객 문서에는 두 번째 문서보다 더 적은 정보가 포함되어 있습니다:

{
 "이름": "John",
 "LastName": "Fake",
 "Motorcycles:" [
  {
    "Model": "BMW",
    "Year": 2020
  }
 ]
}

{
 "이름": "Alex",
 "LastName": "노라스트네임",
 "Age": 15,
 "주소": {
    "국가": "폴란드",
    "도시": "어딘가"
  },
 "오토바이:" [
  {
    "Model": "BMW",
    "Year": 2020
  }
 ]
}

언제 선택해야 하나요?

빠른 처리를 위해 유연한 스키마가 필요한 데이터에 유용합니다:

• 제품 카탈로그,
• CMS(콘텐츠 관리 시스템),
• 사용자 프로필 및 개인화.

예시:

Amazon DocumentDB, Azure Cosmos DB, 몽고DB, Redis.

4. 그래프

그래프 구조를 사용하며 노드와 에지라는 두 가지 요소로 구성됩니다. 노드는 테이블 행 또는 JSON 문서와 유사합니다. 에지는 노드 간의 관계로 노드만큼이나 중요합니다. 둘 다 속성을 가질 수 있습니다. 또한 엣지는 정의된 관계의 방향을 가질 수 있습니다.

언제 선택해야 하나요?

데이터 항목 간의 관계가 동적이고 시간에 따라 변화하는 등 데이터가 그래프와 유사한 경우에 유용합니다. 또한 비즈니스 또는 기술적 팀 데이터 내의 관계를 이해해야 합니다. 몇 가지 대표적인 예는 다음과 같습니다:

• 조직 차트,
• 사기 탐지,
• 소셜 그래프/네트워킹,
• 추천 엔진,
• 지식 그래프.

예시:

아마존 넵튠, Neo4j, 아랑고DB, 타이탄.

5. 시계열

시간별로 정리된 데이터를 저장합니다. 일반적으로 엄청난 양의 데이터를 실시간으로 축적합니다. 데이터를 저장하는 데 가장 자주 사용되지만 업데이트하는 경우는 매우 드뭅니다. 일반적으로 타임스탬프는 기본 키 및/또는 정렬 데이터로 사용됩니다. 일부 데이터베이스에서는 데이터 출처나 유형과 같은 추가 정보로 태그를 정의할 수 있습니다.

언제 선택해야 하나요?

예를 들어 시간 순서대로 순차적으로 추가된 소량의 데이터를 저장할 때 유용합니다:

• DevOps,
• 애플리케이션 모니터링,
• 모니터링 및 이벤트 원격 분석,
• IoT 애플리케이션(예: 디바이스 센서의 데이터 수집).

예시:

Azure 시계열 인사이트, Amazon 타임스트림, InfluxDB.

6. 원장

중앙 기관이 소유한 불변의 투명하고 암호학적으로 검증 가능한 거래 로그를 제공합니다. - Amazon의 QLDB 개요

위 인용문의 모든 키워드에 대해 간략하게 설명해 보겠습니다:

• 불변 - 이 데이터베이스에서 생성된 레코드는 삭제, 수정 또는 덮어쓸 수 없음을 의미합니다,
• 투명성 - 데이터의 각 변경 사항을 추적하고 시퀀스 기록을 유지합니다,
• 암호화 검증 가능 - 이 데이터베이스에서 생성된 데이터는 블록체인과 유사한 암호화 해싱 기법(SHA-256 해시 함수 사용)으로 검증됩니다.

언제 선택해야 하나요?

다음과 같이 모든 데이터 변경 사항을 순차적으로 기록하는 등 정확한 이력을 저장하는 데 유용합니다:

• 재정(직불 또는 신용 거래 내역),
• 제조 (부품의 공급처 추적),
• 보험,
• 인사 및 급여,
• 소매,
• 공급망.

예시:

Amazon QLDB

결론

이 글의 제목에 제시된 질문에 대한 간단한 답은 없습니다. 올바른 데이터베이스를 선택하는 유일한 방법은 데이터에 대해 자세히 알아보는 것입니다. 질문에 답해 보세요: "애플리케이션이 어떤 종류의 데이터를 생성하는가?"라는 질문에 답하면 올바른 선택을 할 수 있습니다.

또한 비즈니스 요구사항과 애플리케이션 도메인을 잘 알고 있어야 합니다. 데이터를 어떻게 사용할 것인지, 어떤 쿼리를 데이터베이스로 보낼 것인지, 데이터를 보관, 읽기, 업데이트 또는 삭제할 횟수를 알아야 합니다. 이 모든 것이 중요하지만 모든 개발자가 이러한 영역에 충분한 주의를 기울이는 것은 아닙니다.

더 나은 소프트웨어를 개선하거나 만들기 위해 개발하는 애플리케이션의 데이터에 대해 생각해 보세요. 전반적으로 데이터를 잘 파악하여 데이터가 행복하게 보관될 수 있는 곳에 보관하시기 바랍니다.

자세히 읽어보세요:

JavaScript 애플리케이션 속도를 높이는 몇 가지 요령

Rails 성능을 향상하는 방법

외부 소프트웨어 개발 파트너와의 협력에 대한 사실과 오해