데이터베이스에 최대 32GB의 데이터를 저장해야하는 앱을 만들고 있습니다. 읽기 때문에 범위 쿼리 (0 < 시간 < 1 시간) 같은 B 트리 인덱싱을 사용하고 있습니다.데이터베이스 확장 성 - 성능 대 데이터베이스 크기
처음에는 (데이터베이스 크기 = 0GB), 밀리 초당 60 및 70 개의 쓰기가 발생합니다. 5GB라고 말한 후에, 내가 테스트 한 세 개의 데이터베이스 (H2, berkeley DB, Sybase SQL Anywhere)는 정말로 밀리 초당 5 개 미만의 쓰기와 같이 느려졌습니다.
질문 :
주 :
각 레코드는 약간의 int
예 구성; 인덱싱은 삽입 시간의 비용으로 가져 오기 시간을 향상시킵니다. 귀하의 전화 번호는 알지 못하는 사이에 합리적으로 들립니다.
벤치 마크 할 수 있습니다. 합리적인 양의 데이터를 저장해야합니다. 무거운 페치 및 라이트 삽입 쿼리에 따라 인덱싱 할 것인지 여부를 고려하십시오. 어디에서나 where 절이이를 사용할 수있는 색인을 생성합니다. 가벼운 인서트, 무거운 인서트? 아마도 색인을 피할 것입니다. 혼합 된 작업량; 벤치마킹해라.
벤치마킹에서는 볼륨 및 데이터 도메인 모두에서 가능한 한 실제 또는 실제 데이터 (모든 "henry smith"가 아닌 모든 유형의 데이터 배포)를 원합니다.
@ Richard-t와 완전히 일치합니다. 대량 업데이트를하기 전에 색인을 완전히 제거하고 업데이트가 완료되면 다시 적용하는 것이 오프라인/배치 시나리오에서는 매우 일반적입니다.
적용되는 인덱스 유형도 삽입 성능에 영향을줍니다. 예를 들어 SQL Server 클러스터 된 인덱스 업데이트 I/O는 인덱스 배포뿐 아니라 데이터 배포에도 사용됩니다. 비 클러스터형 인덱스는 별도의 (따라서 더 비싼) I/O 작업.
어떤 엔지니어링 프로젝트와 마찬가지로
- 최고의 조언은 실제 데이터 세트와 함께 측정하는 인덱스 액세스 속도를 삽입 속도를 희생하는 것이 일반적입니다(등 찢어 페이지의 분포를 기울입니다). 모든 단일 열에 대해 색인을 생성하는 데이터베이스 테이블 (그리고 나는 이것들을 야생에서 보았습니다)에서 찾을 수 있습니다. 업데이트 횟수가 쿼리 수에 비해 적은 경우 본질적으로 잘못된 것은 없습니다.
이1/당신은 당신의 쓰기가
2/당신은 몇을 작성하고, (즉, 5000/초 아직) 5/MS 둔화 우려 것 같다 :
그러나, 주어진 레코드 당 정수; 및
3/당신은
이정기적 데이터베이스를 무시하고 자신의 종류 - 중 - 데이터베이스 롤링 고려할 수, 쿼리 시간 쿼리를 기반으로 전용있어 (내 생각은 당신이 진짜 수집하고 있다는 있습니다 장치 판독과 같은 시간 데이터).
순차적 데이터 만 작성하는 경우 플랫 파일을 사용하고 '인덱스'정보를 별도로 주기적으로 작성할 수 있습니다 (매분 초 말).
이것은 쓰기 속도를 크게 향상 시키지만 비교적 효율적인 읽기 프로세스를 허용합니다. 최악의 경우 관련 기간의 시작을 찾아서 거기에서 스캔을해야합니다.
1/당신이 작성하는 레코드를 순차적으로 시간을 기준으로 : 물론
이 스토리지가 올바른되는 내 가정에 따라 달라집니다.
2/시간 범위에 대해서만 쿼리하면됩니다.
제안서에 귀하가 기재 한 것보다 더 많은 가정이 있습니다! - 그 중 가장 적은 것은 그 사람이 RDBMS를 사용하고 있다는 것입니다 (그 중 많은 이유가 가능합니다). 예를 들어 JOIN을 원할 경우 RDBMS가 필요합니다. –
경우에 따라 실제로 이것은 좋은 아이디어입니다. 그 속임수는 그것을 언제 사용해야 하는지를 아는 것입니다. 질문을하는 사람이 JOIN을해야하는지는 알 수 없습니다. – Jacob
예, 인덱스는 일반적으로 삽입 속도가 느려지고 select (쿼리)는 속도가 크게 향상됩니다.
B 트리의 모든 삽입이 동일하지는 않습니다. 나무예요. 당신이하는 모든 일이 그것에 삽입된다면 계속 성장해야합니다. 데이터 구조는 약간의 패딩을 허용하지만 순차적으로 증가하는 숫자를 계속 삽입하면 새 페이지를 계속 추가하거나 균형을 유지하기 위해 주변을 뒤섞어 야합니다. 테스트에서 잘 분산 된 숫자가 삽입되었는지 확인하십시오 (실제 생활에서 어떻게되는지 가정). 처음부터 B-tree에 예상되는 항목 수를 알리기 위해 무엇이든 할 수 있는지 확인하십시오.
우수한 점. 일반적으로 테이블을로드하고 인덱스를 빌드하는 것이 더 바람직합니다. 새 데이터가 삽입되는 (그리고 경우에 따라 업데이트되는) 중요한 서비스 시간 후에 재조정을 돕기 위해 때때로 테이블을 언로드하고 다시로드 할 것입니다. –
당신은 꽤 멀리 갈 필요가 없습니다, 리처드, 인덱스를 삭제하고 다시 만들면 충분합니다. 재로드에서 조각 모음을 얻을 수도 있지만 좋은 일이 될 수는 있지만 일반적으로 인덱스를 다시 작성한다고 말하고 싶습니다. – SquareCog
예, Dmitriy, 아직 일부 RDBMS는 "고유 한"테이블 구조를 가지고 있으며 힙을 인덱싱하지 않습니다. 즉, 기본 테이블 자체는 하나의 인덱스 (기본 제공 인덱스)와 같은 구조이며, 이러한 경우에는 지금 다시로드하면 도움이됩니다. –
나는 페이지 크기가 btree에서이 동작에 큰 영향을 미친다고 BDB 워드 프로세서 어딘가에 생각한다. 동시성의 방식으로 많은 일을하지 않고 레코드 크기를 고정 시킨다고 가정하면 페이지 크기를 늘려야합니다.
btw, 성능 향상을 위해 가장 먼저해야 할 일은 데이터 도메인을 통해 데이터를 분할하는 것입니다. 단일 열/속성. 이것은 나를 대신 24 테이블을 제공해야합니다. –