4

비교적 작은 데이터베이스로 작업하고 있습니다. 총 67 개의 테이블과 100 만 개가 넘는 레코드가 있습니다. 그것은 약 254 MB입니다. 이 소프트웨어와 함께 작동하는 응용 프로그램은 약 5 년간 실행되었으며 사용량은 매년 두 배로 증가했습니다. 올해 우리는 3 배가 될 것으로 예상되는데, 이는 어느 정도 규모의 데이터베이스를 거의 두 배로 늘릴 것입니다. 제 질문은, 데이터베이스를 여러 데이터베이스로 분할하는 것은 나쁜 생각입니까? 300 개의 클라이언트가 있다고 가정하면 67 개의 테이블을 포함하는 300 개의 개별 데이터베이스를 만들지 만 해당 클라이언트에 관련된 데이터 만 만듭니다. 다른 서버에서 수행 할 수있는 내부 통계 외에 데이터가 함께 존재해야하는 이유는별로 없습니다. 평생 동안 10,000 명이 넘는 고객이되어서는 안됩니다.클라이언트 당 mysql 데이터베이스 분할하기

문제는 우리가 "마스터 데이터베이스"스키마를 변경해야이

는 또한 복제가 도전이 될 것

은 "슬레이브 데이터베이스"모든 전반에 걸쳐 변화를 복제해야 할 때이 설정 인 참조 새로운 클라이언트가 추가 될 때.

코드 수준의 응용 프로그램은이 유형의 설정에 대해 거의 설정되어 있습니다.

누락 된 항목이 있습니까? 이것은 끔찍한 생각입니까?

데이터베이스는 미래를 염두에 두지 않고 서둘러 (날이 아닌) 만들어졌으며 이제는 내 책임입니다.

정규화, 필드 유형 감사, SQL 최적화, 색인 작성 및 서버 조정까지 수행해야 할 작업이 많습니다. 모든 의견은 크게 감사하겠습니다.

답변

0

내가 가지고있는 질문은 데이터베이스에 어떻게 액세스합니까? 클라이언트마다 하나의 응용 프로그램이 설치되어 있습니까? 그렇다면 데이터베이스를 별도로 유지하면 응용 프로그램을 업그레이드 할 때 약간의 시간을 절약 할 수 있습니다 (응용 프로그램을 업데이트 할 때만 데이터베이스를 업데이트하면되므로). 하나의 응용 프로그램 설치로 액세스하는 경우이를 유지하십시오.

하지만 다른 고려 사항이 있습니다. 당신은 오늘 크기가 256 만 메가 바이트의 1 백만 행이라고 언급합니다. 그것은 상품 서버의 범위 내에서 매우 쉽게 이루어져야합니다. 따라서 매년 최악의 5 배 성장이 예상된다면 금년에는 5 백만 행, 다음은 25 행, 세 번째 행은 125 행, 네 번째 행은 625 행, 다섯 번째 행은 3 억 2 천 5 백만 행입니다. 심지어 정확한 사용법 및 쿼리 유형에 따라 30 억 개의 행 (MySQL의 경우 여전히 상한 서버 범위 내에 있음)을 처리하기가 어렵지 않습니다.

문제가 발생하면 client 키의 각 (또는 주요 테이블)은 항상 partition 일 수 있습니다 ... MySQL이 자동으로 관리하므로 유지 관리의 어려움이 없습니다.

+0

그것은 웹 응용 프로그램입니다. 그런 다음 테스트 클라이언트에 변경 사항이 적용된 다음 전개됩니다. – rizzo0917

+0

맞습니다.하지만 웹 응용 프로그램의 인스턴스가 하나만 있습니다. 맞습니까? 하나의 웹 사이트 만이 모든 데이터에 액세스한다는 것을 의미합니다. (각 클라이언트마다 다른 웹 사이트를 만드는 대신) ... – ircmaxell

1

현재 당신은 4 분의 1 데이터를 가지고 있습니다. 올해는 두 배로 늘릴 계획입니다. 1997 년인가요? 아니요 2010 년이며 사람들은 휴대 전화에 의 기가 바이트를 가지고 있습니다.

문제는 무엇을 해결하려고합니까? 사소한 양의 데이터이기 때문에 저장소가 될 수 없습니다. 성능이라면 여러 데이터베이스로 분할하면 데이터베이스 당 서버를 예상 할 때 상황이 악화 될 수 있다고 생각합니다. 보안 관점에서 보면 별도의 데이터베이스에 대한 논점이 있지만 이러한 우려를 해결하는 다양한 방법이 있습니다.

현재 환경에 문제가 있습니까? 아니면 적어도 12 개월 동안 문제가 생길 수 있다는 추세가 있습니까? 그렇지 않다면, 단단히 앉으십시오.그렇다면 명확하게 공식화 한 다음 300 개의 데이터베이스가 이러한 문제를 어떻게 해결할 것인지, 그리고 피할 수없는 슬픔의 가치가 있는지 여부를 파악하십시오. 그런 다음 슬픔을 재조정하여 10000 명의 사용자를 고려한 다음 다시 질문하십시오.

가장 좋은 답변은 "만 개의 데이터베이스"이지만 그다지 많지는 않은 질문이있을 수 있습니다.


는 "우리의 가장 큰 클라이언트는 연간 약 12,000 기록을 추가합니다."

을 즉 하나 개의 레코드 매 10 일 분 (여덟 시간 일을 가정)에 대해. 이것은 큰 쓰기로드처럼 보이지 않습니다.

"아이디어는 다음 클라이언트가 모든 데이터를 를 이동하지 않고, 그것은 단지 자신의 데이터에 액세스합니다."

그러나 많은 양의 데이터는 아니며 적절한 색인 생성 전략으로 해결할 수없는 것은 아닙니다.

실제 실제 문제가 인지 아직 이해하지 못했거나 향후 어느 시점에서 문제가 될지도 모릅니다.

+0

문제는 성능입니다. 우리의 가장 큰 고객은 연간 약 12000 개의 레코드를 추가합니다. 우리의 평균 고객은 연간 약 1000 건입니다. 아이디어는 클라이언트가 모든 데이터를 거치지 않고 단지 데이터에 액세스하는 것입니다. 그것이 당신이 할 가능성이 있다고 말했을 때 그것이 어떻게 성능을 악화시킬 것입니까? – rizzo0917

+0

비교적 작은 (예 : 12k는 SMALL) 레코드로 인해 성능 문제가있는 경우 쿼리를 리팩터링하여보다 효율적으로 조사해야합니다. – drudge

0

여러 클라이언트를 허용하도록 현재 스키마를 수정하고 n 번째 클라이언트에 도달 할 때 성능이 떨어지면 (SELECT 최적화가 도움이되지 않음) 새 서버를 추가 할 수 있습니다. 우리의 경우에는 데이터를 "사이트"로 나누어 한 사용자가 자신의 사이트에없는 데이터에 액세스 할 수 없도록합니다.

4

당신은 "정상화, 필드 유형 감사, SQL 최적화, 인덱싱 및 서버 튜닝"

300 데이터베이스에 그 분할 할 이유가 없습니다 전체 손을 가지고있다. 그리고 당신이 분명히 말하지 않은 많은 좋은 이유들. CustomerId가 고객 데이터를 데이터베이스를 통해 명확하게 구분하는 한 괜찮습니다.

당신이해야 할 일을하고, 더 불필요한 작업을하지 마십시오.

데이터베이스 크기와 속도가 좋지 않으면 실제 SQL 플랫폼으로 이동하십시오.

0

SAP ERP를 살펴보십시오. 잠재적으로 수천 명의 고객과 수십억의 레코더를 보유 할 수 있습니다. 그것은 전력 시스템입니다. 그리고 그것의 모든 테이블 (시스템 테이블 제외)에는 클라이언트를 지정한 "MANDT"필드가 있습니다. offcource SAP는 일반적으로 오라클과 함께 작동하지만, 당신의 경우 데이터의 일부가 희소하기 때문에 충분하지 않습니다.
그래서 SAP에서 좋은 DBMS로서의 MySQL에 관한 성공적인 히스토리 및 친절한 의견에 따르면 나는 고객들 사이에서 DB를 빼앗아서는 안된다고 결론 내릴 수 있습니다. 이것은 많이 산출하지 않을 것입니다

관련 문제