러닝 SQL: 데이터 생성, 검색, 조작까지 데이터 제대로 주무르기

390

러닝 SQL

●

개별 샤드가 너무 커지면 (예를 들어 소셜 미디어업체에 현재

20

억 명의 사용자가 존재할 경우 ) 더 많은

샤드를 추가하고 샤드 전체에 데이터를 재분배할 계획이 필요합니다.

●

스키마를 변경해야 하는 경우 모든 스키마가 동기화되도록 모든 샤드에 변경 사항을 배포하는 전략이 필

요합니다.

●

애플리케이션 로직에서 둘 이상의 샤드에 저장된 데이터에 액세스해야 하는 경우, 여러 데이터베이스를

통해 쿼리하는 방법과 여러 데이터베이스에 걸쳐 트랜잭션을 구현하는 방법에 대한 전략이 필요합니다.

만약 샤딩이 복잡해 보인다면 그것은 방금 설명한 사항들 때문이며,

2000

년대 후반에 이르러

많은 업체가 새로운 접근법을 찾기 시작했습니다. 다음 절에서는 관계형 데이터베이스 영역 밖

에서 대용량 데이터셋을 처리하는 다른 전략을 살펴봅니다.

17.4

빅데이터

샤딩의 장단점을 따져본 후, 소셜 미디어업체의 데이터 아키텍트인 여러분이 다른 접근 방식을

조사하기로 결정했다고 가정해보겠습니다. 이때 자신의 길을 개척하려고 하기보다는 아마존,

구글, 페이스북, 트위터와 같은 다른 업체들이 방대한 양의 데이터를 어떻게 다루는지를 검토

하는 편이 도움이 될 것입니다. 이 기업들이 개척한 일련의 기술은

빅데이터

bigdata

로 브랜드화되

어 업계의 유행어가 되었지만 몇 가지 정의를 담고 있습니다. 빅데이터의 경계를 정의하는 한

가지 방법은 다음과 같은 ‘

3V

’입니다.

●

볼륨

volume

: 이러한 맥락에서 볼륨은 보통 수십 억 또는 수조