내 요구 사항은 다음과 같습니다
- 3000 연결
- 70-85 % 쓰기 대 읽기
현재 700 개의 연결에서 High-CPU, Extra Large Instance를 최대한 활용하고 있습니다. 8 개의 코어가 모두 최대입니다. 메모리가 좋기 때문에 동시 연결 수라고 생각합니다. 쓰기 자체는 매우 간단합니다 (유효성 확인이 느림). 3000으로 확장하려면 현재 옵션 인 여러 서버로 이동해야합니다.
- MySQL 샤딩
- MongoDB 클러스터
- 카산드라
- 하둡 및 MySQL (Hadoop 캐시, MySQL에 대한 단일 덤프)
- MongoDB 및 MySQL (Hadoop 대신 캐시에 mongo를 사용함)
이 연결 수를 처리하려면 다음과 같은 여러 가지 질문이 있습니다.
- MySQL Sharding은 동시 연결을 처리 할 수 있습니까?
- 단일 마스터가 이러한 동시 연결을 처리 할 수 있습니까? 아니면 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 필요하다는 것을 알고 그것의 디스크 사용률 아래로 유지. (디스크 유틸리티의 속도와 편리함을 교환합니다 …)
마지막으로 용량 계획은 예측하기 쉽지 않습니다. 가능한 한 현실적인 조건에서 테스트하고보고있는 내용에 따라 치료를 준비해야합니다. 슬프게도 “컴퓨터 과학”은 과학만큼이나 예술입니다.