관계형 데이터베이스가 빅 데이터의 규모를 충족시킬 수없는 이유는 무엇입니까?


17

빅 데이터 문제는 관계형 데이터베이스가 현재 생성되는 방대한 양의 데이터를 처리하도록 확장 될 수 없다는 것이 종종 반복됩니다.

그러나 Hadoop과 같은 빅 데이터 솔루션에는 이러한 확장 성 제한이 무엇입니까? Oracle RAC 또는 MySQL 샤딩 또는 Teradata와 같은 MPP RDBMS가 이러한 장점을 달성 할 수없는 이유는 무엇입니까?

기술적 인 한계에 관심이 있습니다. 클러스터링 RDBMS의 재정 비용이 엄청나다는 것을 알고 있습니다.

답변:


15

MS 는 네덜란드에서이 기술에 대해 토론기술 강연 을했습니다. 천천히 시작하지만 20 분 정도면 하둡 고기에 들어갑니다.

그것의 요지는 "그것은 달려있다"는 것입니다. (적어도 다소) 균질 한 데이터 세트를 (적어도 다소) 쉽게 분할 할 수있는 데이터 세트를 가지고 있다면 RDBMS를 사용하여 많은 양의 데이터 볼륨으로 확장하는 것이 상당히 쉬워야합니다. .

하둡과 MR은 특히 데이터가 RDBMS 세계에서 찾은 것만 큼 균질하거나 구조적 일 필요는없는 대규모 분산 데이터 스캔이 필요한 상황에보다 적합 해 보입니다.

Big Data 솔루션에는 어떤 제한이 있습니까? 제게, 그들이 바인딩하지 않은 가장 큰 제한은 미리 엄격한 스키마를 만들어야한다는 것입니다. Big Data 솔루션을 사용하면 대량의 데이터를 "박스"에 넣고 나중에 데이터의 동질성 부족을 처리하기 위해 쿼리에 논리를 추가 할 수 있습니다. 개발자의 관점에서 볼 때, 쿼리의 복잡성 및 즉각적인 데이터 일관성 저하와 비교하여 프로젝트 프런트 엔드에서의 구현 용이성 및 유연성이 절충됩니다.


고마워 데이브, 당신은 내가 찾으려고하는 것에 더 가까이 가고 있습니다. 하둡은 대규모 분산 스캔이 필요한 상황에 맞춰져 있다고 말합니다. 일부 / 많은 RDBMS에 클러스터 된 솔루션 (RAC, 샤드, MPP 등)이 있다면 왜 그렇게 할 수 없습니까? RDBMS가 매우 큰 Hadoop 클러스터처럼 16 시간 내에 10 조 개의 레코드를 정렬 할 수없는 이유는 무엇입니까? 여기에서 볼
제레미 수염을

2
RDBMS 클러스터가 이러한 종류의 작업을 수행 할 없는 것은 없으며 RDBMS가 이러한 종류의 작업을 수행 하도록 확장되도록 구성 할 있습니다. RDBMS의 문제점은이를 수행하기 위해 스키마와 파티션이 작동하도록 스키마와 파티션을 구성하는 방법에 대해주의를 기울여야한다는 것입니다. 빅 데이터 아키텍처는 RDBMS에서 데이터를 쉽고 효율적으로 분할하고 최적화 할 수있을 정도로 구조화되지 않은 경우에 승리합니다.
Dave Markle

1
무능한 db 디자이너는 관계형 데이터베이스를 확장하기 어렵게 만듭니다. 너무 많은 회사는 처음부터 컴플리트 데이터베이스 개발자를 고용해야 할 때 응용 프로그램 개발자가 데이터베이스를 설계 할 수 있다고 생각합니다 (또는 설계를 수행하기 위해 ORMS를 더 사용). 데이터와 관련된 프로젝트를 위해 고용 한 두 번째 사람은 데이터베이스 개발자 여야합니다.
HLGEM

3
@HLGEM : 이것에 대한 나의 대답은 "meh"입니다. 가장 효과적인 개발자는 스택의 양쪽 측면을 이해하는 사람이 될 것입니다. RDBMS와 함께 일하는 방법을 잘 모르면서 좋은 "응용 프로그램 개발자"라는 아이디어가 잘못입니다. . 마찬가지로, ORM을 이해하지 못하는 훌륭한 "데이터베이스 개발자"나 응용 프로그램 측면이 있다는 아이디어는 IMO도 오류입니다.
Dave Markle

6

데이터베이스 개척자이자 연구원 인 Michael Stonebraker 는 기존 데이터베이스 아키텍처의 한계에 대해 논의 하는 논문 을 공동으로 작성했습니다 . 일반적으로 고가의 하드웨어로 확장되지만 더 많은 상용 하드웨어로 병렬 확장하는 데 어려움이 있으며 이전 시대를 위해 설계된 레거시 소프트웨어 아키텍처에 의해 제한됩니다. 그는 BigData 시대에는 최신 인프라를 활용하고 특정 워크로드에 최적화 된 여러 개의 새로운 데이터베이스 아키텍처가 필요하다고 주장합니다. 예로는 상용 데이터베이스 Vertica Systems로 이어진 C-store 프로젝트와 고속 BigData 워크로드를 위해 설계된 인 메모리 OLTP SQL 데이터베이스 인 VoltDB로 이어진 H-store 프로젝트가 있습니다. (전체 공개, 저는 VoltDB에서 일합니다).

이 찾을 수있는 웹 세미나에 이 주제에 관심을. NoSQL 데이터베이스의 성공으로 인해 발생한 신화에 반응합니다. 기본적으로 그는 SQL이 문제가 아니라고 주장하며 성능을 얻기 위해 일관성과 같은 기존 데이터베이스 기능을 포기할 필요는 없습니다.


6
완전한 공개 자격을 갖추 려면 공동 설립자이자 CTO Michael Stonebraker 도 모든 사례의 공동 설계 자라고 언급해야 합니다 . 그리고 VoltDB의 SQL 지원은 매우 작은 하위 집합 입니다.
Daniel Lyons

5

RDBMS가 확장 할 수없는 것은 전적으로 사실이 아닙니다. 그러나 성명서의 일부 진실은 아키텍처에 따라 다릅니다. 제공 한 목록에서 Oracle RAC는 나머지 부분과 다릅니다 (Sharded MySQL 및 Teradata). 가장 큰 차이점은 공유 디스크와 공유 없음 아키텍처입니다.

Oracle RAC와 같은 공유 디스크 아키텍처는 어느 시점에서 또는 실행중인 다른 모든 시스템이 데이터의 일부에서 동기화되어야하기 때문에 확장에 어려움이 있습니다. 예를 들어 전역 잠금 관리자는 킬러입니다. 어느 정도 미세 조정을 계속할 수는 있지만 결국에는 벽에 부딪칩니다. 기계를 쉽게 추가 할 수없는 경우 주머니를 태울 수있는 강력한 기계가 적어야합니다. 공유 된 아키텍쳐 (또는 샤드 데이터)의 경우 각 머신은 일부 데이터의 소유권을 갖습니다. 일부 데이터를 업데이트하려는 경우 다른 mahcine과 동기화 할 필요가 없습니다.

그런 다음 NoSQL 데이터베이스의 유형이 제공됩니다. 나는 그것들을 전통적인 RDBMS 데이터베이스의 서브셋으로 취급 할 것이다. 이 세상의 모든 응용 프로그램이 RDBMS가 제공하는 모든 기능을 필요로하는 것은 아닙니다. 데이터베이스를 캐시로 사용하려면 내구성에 신경 쓰지 않습니다. 경우에 따라 일관성에 신경 쓰지 않을 수도 있습니다. 모든 데이터 조회가 키를 기반으로하는 경우 범위 쿼리를 지원할 필요가 없습니다. 보조 인덱스가 필요하지 않을 수 있습니다. 모든 기존 데이터베이스에있는 전체 쿼리 처리 / 쿼리 최적화 계층이 필요하지 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.