※ 본 글은 작성자 본인이 나중에 찾아보기 위해 메모장처럼 정리한 글이므로 형식과 내용이 자유롭고 ‘그렇다더라’식의 기록이 많을 수 있음. 주제 또한 산발적일 수 있음.
하드웨어의 성능 확장이 필요한 때
하드웨어의 성능 확장이 필요한 때
소프트웨어는 계속 업데이트 되어서 무거워지는데 하드웨어가 못 따라가고, 용량이 부족해지고(누적된 사용량을 고정된 하드웨어가 충당하지 못함), 새로운 하드웨어에 맞춘 소프트웨어들이 등장하는데 예전의 하드웨어만으로는 그 기능을 사용할 수가 없게 되어서,
하드웨어 성능 확장이 필요하게 된다.
성능 확장의 2가지 방법
수직 확장 Scaling up
하드웨어를 더 좋은 성능으로 갈아끼우는 것.
수평 확장 Scaling out
같은 하드웨어를 여러 개 사서 연결하는 것.
RDB에서 수평확장하기
RDB가 하는 수평확장을 전용 용어로 Sharding이라고 함.
Sharding: 같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법
수평확장이 어렵다고 하는데, 그냥 같은 스키마를 가진 테이블을 또 시작해주면 되는 거잖아, 새로운 저장소에서? 했는데, 샤딩이 정확히 이런 의미였네. 오오.
‘사용자’나 ‘관계’, ‘영상’같은 이름의 테이블들이 새 저장소에 분산되어버릴 수 있다고 가정한다. 그리고 한 ‘사용자’의 ‘관계’와 ‘영상’ 정보를 각각 다른 저장소에서 찾아야 하는 것을 두려워한다. 저장소를 서칭하는 게 오래걸려서 그러나?
아무튼 그래서 관계가 복잡하고 데이터가 많아질수록 RDB는 수평 확장에 대한 관리가 매우 복잡해진다고 함.
NoSQL에서 수평확장하기는
한 컬렉션(말하자면 테이블)에 모든 데이터가 저장되는 형태이므로 문제가 없다.
예를 들면 한 컬렉션에 사용자 문서들(객체들)이 저장되어 있을 때 ‘사용자1번’ A씨에 대한 정보는 그 A씨에 대한 몸통 하나에 몽땅 들어가 있다. ‘관계’ 정보든 ‘영상’정보든 뭐든. 그래서 수평 확장 시 그냥 “사용자 n번 부터는 여기 저장소로 옮기자”로 깔끔하게 자르기가 가능한 것이라고 한다.
NoSQL은 ‘나’라는 사람의 데이터에 집중해서 데이터를 저장하기 때문에 내가 누군지만 알면 데이터를 한 번에 다 가져올 수 있다. RDB처럼 관계에 집중하는 게 아니라 ‘나’라는 객체에 집중하는 구조이기 때문이다.
참조: https://broccoli45.tistory.com/46
Uploaded by N2T