어떤 시점에서 클라이언트 당 하나의 데이터베이스를 사용할 수 없게됩니까?

시스템 중 하나의 경우 민감한 클라이언트 데이터가 있으며 각 클라이언트의 데이터를 별도의 데이터베이스에 저장합니다. 우리는 그 시스템에 대해 약 10-15 명의 클라이언트가 있습니다.

그러나 50-100 명의 클라이언트를 보유한 새로운 시스템을 개발하고 있습니다. 이 인스턴스에서 클라이언트 당 하나의 데이터베이스를 보유하는 것이 불가능하다고 생각합니다 (민감한 레코드 및 감사 기록 ​​저장). 그러나 이것이 완벽하게 정상적인 지 아닌지 또는 보안을 유지하는 다른 방법이 있는지 모르겠습니다.

이것에 대한 생각?

100 또는 500 개의 데이터베이스를 관리하는 것이 실제로는 5 또는 10을 관리하는 것과 다르지 않습니다. 자동화를 수용하고 확장 성 계획을 세워야합니다 (모든 데이터베이스에서 미러링과 같은 데이터베이스 당 비용이 높은 기능을 사용하지 않음) 고객).

이전 작업에서 우리는이 아키텍처를 사용했으며, 한 번의 어려움이 "어려울"수 있지만 두 클라이언트를 단일 데이터베이스로 병합하는 것을 생각한 적이 없었습니다.

가장 큰 장점은 독립적 복구 모델 ( a단순, b전체 용량 등), 다른 사람을 방해하지 않고 특정 시점으로 복원 (또는 완전히 제거)하는 기능, 리소스가 많은 클라이언트를 원활하게 이동할 수있는 기능입니다 자체 스토리지 또는 투명성이 거의없는 완전히 다른 서버 (앱에 해당 클라이언트를 찾을 수있는 위치를 알려주는 구성 파일 또는 테이블을 업데이트 함).

다음 게시물에서 몇 가지 반대 의견 및 / 또는 문제에 접근하는 방법을 설명합니다.

• 다중 테넌트 데이터베이스 아키텍처에서 점점 더 많은 테넌트 처리

• SQL Server 2008을 사용하는 다중 테넌트 데이터베이스?

• 많은 수의 데이터베이스 백업 자동화

모두가 말했다, 나는 우리의 말할 수 있다고 생각하지 않습니다 당신에게 관리를위한 비실용적하는 지점 을 그냥 어떤 알 - 별이 개별적으로 그 문제에 대해 요청할 수 있습니다, 당신은 건너 도전한다.

사용 가능한 옵션과 장단점에 대해 설명하는 백서 인 다중 테넌트 데이터 아키텍처 를 읽어보십시오 . 요약하면 세 가지 옵션이 있습니다.

• 별도의 DB
• 별도의 스키마
• 공유 스키마

이제 분리 된 DB 단계에있게되었으며, 이는 가장 우수한 분리 (테넌트 간 격리)를 제공하지만 관리하기가 가장 어렵습니다. 수백 명의 테넌트로 성장함에 따라 100 개의 DB를 관리하는 물류가 사소한 것이 아니라는 것을 알게 될 것입니다. 백업 복원 (백업 된 파일, 작업, 일정 등의 위치)을 생각하십시오. 수백 개의 DB에서 파일 할당, 사용 된 디스크 공간 및 데이터베이스 증가를 어떻게 모니터링하고 관리 할 것인지 생각하십시오. 1000 명의 임차인이 가까운 시일 내에 고 가용성 / 재해 복구 가능성 시나리오를 어떻게 생각하십니까? 1000 개의 미러링 된 DB, 1000 개의 로그 전달 세션? 6 개월 안에 개발자 팀이 와서 "이 제품에이 멋진 기능을 어떻게 제공하는지 알고 있습니다. 우리는 트랜잭션 복제를 사용할 것입니다!"라고 어떻게 생각하십니까? "저는 500 명의 게시자를 설정하겠습니다."! 데시벨의 수백을 관리하는 것은 불가능하지,하지만 당신은, 당신이 더 잘 꾸밀 계획이라면 PowerShell에서의 UI를 관리 도구를 사용하여 기술과 정지를 지금 .

또한 여러 (수백) DB가 성능과 비용에 상당한 영향을 미친다는 점을 고려해야합니다.

• 물리적 디스크 공간을 비효율적으로 사용된다 (모든 데이터베이스가 있어야합니다 일부 여분의 방을, 당신은 데시벨의 수를 곱한 그 여분의 공간이 있습니다)
• 쓰기 집약적 작업을 위해 전용 로그 디스크를 만들 수있는 방법은 없습니다. 모든 LDF를 하나 이상의 SSD 스토리지로 이동해야합니다.
• 로그 쓰기는 자주 수행되는 커밋이 여러 개별 로그 블록 레코드에 분산되어 하나에 집계되므로 덜 효율적입니다. 내가 말하는 것을 이해 하려면 LSN이란 무엇입니까 : 로그 시퀀스 번호 를 참조하십시오 .

분리 된 DB는 격리로 인해 몇 가지 장점이 있지만, 주요 장점은 독립적 인 백업 / 복원입니다.

귀하와 같은 시나리오는 SQL Azure 데이터베이스 의 완벽한 후보입니다 . 디스크 공간 관리, HA / DR 제공 불필요, 수백 / 수천 개의 DB 등으로 확장

이전 작업에서 우리는 클라이언트 당 하나의 데이터베이스 만이 아니라 대부분의 경우 그 이상이었습니다. 내가 떠났을 때, 하나의 MariaDB 클러스터에서 실행되는 4,500 개 이상의 데이터베이스가 있었고, 다른 (아이 론적으로 작은) 클러스터에서 거의 7,000 개, 그리고 4 개의 "샤드"(완전히 분리 된 독립적 인 웹 및 데이터베이스 서버, 심지어 완전히 별개의 데이터 센터에서도) 단일 MySQL 서버에 200-500 개의 데이터베이스가 있습니다. 그리고 그 회사는 여전히 좋은 클립으로 성장하고 있습니다.

길고 짧은 것은 그 회사의 성공이 그러한 아키텍처가 실제로 실현 가능하다는 것을 증명한다는 것입니다. (주의 사항 : 별도의 데이터베이스를 사용하여 격리 된 명백한 이익과는 달리 모든 데이터는 동일한 데이터베이스 사용자 / 패스를 사용하는 밀접하게 결합 된 응용 프로그램 트리오를 통해 액세스됩니다! 각 클라이언트가 약간의 성능 저하를 겪을 수 있습니다 별도의 사용자 / 패스가 있지만 약간만 있습니다.)

시스템 관리자와의 긴밀한 협력 경험 (기술적으로는 회사의 프로그래머 였지만 실제로는 DBA가 가장 좋았으며 방화벽을 설정하는 방법을 아는 유일한 사람이었습니다!), 성능 관련 동시 액세스, 쿼리 복잡성 / 시간, 인덱스 성능 등으로 정리 된 우려-일반적으로 모든 용의자, 즉 서버의 데이터베이스 수는 눈에 띄지 않는 부분을 차지했습니다. 우리는 정기적으로 상담했습니다.

결론적으로, 데이터베이스 수에 관계없이 애플리케이션, 인프라에 대한 관심에 집중해야합니다. 다른 모든 요소는 성능 문제 및 병목 현상을 해결하기 위해 바쁘게 유지하기에 충분할 것입니다.