mysql 데이터베이스에는 약 2TB의 데이터가 있습니다.
마스터-슬레이브-슬레이브 복제가 실행 중입니다. 데이터베이스를 사용하는 애플리케이션은 2개의 슬레이브 중 하나에서만 쿼리를 읽고(SELECT) 마스터에서는 쿼리를 작성(DELETE/INSERT/UPDATE)합니다. 애플리케이션은 쓰기보다 읽기를 훨씬 더 많이 수행합니다.
읽기(SELECT) 쿼리에 문제가 있는 경우 다른 슬레이브 데이터베이스를 추가하고 애플리케이션에 또 다른 해결책이 있음을 알릴 수 있습니다. 그래서 잘 늘어나요...
현재 마스터는 쓰기로 인해 약 40%의 디스크 IO를 실행하고 있습니다.
그래서 앞으로 데이터베이스를 어떻게 확장할지 고민 중이에요. 언젠가는 마스터가 과부하될 것이기 때문입니다.
거기에 대한 해결책은 무엇입니까?
어쩌면 mysql 클러스터일까요? 그렇다면 데이터베이스를 ndb로 전환하는 데 함정이나 제한 사항이 있습니까?
많은 감사드립니다... :)
답변1
MySQL 확장에 대한 모든 경우에 적용되는 일률적인 답변은 없습니다.몇 가지 일반적인 팁:
가능한 한 "대각선으로" 확장하십시오. 상용 하드웨어에서 실행할 수 있는 한 단일 MySQL 서버에 작업을 유지하십시오. 이는 아마도 쿼드 코어 CPU 2개, 64GB RAM, 디스크 RAID 10 8개 이상을 의미할 것입니다. "상용 하드웨어"의 상단은 매년 점점 더 빨라지고 있습니다.
LiveJournal 확장에 대한 Brad Fitzpatrick의 프레젠테이션을 살펴보십시오. LAMP 확장에 관한 한 거의 고전적입니다. ~에이 프레젠테이션의 25~26페이지MySQL 복제에서 결국 직면하게 될 문제는 다음과 같습니다. 쓰기 작업은 사용 가능한 모든 디스크 I/O를 소비합니다.
읽다 "고성능 MySQL". 정말 좋은 책이에요.부하가 높은 MySQL 설치를 많이 본 저자.
가능한 한 샤딩(많은 MySQL 서버에 데이터 분산)을 피하세요.샤딩을 시작하면 관계형 데이터베이스의 대부분의 이점을 포기하고 개발 속도가 느려집니다. 샤딩을 수행해야 하는 경우 fx Riak, Cassandra, HBase, MongoDB와 같은 다중 서버 모델이 내장된 NoSQL 데이터 저장소를 대신 사용하는 것이 좋습니다. 이상적으로는 MySQL과 NoSQL 간에 "기능적 파티셔닝"을 수행하여 RDBMS에 잘 맞는 덜 핫한 데이터에는 MySQL을 계속 사용하고 MySQL과 결합할 필요가 없는 '핫' 데이터에는 NoSQL 엔진을 사용합니다. 데이터.
어쩌면 mysql 클러스터일까요? 그렇다면 데이터베이스를 ndb로 전환하는 데 함정이나 제한 사항이 있습니까?
안에 "웹 운영" Baron Schwartz가 쓴 MySQL에 관한 장이 있습니다. 그는 웹 사이트 환경에서 MySQL Cluster/NDB를 사용하는 것에 대해 "아니요!"라고 거의 말합니다. 인용문: ".. 조인 및 GROUP BY 쿼리에서는 성능이 좋지 않습니다. 웹 애플리케이션에는 그런 것이 필요합니다.".
답변2
MySQL 클러스터링은 데이터베이스를 여러 시스템에 분산된 조각으로 나누어 쓰기 확장성을 확보합니다. 그러나 여러 조각에서 데이터를 가져오는 복잡한 쿼리 속도가 크게 느려집니다. 이것이 애플리케이션 성능에 미치는 영향은 오직 귀하만이 판단할 수 있습니다.
클러스터링 엔진이 자동으로 수행하도록 하는 대신 데이터를 수동으로 샤딩하는 것을 고려할 수 있습니다. 더 많은 구성이 필요하지만 애플리케이션이 데이터베이스를 사용하는 방식을 이해하면 대부분의 쿼리가 하나의 샤드에만 액세스하도록 허용하는 샤딩 체계를 생각해 낼 수 있습니다.
답변3
MySQL 복제는 단일 스레드이므로 복제가 마스터 용량에 의해 제한되지 않고 마스터 뒤에 있을 수 없고 동기화되지 않는 슬레이브에 의해 제한될 수 있다는 점을 기억하십시오.이 기사에서:
복제 재생 프로세스는 복제본의 단일 스레드에서 실행되므로 많은 업데이트가 동시에 발생하는 기본에서 중간 정도의 쓰기 로드도 따라잡을 수 없습니다.
답변4
정보 자체를 클러스터링하는 것에 대해 생각할 수 있습니다. 가능하다면 - 서로 다른 서버 간에 쓰기 소비 테이블을 분리하는 것입니다.