'큰 데이터베이스'란 무엇입니까?

좋아, 내가 아는 멍청한 질문이지만 중소뿐만 아니라 '대형 데이터베이스'라는 모호한 댓글이 보이고 그것이 무엇을 의미하는지 궁금합니다. 누군가 SQL 초보자를위한 소형, 중형 및 대형 데이터베이스를 정의 할 수 있습니까?

소규모 데이터베이스가 중간이되거나 중간 데이터베이스가 커지는 임계 값은 없습니다. 일반적으로 이러한 용어를들을 때 저장되는 총 레코드 측면에서 특정 규모를 생각합니다.

• 작게 : 10 ⁵ 개 이하의 레코드.
• 중간 : 10 ⁵ ~ 10 ⁷ 레코드.
• 크게 : 10 ⁷ ~ 10 ⁹ 레코드.
• 매우 큼 : 10 ⁹ 개 이상의 레코드 수.

포스터 dkretz가 제안 했듯이 각 종류의 데이터베이스가 갖는 속성 측면에서도 생각해 볼 수 있습니다. 이렇게 분류하면 다음과 같이 말할 수 있습니다.

• 소규모 : 성능은 문제가되지 않습니다. 특별한 최적화없이 쿼리가 잘 실행됩니다. 인덱스와 같은 최전선 개선 사항을 사용할 때 약간의 성능 차이 만 보입니다.

• 보통 : 데이터베이스에는 유지 관리 및 관리에 시간 제로 할당 된 직원이 한 명 이상있을 수 있습니다. 이 사람들은 데이터베이스의 건강에주의를 기울입니다. 그들의 주요 관리 책임은 용납 할 수없는 성능 문제를 방지하고 가동 중지 시간을 최소화하는 것입니다.

• 대규모 : 데이터베이스에서 작업하고 성능을 개선하고 애플리케이션 변경으로 인해 데이터베이스 수명 동안 스키마가 손상되지 않도록하는 전담 직원이있을 수 있습니다. 데이터베이스의 상태 및 상태에 대한 메트릭은 면밀히 모니터링됩니다. 최적화를 이해하고 수행하려면 상당한 전문 지식이 필요합니다.

• 매우 큼 : 데이터베이스는 쉽게 액세스 할 수 있어야하는 방대한 양의 정보를 저장합니다. 성능 최적화는 각 쿼리에서 모든 속도를 내기 위해 절대적으로 필요하며, 그렇지 않으면 데이터베이스의 사용 가능성이 훨씬 떨어지거나 사용이 불가능합니다. 데이터베이스는 정교하거나 혁신적인 복제 또는 클러스터링 기술을 사용하여 현재 기술의 경계를 넓힐 수 있습니다.

이것들은 전적으로 주관적이며 누군가 "대형"에 대한 완벽하게 합법적 인 대체 정의를 가지고있을 수 있습니다.

이를 파악하는 한 가지 방법은 테스트 쿼리를 관찰하는 것입니다.

작은 데이터베이스는 인덱스가 중요하지 않은 데이터베이스입니다.

중간 데이터베이스는 적절한 인덱스가없는 경우 쿼리가 1 초 이상 걸리는 데이터베이스입니다.

큰 데이터베이스는 쿼리 디자인, 인덱스 수정 및 여러 테스트주기의 조합을 사용하여 쿼리를 최적화하는 데 종종 몇 시간이 걸리는 데이터베이스입니다.

대형 데이터베이스는 관계형 데이터베이스 사용을 중단해야하는 데이터베이스입니다.

즉, 대규모 JOIN으로 인해 전 세계의 모든 인덱스가 응답 시간 요구 사항을 충족하는 데 도움이되지 않는 정규화 된 관계형 데이터베이스입니다.

다른 것을 위해 관계형 데이터베이스를 포기해야했다면, 당신은 열악한 데이터베이스 개발자이거나 전문 DBA가 없거나 매우 큰 데이터베이스를 가지고있을 것입니다.

"대형 데이터베이스"는 참으로 모호한 개념입니다. 이 질문에 대한 답변에는 이미 매우 다른 답변과 의견이 게시되어 있습니다. "소형", "중형"및 "대형"데이터베이스를 정의하는 일부 접근 방식은 다른 데이터베이스보다 더 의미가있을 수 있지만 어느 시점에서 각 정의가 옳고 사실이며 타당하다고 생각합니다.

일부 정의는 데이터베이스의 설계, 프로그래밍, 사용, 유지 관리 및 관리에 대한 중요성의 다른 측면에 초점을 맞추고 있으며 이러한 다양한 측면이 사용 가능한 데이터베이스에 실제로 중요한 것이므로 다른 것보다 더 의미가 있습니다. 이러한 모든 측면은 "데이터베이스 크기"라는 모호한 개념의 영향을받습니다.

그렇다면 특정 데이터베이스가 큰지 여부를 정의 할 수 있는지 여부가 중요하지 않다는 의미입니까?

확실히. 의미하는 바는 데이터베이스의 다양한 설계 / 운영 / 관리 측면을 평가하면서 개념을 다르게 적용한다는 것입니다. 또한 매번이 개념이 모호 할 것임을 의미합니다.

예 : 데이터베이스 인덱스 전략 (데이터베이스 설계의 한 측면)은 각 테이블의 레코드 수 (“크기”측정), 레코드 크기 곱하기 레코드 수 (“크기”의 또 다른 측정) 및 쿼리 대에 의해 영향을받습니다. . 생성 / 업데이트 / 삭제 작업 비율 (데이터베이스 사용 측면).

레코드가 많은 테이블에 인덱스를 사용하는 경우 쿼리 응답 시간이 더 좋습니다. WHERE, ORDER BY 및 레코드 집계 절의 특성에 따라 특정 테이블에 대해 여러 인덱스가 필요할 수 있습니다.

생성, 업데이트 및 삭제 작업은 영향을받는 테이블의 인덱스 수가 증가함에 따라 부정적인 영향을받습니다. 영향을받는 테이블에 대한 인덱스가 많을수록 RDBMS가 수행해야하는 변경 사항이 많아지고 이러한 변경 사항을 적용하는 데 더 많은 시간과 리소스가 소비됩니다.

또한 RDBMS가 이러한 변경 사항을 적용하는 데 더 많은 시간을 소비하는 경우 잠금이 더 오랜 시간 동안 유지되어 동시에 시스템으로 전송되는 다른 쿼리의 응답 시간에 영향을줍니다.

그렇다면 인덱스의 수량과 디자인의 균형을 어떻게 잡습니까? 추가 인덱스가 필요한지 그리고 해당 인덱스를 추가해도 쿼리 응답 시간에 큰 부정적인 영향을주지 않는지 어떻게 알 수 있습니까? 답변 : 부하 / 성능 요구 사항에 따라 대상 부하에 대해 데이터베이스를 테스트 및 프로파일 링하고 추가 최적화 / 재 설계 / 인덱스가 필요한지 여부를 확인하기 위해 프로파일 링 데이터를 분석합니다.

쿼리 대마다 다른 인덱스 전략이 필요합니다. 생성 / 업데이트 / 삭제 작업 비율. 데이터베이스에 쿼리로드가 많지만 거의 업데이트되지 않는 경우 쿼리 응답 시간을 향상시키는 모든 인덱스를 추가하면 전체 애플리케이션의 성능이 향상됩니다. 반면에 데이터베이스가 지속적으로 업데이트되지만 큰 쿼리 작업이없는 경우 인덱스를 적게 사용하면 성능이 향상됩니다.

물론 다른 측면도 있습니다 : 데이터베이스 스키마 디자인, 스토리지 전략, 네트워크 디자인, 백업 전략, 저장 프로 시저 / 트리거 / 기타. 프로그래밍, 애플리케이션 프로그래밍 (데이터베이스에 대한) 등. 이러한 모든 측면은 "크기"라는 고유 한 개념 (레코드 크기, 레코드 수, 인덱스 크기, 인덱스 수, 스키마 디자인, 스토리지 크기 등)에 따라 다르게 영향을받습니다.

이 주제가 매력적이므로 더 많은 시간을 보내고 싶습니다. 이 작은 기여가이 매혹적인 SQL 세계에서 출발점이되기를 바랍니다.

이 정의에 대한 하드웨어 발전을 고려해야합니다.

1. 소규모 데이터베이스 : 단일 상용 서버의 물리적 RAM에 맞는 작업 세트 (현재 약 16GB)

2. 중간 규모 데이터베이스 : 단일 시스템에서 단일 또는 여러 (RAID를 통해) 범용 하드 드라이브에 맞음 (현재 최대 몇 TB)

3. 대규모 데이터베이스 : 데이터에 맞게 여러 상용 서버에 분산되어야합니다 (현재 최대 여러 PB).

Very Large Database 에 대한 wikipedia 기사에 따르면

초대형 데이터베이스 또는 VLDB는 매우 많은 수의 튜플 (데이터베이스 행)을 포함하거나 매우 큰 물리적 파일 시스템 스토리지 공간을 차지하는 데이터베이스입니다. VLDB의 가장 일반적인 정의는 1TB 이상을 차지하거나 수십억 행을 포함하는 데이터베이스입니다. 물론이 정의는 시간이 지남에 따라 변경됩니다.

개발 또는 테스트 상자에 배치하기 위해 "백업"할 수 없을만큼 충분히 큰 데이터베이스가있는 경우 "대형 데이터베이스"가있을 수 있습니다.

위키피디아 나 미국 인구 조사 데이터는 '큰'데이터베이스라고 생각합니다. 내 개인 주소 목록 또는 할 일은 작은 데이터베이스입니다. 중간 크기의 데이터베이스는 그 사이에 있습니다.

필요한 서버 수에 따라 크기를 정의 할 수 있습니다. 소규모 데이터베이스는 데스크톱에서 실행하는 응용 프로그램의 구성 요소이며, 중간 규모 데이터베이스는 어딘가에있는 단일 mysql (무엇이든) 서버이며, 대규모 데이터베이스에는 일종의 복제 / 장애 조치 지원이있는 여러 서버가 필요합니다.