릴레이셔널 데이터베이스를 수평으로 확장할 수 있다

릴레이셔널 데이터베이스를 수평으로 확장할 수 있다

검색한 결과 다음과 같이 검색했습니다.

mysql 문서 메모:

MySQL Cluster는 노드 간에 테이블을 자동으로 분할(파티션)하여 데이터베이스를 저비용 범용 하드웨어로 수평으로 확장하여 읽기 및 쓰기 집약적인 워크로드를 처리할 수 있도록 합니다.이러한 하드웨어는 SQL에서 액세스하거나 NoSQL API를 통해 직접 액세스합니다.

관계형 데이터베이스를 수평으로 확장할 수 있습니까?NoSQL 데이터베이스를 기반으로 할 수 있습니까?

실제 사례를 가지고 있는 사람이 있나요?

이러한 데이터베이스에서 어떻게 SQL 요청, 트랜잭션 등을 관리할 수 있습니까?

가능하지만 유지보수가 많이 필요합니다.설명 -

데이터의 수직 스케일링(SQL 데이터베이스의 정규화와 동일)은 공간의 용장성을 줄이기 위해 데이터 열을 여러 테이블로 분할하는 것을 말합니다.사용자 테이블의 예 -

데이터의 수평 스케일링(Sharding과 동일)은 데이터를 가져오는 데 걸리는 시간을 줄이기 위해 행을 여러 테이블로 분할하는 것을 말합니다.사용자 테이블의 예 -

여기서 주의할 점은 SQL 데이터베이스의 테이블이 관련 데이터의 여러 테이블로 정규화되어 있다는 것입니다.이러한 테이블의 데이터를 여러 머신에 샤드하려면 관련된 정규화된 데이터를 샤드해야 합니다.이것에 의해, 유지보수 작업이 증가합니다.위의 SQL 데이터베이스 예시와 같이

주문 테이블과 일대다로 관련된 고객 테이블

고객 데이터의 일부 행을 다른 머신으로 이동하는 경우(샤딩이라고 함), 관련된 주문 데이터를 동일한 머신으로 이동해야 합니다.이러한 데이터는 관련된 테이블이 여러 개 있는 경우 번거로운 작업입니다.

NOSQL 데이터베이스는 플랫 테이블 구조를 따를 때 샤드아웃이 용이합니다(데이터는 정규화된 형식이 아닌 집계된 형식으로 저장됩니다).

내 생각에 답은 명백하게, 그렇다이다.SQL은 단순한 데이터 액세스 언어라는 점에 유의해야 합니다.여러 컴퓨터 및 네트워크 파티션으로 확장하지 못할 이유가 전혀 없습니다.어려운 문제인가요?물론, 그것이 그것을 하는 소프트웨어가 아직 걸음마 단계인 이유입니다.

여기서 여러분이 질문하고자 하는 것은 "내가 익숙한 기능과 표준 SQL 유형의 릴레이셔널 데이터베이스 관리 시스템에 제공되는 모든 기능을 이러한 방식으로 여러 서버에서 작동하도록 개발할 수 있는가?"입니다.제가 그 문제를 깊이 연구하지 않았다는 것은 인정하지만, 세상에는 "아뇨, 그럴 수 없습니다."라고 말하는 이론들이 있습니다.일관성-가용성-분할정리는 우리가 같은 수준에서 세 가지 특성을 모두 가질 수 없다고 가정합니다.

이제, 모든 실질적인 목적을 위해, "부끄러움"이나 "분할" 혹은 여러분이 부르고 싶은 것은 사라지지 않습니다; 그 반대입니다.즉, CAP 정리가 어느 정도 유지되고 있는지에 따라 데이터베이스에 대한 사고방식과 데이터베이스와의 상호작용(적어도 어느 정도)을 전환해야 합니다.많은 개발자들이 이미 No-SQL 플랫폼에서 성공을 거두기 위해 필요한 전환을 했지만, 많은 개발자들은 그렇지 못했습니다.최종적으로 모델의 완성도가 높고 효과적인 회피책이 충분히 개발되어 기존의 SQL 데이터베이스가 여러 머신에서 어느 정도 실용적이 될 수 있습니다.이것은 이미 시작되었고, 저는 몇 년만 더 참으면 그 지경에 이를 것이라고 말하고 싶습니다.아니면 우리는 더 이상 필요하지 않을 정도로 생각을 바꾸게 될 것이고, 세상은 더 나은 곳이 될 것이다.:)

질의응답 감사합니다.나는 누군가에게 이렇게 설명하려고 했다.

「 」에 CAP 또는이 발생했을 :따라서 파티션(네트워크 또는 서버 장애)이 발생한 경우:

• A relational database에 1개의 「1」이 되어 있습니다.C그러니까...P 장애발생하면 (서버/네트워크 장애)가하지 않습니다A - 으 - db down > ）

• A nosql datastoreA 때P일이 안 돼요.C(복제된 파티션 중 하나 또는 여러 개는 n/w가 돌아와 모두 동기화될 때까지 동기화되지 않습니다). ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★eventually consistent

편집 #2: 매니쉬의 코멘트를 바탕으로 더 많은 관점을 제공합니다.제 의도는 왜 이 세 가지를 모두 가질 수 없는지 예를 들어 설명하려는 것입니다.댓글에 기재된 바와 같이 A를 희생하여 P가 발생했을 때 C를 가질 수 있는 다른 db가 있습니다.

Google Spanner는 수평 확장이 가능한 관계형 데이터베이스의 한 예입니다.샤딩과 레플리케이션은 자동으로 실행되므로 걱정할 필요가 없습니다.상세한 것에 대하여는, 본서를 봐 주세요.

네, 하지만 스토리지가 증가하면 마이그레이션해야 합니다.

일부 오픈 소스 도구는 다음과 같은 기능을 지원할 수 있습니다.Vitess 또는 Apache ShardingSphere.

네, 할 수 있어요.이것은 NewSQL이라고 불립니다.

NewSQL은 우수한 RDBMS의 트랜잭션 ACID(원자성, 일관성, 격리, 내구성) 보증과 NoSQL의 수평 확장성을 결합하고자 하는 관계형 데이터베이스에 대한 새로운 접근법입니다.출처

데이터베이스의 예:

• 사용자 공유 MySQL 클러스터
• 시투스 (포스트그레)SQL 확장자)
• 바퀴벌레 DB
• Azure Cosmos DB
• 구글 스패너
• NuoDB
• 바이티스
• 스플라이스 머신(Hadoop 생태계의 일부)
• MemQSL(메모리 저장소 내)
• VoltDB(메모리 저장소 내)

데이터 웨어하우스의 예:

• IBM Netezza
• 오라클
• 테라데이터
• Hive Engine(Hadoop 생태계의 일부)
• Spark SQL(Hadoop 생태계의 일부)

언급URL : https://stackoverflow.com/questions/27157227/can-relational-database-scale-horizontally