높은 동시 쓰기 데이터베이스를위한 인프라

내 요구 사항은 다음과 같습니다

• 3000 연결
• 70-85 % 쓰기 대 읽기

현재 700 개의 연결에서 High-CPU, Extra Large Instance를 최대한 활용하고 있습니다. 8 개의 코어가 모두 최대입니다. 메모리가 좋기 때문에 동시 연결 수라고 생각합니다. 쓰기 자체는 매우 간단합니다 (유효성 확인이 느림). 3000으로 확장하려면 현재 옵션 인 여러 서버로 이동해야합니다.

• MySQL 샤딩
• MongoDB 클러스터
• 카산드라
• 하둡 및 MySQL (Hadoop 캐시, MySQL에 대한 단일 덤프)
• MongoDB 및 MySQL (Hadoop 대신 캐시에 mongo를 사용함)

이 연결 수를 처리하려면 다음과 같은 여러 가지 질문이 있습니다.

1. MySQL Sharding은 동시 연결을 처리 할 수 ​​있습니까?
2. 단일 마스터가 이러한 동시 연결을 처리 할 수 ​​있습니까? 아니면 Mongo와 같은 다중 헤드가 더 나은 옵션입니까?

내 문제를 잘 설명하지 않으면 사과드립니다. 질문하십시오.

MySQL을 기본 데이터베이스로 사용하는 경우 MySQL 복제를 통한 스타 토폴로지 사용을 고려할 수 있습니다.

자, UGHHH, ROFL 및 OMG to MySQL Replication에 대해 이야기하기 전에 들으십시오.

스타 토폴로지를 사용하면 하나의 DB 서버 (DM (Distribution Mster))에 쓰고 SQL 명령을 여러 DB 서버에 보낼 수 있습니다. 이러한 DB 인프라를 어떻게 설정합니까?

설명은 다음과 같습니다

5 개의 DB 서버 (서버 A, B, C, D, E)가 있습니다

서버 A

• MySQL 복제 설정에서는 마스터가됩니다.
• DM으로서 특별한 역할을합니다
• 서버 마스터 B, C, D, E
• 모든 테이블은 스토리지 엔진 BLACKHOLE (/ dev / null)을 사용합니다.
• 이진 로그 만 저장
• 베어 메탈 머신
• 혜택
  • DM의 모든 테이블이 BLACKHOLE을 사용하므로 매우 빠른 쓰기
  • 읽기가 DB 활동의 15-30 %이므로 네트워크 대기 시간은 문제가되지 않습니다.
  • 모든 슬레이브는 DM에서 엄격하게 업데이트됩니다

서버 B, C, D, E

• A의 노예
• 무거운 SELECT를위한 기반 서버
• 서버는 가상 또는 베어 메탈 일 수 있음
• 사용자 테이블이 스토리지 엔진 InnoDB를 사용하는 모든 서버
  • 웜 스탠바이 DB 서버로 서버 가능
  • 방해받지 않는 백업을 실행할 수 있습니다
• 사용자 테이블이 스토리지 엔진 MyISAM을 사용하는 모든 서버
  • 읽기 전용 oprion으로 설정
  • 읽기를 가속화하기 위해 테이블의 행 형식을 다시 실행할 수 있음

나는 전에 이것에 대한 게시물을 작성했습니다

• /server/264374/mysql-in-star-topology/264444#264444
• /programming/5273043/mysql-in-star-topology/5781504#5781504

MySQL 복제를 최상의 상태로 유지하려면

• MySQL 5.5 사용
• 반 동기식 복제 사용
• 더 많은 CPU를 사용하도록 InnoDB 조정

MySQL 클러스터는 샤딩에 대한 또 다른 접근법 일 수 있습니다. 여기에서 게시물을 확인하십시오 .

나는 또한 Cassandra의 열렬한 팬이지만 데이터 모델과 수행하려는 쿼리에 많이 의존합니다. Cassandra는 항상 디스크에서 순차적이기 때문에 쓰기 속도가 빠릅니다.

멀티 헤드를 사용하려는 경우 (실제로 3K 활성 연결이 필요한 경우 필요할 수 있음) Riak 또는 Cassandra를 볼 수 있습니다. 실제로 앱이 얼마나 잘 맞는지에 따라 다르지만 설명 한 내용에서 Riak과 같은 것에 적합하다고 생각합니다.

즉, 데이터를 분할하는 좋은 방법을 찾을 수 있고 크로스 샤드 자료의 필요성을 최소화 할 수 있다면 샤드 접근 방식이 상당히 가능해 보입니다. 나는 mysql에서 반지 / 별 / mmm 물건을 멀리하고 똑바로 샤딩을 고수합니다. 실제로 Postgres를 기꺼이 사용하려는 경우 heroku와 같은 스키마를 사용하여 프로토 타입을 쉽게 프로토 타입 한 다음 개별 노드를 초과하여 데이터베이스를 포크 및 분할 할 수 있습니다.

아, 그리고 당신이 수직으로 (3K 콘을 처리하는 단일 노드) 이와 같은 것을 확장하려고 시도 할 수 있다고 생각하지만, 클라우드에서 그것을 할 수 있다고 생각하지 않습니다.

특정 응용 프로그램의 옵션 인 경우 비동기식 방법을 사용하여 데이터베이스에 데이터를 쓰거나 (작업 대기열, 배치 삽입물 ...) 프록시를 사용하여 데이터베이스에서 많은 클라이언트 연결을 멀리 전환 할 수 있습니다 .

샤딩을 사용하면 일반적으로 정밀하게 확장 할 수 있지만 (2x db-servers == 2x 연결) 데이터 세트의 특성과 샤드간에 분할하는 방법에 따라 크게 달라집니다.

개인적으로 MongoDB는 관리 용이성, 확장 성, 일반적인 사용 편의성으로 선호합니다. 또한 실제로 RDBMS가 필요하지 않으면 SQL을 사용하지 않을 것입니다.

그렇게 말한 후 응용 프로그램에 가장 적합한 DB를 선택하십시오. 트랜잭션이 필요하거나 조인없이 앱을 디자인 할 수없는 경우 (또는 평범한 것이 더 합리적 인 경우) RDBMS (MySQL, PostGres 등)를 사용하십시오

개인적으로 MongoDB를 선호하지만 MySQL이 확장되지 않거나 높은 비율의 트랜잭션을 처리 할 수 ​​없다는 생각은 전적으로 허위입니다. Facebook 엔지니어링 팀 (및 그 내부의 MySQL 팀)이 이에 대해 자세히 설명합니다. Etsy Ops 팀 블로그도 확인하십시오. 그들은 MySQL도 좋아합니다.

마지막으로 MySQL 캐시에 MongoDB를 사용하지 않습니다. 이를 위해 Memcached를 사용하십시오.

Redis는 또한 특정 사용 사례를 처리하는 데 유용한 인 -RAM 키-값 저장소입니다. blog.agoragames.com에는 일부 유스 케이스를 설명하는 블로그 항목이 있습니다.

No-SQL을 생각하고 있다면 CouchDB를 확인해야합니다. 그냥 이 일반 MAINT 필요하다는 것을 알고 그것의 디스크 사용률 아래로 유지. (디스크 유틸리티의 속도와 편리함을 교환합니다 ...)

마지막으로 용량 계획은 예측하기 쉽지 않습니다. 가능한 한 현실적인 조건에서 테스트하고보고있는 내용에 따라 치료를 준비해야합니다. 슬프게도 "컴퓨터 과학"은 과학만큼이나 예술입니다.