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




데이터베이스를 연결하는 동안 오류가 발생했습니다. (8)

여러 클라이언트를 위해 설계된 데이터베이스 중심의 응용 프로그램에서는 모든 클라이언트에 대해 단일 데이터베이스를 사용하는 것이 "올바른"것으로 생각했습니다. 즉, 레코드를 적절한 인덱스와 키로 연결하는 것이 "더 나은"방법이라고 생각했습니다. Stack Overflow podcast를 듣고 FogBugz가 클라이언트 당 하나의 데이터베이스를 사용한다는 Joel의 말을 들었습니다. (따라서 1000 개의 클라이언트가 있다면 1000 개의 데이터베이스가 있습니다.) 이 아키텍처를 사용하면 어떤 이점이 있습니까?

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

Joel (숙련 된 개발자)이 자신의 소프트웨어가 다른 접근 방식을 사용한다고 언급 할 때까지는 "모든 고객을위한 하나의 데이터베이스"방법에 대해 확신했습니다. 그리고 나는 그의 결정에 약간 혼란 스럽습니다 ...

사람들이 많은 수의 레코드로 데이터베이스가 느려지는 것을 들었지만 어떤 장점을 가진 관계형 데이터베이스는 문제를 일으키지 않을 것입니다 - 특히 적절한 인덱스와 키가 사용되는 경우 특히 그렇습니다.

어떤 입력이라도 대단히 감사합니다!


그것을 간단하게 유지하십시오. 클라이언트가 자신의 데이터 만 볼 수 있는지 확인할 수 있습니다. 레코드 수가 적은 고객은 데이터베이스에있을 수있는 수십만 개의 레코드와 경쟁해야하는 불이익을 지불 할 필요가 없으며 해당 레코드가 아닌 레코드를 사용할 수 있습니다. 모든 것이 얼마나 잘 색인되고 최적화되어 있는지 상관하지 않습니다. 모든 레코드를 검사해야한다는 쿼리가있을 것입니다.


한 번에 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


의료와 같은 규제 산업에서는 고객 당 하나의 데이터베이스가 필요하며 별도의 데이터베이스 서버도 필요합니다.

업그레이드 할 때 여러 데이터베이스를 업데이트하는 간단한 대답은 업그레이드를 트랜잭션으로 수행하고 필요할 경우 업그레이드하기 전에 스냅 샷을 만드는 것입니다. 당신이 당신의 운영을 잘 운영한다면 당신은 많은 데이터베이스에 업그레이드를 적용 할 수 있어야합니다.

클러스터링은 실제로 색인 및 전체 테이블 스캔 문제에 대한 솔루션이 아닙니다. 클러스터로 이동하면 거의 변경되지 않습니다. 여러 대의 컴퓨터를 통해 배포 할 더 작은 데이터베이스가 많은 경우 클러스터없이이 작업을보다 저렴하게 수행 할 수 있습니다. 안정성과 가용성은 고려 사항이지만 다른 방법으로 처리 될 수 있습니다 (어떤 사람들은 여전히 ​​클러스터가 필요하지만 대다수는 그렇지 않을 수도 있습니다).

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


이전에 보았던 한 가지 접근 방식이 있습니다.

  • 각 고객은 마스터 고객 데이터베이스에 저장된 고유 연결 문자열을가집니다.
  • 데이터베이스는 데이터베이스에 단일 고객이 있어도 모든 것이 CustomerID로 세분화되도록 설계되었습니다.
  • 필요한 경우 스크립트를 작성하여 모든 고객 데이터를 새 데이터베이스로 마이그레이션 한 다음 해당 고객의 연결 문자열 만 새 위치를 가리 키도록 업데이트해야합니다.

이렇게하면 처음에는 하나의 데이터베이스를 사용하고 많은 수의 고객이있는 경우 나 나중에는 시스템을 과도하게 사용하는 몇 명의 고객이있을 때 쉽게 구분할 수 있습니다.

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

고객 당 하나의 데이터베이스를 사용하는 경우 모든 고객을 동일한 스키마 버전으로 유지하는 데 큰 문제가 발생하며 모든 고객 별 데이터베이스에서 백업 작업을 고려하지 않습니다. 자연스럽게 데이터를 복원하는 것이 더 쉽지만 레코드를 영구적으로 삭제하지 않고 (삭제 된 플래그로 표시하거나 아카이브 테이블로 이동하는 경우) 데이터베이스를 처음으로 복원 할 필요가 거의 없습니다.


확장 성. 보안. 우리 회사는 고객 접근 방식 당 1 DB를 사용합니다. 또한 코드를 유지 관리하기가 더 쉽습니다.


하나의 데이터베이스에 모든 클라이언트를 저장할 때 스케일링 패널티가 없다고 가정하십시오. 대부분의 사람들과 잘 구성된 데이터베이스 / 쿼리의 경우 요즘은 상당히 사실입니다. 당신이이 사람들 중 하나가 아니라면, 단일 데이터베이스의 이점은 명백합니다.

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

또한 분리 가능성의 이점을 얻습니다. 특정 클라이언트와 관련된 데이터를 추출하여 다른 서버로 이동하는 것은 간단합니다. 또는 내장 데이터베이스 메커니즘을 사용하여 "중요한 데이터를 삭제했습니다!"라고 말하면 해당 클라이언트의 백업을 복원하십시오.

쉽고 자유로운 서버 이동성 - 하나의 데이터베이스 서버를 초과하는 경우 다른 서버에서 새로운 클라이언트를 호스트 할 수 있습니다. 그것들이 모두 하나의 데이터베이스에 있다면, 더 많은 하드웨어를 갖거나 여러 대의 컴퓨터에서 데이터베이스를 실행해야합니다.

한 버전의 클라이언트가 소프트웨어 버전 1.0에 머무르고 다른 버전이 2.0을 원한다면 1.0과 2.0은 다른 데이터베이스 스키마를 사용하기 때문에 아무런 문제가 없습니다. 하나의 데이터베이스에서 제거하지 않고도 마이그레이션 할 수 있습니다.

몇 십 가지 더 생각할 수 있습니다. 그러나 모두 핵심 개념은 "단순성"입니다. 제품은 하나의 클라이언트와 하나의 데이터베이스를 관리합니다. "그러나 데이터베이스에도 다른 클라이언트가 포함되어 있습니다"라는 문제는 결코 복잡하지 않습니다. 그것은 혼자 존재하는 사용자의 정신 모형에 적합합니다. 한 번에 모든 클라이언트에 대한보고를 쉽게 수행 할 수 있다는 장점은 최소한입니다. 한 명의 클라이언트가 아닌 전체 보고서를 얼마나 자주보고 싶습니까?


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

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

아마 Joel은 하위 계층 중 하나를 의미합니다. 이 경우 소프트웨어 구성 관리의 문제 일뿐입니다. 예를 들어 보안 버그를 수정하기 위해 1000 개의 소프트웨어 서버를 패치하지 않아도됩니다.

소프트웨어 버그로 인해 클라이언트간에 정보가 유출되지 않도록하는 것이 좋습니다. 고객 데이터뿐만 아니라 내 자신을 보여준 잘못된 where 절을 가진 사례를 상상해보십시오.


귀하의 의견을 보내 주셔서 감사합니다 - 우수하고 유효한 모든 포인트. 업그레이드 유연성에 대해 더 알고 싶습니다. 스키마를 수정하여 새로운 기능을 추가하거나 (웹 응용 프로그램을 말하도록 함) 기존 기능을 향상 시키려면 단일 데이터베이스에서 수행하는 것이 간단합니다. 이 변경 사항을 1000 개의 개별 데이터베이스에 복제해야하는 경우 오류가 발생할 확률이 높아집니다. 작업이 실패하면 어떻게됩니까? 모든 클라이언트를 업그레이드하는 데 얼마나 걸리나요?

적절한 백업이 보관 된 경우 (또는 데이터를 실제로 덮어 쓰지 않은 데이터베이스가 구성된 경우) 특정 클라이언트의 데이터를 복원하는 것은 간단합니다.

코드의 단순성은 중요하지만 실제로는 매우 복잡하지 않습니다. 사용 된 언어와 방법론에 따라 특정 클라이언트 (특정 클라이언트 ID 저장) 만 나타내는 개체를 만드는 것이 간단하며 나머지 프로젝트는 단일 개체 (단일 클라이언트와 같은 종류)로 코딩해야합니다. ).

확장 성은 고려해야 할 사항입니다. 단 하나의 격리 된 데이터베이스를 가져 와서 다른 물리적 서버로 옮기는 것이 쉽습니다. 그러나 서버를 클러스터링하는 것이 점점 더 쉬워지고 있습니다. 심지어 클러스터링이 없어도 유니버설 데이터베이스를 호스팅하는 데이터베이스 SERVER에서 각 클라이언트를 가리키는 작은 변화가있는 것 같습니다 (따라서 2 ~ 3 개의 데이터베이스 서버를 호스팅 할 수 있습니다. 예를 들어 하나의 데이터베이스 만 있습니다. 이 접근 방식은 업그레이드 프로세스를 단 세 개의 데이터베이스로 제한합니다.





multi-tenant