단일 V / s 다중 데이터베이스
다양한 조직 (현재 약 20 명의 클라이언트)에 대한 정보를 저장하는이 웹 응용 프로그램 (php & mysql)을 만들었습니다.
현재 시나리오는 클라이언트 관련 정보를 개별 데이터베이스에 저장하므로 20 개의 클라이언트 데이터베이스와 1 개의 마스터 데이터베이스가 있습니다.
여기서 주요 장점 중 하나는 각 클라이언트 DB가 분리 될 때 클라이언트 아티팩트 (보고서, 감사)의 번호가 매겨지는 것입니다. 고객에게 보안 느낌을줍니다.
각 DB에는 약 15 개의 테이블이 있으며 테이블에서 가장 많은 행은 약 2000 개입니다. 최대 5000 개의 레코드까지 충돌 할 것으로 예상됩니다.
단일 DB 수준 변경을 관리한다는 것은 20 개의 데이터베이스를 변경하는 것을 의미하지만 드물게 변경해야 할 경우 단일 함수 호출에서이를 수행하는 스크립트를 사용합니다.
우리는 공유 호스팅 계약을 맺고 있으며 ISP는 제한된 번호를 제공합니다. 데이터베이스 그리고 이것이 데이터베이스 중앙화 측면에서 생각하게하는 이유입니다. 모든 클라이언트 데이터를 마스터 데이터베이스에 저장할 수 있습니다.
물론 몇 가지 중요한 문제는 다음과 같습니다.
에이. 이슈 시퀀스 유지 (추가 참조 키를 생성하여 해결할 수 있음) b. 속도 및 성능 (이 경우 속도를 높이기 위해 인덱스를 만들 수 있음) c. 보안 : 클라이언트 정보를 가져 오는 각 쿼리로 관리됩니다. 또한 client_id를 추적합니다
앞으로 한 조직의 데이터 집합을 다른 조직과 비교하는 것을 고려해야 할 수도 있지만 중앙 집중식 DB에서도 달성 할 수 있다고 생각합니다. 성능 및 유지 관리상의 이유로 중앙 집중식 데이터베이스로 이동하려는 경향이 있습니다.
중앙 데이터베이스로 이동하는 것이 개별 데이터베이스에있는 그대로 유지하는 것보다 더 의미가 있다고 생각하십니까?
조언 해 주셔서 감사합니다.
두 시스템 모두에 상속 위험과 보상이 있습니다. 저는 1 개의 데이터베이스에서 약 40 개의 고객 (국가 은행)을 지원하는 금융 회사에서 일했습니다. 그런 다음 비슷한 소프트웨어를 판매하고 클라이언트 당 데이터베이스가 1 개인 다른 회사를 구입했습니다. 결국 회사는 파산했고 모든 사용자 데이터를 내 보내야했습니다. 내가 함께 일하고 찾은 사람들은 다음과 같습니다.
단일 DB 전문가 :
- 소프트웨어 업데이트 및 버그 수정이 더 쉽습니다.
- 모든 클라이언트 데이터를 쉽게 관리하고보고 할 수 있습니다.
- 데이터 업데이트가 쉬워집니다.
- 한 명의 고객이 원하는 모듈 식 기능을 쉽게 생성하고 다른 고객의 경우 사용 중지 한 다음 나중에 필요할 때 사용하도록 설정할 수 있습니다.
단일 DB의 단점 :
- 데이터 무결성-한 은행 사용자가 다른 은행 데이터를 본 사례가 2 ~ 3 건있었습니다. 이것은 악몽이었다. 특히 사이트 사용자는 은행 직원뿐만 아니라 은행 고객을 보유한 실제 계좌이기 때문입니다! 이것은 데이터베이스 1에서 가장 큰 문제입니다.
- 클라이언트 데이터 내보내기-이 작업을 수행 할 때는 대개 큰 문제가되지 않았습니다. 모든 클라이언트가 포함 된 1 개의 테이블로 끝나고 해당 테이블에서 키를 지정하여 클라이언트 특정 데이터를 가져옵니다.
여러 DB의 전문가 :
- 클라이언트 간 데이터 오염 또는 유출에 대한 우려가 없습니다
- 클라이언트 데이터 내보내기는 매우 쉽습니다.
여러 DB의 단점 :
- 업데이트 및 버그 수정-이건 진짜 악몽이었습니다. 20 개의 서로 다른 데이터베이스에 20 개의 클라이언트가있는 경우 한 클라이언트가 버그 수정을 원하고 다른 클라이언트가 버그가 기능이라고 생각하거나 업데이트를 위험에 빠뜨리고 싶지 않은 경우가 빨리 발생합니다. 또한 한 클라이언트가 게임 변경 기능 향상을 원하지만 다른 클라이언트는 그렇지 않은 인스턴스가 있습니다. 이런 일이 발생하면 데이터베이스가 분기되기 시작합니다. 갑자기 클라이언트 1-15를 스크립트 1-16-19로, 클라이언트 20을 다른 스크립트 1로 업데이트해야합니다. 우리는 버그 수정이 모든 클라이언트에 대해 모든 테스트를 실행하고 각 클라이언트에 대한 특수 코드를 처리해야했기 때문에 우리보다 구매 한 회사의 경우 15 ~ 20 배 더 오래 걸리는 문제가되었습니다. 효과적으로, 그들은 모든 새로운 고객을 위해 새로운 지원 인력이 필요했고, 모회사는 5-10 명의 고객마다 1 명이 필요했습니다.
- DB 관리-모든 데이터베이스를 관리하는 많은 수의 클라이언트에 도달하면 정말 번거 롭습니다. 의심 할 여지없이 DBA 관리에 더 많은 DBA 시간이 필요합니다.
결국 두 가지를 모두보고 수행 한 권장 사항은 "징계"입니다. 나는 멀티 DB 선택이 당신을 보호하기 때문에 약간 더 낫다고 생각하지만 클라이언트가 당신에게 기능을 추가하게하는 선택을 할 수는 없다. 그렇지 않으면 실패의 길을 가게 될 것이다.
별도의 클라이언트를위한 별도의 데이터베이스가 있습니다. 고객은 보안상의 이유로이를 요구할 수 있습니다. 즉, 자신의 사이트 만 데이터에 액세스 할 수 있습니다. 또한 클라이언트가 데이터를 이동하려면 much 관리하기 쉬워 질 것입니다.
또한 한 클라이언트의 데이터베이스에 문제가 있으면 다른 모든 데이터베이스에 영향을 미치지 않습니다.
클라이언트 간 데이터를 비교하려면 별도로 수행해야합니다.
데이터베이스가 부족한 경우 호스트 제공자 변경을 고려해야합니다.
지금까지 프로/콘에 추가하려면 :
여러 데이터베이스의 전문가 :
잠금 문제는 피합니다. 클라이언트가 일부 테이블에서 DDL 변경을 트리거 할 수있는 데이터베이스가 있습니다. 더 큰 테이블 (> 2m 레코드)의 경우 이것은 상당한 시간 동안 테이블을 잠급니다. 단점이있는 유일한 사람은 자신의 사용자이므로이 정도는 허용됩니다.
유연성-일부 고객은 저장하고자하는 데이터와 관련하여 특별한 희망을 가지고 있습니다. 멀티 데이터베이스는 다른 클라이언트의 데이터 모델을 어지럽히 지 않고도 데이터베이스를 구체적으로 변경할 수있는 유연성을 제공했습니다.
단점 :
- 주요 단점 : 다른 테이블에 참여하는 것이 훨씬 성가시다. 대부분의 메타 데이터가 포함 된 기본 데이터베이스가 있습니다. 클라이언트 특정 데이터베이스 사용자는이 데이터베이스에 액세스 할 수 없으므로 해당 데이터베이스의 테이블과 클라이언트 특정 테이블 간의 모든 조인이 데이터베이스가 아닌 응용 프로그램에서 처리됩니다. 클라이언트 특정 사용자에게 기본 데이터베이스에 대한 액세스 권한을 부여하여이 문제를 해결할 수 있지만 앱에서 정보가 다시 유출 될 수 있습니다.
선택에 행운을 빕니다!
이미 답변을 선택했지만 제안되지 않은 다른 솔루션이있는 것 같습니다.
모든 것을 하나의 데이터베이스로 옮기고 다음과 같이 접두사를 사용하여 각 고객에 대한 테이블을 작성하십시오.
initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl
그것은 두 세계 중 최고입니다.
- 현재 설정에서 새 설정으로 쉽게 마이그레이션 할 수 있습니다.
- 클라이언트 당 1 명의 사용자를 생성하고 권한을 그의 회사 테이블로 제한 할 수 있습니다.
- 필요한 경우 수퍼 유저를 생성하고 데이터를 쉽게 집계 할 수 있습니다.
- 하나의 데이터베이스 만 사용
각 클라이언트에 대해 개별 데이터베이스가없는 유일한 이유는 100 대 또는 1000 대의 클라이언트/데이터베이스를 보유하려는 경우입니다. 데이터베이스를 변경하거나 모든 데이터베이스에서 무언가를 수행하는 것을 포함하여 관리하기가 정말 어려울 수 있습니다. 많은 수의 여러 데이터베이스에서 발생하는 작업은 너무 많은 테이블을 열어야하기 때문에 느려질 수 있습니다.
그러나이 경우를 제외하고는 여러 데이터베이스가 더 좋습니다.
중요하지는 않지만 유용 할 수있는 한 가지 이점은 각 클라이언트가 다른 클라이언트가 레코드를 추가했기 때문에 무리를 건너 뛸 수있는 대신 고유 한 순차적 ID를 얻는다는 것입니다.
또한 여러 데이터베이스를 사용하면 전화 테이블과 같은 하위 테이블을 이러한 테이블의 부모 레코드 ID 없이도 클라이언트별로 쉽게 사용자 지정할 수 있습니다.
먼저 아티팩트 시퀀싱. 정수 기본 키를 사용하여 이것을 제공한다고 가정합니다. 실제로 별도의 "아티팩트 번호"열이 있어야합니다. PK는 PK 여야하며 그 밖의 다른 것은 아닙니다. 사람들은 "천연 열쇠"등에 대해 이야기하고 울었습니다. 당신이 PK를 식별자 이상으로 의존 할 때마다 당신을 물게됩니다. 무언가의 순서를 알고 싶다면 날짜 또는 순서 번호를 저장하십시오.
귀하의 경우 구성 관리가 단일 데이터베이스로 당신을 이끌 것이라고 생각합니다. 데이터베이스 유지 관리 및 업그레이드에 소요되는 비용을 확인하십시오. 소프트웨어의 각 릴리스와 관련된 비용은 무엇입니까? 또한 새로운 고객을 확보하고 DB를 생성하고이를 위해 앱을 구성해야 할 때의 비용에 대해서도 생각하십시오. 문제는 100 개의 데이터베이스가있을 때 그만한 가치가 있습니까?
길을 가면 100 개의 데이터베이스에 대해 동일한 것보다 단일 데이터베이스를 확장 (파티션, 하드웨어, 샤딩 등)하는 것이 더 쉽습니다.
나는 다른 포스터가 몇 가지 훌륭한 점을 지적했다고 생각합니다.