MySQL 사용자 정의 값 - 많은 테이블에서 EAV 대 샤딩하기

Question

현재 시스템의 핵심 기능으로 사용자가 사용자 정의 유형을 정의 할 수있는 멀티 테넌트 시스템이 개발 중입니다. 예를 들어 이벤트, 계정, 주문, 배송 등을 정의합니다. 시스템의 모든 사용자는 필드의 관점에서 관리하려는 내용에 대해 서로 다른 정의를 갖습니다. 따라서 한 사용자에게는 주문 번호, 상태 및 만기일이있을 수 있습니다. 다른 사용자의 경우 10 개의 필드가있을 수 있습니다.

내가 작업하고있는 개발자는 EAV를 사용하여이 데이터를 저장하려고합니다. 나는이 생각에 반대한다. 나는이 사이트에서 많은 기사를 읽었을뿐만 아니라 인터넷 전체에이 반 디자인 패턴의 단점을 열거하고 있지만 필자가 취할 생각은 전혀 언급하지 않았다. 이 응용 프로그램을 처음부터 확장 가능하도록 빌드하려고합니다.

내가 수학을 할 때, 나는 1000 명의 세입자가 있고, 각각 평균 ​​5 가지 유형 (5000 가지)이있다. 각 유형에는 1000 개의 레코드 (예 : 5,000,000 개의 레코드)가 있습니다. 각 레코드는 평균 5 개의 필드로 EAV 모델의 최저 레벨에서 총 25,000,000 개의 행을 제공합니다.

다운 스트림 프로세스는 각각의 개별 사용자 데이터를 jquery 그리드에 바인딩하므로이 데이터를 먼저 가져 와서 데이터를 조 변경하면 비용이 많이 드는 것처럼 보입니다. 10k 임차인이나 50,000 명의 임차인이있을 때 어떻게 될지 ... MySQL이 최적화되었을 때 MySQL이 이러한 유형의 작업을 처리 할 수 ​​있다는 것을 이해합니다.하지만 발로 직접 촬영하는 것처럼 보입니다.

다른 방식으로하고 싶습니다. 그러나 나는 내가 아는 모든 것을 거스르는 것에 대해 내가 제안하고있는 것에 대해 나쁜 감정을 가지고있다. 그래서 나는 나의 접근법을 입증하거나 비판하는 실제 지식을 가진 진정한 전문가를 원한다. 당신이 유효성을 확인했다면, 내가 그것을 지원하고 그것이 작동하도록하기 위해해야 ​​할 일을 말해주십시오. 비판을한다면, 단기간과 장기간에 내가 맞을 함정을 말해주세요.

나의 제안.

1. 특정 샤드에 최대 세입자가 있도록 도메인 분할을 사용하여 시스템을 분할합니다. 마스터 카탈로그는 세입자가 어떤 샤드에 속해 있는지를 나타냅니다.
2. 각 샤드에 대해 사용자가 유형을 정의 할 때이 유형을 보유 할 새 테이블을 생성하십시오. 샤드에서 매핑 테이블을 잡고 사용자를 정의 된 유형 (사용자 정의 테이블)에 연결합니다.

이것은 본질적으로 하나의 샤드와 1000 개의 사용자 정의 테이블에 몇 가지 핵심 테이블을 갖출 예정이라는 것을 의미합니다.

나에게 일반적으로 데이터베이스에있는 많은 테이블을 가지고 있으면 일반적으로 스키마에 문제가 있거나 뭔가 잘못 설계된 것으로 나에게 알려주지 만,이 시나리오에서는 스키마가 잘못되었는지를 알고 싶어합니다. 실현 가능한 접근법. 앞의 예에서, 샤드에 5000 개의 테이블이 있고, 단지 각각 1000 개의 행이 있다는 것을 의미합니다. EAV를 사용하는 것보다 나에게 더 나은 접근법으로 보인다. 사용자를 기준으로 유형을 찾고 그리드에 데이터를 바인딩합니다.

일부 노트는 멀티 테넌트 아키텍처는 사용자가 자신의 사용자가있을 수 있습니다

1. 을 고려합니다. 따라서 잠재적으로 1000 명의 가입자가 있지만 5000 명의 사용자가 있습니다. 따라서 데이터베이스 연결을 관리해야합니다. 연결을 관리하는 데 문제가 발생합니까?

2. 테이블 캐싱 관련 문제가 발생합니까? 테이블을 씻어 내는데 문제가 있습니까?

3. 어디에서이 디자인의 성능 문제가 발생할 수 있습니까? 마스터 카탈루어 데이터베이스가 병목 일 수 있지만이 데이터베이스의로드가 너무 무거울 수는 없다는 것을 알고 있습니다.

4. 개발이 이미 시작되었으므로 NoSQL 데이터베이스로 변경하라고 요청하지 마십시오!

또 다른 제안은 EAV를 계속 사용했지만 샤드 내에서 사용하는 것이 었습니다. 이 아이디어에 대해 어떻게 생각하십니까?

펀치를 당기지 마십시오. 나는 그 모든 것을들을 필요가있다. 미리 감사드립니다.

Answer 1

데이터 스케일링 측면에서 보면 비교적 작은 수천 개의 사용자 정의 테이블을 관리하는 것이 EAV를 사용하는 것보다 효과적 일 것입니다. 저는 단일 MySQL 인스턴스에서 100,000 개가 넘는 테이블을 가진 고객을 위해상의했습니다.

인스턴스에 수만 개의 테이블이있을 때 서로 다른 확장 성 문제가 발생하지만, 샤딩을 지원하는 아키텍처가 이미 있다면 사용자를 세분화하여 준비하지 않아도됩니다. 어느 한 인스턴스에 너무 많은 것을 가지고있다.

사용자를 shard 인스턴스로 매핑하는 일이 매우 드물기 때문에 카탈로그 테이블은 캐시에 넣는 것이 좋습니다 (예 : memcached). 그러면 카탈로그의로드가 줄어 듭니다.

또한 카탈로그에 대한 MySQL의 파티셔닝과 사용자를 사용자 정의 테이블에 매핑하는 테이블을 살펴볼 것입니다. 뿐만 아니라 다른 일반적인 (비 사용자 지정) 테이블. 사용자 ID로 파티션을 분할하고 파티션 정리에 의존하여 다중 사용자 테이블을 더 작은 테이블처럼 작동하게 만들 수 있습니다.