다중 데이터베이스 사용과 단일 데이터베이스 사용의 장단점

나는 성능, 안정성, 최적화가 더 쉽게 구현된다고 주장하면서 7 개의 데이터베이스를 사용해야하는 새로운 프로젝트를 진행하고있었습니다.

동의하지 않지만 단일 데이터베이스를 사용하기 위해 좋은 인수를 수집하는 데 어려움을 겪고 있습니다 (테이블을 논리 도메인으로 분할).

지금까지 내가 한 주장은 데이터 무결성입니다 (데이터베이스간에 외래 키를 사용할 수 없습니다).

하나 또는 여러 개의 데이터베이스를 사용할 때 좋은 장단점이 무엇입니까?

[지금까지의 요약]

여러 데이터베이스에 대한 인수 :

• 데이터 무결성 상실 (데이터베이스에 외래 키를 사용할 수 없음)

• 복원 무결성 상실

• 복잡성 확보 (DB 사용자 / 역할)

• 작은 확률 서버 / 데이터베이스가 다운 됨

솔루션 :

• 스키마를 사용하여 도메인을 분리하십시오.

• POC : 더미 데이터를 사용하여 7/1 db의 실행 계획에서 요점을 증명

성능, 안정성, 최적화는 사실이 아닙니다. 왜 이것이 사실인지에 대한 확실한 주장이나 참고 기사가 있습니까?

리소스는 데이터베이스에 할당되지 않습니다. SQL Server 인스턴스는 리소스의 균형을 유지하므로 차이 가 없습니다.

당신은 잃는다 :

• 데이터 무결성
• 무결성 복원 (DB7의 데이터는 나중에 DB1이 됨)

복잡성을 얻습니다.

• 보안 (사용자, 역할 등)은 모든 데이터베이스에 있어야합니다.
• 하나의 데이터베이스에 잘 맞지 않는 데이터가 있습니다.

옵션 :

• 파일 그룹을 사용하여 데이터베이스를 별도의 디스크로 분할 할 수 있습니다
• 스키마를 사용하여 논리적으로 데이터를 분리하십시오 (다른 답변을 기반으로)

별도의 데이터베이스를 작성해야하는 이유는 서로 다른 가용성 요구 사항을 지원하거나 관리를 단순화하기위한 것입니다. 예를 들어, 데이터베이스에 매우 다른 백업 스케줄 또는 다른 복구 모델이 필요한 경우. 다른 인스턴스에서 다른 인스턴스를 실행하려는 경우가 있습니다.

하나의 데이터베이스로는 달성 할 수없는 여러 데이터베이스에서 사용 가능한 성능 최적화가 없습니다. "성능, 안정성, 최적화"의 의미에 대해 자세히 설명 할 수 있습니까?

논리 도메인별로 데이터를 분할 한 후에는 항상 SQL2008 내에서 스키마 (dbo의 기본값에서 멀어짐)를 사용하는 것을 볼 수 있지만 고통스럽고 예상치 못한 OR / M에 문제가 발생할 수 있습니다. 표준 스키마.

나는 하나 이상의 데이터베이스에서 데이터를 수집하는 위치에 있었고 고통스럽고 고성능과는 거리가 멀다. 속도를 유지하기 위해 데이터를 캐시하거나 최소한 트릭을 사용하게됩니다.

테스트로 7 개의 더미 데이터베이스를 구축하십시오. 7 개 이상의 데이터를 동시에 요구하거나 적어도 많은 수의 데이터를 요구하는 쿼리를 작성하십시오.

그런 다음 실행 계획을 비교하십시오! 나는 당신이 바로 당신의 사건을 이길 것이라고 생각합니다.

생각 실험 : 데이터베이스를 7 개로 나누는 대신 7,000 개로 나눕니다. 하드웨어 오류가 응용 프로그램에 영향을 줄 가능성은 무엇입니까? 특정 날짜에 특정 서버가 사망 할 가능성이 0.1 % 인 경우, 의존하는 컴퓨터의 수를 늘릴 때 하드웨어 오류로 인해 영향을받을 가능성이 더 높거나 나쁘습니까?

"데이터베이스"라는 개념을 스키마와 데이터와 데이터를 제공하는 데 사용되는 하드웨어의 두 부분으로 나누는 것이 중요하다고 생각합니다.

여러 머신에서 데이터베이스를 분리해도이 주제의 다른 답변에서 설명하는 여러 가지 이유로 좋지 않습니다.

안정성과 성능 향상을 위해 여러 대의 컴퓨터를 사용하려는 경우 여러 개의 웜 / 핫 대기 컴퓨터가있는 마스터 서버가 쿼리를 분산시키는 데 사용할 수 있도록이를 구성 할 수 있습니다. 이 방법으로 하나의 시스템에 오류가 발생하면 데이터가 손실되지 않으며 최악의 경우 쿼리를 다시 시작해야합니다. 물론 이것보다 복잡하지만 기본 사항이 적용됩니다.

하나의 DB와 파일 및 스키마 옵션을 대신 사용합니다.

여러 조각으로 나누는 것이 합리적 인 경우가 있습니다.

FTP 서버, 내보내기 파일 경로 등과 같은 응용 프로그램 환경 (dev, test, prod) 구성, 서버 당 저장하려는 항목, 복원시 덮어 쓰지 않음

또한 클라이언트 특정 프로 시저 변경 사항을 분리하는 방법입니다.

그러나 이것들은 성능 문제가 아닌 지원입니다.