수십억 개의 행을 저장할 수 있는 최적의 데이터 저장소

수십억 개의 행을 저장할 수 있는 최적의 데이터 저장소

수십억 개의 레코드에 대해 작은 데이터 비트(약 50~75바이트)를 저장할 수 있어야 합니다(1년간 월 30억까지).

유일한 요건은 동일한 GUID를 가진 모든 레코드에 대한 빠른 삽입과 빠른 조회이며 .net에서 데이터스토어에 액세스할 수 있어야 합니다.

저는 SQL Server 전문가이고 SQL Server가 이 기능을 수행할 수 있다고 생각합니다. 하지만 BigTable, CouchDB 및 기타 nosql 솔루션에 대한 이야기가 많으니 분산 쿼리 및 확장 최적화를 위해 기존 RDBS를 대체하는 것이 더 나을 것 같습니다.cassandra를 사용해 봤는데 .net 라이브러리는 현재 컴파일되지 않았거나 (cassandra 자체와 함께) 모두 변경될 수 있습니다.

사용 가능한 nosql 데이터 스토어를 많이 찾아봤지만 견고한 운영용 플랫폼으로서의 요구에 맞는 데이터 스토어를 찾을 수 없었습니다.

360억 개의 작은 플랫 레코드를 저장하여 .net에서 액세스할 수 있도록 해야 한다면 무엇을 선택하고 그 이유는 무엇입니까?

보관시 최대 3.5TB의 데이터와 약 1K/sec의 24시간 365일 삽입 및 지정되지 않은 속도로 쿼리하는 것은 SQL Server에서는 가능하지만 더 많은 질문이 있습니다.

• 99.999%의 가동시간과 95%의 가동시간 중 어느 정도의 가용성이 확보되어 있습니까?
• 어떤 신뢰성 요건을 가지고 있습니까?삽입물을 분실하면 100만 달러가 드나요?
• 어떤 복구 기능을 필요로 합니까?하루의 데이터 유출이 문제가 됩니까?
• 어떤 일관성 요건을 가지고 있습니까?쓰기가 다음 번 읽을 때 표시되도록 보장해야 합니까?

여기서 설명한 모든 요건이 필요한 경우, 어떤 수법(샤딩, 파티션 분할 등)을 사용하든 관계형 시스템이나 모든 시스템에서 하드웨어와 라이선스에 수백만 달러가 소요됩니다.nosql 시스템은 정의상 이러한 모든 요건을 충족하지 못합니다.

따라서 이러한 요구사항 중 일부는 이미 완화되었습니다.Visual Guide와 NoSQL Systems의 '3개 중 2개 선택' 패러다임에 기반한 nosql 제품을 비교하는 훌륭한 비주얼 가이드가 있습니다.

OP 댓글 갱신 후

SQL Server에서는 다음과 같은 간단한 구현이 가능합니다.

• 단일 테이블 클러스터(GUID, 시간) 키 1개예, 단편화되지만 단편화가 읽기 전이나 읽기 전에만 영향을 미치는지 여부 및 읽기 전은 상당한 범위 검색에만 필요합니다.특정 GUID 및 날짜 범위만 쿼리하므로 플래그멘테이션은 크게 문제가 되지 않습니다.네, 와이드 키이므로 페이지 이외의 페이지는 키 밀도가 낮습니다.네, 필 팩터 불량으로 이어집니다.네, 페이지 분할이 발생할 수 있습니다.이러한 문제에도 불구하고 요건을 고려할 때 클러스터화된 키를 선택하는 것이 가장 좋습니다.
• 는 자동 슬라이딩 창을 통해 유효기간이 지난 레코드를 효율적으로 삭제할 수 있도록 시간별로 테이블을 분할합니다.이를 지난달 온라인 인덱스 파티션 재구축으로 강화하여 GUID 클러스터링으로 인한 불량 채우기 및 단편화를 제거합니다.
• 페이지 압축을 활성화합니다.GUID별로 클러스터된 키 그룹이 먼저 이루어지므로 GUID의 모든 레코드가 서로 옆에 있으므로 페이지 압축에 사전 압축을 배치할 수 있습니다.
• 로그 파일의 고속 IO 경로가 필요합니다.로그가 초당 1K의 삽입량을 따라잡기 위해서는 짧은 지연 시간이 아니라 높은 throughput에 관심이 있으므로 제거는 필수입니다.

파티션 분할과 페이지 압축에는 각각 Enterprise Edition SQL Server가 필요합니다.이것들은 Standard Edition에서는 동작하지 않습니다.요건을 충족시키기 위해서는 둘 다 매우 중요합니다.

참고로 레코드가 프런트엔드 웹 서버 팜에서 온 경우 각 웹 서버에 Express를 설치하고 백엔드에 INSERT 대신 웹 서버와 같은 위치에 있는 Express 로컬 연결/트랜잭션을 사용하여 백엔드에 정보를 전달합니다.이를 통해 솔루션의 가용성이 크게 향상됩니다.

SQL Server에서는 이렇게 합니다.좋은 소식은 여러분이 직면하게 될 문제들이 잘 이해되고 해결 방법이 알려져 있다는 것입니다. 그렇다고 해서 이것이 반드시 Cassandra, BigTable 또는 Dynamo로 달성할 수 있는 것보다 낫다는 것을 의미하지는 않습니다.좀 더 알기 쉬운 사람이 자기 주장을 하게 할 거야

프로그래밍 모델, .Net 지원 등에 대해서는 언급하지 않았습니다.솔직히 대규모 배치에서는 무관하다고 생각합니다.개발 프로세스에는 큰 차이가 있지만, 일단 도입하면 ORM 오버헤드로 인해 성능이 저하될 경우 개발 속도가 얼마나 빠른지는 중요하지 않습니다.

일반적인 생각과는 달리 NoSQL은 성능이나 확장성에 관한 것이 아닙니다.이는 주로 객체-관계 임피던스 불일치를 최소화하는 데 중점을 두고 있지만 RDBMS의 일반적인 수직 확장성과 비교하여 수평 확장성에 대해서도 마찬가지입니다.

고속 인서트나 고속 검색의 심플한 요건은, 거의 모든 데이타베이스 제품에 대응합니다.관계형 데이터를 추가하거나 결합하거나 복잡한 트랜잭션 논리 또는 제약 조건을 적용해야 하는 경우 관계형 데이터베이스를 사용해야 합니다.비교할 수 있는 NoSQL 제품이 없습니다.

도식 없는 데이터가 필요한 경우 MongoDB 또는 CouchDB와 같은 문서 지향 데이터베이스를 사용하는 것이 좋습니다.느슨한 스키마가 주된 매력입니다.저는 개인적으로 MongoDB를 좋아해서 몇 가지 커스텀 리포트 시스템에서 사용하고 있습니다.데이터 요건이 끊임없이 변경될 때 매우 유용합니다.

다른 주요 NoSQL 옵션은 BigTable이나 Cassandra와 같은 분산된 Key-Value Stores입니다.이러한 기능은 범용 하드웨어를 실행하는 여러 시스템에 걸쳐 데이터베이스를 확장하려는 경우에 특히 유용합니다.서버에서도 정상적으로 동작하지만 SQL Server, Oracle 또는 수직 확장용으로 설계된 기타 데이터베이스뿐만 아니라 하이엔드 하드웨어도 이용하지 않습니다.또한 이러한 데이터베이스는 관계성이 없기 때문에 정규화 또는 제약 조건을 적용하는 데 적합하지 않습니다.또, 아시다시피,NET 지원은 기껏해야 얼룩이 많은 경향이 있습니다.

모든 관계형 데이터베이스 제품은 제한된 정렬의 파티션을 지원합니다.BigTable이나 다른 DKVS 시스템만큼 유연하지 않고 수백 대의 서버 간에 쉽게 파티셔닝되지 않습니다.그러나 실제로는 그렇게 생각하지 않습니다.데이터를 적절히 인덱싱 및 정규화하고, 강력한 하드웨어(특히 SSD)에서 데이터베이스를 실행하고, 필요에 따라 2개 또는 3개 또는 5개의 물리적 Disk 간에 파티션을 분할하는 한 수십억 개에 달하는 레코드 수를 처리하는 데 매우 능숙합니다.

위의 기준을 충족하고 기업 환경에서 일하고 있으며 적절한 하드웨어 및 데이터베이스 최적화에 투자할 돈이 있다면 지금은 SQL Server를 사용합니다.저렴한 Amazon EC2 클라우드 컴퓨팅 하드웨어에서 이 기능을 실행해야 한다면 Cassandra 또는 Voldemort를 선택하는 것이 좋습니다(사용할 수 있는 경우).네트워크)

수십억 개의 행 집합 크기로 작업하는 사람은 거의 없습니다. 스택 오버플로에서 이와 같은 요청을 볼 때 데이터가 보고되는 크기에 전혀 미치지 못합니다.

하루에 약 1억 개, 시간당 416만 개, 분당 약 7만 개, 초당 1.1만 개의 행이 다운타임이 없는 경우 12개월 동안 지속적으로 시스템에 들어갑니다.

이러한 수치는 결코 불가능한 것은 아닙니다.저는 더 큰 시스템을 사용해 본 적이 있지만, 실제로 이 수량을 가지고 있는 애플리케이션은 거의 없습니다.

저장/검색 및 아직 언급하지 않은 매우 중요한 측면은 오래된 데이터의 에이징입니다.삭제는 무료가 아닙니다.

통상적인 테크놀로지는 파티셔닝입니다만, GUID 베이스의 룩업/취득은, 12개월 전체에 걸쳐 모든 일치치를 취득할 필요가 있는 것을 전제로 하면, 퍼포먼스가 저하합니다.클러스터된 인덱스를 GUID 열에 배치하면 관련 데이터 clusterd를 읽기/쓰기용으로 가져올 수 있지만, 이 수량과 삽입 속도에서는 플래그멘테이션이 지원하기에 너무 높아 바닥에 떨어집니다.

또한 이것이 OLTP 유형의 응답 속도를 가진 심각한 애플리케이션인 경우, 대략적인 추측에 따르면 매우 적은 오버헤드(2.7)가 필요할 것으로 생각됩니다.TB의 데이터

SQL Server 캠프에서는 대규모 데이터마트에 대해 고속으로 데이터를 샤드아웃하고 병렬 쿼리를 실행할 수 있도록 설계된 새로운 패럴렐 데이터 웨어하우스 에디션(madison)만 검토해야 합니다.

"수십억 개의 레코드에 대해 작은 데이터 비트(약 50~75바이트)를 저장할 수 있어야 합니다(1년간 월당 30억 개).

유일한 요건은 동일한 GUID를 가진 모든 레코드의 빠른 삽입과 빠른 조회입니다.또한 .net에서 데이터 스토어에 액세스할 수 있습니다.」

SQL Server에서는 2009년 초에 실행했기 때문에 지금까지도 매우 빠르게 동작하고 있습니다.

테이블은 256개의 파티션으로 분할되어 있습니다.이것은 2005년 SQL 버전입니다.당신이 말한 대로 실행했습니다.그것은 GUID로 정보를 저장하고 GUID로 빠르게 취득하는 것입니다.

제가 떠났을 때 약 20억에서 30억 개의 레코드가 있었고, 데이터 보유 정책이 인스턴스화되기 직전임에도 불구하고 데이터 검색은 여전히 양호했습니다(UI를 통해 1~2초, RDBMS를 통해서는 그 이하).

요컨대, GUID 문자열에서 8번째 문자(즉, 중간쯤)를 꺼내 SHA1이 해시하고 작은 int(0-255)로 캐스트하여 적절한 파티션에 저장하고 데이터를 되돌릴 때 동일한 함수 호출을 사용했습니다.

더 자세한 정보가 필요하시면 제게 ping 하세요...

다음 기사에서는 Microsoft SQL에서의 160억 행 테이블 Import 및 사용에 대해 설명합니다.https://www.itprotoday.com/big-data/adventures-big-data-how-import-16-billion-rows-single-table

기사 내용:

다음은 제 경험에서 얻은 몇 가지 요령입니다.

• 정의된 클러스터 인덱스가 있는 테이블에 데이터가 많을수록 정렬되지 않은 레코드를 가져오는 속도가 느려집니다.어느 순간, 너무 느려져서 실용적이 될 수 없다.
• 테이블을 가능한 한 작은 파일로 내보내려면 기본 형식으로 지정하십시오.이 방법은 문자 데이터보다 이진 필드에 더 간결하게 표시되므로 대부분 숫자 열이 포함된 표에서 가장 적합합니다.모든 데이터가 영숫자일 경우 네이티브 형식으로 내보내도 큰 효과를 얻을 수 없습니다.숫자 필드에 null을 허용하지 않으면 데이터가 더욱 압축될 수 있습니다.필드를 null로 할 경우 필드의 바이너리 표현에는 데이터 바이트 수를 나타내는 1바이트 접두사가 포함됩니다.
• BCP 카운터 변수는 4바이트 정수이므로 2,147,483,647개 이상의 레코드에 BCP를 사용할 수 없습니다.MSDN이나 인터넷에서는 이에 대한 참조를 찾을 수 없었습니다.이 로 구성되어 있는 경우
  2의 레코드가 에는 2,480,483,647개의
  직접 내보내기 루틴을 작성할 수도 있습니다.
• 미리 채워진 테이블에서 클러스터된 인덱스를 정의하려면 많은 디스크 공간이 필요합니다.내 했다.
  완료 전 테이블 크기
• BULK INSERT bulk할할 Import 、 BATCHSIZE bulk bulk bulk 。
  한 번에 커밋할 수 있습니다.하지 않으면 " " " 입니다.
  .
  이치
• 클러스터 인덱스를 사용하여 데이터를 테이블로 가져오는 가장 빠른 방법은 먼저 데이터를 사전 정렬하는 것입니다. 다음 "BULK " "BULK" "Import" "Import"
  ORDER order 、 INSERT 、 INSERT 、 INSERT order 、 INSERT 、 INSERT 。

간과하고 있는 듯한 특이한 사실이 있다.

"기본적으로 하루에 3000만 행을 삽입한 후 동일한 GUID(약 20줄)로 모든 행을 가져와 모든 행을 다시 가져올 수 있는지 확인해야 합니다."

20개의 열만 필요하므로 GUID의 비클러스터 인덱스는 정상적으로 작동합니다.파티션 간에 데이터를 분산하기 위해 다른 열에 클러스터링할 수 있습니다.

데이터 삽입에 대한 질문이 있습니다.어떻게 삽입되고 있습니까?

• 일정(분당, 시간당 등)에 따라 대량 삽입이 이루어집니까?
• 이 데이터는 어떤 소스(플랫 파일, OLTP 등)에서 추출되고 있습니까?

저는 방정식의 한 측면을 이해하는 데 도움이 되도록 이러한 질문에 대답할 필요가 있다고 생각합니다.

Amazon Redshift는 훌륭한 서비스입니다.이 질문이 처음 게시되었을 때는 2010년에 이용할 수 없었지만, 지금은 2017년에 주요 선수가 되었다.Postgres에서 분기된 컬럼 기반 데이터베이스이므로 표준 SQL 및 Postgres 커넥터 라이브러리가 작동합니다.

보고서 작성, 특히 집계에 가장 적합합니다.단일 테이블의 데이터는 정의된 테이블 Distkey에 의해 분산된 Amazon 클라우드의 서로 다른 서버에 저장되므로 분산된 CPU 전력에 의존합니다.

따라서 SELECT와 특히 집약 SELECT는 매우 고속입니다.대용량 데이터는 Amazon S3 csv 파일에서 COPY 명령을 사용하여 로드하는 것이 좋습니다.단점은 DELETE와 UPDATE가 평소보다 느리다는 것입니다.그러나 Redshift는 주로 다국적 데이터베이스가 아니라 데이터 웨어하우스 플랫폼입니다.

Cassandra 또는 HBase를 사용해 볼 수 있지만, 사용 사례에 따라 기둥 패밀리를 설계하는 방법을 자세히 읽어봐야 합니다.Cassandra는 자체 쿼리 언어를 제공하지만 데이터에 직접 액세스하려면 HBase의 Java API를 사용해야 합니다.Hbase를 사용해야 한다면 오픈소스 프로젝트인 Map-R에서 Apache Drill로 데이터 조회를 권장합니다.Dill의 쿼리 언어는 SQL-Compliance입니다(드릴의 키워드는 SQL과 동일한 의미임).

연간 레코드가 그렇게 많으면 결국 공간이 부족해질 것입니다.2^64 파일을 지원하며 작은 상자를 사용하는 xfs와 같은 파일 시스템 스토리지를 사용하는 것은 어떨까요?사람들이 얼마나 많은 정보를 얻고 싶은지, 혹은 돈을 얼마나 쓰느냐에 관계없이 SQL NoSQL을 데이터베이스로 사용하는 시스템을 구입하게 됩니다.이러한 많은 기록은 보통 전기회사와 전국의 소규모 관측소를 관리하는 환경부 등 기상 관측소/공급자에 의해 작성됩니다.압력을 저장하는 것 같은 일을 하고 있다면..온도..풍속..습도 등...guid는 장소입니다.데이터를 연도/월/일/시간별로 분할할 수 있습니다.하드 드라이브당 4년간의 데이터를 저장한다고 가정합니다.그런 다음 미러 기능이 있는 소형 NAS에서 실행할 수 있습니다. 읽기 속도가 향상되고 여러 개의 마운트 지점이 있습니다.만들어진 연도를 기준으로 합니다.검색용 Web 인터페이스를 간단하게 작성할 수 있습니다.따라서 location 1/2001/06/01//temperature 및 location 1/2002/06/01/temperature를 덤프하는 것은 여름의 첫 번째 날의 시간당 온도 내용뿐입니다(24시간*2) 48개의 작은 파일이 있는 데이터베이스 검색에 수십억 개의 레코드가 사용되고 있을 가능성이 있습니다.사물을 보는 간단한 방법..만약 구글과 같은 회사가 슈퍼컴퓨터를 구입하기 위해 30억건당 수백만건을 검색하는데 써야 한다면 그들은 파산할 것이다.대신 전력 청구서를 가지고 있고... 수백만 대의 쓰레기 컴퓨터를 가지고 있어요.그리고 카페인 색인은...미래에 대비할 수 있습니다.계속 추가해 주세요.또한 SQL에서 인덱스를 실행하는 것이 효과적인 경우 날씨와 같은 고정된 작업을 위한 슈퍼컴퓨터를 구축하여 기술자가 xtb를 x초 만에 크런치할 수 있도록 합니다.다른 곳에 쓸 수 있는 돈 낭비..10대의 NAS 서버를 가동한다고 해서 조만간 수백만 대에 달하지는 않을 전력 요금 청구서일 수도 있습니다.

레코드를 GUID당 하나의 파일로 일반 바이너리 파일로 저장하면 이보다 더 빠를 수 없습니다.

MongoDB를 사용하여 GUID를 샤딩 키로 사용할 수 있습니다.즉, 데이터를 여러 머신에 분산할 수 있지만 샤딩 키로 선택하기 때문에 선택하는 데이터는 1대의 머신에만 존재합니다.

MongoDb의 샤딩은 아직 생산 준비가 되지 않았습니다.

언급URL : https://stackoverflow.com/questions/2794736/best-data-store-for-billions-of-rows