SQL에서 NoSQL로 옮기는 것이 어떤 크기의 데이터에 도움이됩니까?

관계형 데이터베이스 프로그래머 (대부분의 경우)로서 관계형 데이터베이스의 확장성에 대한 기사와 MongoDB와 같은 NoSQL 솔루션의 기사를 읽었습니다. 지금까지 개발 한 대부분의 데이터베이스는 중소 규모이므로 일부 인덱싱, 쿼리 최적화 또는 스키마 재 설계로 해결되지 않은 문제는 없었습니다.

MySQL이 어려움을 겪을 것으로 예상되는 크기는 무엇입니까? 행이 몇 개입니까?

(이것은 응용 프로그램과 저장된 데이터 유형에 따라 다릅니다. 기본적으로 유전학 데이터베이스 였으므로 3 또는 4 개의 조회 테이블이있는 하나의 기본 테이블이 있습니다. 다른 것들, 염색체 참조 및 위치 좌표. 염색체에있는 두 물약 사이의 많은 항목에 대해 쿼리되어 저장된 내용을 볼 수 있습니다).

얼마나 큰 데이터입니까?

두 가지 중요한 임계 값이 있습니다.

1. 전체 데이터는 RAM에 적합
2. RAM에 맞는 전체 인덱스 데이터

빠른 SSD를 사용하면 트래픽이 많지 않으면 첫 번째 임계 값이 문제가되지 않습니다.

신맛

RDBMS 확장의 문제점 중 하나는 설계 상으로는 ACID이며 이는 트랜잭션 및 행 레벨 잠금 (또는 일부 이전 / 간단한 RDBMS의 테이블 레벨)을 의미합니다. 동시에 실행중인 많은 데이터를 수정하는 많은 쿼리가있는 경우 제한 요소가 될 수 있습니다. NoSQL 솔루션은 일반적으로 최종 일관성 모델을 사용합니다.

RDBMS는 데이터 크기를 어떻게 확장합니까?

RDBMS가 데이터 크기를 확장 할 수 없다는 것은 전적으로 사실이 아니며 수직 분할과 수평 분할 (일명 샤딩)의 두 가지 대안이 있습니다 .

수직 분할은 기본적으로 관련되지 않은 테이블을 별도의 DB 서버에 유지하므로 각 테이블의 크기를 위에서 언급 한 임계 값 미만으로 유지합니다. 따라서 일반 SQL을 사용하여 이러한 테이블을 조인하는 것이 덜 간단하고 덜 효율적입니다.

샤딩이란 특정 키를 기준으로 다양한 서버간에 하나의 테이블에서 데이터를 배포하는 것을 의미합니다. 이는 조회를 위해 해당 키를 기반으로 쿼리 할 서버를 알고 있음을 의미합니다. 그러나 이로 인해 샤딩 키에서 조회되지 않은 쿼리가 복잡해집니다.

두 종류의 파티셔닝의 경우 극단적으로 가면 기본적으로 NoSQL 데이터베이스와 동일한 상황이 발생합니다.

나는 데이터의 크기가 유일한 요소라고 생각하지 않습니다. "데이터 모델"도 매우 중요한 부분입니다.

전자 상거래 카탈로그 페이지 (Solr, ElasticSearch), 웹 분석 데이터 (Riak, Cassandra), 주가 (Redis), 소셜 네트워크 (Neo4J, FleetDB)의 관계 연결은 NoSQL 솔루션이 실제로 빛을 발할 때의 몇 가지 예일뿐입니다.

IMHO, 데이터 모델은 NoSQL 솔루션 또는 RDBMS를 고려할 때 데이터 크기보다 더 중요한 역할을합니다.

관계형 데이터베이스가 확장되지 않으면 아무 것도 수행하지 않습니다. 스케일링 문제에 대해 걱정하지 마십시오.

SQL에는 일종의 분석에 문제가 있지만 문제를 유발하는 데 많은 데이터가 필요하지 않습니다. 예를 들어, 고유 키를 기반으로 다른 행을 참조하는 열이있는 단일 테이블을 고려하십시오. 일반적으로 트리 구조를 만드는 데 사용될 수 있습니다. 관련 행을 참조하는 빠른 SQL 문을 작성할 수 있습니다. 또는 관련 행의 관련 행. 실제로 특정 수의 점프를 할 수 있습니다. 그러나 각 행에 대해 체인의 첫 번째 관련 행에서 일부 기준을 충족하는 필드를 선택하려는 경우 복잡해집니다.

국가, 주 /도, 카운티, 마을 및 마을 수준의 사무실 위치 테이블을보고 각 사무실은보고하는 사무실을 참조하십시오. 각 사무소의보고 사무소가 한 레벨 만 있다고 보장 할 수 는 없습니다 . 선택한 사무실 집합에 대해 한 수준에 모두있는 것은 아니며 각 사무실의 관련 국가 사무실을 나열하려고합니다. 이를 위해서는 반복되는 SQL 문이 필요하며 오늘날에도 오랜 시간이 걸립니다. (30 개 사무실을 선택하면 30 초가 걸렸지 만 오래 전부터 저장 프로 시저로 전환하면 약간 도움이되었습니다.)

대안은 전체 구조를 하나의 큰 데이터 블록에 넣고 레이블을 붙여 저장하는 것입니다. 데이터를 분석하려면 한 번에 모든 데이터를 메모리로 읽어 구조를 추적 할 포인터를 설정하고 눈을 깜박이면서 2 백만 개의 사무실을 처리 할 수 ​​있습니다.

이 중 어느 것도 데이터 양과 관련이 없습니다. 핵심은 데이터 조직의 본질입니다. 관계형 레이아웃이 도움이되면 RDBMS가 원하는 것입니다. 그렇지 않다면, 어떤 종류의 벌크 스토리지는 약간에서 수십 배 더 빠를 것입니다.

이러한 데이터 세트 중 하나가 메모리에 비해 너무 커지면 SQL 이외의 데이터베이스는 더 이상 작동하지 않습니다. 다른 문제는 한 번에 여러 블록의 데이터가 필요할 때입니다. 당신은이 작업을 수행 할 수있는 경우 , 그리고 에만 경우, 모든 블록은 한 번에 메모리에 맞지. 그리고 사용자는로드하는 동안 기다려야합니다.

관계형 데이터베이스로 인해 문제가 발생하면 많은 데이터를 저장하기 전에 그렇게합니다. nosql DB에 대해 어셈블 할 데이터 블록 (사용해야하는 경우)이 너무 커질 때 프로그램에 문제가있을 수 있습니다. (메모리 부족 오류를 읽으십시오. 새로운 언어는 때때로 메모리에 이상한 일을합니다.)

NoSQL 또는 분산 솔루션으로 이동하는 첫 번째 이유는 모든 데이터의 크기가 아니라 테이블의 크기라고 생각합니다. 분산 솔루션이 잘하는 것은 테이블을 다른 노드로 분할 한 다음 테이블을 쿼리해야 할 때 각 노드가 해당 테이블 조각을 처리하는 것입니다.

RDBMS가이를 수행 할 수 있지만이를 위해 NoSQL 데이터베이스의 새로운 물결이 구축되었습니다. Oracle, MSSQL, MySQL은 중앙 집중식 모델을 가져 와서 분산 환경에서 작동하도록 조정했습니다. 그러나 여전히 엄격한 ACID 규칙을 준수하지만 일부 새 데이터베이스는 최종 일관성 사용과 같은 엄격한 규칙을 준수하지 않습니다.

하나를 선택해야하는 정해진 양의 데이터가 없습니다. 고려해야 할 것은 데이터베이스의 요구와 데이터베이스의 사용량입니다. NoSQL 데이터베이스는 더 큰 데이터 세트를 더 빨리 처리 할 수있는 반면 관계형 데이터베이스는 ACID 원칙에 따라 데이터가 정확하다는 확신을줍니다.

데이터 모델이 사물에 큰 영향을 미친다는 점도 언급 할 가치가 있습니다. 어떤 형태의 트리 구조를 만들어야하는 경우 (예 : 복합 기본 키에 해당 외래 키가 포함 된 테이블에 자체 참조 외래 키가있는 경우) 해당 트리 구조를 처리하는 데이터베이스 형식으로 수행하는 것이 좋습니다. mongodb 또는 couchdb와 같은 데이터 유형이 정말 좋습니다.

다른 사람들이 말했듯이 응용 프로그램에서 발생하는 일도 고려해야합니다. 여러 테이블에서 ACID가 실제로 필요한 경우 RDBMS를 고수해야하지만 약간 오래된 데이터를 가질 수 있고 NoSQL 스키마의 유연성이 필요한 경우 (원하는 경우 스키마가 없음) 여전히 어떤 형태의 암시 적 스키마를 가지고 있다면 NoSQL 스토어를 잡는 것을 고려할 수 있습니다 ( http://www.10gen.com/customers/craigslist 여기는 craigslist가 전환 된 이유의 예입니다 ... 그러나 분명히 ~ 10TB의 아카이브 내가 아는 데이터는 중소 규모의 데이터베이스 크기에 전혀 맞지 않지만 사용 사례는 도움이 될 수 있습니다.

NoSQL 시스템이 반드시 RDMS를 대체 ​​할 필요는 없지만 많은 경우 Polyglot Persistence라는 아이디어를 통해 RDBMS를 보완 할 수 있으며 대부분의 데이터를 RDBMS에 저장할 수 있지만 특정 틈새 인스턴스에서는 일부를 오프로드 할 수 있습니다 어떤 형태의 NoSQL 저장소에 데이터를 저장합니다.

Mongo여러 컴퓨터 / 노드에 설치할 수 있습니다. PostgreSQL샤딩을위한 기본 제공 도구를 제공하지 않지만 citus 가 있습니다.

MongoDB 는 최대 64 테라 바이트의 데이터베이스를 지원하며 문서 크기는 16MB입니다.

MySQL 의 데이터베이스 제한은 256 테라 바이트, 테이블의 최대 크기는 64 테라 바이트, 레코드 제한은 4 기가 바이트입니다.

PostgreSQL 에는 데이터베이스에 대한 제한이 없으며 (테스트를 위해 4 테라 바이트가 있습니다) 테이블의 한 필드 크기에 대해 1 기가 바이트의 제한이 있으며 테이블의 최대 크기는 다시 64 테라 바이트입니다.