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

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

---

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

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

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

사람들이 많은 수의 레코드로 인해 데이터베이스 속도가 느려진다는 말을 들었지만, 어떤 장점이있는 관계형 데이터베이스는 특히 적절한 인덱스와 키를 사용하는 경우 문제가 발생하지 않을 것입니다.

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

---

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

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

또한 분리 성의 이점을 얻을 수 있습니다. 특정 클라이언트와 관련된 데이터를 가져 와서 다른 서버로 이동하는 것은 쉬운 일이 아닙니다. 또는 내장 된 데이터베이스 메커니즘을 사용하여 "우리는 일부 주요 데이터를 삭제했습니다!"라고 호출 할 때 해당 클라이언트의 백업을 복원하십시오.

쉽고 자유로운 서버 이동성을 얻을 수 있습니다. 한 데이터베이스 서버를 확장하면 다른 서버에서 새 클라이언트를 호스팅 할 수 있습니다. 이들이 모두 하나의 데이터베이스에 있다면 더 강화 된 하드웨어를 확보하거나 여러 시스템에서 데이터베이스를 실행해야합니다.

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

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

---

이전에 보았던 접근 방식은 다음과 같습니다.

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

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

모든 데이터가 동일한 데이터베이스에 있으면 특정 고객 데이터를 복원하는 것이 정말 힘들지만 업그레이드 관리가 훨씬 더 간단하다는 것을 알게되었습니다.

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

---

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

---

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

---

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입니다.

---

확장 성. 보안. 우리 회사도 고객 접근 방식 당 1 개의 DB를 사용합니다. 또한 코드를 좀 더 쉽게 유지 관리 할 수 ​​있습니다.

---

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

---

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

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

코드의 단순성은 중요하지만 그다지 복잡하지는 않습니다. 사용되는 언어와 방법론에 따라 특정 클라이언트 (특정 클라이언트 ID를 저장하는) 만 나타내는 개체를 만드는 것이 간단하고 나머지 프로젝트는 단일 개체 (단일 클라이언트와 같은 종류)에 대해서만 코딩하면됩니다. ).

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

---

건강 관리와 같은 규제 대상 산업에서는 고객 당 하나의 데이터베이스, 심지어는 별도의 데이터베이스 서버가 필요할 수 있습니다.

The simple answer to updating multiple databases when you upgrade is to do the upgrade as a transaction, and take a snapshot before upgrading if necessary. If you are running your operations well then you should be able to apply the upgrade to any number of databases.

Clustering is not really a solution to the problem of indices and full table scans. If you move to a cluster, very little changes. If you have have many smaller databases to distribute over multiple machines you can do this more cheaply without a cluster. Reliability and availability are considerations but can be dealt with in other ways (some people will still need a cluster but majority probably don't).

I'd be interested in hearing a little more context from you on this because clustering is not a simple topic and is expensive to implement in the RDBMS world. There is a lot of talk/bravado about clustering in the non-relational world Google Bigtable etc. but they are solving a different set of problems, and lose some of the useful features from an RDBMS.

---

There are a couple of meanings of "database"

• the hardware box
• the running software (e.g. "the oracle")
• the particular set of data files
• the particular login or schema

It's likely Joel means one of the lower layers. In this case, it's just a matter of software configuration management... you don't have to patch 1000 software servers to fix a security bug, for example.

I think it's a good idea, so that a software bug doesn't leak information across clients. Imagine the case with an errant where clause that showed me your customer data as well as my own.

참고URL : https://stackoverflow.com/questions/13348/what-are-the-advantages-of-using-a-single-database-for-each-client