하나의 큰 데이터베이스와 여러 개의 작은 데이터베이스

(A) 테이블 접두사를 사용하여 하나의 MySQL 데이터베이스에 응용 프로그램 인스턴스를 배포하거나 (B) 응용 프로그램의 각 인스턴스마다 다른 MySQL 데이터베이스를 사용할 수있는 상황이 있습니다.

"A"설정 :

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

최종 결과는 많은 테이블이있는 큰 db입니다.

"B"설정 :

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

최종 결과는 일부 테이블이있는 많은 데이터베이스입니다.

모든 것이 동일합니다 (예 : 데이터 양, 앱 인스턴스 수 등). 두 가지 접근 방식의 장단점은 무엇입니까? 데이터베이스 성능 및 유지 관리에 해로운 것은 무엇입니까? 애플리케이션은 PHP 5 기반이며 Apache 2.x를 통해 실행되며 MySQL 5.x를 실행하고 있습니다.

시간과 생각에 감사드립니다!

나는 수천 개의 데이터베이스 중 가장 좋은 부분을 가진 시스템을 여러 서버에 분산시켜 운영했다. 그것들은 모두 동일한 구조였으며 각 머신에있는 템플릿 데이터베이스와 동기화되었습니다.

이를 통해 데이터베이스에 과부하가 걸리는 경우 한 데이터베이스에서 다른 데이터베이스로 데이터베이스를 마이그레이션 할 수 있었으며, 클라이언트 믹스가 변경됨에 따라 다른 서버에서 새 데이터베이스를 만들어 서버 전체에 걸쳐 부하를 분산시킬 수있었습니다. 이것은 시스템에서 얻은 가장 큰 장점이었습니다. 별도의 서버에서 동시에 여러 개의 복잡한 쿼리를 수행하는 대량의 주석이 여러 개있었습니다.

이것에 대한 좋은 점은 각 서버가 오버로드되기 시작하고 믹스에 다른 서버를 추가하고 새로운 서버로 일부 db를 마이그레이션하고 멋지게 끝내면서 자신의 속도로 구성에 서버를 추가 할 수 있다는 것입니다 로드 밸런스 서버 세트. 필요할 때 시스템에 스케일을 추가하는 정말 좋고 간단한 방법입니다!

내가 하나의 거대한 데이터베이스 접근 방식이 아닌이 접근 방식을 사용 한 이유는 생성 된 잠재적 데이터베이스의 크기가 컸기 때문입니다 ... 1000 개의 데이터베이스 각각에는 200 개의 테이블이 있고 각 테이블에는 많은 개별 테이블이 있습니다. 데이터베이스는 수억 개로 구성 행의 데이터로 구성되었습니다!

단일 데이터베이스 구성에서는 특정 테이블 (약 8 개)에 수십억 행의 데이터 행이 있어야했으며 총 db 크기는 10Tb를 초과했습니다. 우리는 5Tb의 RAID 10 스토리지를 가진 여러 서버를 가질 수 있었으며 각각에 데이터베이스가 많았습니다.

그게 내가 할 것입니다! 희망이 의사 결정을 내리는 데 도움이되기를 바랍니다 ... :)

애플리케이션이 SaaS 애플리케이션을 구축하고 있습니까? 그렇다면 세 번째 접근 방식을 고려해보십시오. 하나의 차이점이있는 모든 응용 프로그램 인스턴스에 대해 공통 구조를 가진 하나의 DB가 있으면 모든 테이블에 userid / applicationid 열을 추가하십시오. 이렇게하면 응용 프로그램 개발 / 유지 보수 비용이 크게 줄어 듭니다. 내 경험상 이것은 다중 테넌트 데이터를 저장하는 가장 좋은 방법 중 하나입니다.

멀티 테넌트 데이터 아키텍처에 대한 Microsoft 의이 백서 도 참조하십시오.

또한 언급 한 접근 방식의 장단점을 강조합니다.

설정 B는 관리하기 쉬운 방법

각각 tablen다른 폴더에 있습니다. OS 제한을 테스트하지 않으려는 경우 매우 유용 할 수 있습니다. .

예를 들어, 고용주는 CRM 자동차 대리점 시스템을 위해 MySQL을 호스팅합니다. 고객은 800 개의 대리점을 보유하고 있습니다. 각 대리점 데이터베이스에는 160 개의 테이블이 있습니다. 128,000 개의 테이블입니다.

• 설정 A에서 모든 128,000 개의 테이블은 하나의 데이터베이스에 있습니다.
• 설정 B에서 160 개의 각 테이블 세트는 / var / lib / mysql 아래의 하위 폴더에 있습니다.

OS의 관점과 폴더 당 최대 파일 수를 포함하여 i- 노드 (또는 Windows의 경우 FAT 테이블)를 처리하는 기능에서

• 설정 A에서 한 폴더 아래 약 128,000 개의 파일이 걱정됩니다. OS가 단일 폴더에서 많은 파일을 지원할 수 있습니까?
• 설정 B에서 그러한 걱정은 없습니다.

ALTER TABLE또는 다른 DDL을 사용하여 테이블 구조를 tweek해야하는 경우 :

• 설정 A에서 특정 테이블 이름 및 해당 쿼리에 대해 PHP (또는 특수 MySQL 스크립트)를 사용하여 필요한 DDL을 액세스하고 변경하기 전에 스크립트를 작성해야합니다.
• 설정 B에서 올바른 데이터베이스에 연결 한 다음 매번 동일한 명명 된 테이블에 액세스하십시오. 액세스 패러다임은 항상 깨끗합니다.
  • 특정 데이터베이스
  • 아래의 특정 폴더 /var/lib/mysql
  • 특정 테이블 이름.

다른 디스크에 다른 데이터베이스를 배치하려면 다음을 수행하십시오.

• 설정 A에서 별도의 디스크로 이동 된 모든 테이블의 심볼릭 링크는 "폴더의 inode 수"문제 만 악화시킵니다. 디스크 I / O 및 전체 테이블 액세스로 인해 더 복잡해지고 전체 서버로드가 증가합니다..frm 는 파일이 반복적으로 액세스 .
• 설정 B에서 전체 데이터베이스 폴더를 별도의 데이터 마운트로 옮기십시오. 디스크 I / O는 필요할 때 배포 할 수 있습니다.
• 주의 사항 : InnoDB에 대한 낙심

은유 적으로 말하면, 당신은 어느 쪽을 원하십니까?

• 침실 1 개, 욕실 1 개 및 주방 1 개가있는 거대한 아파트 (SetupA)
• 침실, 욕실 및 주방이 각각있는 여러 아파트 (SetupB)

아파트에 라디에이터를 고정시킬 때 :

• 설정 A를 사용하면 모든 테넌트가 불편을 겪을 수 있으며 모든 사람의 비즈니스처럼 모든 사람 앞에서 영향을받는 테넌트와 대화해야하므로 참여해야합니다
• Setup B를 사용하면 벽이나 파이프에서 튕기는 소리를 듣는 것 외에 세입자는 개인 생활을 계속할 수 있습니다
• 이 목록과 그 은유는 계속해서 갈 수 있습니다

IHMO 예산은 의사 결정을 설계 / 인프라 결정하는 원동력이 될 수 있지만 클라이언트마다 별도의 데이터베이스를 선호합니다.

또한 SaaS 제품이 있으며 Dave Rix가 언급 한 것과 동일한 설정을 사용합니다.

각 고객은 자신의 데이터베이스를 가지고 있습니다

몇 가지 제안을 더 드리겠습니다.

• 데이터베이스 위치 (ip), 데이터베이스 이름 및 고객 이름을 저장하는 데이터베이스 "제어기"로드 밸런싱 (마스터-마스터)이 있어야합니다. 이 컨트롤러는 애플리케이션이 각 고객 데이터베이스의 위치를 ​​알고있는 곳입니다.

• 응용 프로그램은 원하는 곳 어디에서나 가능합니다. 전 세계 여러 데이터 센터에 대한 데이터베이스를 보유 할 수 있습니다.

• 애플리케이션이 원하는만큼 커질 수 있습니다. Web SaaS 인 경우 고객 로그인 시간에 따라 각 데이터베이스를 가리키는 부하 분산 웹 서버 팜을 만들 수 있습니다.

• 다른 고객에게 영향을주지 않고 일부 고객을 위해 사용자 정의 된 VIEW / 데이터베이스를 작성할 수 있습니다. 비즈니스의 일부로 사용자 정의를 제공하려는 경우 중요합니다.

• 두 개의 웹 팜 + 데이터베이스 팜을 설정할 수 있습니다. 하나는 "EDGE"용이고 다른 하나는 "STABLE"릴리스 용입니다. 그런 다음 모든 고객에게 적용하기 전에 사물을 테스트하고 모든 것이 예상대로 작동하는지 (즉, 품질 보증 [QA]) 확인하려는 소규모 고객 그룹이 있어야합니다.

• 최소한 하루에 한 번 데이터베이스 당 자동 백업 작업이 있어야합니다.

• 복제를 수행 할 다른 서버가 있어야합니다. 동일한 양의 "마스터"및 "슬레이브"호스트 서버를 감당할 수없는 경우 동일한 호스트가 많은 데이터베이스를 복제 할 수 있습니다 (동일한 호스트의 각 서버에 대해 다른 포트 사용).

  예를 들어, 5 개의 마스터 서버 + 5 개의 데이터베이스가있는 1 개의 슬레이브 서버 (다른 포트에서 실행)-RAM이 충분합니다.

• 원할 때마다 한 데이터베이스를 다른 서버로 이동하려면 "마이그레이션"도구를 사용해야합니다.

• 수익을 보호하려면 VIP 고객을보다 안전하고 사용 가능한 데이터베이스 서버로 마이그레이션해야합니다. 고객의 20 %가 수익의 80 %를 나타내는 경우가 많습니다. 특별 고객 관리.

• 고객이 회사를 떠날 때 "마지막 백업"을 수행하고 데이터베이스를 삭제하려면 백업 삭제 "가비지"콜렉터가 있어야합니다.

• 새 계정으로 내보내고 사용할 데이터베이스 이미지가 있어야합니다.

• 기존 계정에 새 패치를 적용하려면 데이터베이스 패치 도구가 있어야합니다.

• subversion 또는 git와 같은 버전 관리 도구를 사용하여 모든 SQL 패치의 버전을 유지하고 고유 한 번호 매기기도 만듭니다. xxx-4.3.0.sql-때때로 패치가 잘못되어 패치 작업을 복구 / 완료하는 방법을 알아야합니다.

글쎄, 이것은 약 600 테이블이 각각 약 5k 데이터베이스가있는 제품으로 회사에서 수행하는 모든 것입니다.