database - 종류 - 데이터베이스를 연결하는 동안 오류가 발생했습니다.




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

여러 클라이언트 용으로 설계된 데이터베이스 중심 응용 프로그램에서는 항상 모든 클라이언트에 대해 단일 데이터베이스를 사용하는 것이 더 좋다고 생각했습니다. 레코드를 적절한 인덱스 및 키와 연결하는 것입니다. 스택 오버 플로우 팟 캐스트를 들으면서 Joel은 FogBugz가 클라이언트 당 하나의 데이터베이스를 사용한다고 언급 한 것을 들었습니다 (따라서 클라이언트가 1000 명인 경우 데이터베이스가 1000이 될 것입니다). 이 아키텍처를 사용하면 어떤 이점이 있습니까?

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

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

사람들은 데이터베이스가 많은 레코드로 인해 속도가 느려진다 고 들었 습니다만, 특히 적절한 인덱스와 키를 사용하는 경우 일부 장점이있는 관계형 데이터베이스에는 문제가 없습니다.

모든 의견을 보내 주셔서 감사합니다!


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

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

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

소프트웨어 버그로 인해 클라이언트에서 정보가 유출되지 않도록하는 것이 좋습니다. 고객 데이터와 본인의 데이터를 보여준 잘못된 where 절이있는 경우를 상상해보십시오.


간단하게 유지합니다. 고객이 자신의 데이터 만보고 있는지 확인할 수 있습니다. 적은 수의 기록을 가진 고객은 데이터베이스에있을 수는 있지만 수십만 개의 기록과 경쟁해야하는 벌금을 지불하지 않아도됩니다. 모든 것이 얼마나 잘 색인화되고 최적화되는지는 중요하지 않습니다. 모든 레코드를 스캔해야한다고 결정하는 쿼리가 있습니다.


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

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

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

확장 성은 고려해야 할 사항입니다. 격리 된 단일 데이터베이스를 쉽게 가져 와서 다른 물리적 서버로 옮기는 것이 옳습니다. 그러나 서버를 함께 클러스터링하는 것이 점점 더 쉬워지고 있습니다. 클러스터링이 없어도 범용 데이터베이스를 호스팅하는 데이터베이스 서버에서 각 클라이언트를 가리 키도록 약간 변경하는 것처럼 보입니다 (따라서 2 ~ 3 개의 데이터베이스 서버를 호스팅 할 수 있음) 예를 들어 각각 단일 데이터베이스). 이 방법을 사용하면 업그레이드 프로세스가 3 개의 데이터베이스로만 제한됩니다.


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


이전에 본 한 가지 접근법이 있습니다.

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

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

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

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


하나의 데이터베이스에 모든 클라이언트를 저장하는 데 스케일링 페널티가 없다고 가정합니다. 대부분의 사람들과 잘 구성된 데이터베이스 / 쿼리의 경우 요즘에는 이것이 사실입니다. 이 사람들 중 하나가 아니라면 단일 데이터베이스의 이점이 분명합니다.

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

또한 분리 가능성의 이점을 얻을 수 있습니다. 특정 클라이언트와 관련된 데이터를 가져 와서 다른 서버로 옮기는 것은 쉽지 않습니다. 또는 내장 된 데이터베이스 메커니즘을 사용하여 "일부 키 데이터를 삭제했습니다!"라고 전화 할 때 해당 클라이언트의 백업을 복원하십시오.

한 대의 데이터베이스 서버보다 규모가 큰 경우 다른 서버에서 새 클라이언트를 호스팅 할 수 있습니다. 그것들이 모두 하나의 데이터베이스에 있다면 더 강력한 하드웨어를 얻거나 여러 컴퓨터에서 데이터베이스를 실행해야합니다.

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

수십 가지를 더 생각할 수 있습니다. 그러나 핵심 개념은 "단순성"입니다. 제품은 하나의 클라이언트와 하나의 데이터베이스를 관리합니다. "그러나 데이터베이스에는 다른 클라이언트도 포함되어 있습니다"문제로 인한 복잡성이 없습니다. 그것은 혼자 존재하는 사용자의 정신 모델에 적합합니다. 한 번에 모든 고객에 대해 간편한보고를 수행 할 수 있다는 이점은 미미합니다. 단 한 명의 고객이 아닌 전 세계에 대한 보고서를 얼마나 자주 원하십니까?


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





multi-tenant