각 클라이언트에 대해 단일 데이터베이스를 사용하면 어떤 이점이 있습니까?

Question

여러 클라이언트를 위해 설계된 데이터베이스 중심 애플리케이션에서는 레코드를 적절한 인덱스 및 키와 연결하여 모든 클라이언트에 대해 단일 데이터베이스를 사용하는 것이 "더 낫다"고 항상 생각했습니다.Stack Overflow 팟캐스트를 들으면서 Joel이 FogBugz가 클라이언트당 하나의 데이터베이스를 사용한다고 언급한 것을 들었습니다(따라서 클라이언트가 1000개라면 데이터베이스는 1000개일 것입니다).이 아키텍처를 사용하면 어떤 이점이 있나요?

일부 프로젝트의 경우 클라이언트가 자신의 모든 데이터에 직접 액세스해야 한다는 것을 이해합니다. 이러한 애플리케이션에서는 각 클라이언트가 자신의 데이터베이스가 필요하다는 것이 분명합니다.하지만 클라이언트가 데이터베이스에 직접 액세스할 필요가 없는 프로젝트의 경우 클라이언트당 하나의 데이터베이스를 사용하면 어떤 이점이 있나요?유연성 측면에서 단일 테이블 복사본이 있는 단일 데이터베이스를 사용하는 것이 훨씬 더 간단한 것 같습니다.새로운 기능을 추가하기가 더 쉽고, 보고서를 만들기도 더 쉽고, 관리하기도 더 쉽습니다.

경험이 풍부한 개발자인 Joel이 자신의 소프트웨어가 다른 접근 방식을 사용한다고 언급하기 전까지는 "모든 클라이언트를 위한 단일 데이터베이스" 방법에 대해 꽤 확신을 갖고 있었습니다. 그리고 그의 결정에 약간 혼란스럽습니다.

레코드 수가 많으면 데이터베이스 속도가 느려진다는 말을 사람들이 들었지만, 어느 정도 장점이 있는 관계형 데이터베이스에는 그런 문제가 발생하지 않을 것입니다. 특히 적절한 인덱스와 키를 사용하는 경우에는 더욱 그렇습니다.

어떤 의견이라도 대단히 감사하겠습니다!

Answer 1

모든 클라이언트를 하나의 데이터베이스에 저장해도 확장성 페널티가 없다고 가정합니다.대부분의 사람들과 잘 구성된 데이터베이스/쿼리의 경우 이는 요즘 상당히 사실입니다.당신이 이러한 사람들에 속하지 않는다면 단일 데이터베이스의 이점은 분명합니다.

이 상황에서는 각 클라이언트를 캡슐화하면 이점을 얻을 수 있습니다.코드 관점에서 볼 때 각 클라이언트는 격리되어 존재합니다. 데이터베이스 업데이트로 인해 다른 클라이언트에 속한 데이터를 덮어쓰거나, 손상하거나, 검색하거나 변경할 수 있는 상황은 없습니다.또한 레코드가 다른 클라이언트에 속할 수 있다는 사실을 고려할 필요가 없으므로 모델이 단순화됩니다.

또한 분리성의 이점도 얻을 수 있습니다. 특정 클라이언트와 관련된 데이터를 꺼내서 다른 서버로 이동하는 것이 간단합니다.또는 내장된 데이터베이스 메커니즘을 사용하여 "일부 주요 데이터를 삭제했습니다!"라는 호출이 발생하면 해당 클라이언트의 백업을 복원합니다.

쉽고 무료로 서버를 이동할 수 있습니다. 하나의 데이터베이스 서버를 확장하는 경우 다른 서버에서 새 클라이언트를 호스팅할 수 있습니다.모두 하나의 데이터베이스에 있는 경우 더 강력한 하드웨어를 구입하거나 여러 시스템에서 데이터베이스를 실행해야 합니다.

버전 관리가 쉽습니다. 한 클라이언트는 소프트웨어 버전 1.0을 유지하고 다른 클라이언트는 2.0을 원하는 경우(1.0과 2.0이 서로 다른 데이터베이스 스키마를 사용하는 경우) 문제가 없습니다. 하나의 데이터베이스에서 꺼내지 않고도 하나를 마이그레이션할 수 있습니다.

아마 수십 개 더 생각할 수 있을 것 같아요.하지만 무엇보다도 핵심 개념은 '단순함'입니다.제품은 하나의 클라이언트, 즉 하나의 데이터베이스를 관리합니다."하지만 데이터베이스에 다른 클라이언트도 포함되어 있습니다" 문제는 전혀 복잡하지 않습니다.이는 혼자 존재하는 사용자의 정신 모델에 적합합니다.한 번에 모든 클라이언트에 대해 쉽게 보고할 수 있다는 장점은 미미합니다. 단 한 명의 클라이언트가 아닌 전 세계에 대한 보고를 얼마나 자주 원하십니까?

Answer 2

이전에 본 접근 방식 중 하나는 다음과 같습니다.

• 각 고객은 마스터 고객 데이터베이스에 저장된 고유한 연결 문자열을 가지고 있습니다.
• 데이터베이스는 데이터베이스에 단일 고객이 있더라도 모든 것이 CustomerID별로 분류되도록 설계되었습니다.
• 필요한 경우 모든 고객 데이터를 새 데이터베이스로 마이그레이션하는 스크립트가 생성되며, 그런 다음 해당 고객의 연결 문자열만 새 위치를 가리키도록 업데이트하면 됩니다.

이를 통해 처음에는 단일 데이터베이스를 사용한 다음 나중에 클라이언트 수가 많거나 시스템을 과도하게 사용하는 고객이 두 명 있는 경우 나중에 쉽게 분할할 수 있습니다.

모든 데이터가 동일한 데이터베이스에 있을 때 특정 고객 데이터를 복원하는 것은 정말 어렵지만 업그레이드 관리는 훨씬 간단하다는 것을 알았습니다.

고객당 단일 데이터베이스를 사용하는 경우 모든 고객이 동일한 스키마 버전에서 실행되도록 유지해야 하는 큰 문제에 직면하게 되며, 이는 전체 고객별 데이터베이스에 대한 백업 작업을 고려하지도 않습니다.당연히 데이터를 복원하는 것이 더 쉽지만 레코드를 영구적으로 삭제하지 않도록 하면(삭제된 플래그로 표시하거나 아카이브 테이블로 이동) 애초에 데이터베이스 복원의 필요성이 줄어듭니다.

Answer 3

간단하게 유지합니다.귀하의 클라이언트가 자신의 데이터만 보고 있는지 확인할 수 있습니다.레코드 수가 적은 고객은 데이터베이스에 있지만 자신의 것이 아닌 수십만 개의 레코드와 경쟁해야 하는 불이익을 지불할 필요가 없습니다.모든 것이 얼마나 잘 색인화되고 최적화되는지는 신경 쓰지 않습니다. 모든 레코드를 스캔해야 한다고 결정하는 쿼리가 있을 것입니다.

Answer 4

클라이언트 중 한 명이 가져오기 작업 실패 등으로 인해 데이터를 이전 버전으로 복원하라고 하면 어떻게 될까요?"귀하의 데이터는 모든 클라이언트 간에 공유되기 때문에 그렇게 할 수 없습니다" 또는 "죄송하지만 클라이언트 X가 데이터베이스 복원을 요구했기 때문에 변경 사항이 손실되었습니다"라고 말하면 클라이언트가 어떻게 느낄지 상상해 보십시오.

Answer 5

1000개의 데이터베이스 서버를 한 번에 업그레이드하는 데 따른 어려움은 매우 간단한 자동화를 통해 해결될 수 있습니다.각 데이터베이스가 동일한 스키마를 유지하는 한 실제로는 문제가 되지 않습니다.우리는 또한 클라이언트별 데이터베이스 접근 방식을 사용하는데 이는 우리에게 잘 작동합니다.

다음은 정확한 주제에 대한 기사입니다(예, MSDN이지만 기술과 무관한 기사입니다). http://msdn.microsoft.com/en-us/library/aa479086.aspx.

데이터 모델과 관련된 다중 테넌트에 대한 또 다른 논의는 다음과 같습니다. http://www.ayende.com/Blog/archive/2008/08/07/Multi-Tenancy--The-Physical-Data-Model.aspx

Answer 6

확장성.보안.저희 회사도 고객당 1개의 DB를 사용하는 방식입니다.또한 코드를 유지 관리하기가 좀 더 쉬워집니다.

Answer 7

여기에 다중 테넌트라는 단어를 포함하기 위해 이 답변을 추가하고 있습니다."다중 테넌트"를 쿼리로 사용하여 검색했는데 이 항목이 나타나지 않았습니다.

Answer 8

귀하의 의견에 감사드립니다. 모두 훌륭하고 유효한 내용입니다.업그레이드 유연성을 더 고려하고 있는 것 같습니다.새 기능을 추가하거나(예: 웹 애플리케이션의 경우) 기존 기능을 향상하기 위해 스키마를 수정해야 하는 경우 단일 데이터베이스에서 간단하게 수행할 수 있습니다.1000개의 개별 데이터베이스에 걸쳐 이 변경 사항을 복제해야 한다면 오류 가능성이 높아집니다.작업이 실패하면 어떻게 되나요?모든 클라이언트를 업그레이드하는 데 시간이 얼마나 걸리나요?

적절한 백업이 유지되는 경우(또는 데이터가 실제로 덮어쓰여지지 않는 구조로 데이터베이스가 구성된 경우) 특정 클라이언트에 대한 데이터를 복원하는 것은 쉽지 않습니다.

코드의 단순성은 중요하지만 실제로는 극도로 복잡해지지 않습니다.사용된 언어와 방법론에 따라 특정 클라이언트(특정 클라이언트 ID를 저장함)만을 나타내는 객체를 생성하는 것은 간단하며 프로젝트의 나머지 부분은 단일 객체(단일 클라이언트와 유사)에 대해서만 코딩하면 됩니다. ).

확장성은 고려해야 할 사항입니다. 격리된 단일 데이터베이스를 다른 물리적 서버로 이동하는 것이 쉽다는 말씀이 맞습니다.그러나 서버를 함께 클러스터링하는 것이 점점 더 쉬워지고 있으며 클러스터링 없이도 범용 데이터베이스를 호스팅하는 데이터베이스 서버에서 각 클라이언트를 가리키는 것은 작은 변화인 것 같습니다. 따라서 두 개 또는 세 개의 데이터베이스 서버를 호스팅할 수 있습니다. 예를 들어 각각 단일 데이터베이스만 있습니다).이 접근 방식을 사용하면 업그레이드 프로세스가 3개의 데이터베이스로만 제한됩니다.

Answer 9

의료와 같이 규제되는 산업에서는 고객당 하나의 데이터베이스가 필요할 수 있으며, 별도의 데이터베이스 서버가 필요할 수도 있습니다.

업그레이드할 때 여러 데이터베이스를 업데이트하는 간단한 대답은 업그레이드를 트랜잭션으로 수행하고 필요한 경우 업그레이드하기 전에 스냅샷을 찍는 것입니다.작업이 원활하게 실행되고 있다면 원하는 수의 데이터베이스에 업그레이드를 적용할 수 있어야 합니다.

클러스터링은 실제로 인덱스 및 전체 테이블 스캔 문제에 대한 해결책이 아닙니다.클러스터로 이동하면 변경 사항이 거의 없습니다.여러 시스템에 분산할 작은 데이터베이스가 많이 있는 경우 클러스터 없이 더 저렴하게 이 작업을 수행할 수 있습니다.안정성과 가용성은 고려 사항이지만 다른 방법으로 처리할 수 있습니다. 일부 사람들에게는 여전히 클러스터가 필요하지만 대부분은 그렇지 않을 것입니다.

클러스터링은 단순한 주제가 아니며 RDBMS 세계에서 구현하는 데 비용이 많이 들기 때문에 이에 대해 좀 더 자세한 내용을 듣고 싶습니다.비관계형 세계인 Google Bigtable 등의 클러스터링에 관해 많은 이야기/허세가 있습니다.그러나 그들은 다른 문제 세트를 해결하고 있으며 RDBMS의 유용한 기능 중 일부를 잃습니다.

Answer 10

"데이터베이스"에는 몇 가지 의미가 있습니다.

• 하드웨어 상자
• 실행 중인 소프트웨어(예:"오라클")
• 특정 데이터 파일 세트
• 특정 로그인 또는 스키마

Joel은 하위 계층 중 하나를 의미할 가능성이 높습니다.이 경우에는 소프트웨어 구성 관리의 문제일 뿐입니다.예를 들어, 보안 버그를 수정하기 위해 1000개의 소프트웨어 서버를 패치할 필요는 없습니다.

소프트웨어 버그로 인해 클라이언트 간에 정보가 유출되지 않도록 하는 것이 좋은 생각이라고 생각합니다.내 데이터뿐만 아니라 귀하의 고객 데이터도 표시하는 잘못된 where 절이 있는 경우를 상상해 보십시오.