샤딩: 두 판 사이의 차이
편집 요약 없음 |
편집 요약 없음 |
||
| (같은 사용자의 중간 판 하나는 보이지 않습니다) | |||
| 9번째 줄: | 9번째 줄: | ||
반면 수평 파티셔닝은 테이블을 수평으로 자르는 것이다. 즉 스키마 자체는 그대로 두고 레코드를 나눠서 분산 저장하는 거 있다. 예를 들어서 기존의 테이블에 1억 명의 고객 정보가 저장되어 있다면 이를 100만 명 단위로 잘라서 100개 테이블로 만드는 것이다. 그리고 앞으로 새로 저장할 고객 정보들은 적절한 방법을 통해서 이 100개 테이블에 고르게 분산시킬 것이다. 수평 파티셔닝은 스키마는 변하지 않고 테이블의 갯수만 늘어난다. | 반면 수평 파티셔닝은 테이블을 수평으로 자르는 것이다. 즉 스키마 자체는 그대로 두고 레코드를 나눠서 분산 저장하는 거 있다. 예를 들어서 기존의 테이블에 1억 명의 고객 정보가 저장되어 있다면 이를 100만 명 단위로 잘라서 100개 테이블로 만드는 것이다. 그리고 앞으로 새로 저장할 고객 정보들은 적절한 방법을 통해서 이 100개 테이블에 고르게 분산시킬 것이다. 수평 파티셔닝은 스키마는 변하지 않고 테이블의 갯수만 늘어난다. | ||
이러한 파티셔닝은 기본적으로 같은 [[데이터베이스]] 안에서 테이블을 쪼개는 방식으로 구현이 되는데 샤딩은 한 발 더 나아가서 아예 [[데이터베이스]]를 분리시키는 것이다. 즉 파티셔닝을 통해서 한 개 테이블을 두 개로 분할했을 때 각각의 테이블을 물리적으로 다른 [[데이터베이스]] 서버에 배치할 수도 있다. [[관계형 데이터베이스]]는 그 특성 때문에 수평적인 확장이 어려운데, 이를 구현할 수 있는 방법으로 널리 쓰이고 있다. 다만 이렇게 해도 수평적인 확장에는 근본적인 한계가 있기 때문에 수평적 확장이 중요한 [[데이터베이스]] 구축 환경이라면 결국은 [[NoSQL]] 계열을 고려하게 된다. | 이러한 파티셔닝은 기본적으로 같은 [[데이터베이스]] 안에서 테이블을 쪼개는 방식으로 구현이 되는데 샤딩은 한 발 더 나아가서 아예 [[데이터베이스]]를 분리시키는 것이다. 즉 파티셔닝을 통해서 한 개 테이블을 두 개로 분할했을 때 각각의 테이블을 물리적으로 다른 [[데이터베이스]] 서버에 배치할 수도 있다. [[관계형 데이터베이스]]는 그 특성 때문에 수평적인 확장이 어려운데, 이를 구현할 수 있는 방법으로 널리 쓰이고 있다. 다만 이렇게 해도 수평적인 확장에는 근본적인 한계가 있기 때문에<ref>질의를 할 때 해당 레코드가 어느 서버에 있는지 찾아줄 서버가 있어야 하며, 질의에 해당하는 레코드가 여러 서버에 걸쳐 있다면 일이 복잡해진다. 여러 테이블을 사용하는 JOIN 연산까지 가면 더더욱 복잡해진다. 예를 들어 서로 다른 서버에 있는 두 테이블의 JOIN 연산을 해야 한다면 서버 간에 통신을 해야 하는데 같은 서버 안에 두 테이블이 모두 있을 때보다 어마어마하게 느려진다. 만약 같은 테이블이 샤딩으로 여러 서버에 퍼져 있다면 그야말로 노답. [[NoSQL]]이 조인 연산을 지원하지 않는 것도, 데이터가 여러 서버에 퍼져 있을 경우에 답이 안 나오니 그냥 데이터를 중복 저장하라는 것이다.</ref> 수평적 확장이 중요한 [[데이터베이스]] 구축 환경이라면 결국은 [[NoSQL]] 계열을 고려하게 된다. | ||
{{각주}} | |||
[[Category:데이터베이스]] | [[Category:데이터베이스]] | ||
2021년 10월 15일 (금) 03:46 기준 최신판
Sharding.
데이터베이스를 수평으로 확장하는 기법 중 하나다.
데이터베이스의 능력을 확장하는 방법은 크게 수직적 방법과 수평적 방법이 있다. 수직적인 방법은 물리적인 서버의 개수는 그대로 두고 서버의 능력을 확장하는 것이다 즉 하드웨어 업그레이드 하든가 저장장치를 더 큰 것을 바꾸든가 하는 것이다. 반면 수평적인 확장 방법은 물리적인 서버의 갯수를 늘려서 서버의 부하를 분산시키는 방법이다. 수평적인 확장 방법은 다시 크게 두 가지 방법으로 나뉘는데 하나는 수직 파티셔닝(vertical partitioning)이고 다른 하나는 수평 파티셔닝이다. 둘 다 덩치 큰 하나의 테이블을 두 개 또는 그 이상으로 쪼개서 분산시키는 것이다. 따라서 수직 파티셔닝은 스키마에 변화가 온다.
수직 파티셔닝은 예를 들어 고객 정보 테이블이 고객의 아이디, 이메일 주소, 우편 주소, 전화번호와 같은 정보를 담고 있다면 수직 파티셔닝은 이 중 우편 주소와 전화번호를 별도의 테이블로 분리시키는 식이다. 분리된 테이블은 기존 테이블의 고유 키를 가지고 있으며 이를 통해 JOIN 연산 같은 방법으로 기존 테이블과 결합해서 쓸 수 있을 것이다. 테이블을 스프레드시트와 같은 개념으로 본다면 스프레드시트를 수직으로, 즉 열을 자르는 것이다. 수직 파티셔닝은 테이블의 갯수가 늘어나는 것은 물론 스키마에도 변화가 온다.
반면 수평 파티셔닝은 테이블을 수평으로 자르는 것이다. 즉 스키마 자체는 그대로 두고 레코드를 나눠서 분산 저장하는 거 있다. 예를 들어서 기존의 테이블에 1억 명의 고객 정보가 저장되어 있다면 이를 100만 명 단위로 잘라서 100개 테이블로 만드는 것이다. 그리고 앞으로 새로 저장할 고객 정보들은 적절한 방법을 통해서 이 100개 테이블에 고르게 분산시킬 것이다. 수평 파티셔닝은 스키마는 변하지 않고 테이블의 갯수만 늘어난다.
이러한 파티셔닝은 기본적으로 같은 데이터베이스 안에서 테이블을 쪼개는 방식으로 구현이 되는데 샤딩은 한 발 더 나아가서 아예 데이터베이스를 분리시키는 것이다. 즉 파티셔닝을 통해서 한 개 테이블을 두 개로 분할했을 때 각각의 테이블을 물리적으로 다른 데이터베이스 서버에 배치할 수도 있다. 관계형 데이터베이스는 그 특성 때문에 수평적인 확장이 어려운데, 이를 구현할 수 있는 방법으로 널리 쓰이고 있다. 다만 이렇게 해도 수평적인 확장에는 근본적인 한계가 있기 때문에[1] 수평적 확장이 중요한 데이터베이스 구축 환경이라면 결국은 NoSQL 계열을 고려하게 된다.
각주
- ↑ 질의를 할 때 해당 레코드가 어느 서버에 있는지 찾아줄 서버가 있어야 하며, 질의에 해당하는 레코드가 여러 서버에 걸쳐 있다면 일이 복잡해진다. 여러 테이블을 사용하는 JOIN 연산까지 가면 더더욱 복잡해진다. 예를 들어 서로 다른 서버에 있는 두 테이블의 JOIN 연산을 해야 한다면 서버 간에 통신을 해야 하는데 같은 서버 안에 두 테이블이 모두 있을 때보다 어마어마하게 느려진다. 만약 같은 테이블이 샤딩으로 여러 서버에 퍼져 있다면 그야말로 노답. NoSQL이 조인 연산을 지원하지 않는 것도, 데이터가 여러 서버에 퍼져 있을 경우에 답이 안 나오니 그냥 데이터를 중복 저장하라는 것이다.
