데이터베이스 스케일 업 & 아웃

 

스케일업 : 단일 서버(하드웨어)의 성능을 증가시켜 더 많은 요청을 처리하는 방법

 

스케일아웃 : 동일한 사양의 새로운 서버(하드웨어)를 추가하는 방법

일반적으로, 스케일업을 할때에는 서비스 중단이나 추가적인 하드웨어 비용이 발생한다. 

RDBMS는 스케일 업을 하기위해서는 새로운 서버에 기존 서버의 데이터를 옮기고 데이터를 정리하는데 번거로운 작업이 필요함.

반면, NoSQL은 처음부터 스케일 아웃을 염두에 두고 설계되었기때문에 데이터의 증가나 요청량이 증가하더라도 비슷한 사양의 새로운 하드웨어를 추가하면 문제가없음.

 

 

 

Horizontal Scaling (Scale-Out)

• What It Is: Horizontal scaling involves adding more machines (or nodes) to the system and distributing the load across them. In the context of databases, this means distributing the data and queries across multiple servers.
• Challenges for RDBMS:
  • Data Distribution: RDBMS are designed with a single-node architecture in mind. Distributing relational data across multiple nodes requires sharding, which can be complex. Sharding splits the database into smaller, more manageable pieces (shards) that are distributed across multiple servers, but it requires careful management to maintain consistency and performance.
  • ACID Compliance: Ensuring ACID properties across multiple nodes is difficult. For example, ensuring strong consistency and isolation of transactions across distributed nodes can lead to increased complexity and performance trade-offs.
  • Complex Queries: SQL queries, especially those involving joins, aggregates, and complex transactions, are harder to execute efficiently when data is spread across multiple nodes.
  • Synchronization: Keeping data synchronized across nodes can introduce latency and requires sophisticated algorithms to handle replication and consistency.
  • Increased Complexity: Managing multiple nodes, dealing with node failures, and ensuring that all nodes have the correct data adds significant operational complexity.

Scale-Out Solutions in RDBMS

Despite the challenges, some modern RDBMS have introduced features to facilitate horizontal scaling:

• Sharding: Some RDBMS support sharding natively, allowing for horizontal distribution of data across multiple servers. However, this often requires careful planning and may not work well for all types of workloads.
• Replication: Many RDBMS support replication (e.g., master-slave or master-master setups), which can help distribute read workloads across multiple servers. However, write operations still generally occur on a single master node, which can become a bottleneck.
• Distributed SQL Databases: Some newer systems, like Google Spanner, CockroachDB, and YugabyteDB, are designed to support SQL queries and ACID transactions while being distributed across multiple nodes. These systems are designed to scale out more easily than traditional RDBMS.

 

Understanding DB I/O Bottlenecks

1. I/O Operations in Databases:
   • Disk I/O: Databases frequently read from and write to disk storage. These I/O operations can become bottlenecks, particularly when the disk cannot keep up with the volume of read/write requests.
   • Network I/O: If the database is distributed or interacts with other services over a network, network bandwidth can also be a limiting factor, especially when transferring large volumes of data.
2. Disk I/O Bottlenecks:
   • Storage Speed: Traditional spinning hard drives (HDDs) have slower read/write speeds compared to solid-state drives (SSDs). If a database relies on slower storage, the I/O operations may become a bottleneck, leading to slower query responses and reduced throughput.
   • Throughput and Latency: The storage device's throughput (the amount of data that can be read or written per unit of time) and latency (the time it takes to start a data transfer) are critical factors. SSDs generally offer lower latency and higher throughput compared to HDDs, making them better suited for I/O-intensive workloads.
   • I/O Contention: When multiple processes or queries try to access the disk simultaneously, I/O contention can occur, where processes are forced to wait for access to the disk, leading to performance degradation.
3. Network I/O Bottlenecks:
   • Bandwidth Limitations: If the database is distributed across multiple nodes or interacts heavily with external systems, the available network bandwidth can become a bottleneck. This is particularly true for operations that involve transferring large datasets or frequent communication between nodes.
   • Latency: Network latency, the time it takes for data to travel between nodes, can also impact performance, particularly in distributed databases or cloud-based systems where data might be stored in different regions.

 

데이터베이스 인프라 확장

파티셔닝 : 데이터베이스의 테이블을 더 작은 테이블로 나누는 것

• vertical partitioning : column을 대상으로 테이블을 나누는 것
  • 정규화라는 것은 결국 중복되는 데이터를 막기 위해서 column을 기준으로 간소화시켜 나누는 것이기때문에 vertical partitioning이라고 할 수 있음.
  • 데이터베이스 쿼리라는 것은 어떤 column을 select하던 간에 전체 record를 선택한 후에 거기서 필요한 column을 선택하는 방식으로 동작하기 때문에 사용하지않는 column의 경우 쿼리양상에 따라서  vertical partioning을 하는 것이 쿼리효율적임.
• horizontal particioning : row를 대상으로 테이블을 나누는 것
  
  • 데이터양이 증가할 수록 이에 비례하여 Index의 크기와 query의 속도가 증가하기때문에 이를 방지하기 위하여 row를 분류하여 테이블을 나누는 행위를 함. (ex : 알파벳 순서로 분할, Id를 Hash값으로 변환하여 Hash값에 따른 분할)

샤딩 : Row를 기준으로 테이블을 나누는데, 각 나눠진 테이블이 서로 다른 DB에 저장됨, 이는 DB서버의 부하를 분산시키기 위한 목적임

 

 

1. 샤딩(Sharding)

• 데이터를 여러 **서버(노드)**에 분산 저장하는 기술입니다.
• 목적: 데이터의 크기와 트래픽을 여러 서버로 분산시켜 확장성을 높이고 부하를 줄이는 것.
• 작동 방식:
  • 데이터를 나눌 때 특정 **샤드 키(Shard Key)**를 기준으로 데이터를 분배.
  • 각 샤드는 독립된 데이터베이스처럼 동작하며, 서로 다른 물리적 서버에 저장됨.
  • 샤드 간에는 데이터가 중복되지 않으며, 한 샤드에만 데이터가 저장됨.

예시

• Shard 1: User ID 1~100 Shard 2: User ID 101~200 Shard 3: User ID 201~300
  • 특정 사용자 데이터를 조회할 때, 해당 샤드에만 접근합니다.

장점

1. 수평 확장(Scale-out) : 데이터와 트래픽이 증가하면 새로운 샤드를 추가하여 처리.
2. 독립적 관리 : 각 샤드는 독립적으로 작동하므로, 특정 샤드에 장애가 발생해도 다른 샤드에 영향을 미치지 않음.

단점

1. 복잡성 증가 : 샤드 간 데이터 분배와 라우팅을 관리해야 하므로 설계와 운영이 복잡.
2. 샤드 키 설계 중요 : 잘못된 샤드 키를 선택하면 특정 샤드에만 데이터가 몰리는 샤드 불균형 발생.

 

2. 파티셔닝(Partitioning)

• 데이터를 하나의 데이터베이스 내에서 논리적으로 나누는 방법입니다.
• 목적 : 테이블 크기를 줄여 쿼리 성능을 최적화하고, 대규모 데이터의 관리 효율성을 높이는 것.
• 작동 방식:
  • 데이터를 나눌 때 **파티션 키(Partition Key)**를 기준으로 데이터베이스의 테이블을 나눔.
  • 모든 파티션은 같은 데이터베이스(혹은 서버) 내에 존재.
  • 물리적으로 데이터를 나누지 않고, 논리적으로만 구분.

예시 RDBMS(MySQL, PostgreSQL 등): id 값에 따라 데이터를 파티션 p1, p2, p3로 나눔.

장점

1. 쿼리 최적화: 특정 파티션에만 쿼리를 실행하므로, 대규모 테이블에서 쿼리 성능 향상.
2. 관리 효율성 : 파티션별 데이터 삭제나 백업이 용이.

단점

1. 단일 서버 한계 : 데이터가 여전히 하나의 데이터베이스에 저장되므로, 수평 확장에는 적합하지 않음.
2. 파티션 설계 필요 : 잘못된 파티션 키로 인해 특정 파티션에 데이터가 몰리면 성능 저하.

---

3. 샤딩과 파티셔닝의 차이

데이터 분산 범위	여러 서버(노드) 간 데이터 분산	단일 데이터베이스 내 데이터 분산
목적	수평 확장과 부하 분산	쿼리 성능 최적화와 데이터 관리 효율성
물리적/논리적 구분	물리적으로 여러 서버에 저장	논리적으로 데이터베이스 내에 저장
데이터 저장 위치	각 샤드는 독립적인 서버	모든 파티션은 하나의 데이터베이스에 존재
확장성	수평 확장 가능 (노드 추가)	수직 확장에 의존 (서버 업그레이드 필요)
운영 복잡성	샤드 키 설계 및 라우팅 관리가 필요	상대적으로 간단

---

 

 

 

레플리케이션 : DB서버의 데이터를 그대로 동작을 복사하여 sync를 맞추고 본 DB서버가 문제가 발생했을때 백업DB로 동작함. read문 같은 경우에는 백업DB에 분산하여 과부하를 막을 수 있다.