계산 및 데이터 저장에 사용되는 상당히 큰 데이터베이스를 설정할 예정입니다. 하나의 기본 키와 두 개의 외래 키를 포함하는 10 개의 필드가있는 하나의 테이블이됩니다. 나는 매일 약 10 억 개의 레코드가 추가 될 것으로 예상한다.SQL-Server 데이터베이스의 실제 한계
각 레코드는 매우 작아야하며 주로 삽입 작업을 수행 할 것입니다. 각 인서트를 통해 연결된 레코드의 하나 또는 두 개의 필드에서 간단한 업데이트를 수행해야합니다. 모든 쿼리는 비교적 간단해야합니다.
SQL Server에서 성능상의 문제가 발생하기 시작합니다. vldb 시스템에 대한 언급을 보았지만 실제 고통을 느낄 수도 있습니다. 내가 그것을보고 시작해야하는 한계점이 있습니까? 이런 종류의 일을 위해 설계된 SQL 서버보다 나은 db가 있습니까?
트랜잭션 속도가 10k/초를 초과하면 포럼에 대한 조언을 구하지 않아야합니다 ... 이것은 수백만 달러의 비용이 소요되는 32 가지 및 64 가지의 TPC-C 벤치 마크 성능에 가깝습니다.
어떤 크기로 문제가 발생합니까?
좋은 데이터 모델 및 스키마 디자인을 사용하면 올바르게 조정 된 올바른 용량 계획 서버로 110 억 개의 문제가 발생하지 않습니다. 하루 기록. 최신 출판 된 SQL Server benchmarks은 약 1.2 mil tran/min입니다. 이는 대략 초당 16,000 건의 트랜잭션으로, 2005 년에는 6 백만 달러 (64 웨이 Superdome)였습니다. Superdome을 필요로하지는 않지만 10kg/s의 속도를 달성하려면 아주 작은 시스템 (최소한 16 가지)과 특히 매우 우수한 I/O 하위 시스템이 필요합니다. 엔벌 로프 용량 계획을 수행 할 때 일반적으로 HBA 당 약 1K tran/초 및 HBA를 공급하는 4 개의 CPU 코어를 고려합니다. 그리고 당신은 1 bil을 먹이기 위해서 꽤 많은 데이타베이스 클라이언트 (응용 프로그램 중간 계층)가 필요할 것입니다. 하루에 데이터베이스에 기록하십시오. 저는 여기서 당신의 능력 계획을했다고 주장하지는 않습니다 만, 저는 우리에게 우리가 말하는 것에 대한 야구장을주고 싶었습니다. 이것은 수백만 달러 규모의 프로젝트이며, 이와 같은 것은 포럼에 대한 자문을 통해 설계된 것이 아닙니다.
+1 : 레무스는 확실히 DBMS에 이러한 수준의 삽입 및 저장을 수행하려면 전문 지식/컨설팅 및 경험이 필요합니다. SQL Cat 팀과 협력하거나 MVP 목록/SQL Certified Masters 목록을 확인하십시오. – Andrew
TPC-C tran/sec는 삽입 및 업데이트보다 큰 tpc-c 작업량 'tran'을 측정합니다. 여전히 10k 간단한 트랜스/초는 꽤 큰 숫자입니다. –
Google의 대형 색인 유형처럼 큰 규모가 아니라면 SQL Server 나 Oracle과 같은 엔터프라이즈 데이터베이스가 정상적으로 작동합니다.
James Devlin over at Coding the Wheel summed it up nicely (이
요즘 내가 관계형 데이터베이스 우주의 죽음의 별과 같은 SQL Server와 Oracle의 생각하고 싶다 오라클/SQL 서버와 MySQL은 같은 무료 DB 년대 사이의 비교보다 비록이. 매우 강력한. 모노 리식. 브릴리언트. 거의 이해하는 하나의 인간의 마음의 능력. 그리고 실제로 행성을 파괴 할 때 그 드문 상황을 제외하고 돈의 기념비적 인 폐기물을 넘어 복잡한. 지금까지 성능이가는대로
, 모두 귀하의 색인 생성 전략에 달려 있습니다. egy. 인서트는 실제 병목 현상입니다. 레코드를 인덱싱 할 필요가있을수록 더 많은 인덱싱을 수행 할 수 있기 때문에 삽입 시간이 길어집니다.
Google 색인과 같은 경우에는 "Big Table"을 읽으십시오. Google이 서버 클러스터를 사용하여 엄청난 양의 데이터를 수 밀리 초 만에 처리하도록 설정 한 것은 흥미로운 일입니다.
큰 테이블 정보 http://en.wikipedia.org/wiki/BigTable#External_links 및 http://labs.google.com/papers/bigtable.html –
그 인용문을 좋아합니다. – feihtthief
데이터베이스 자체의 크기로 인해 성능 문제가 발생하지 않습니다. 데이터베이스 크기의 실질적인 문제는 운영/유지 관리 문제에서 비롯됩니다.예를 들어
:
처음부터 일종의 파티션으로 설계/구축하는 것이 좋습니다. SQL Server 분할, 응용 프로그램 분할 (예 : 한 달에 한 개의 테이블), 보관 (예 : 다른 데이터베이스로) 일 수 있습니다.
나는 모든 데이터베이스 제품에서 이러한 문제가 발생한다고 생각합니다.
또한 트랜잭션 로그 파일 크기를 허용해야합니다.
하지만 하드웨어 비용과 계획을 수립하면 MS가 사양에 맞게 처리 할 수 있습니다. 그것은 당신의 HW 비용의 일부일 것입니다.
2 년 전 Paul Nielson blogged about 35k TPS (1 일당 30 억 행)이라고 말합니다. 댓글을 읽을 가치가있는 의견 및 Remus가 말한 내용 중 일부를 반영하십시오.
특정 응용 프로그램을 프로파일 링하기 위해 하드웨어 및 소프트웨어를 설정하는 것이 좋습니다. 성능 문제는 특히이 규모에서 애플리케이션별로 다를 수 있습니다. –
하루에 10 억 건의 아이디어를 어떻게 내놓았습니까? 이것은 매우 강렬한 트랜잭션 비율입니다. 사실적인 지속 처리율일까요? 각각의 계산을 자체 트랜잭션에 저장하는 것에 대해 정말로 생각하고 있습니까? 아마도 당신이 원하는 것은 훨씬 적은 트랜잭션 처리량과 데이터베이스에 저장된 더 큰 바이너리 블롭 (blob) 데이터입니다. –
기본 아이디어는이 데이터베이스가 다소 복잡한 상태 공간에 대한 검색 트리라는 것입니다. 저의 백 엔드는 끊임없이 새로운 상태를 검색하고 추가 할 것이므로, 10 억/일은 얼마나 빨리 새로운 상태를 만들 수 있을지 예측 한 것입니다. 나는 나무가 완전히 완성 될 것이라고 기대하지 않기 때문에, 이론적으로 그것을 늘일 수 있었다. – captncraig