Weibo 데이터베이스에 대한 정보 : 세 가지 변경 사항 뒤에 숨겨진 디자인 아이디어

Weibo 데이터베이스에 대한 정보 : 세 가지 변경 사항 뒤에 숨겨진 디자인 아이디어

편집자 주 : 고 가용성 아키텍처 공유 및 보급은 아키텍처 분야에서 일반적으로 중요한 기사이며,이 기사는 고 가용성 아키텍처 그룹의 Xiao Peng이 공유합니다. 고 가용성 프레임 워크 공용 계정 "ArchNotes"에서 가져온 것임을 표시하십시오.

Weibo R & D Center의 기술 관리자 인 Xiao Peng은 주로 Weibo 데이터베이스 (MySQL / Reids / HBase / Memcached)와 관련된 비즈니스 보증, 성능 최적화, 아키텍처 설계 및 주변 자동화 시스템 구축을 담당하고 있습니다. 서비스 보증 및 SLA 시스템 구축, 마이크로 블로그 다중 컴퓨터 실 구축, 마이크로 블로그 플랫폼 전환 및 기타 프로젝트를 포함한 다양한 단계의 마이크로 블로그 데이터베이스 아키텍처 전환 경험, 데이터베이스 고성능 및 고 가용성에 중점을 둔 인터넷 데이터베이스 아키텍처 및 관리 경험 10 년 기술 지원 방향.

데이터베이스 전문가의 성장에 대한 느낌

"MySQL에서의 첫 번째 직업은 주로 관심사였습니다. 첫 번째 직업은 소규모 회사였습니다. 제한된 인원으로 인해 다양한 분야에서 일을해야했습니다. 대조적으로 데이터베이스에 가장 관심이 있다는 것을 알게되어 데이터베이스 관련 기술 작업. 근무 년 수가 늘어남에 따라 데이터베이스에 축적 된 경험이 점차 증가하고 있으며, 데이터베이스 관리자 (DBA)가보다 실용적인 유형의 작업이며 많은 이론적 작업이 실제로 존재하는 것으로 느껴지고 있습니다. '반 패러다임'설계 등 다양한 변화가있을 것이므로 데이터베이스 전문가가 되려면 좋은 환경을 선택하는 것이 좋습니다. 대형 플랫폼은 양적 변화와 질적 변화로 인해 많은 도전적인 문제를 일으키는 경우가 많습니다. 이러한 질문은 기술 전문가가되는 유일한 방법입니다. "-Xiao Peng

Weibo 데이터베이스에서 경험 한 변경 사항

먼저 Weibo 데이터베이스가 경험 한 중요한 단계를 알려 드리겠습니다.

초기 단계 에서 Weibo는 비교적 간단한 기능을 갖춘 내부 혁신 제품입니다. 데이터베이스 구조는 표준 1M / 2S / 1MB 구조를 채택하고 있으며 읽기와 쓰기의 분리에 따라 설계되었습니다. 메인 라이브러리는 쓰기를 담당하고 보조 라이브러리는 액세스를 담당합니다. 액세스 압력이 너무 높으면 라이브러리 수를 확장하여 수평 확장 기능을 얻을 수 있습니다.

위 그림에서 빨간색은 쓰기, 녹색은 읽기, 검은 색은 내부 구조에 매핑되어 있습니다. 그림에서 알 수 있듯이 비즈니스는 수직으로 만 분할되어 사용자, 콘텐츠, 관계 등 비즈니스 모듈로 구분되며 데이터베이스는 별도로 사용됩니다. . 초기 단계에서 이것은 실제로 매우 좋은 아키텍처입니다. 기능 모듈을 분리하기위한 기반을 제공합니다. 문제도 쉽게 찾을 수 있습니다. 처음에는 다른 기능 모듈에 따라 다운 그레이드 할 수 있습니다.

저는 개인적으로 초기 단계에서이 아키텍처가 실제로 비즈니스의 성장을 충족시킬 수 있고 과도하게 설계 할 필요가 없으며 처음에 너무 복잡하게 만들면 민첩성이 떨어질 수 있다고 생각합니다.

발발 단계

Weibo 출시 이후 사용자 활동이 증가함에 따라 데이터베이스에 대한 부담도 증가했습니다. 우리는 먼저 빠른 비즈니스 개발을 지원하기위한 요구 사항을 충족하기 위해 고성능 하드웨어 장비를 구입하여 단일 시스템의 성능을 확장했습니다. 그런 다음 고성능 장비를 사용하여 Weibo의 전체 비즈니스를 수직 분할하는 시간을 확보하여 사용자, 관계, 블로그 게시물, 포워딩, 댓글 및 기타 기능 모듈을 별도로 저장하고 수직 분할을 기반으로하여, 대량의 데이터를 생성 할 것으로 예상되는 일부 비즈니스 모듈이 다시 분할되었습니다.

하드웨어 사용에 대해 몇 마디 더 말씀 드리겠습니다 .Weibo는 처음에 사용자 증가가 매우 높았 기 때문에이 단계에서 축적 된 기술은 그다지 풍부하지 않으며 가장 중요한 것은 아키텍처 변환을위한 시간이 없다는 것입니다. , PCIE-Flash 장치 구매로 지원되는 핵심 비즈니스가 너무 많아서 초기 피드 시스템이 MySQL에 크게 의존했다는 사실을 여전히 분명히 기억하고 있습니다. 2012 년 봄 축제 갈라 당일 MySQL은 QPS를 35,000으로 기록했습니다. 아직도 기억하고 있습니다. 새로운.

고성능 하드웨어의 가격은 일반 하드웨어에 비해 훨씬 비싸지 만 시간이 가장 소중합니다. 일부 성능 문제로 인해 제품 수명 초기에 제품 고장이 발생하여 사용자를 잃고 더 많은 손실을 입을 가능성이 높습니다. . 따라서 저는 개인적으로 문제를 해결하기위한 자금의 폭력적인 투자가 실제로 초기 발병 단계에서 가장 비용 효율적이라고 생각합니다.

블로그 게시물을 예로 들어 데이터베이스 분할에 대해 계속 이야기하십시오. 블로그 게시물은 Weibo 사용자가 생성하는 주요 콘텐츠입니다. 시간이 지남에 따라 차원이 증가하여 결국 매우 커질 것으로 예상됩니다. 비즈니스 성능 요구 사항을 충족하면서 가능한 한 적은 비용의 스토리지를 사용하는 방법은 무엇입니까? 우리는 더 어려운 문제에 직면 해 있습니다.

• 우선, 인덱스가 저장 공간을 덜 필요로하지만 컨텐츠 저장 공간에 더 많은 공간이 필요하고 둘의 사용 요구 사항이 다르며 액세스 빈도가 다르므로 구별이 필요하기 때문에 인덱스를 컨텐츠에서 분할했습니다. 치료하다.
• 그런 다음 인덱스와 콘텐츠를 먼저 해시 한 다음 시간 차원 분할 방법에 따라 수평으로 분할하여 각 테이블의 용량이 제어 가능한 범위 내에 있는지 확인하여 쿼리의 성능 지표를 보장합니다.
• 마지막으로 기업은 먼저 인덱스를 통해 필요한 실제 콘텐츠의 ID를 얻은 다음 콘텐츠 라이브러리를 통해 실제 콘텐츠를 얻고 memcached를 배포하여 전체 프로세스를 가속화합니다. 단계가 더 많은 것 같지만 실제 효과는 비즈니스 요구를 완전히 충족시킬 수 있습니다.

언뜻보기에 위의 그림은 이전 그림과 같지만 실제로는 블로그 포스트 기능 모듈의 데이터베이스 아키텍처 다이어그램에 불과합니다. 인덱스와 콘텐츠가 여러 포트로 나뉘어 있고 각 포트가 여러 DB로 나뉘어져 있음을 알 수 있습니다. 각 DB 아래의 테이블은 먼저 해시 된 다음 시간 차원에 따라 분할되므로 어떤 항목을 선택하든 이후 단계에서 용량 병목 현상이나 성능 병목 현상이 발생하면 배포 구조를 보관하거나 조정할 수 있습니다. 편의. 또한 보관 후 다른 하드웨어를 사용하여 다른 비즈니스를 수행하고 하드웨어 활용도를 높이며 비용을 절감 할 수도 있습니다.

이 단계에서 우리는 사용자, 관계, 블로그 게시물, 포워딩, 댓글, 좋아요 등 많은 Weibo 기능을 분할 및 개편했으며 기본적으로 핵심 기능을 데이터로 분할하여 병목 현상이 발생하도록했습니다. 계획에 따라 수정 및 조정할 수 있습니다.

침전 단계

마지막 단계에서 Weibo의 데이터베이스는 많은 분할 및 변환을 거쳐 규모가 기하 급수적으로 증가했으며 비즈니스의 급속한 성장 이후에도 안정화되기 시작했습니다. 이 단계에서 우리는 자동화 도구를 사용하여 급속한 확장 기간 동안 축적 된 경험을 구현하고 표준화되고 간소화 된 플랫폼 서비스를 외부 적으로 형성하는 등 자동화 구축에 집중하기 시작했습니다. 우리는 백업 시스템, 모니터링 시스템, AutoDDL 시스템, MHA 시스템, 검사 시스템, 느린 검사 시스템 및 Maya 미들웨어 시스템을 연속적으로 구성하고 변형했습니다. 그리고 내부 관리 시스템에 비해 업무 활용의 효율성을 높이고 커뮤니케이션의 배가를 줄이기 위해 데이터베이스 플랫폼 사용자를 위해 iDB 시스템을 재개발했습니다. iDB 시스템을 통해 사용자는 자신의 비즈니스 데이터베이스의 운영 상태를 쉽게 파악하고 데이터베이스의 DDL 수정 요구 사항을 직접 제출할 수 있습니다. DBA는 승인을 클릭하기 만하면 온라인 실행을 위해 로봇에 전달되므로 업무 효율성이 향상 될뿐만 아니라, 또한 안전성과 표준화를 향상시킵니다.

자동화 시스템이 많기 때문에 하나씩 설명하지는 않겠습니다. 실제로 제품이 일정 단계로 발전하면 초기 작업이 적고 변경 및 운영을 지원하기에 충분한 노동력이 있기 때문에 운영 및 유지 보수가 자동화 단계로 진입한다는 것을 알고 있습니다. , 그리고 인간의 개입이 필요한 특별한 상황이 많이 있습니다. 특히 인간의 두뇌가 판단하고 처리해야합니다.

여기에 규범의 중요성에 대한 추가 강조가 있습니다. MySQL 개발 사양의 경우 사전에 동의하고 좋은 제한을두면 개발자가 사용 중에 제약을 느끼더라도 라인에서 완전히 제어 할 수없는 오류를 피할 수 있으며 일부 문제는 사양으로 인한 것입니다. 의 존재는 결코 일어나지 않을 것입니다.

예를 들면. MySQL의 느린 검색은 느린 온라인 성능의 주요 원인이지만 대부분의 경우 인덱스가없는 것이 아니라 코드가 잘못 작성되어 암시 적 변환과 같은 문제가 발생합니다. 이 경우 암시 적 변환 가능성을 직접 제거 할 수 있도록 모든 where 조건을 큰 따옴표로 묶는 것이 일반적으로 권장되며 개발자는 코드를 작성할 때 이것이 문자 유형인지 정수인지 고의로 고려할 필요가 없습니다. 유형.

계속해서 자동화에 대해 이야기하십시오. 초기 단계와 규모 확장 이후에는 더 많은 생명과 더 적은 사람이있을 것이며, 이러한 압력은 모든 사람들이 자동으로 해결책을 찾도록 촉구하고 자연스럽게 자동화 변혁을 겪게 될 것입니다. 물론 사업이 안정된 후에 발전 할 시간이 있기 때문에 실제로는 더 중요한 이유입니다.

개인적으로 자동화는 두 단계로 나뉩니다. 첫 번째 단계는 기계로 노동을 대체하는 것인데, 이는 대부분의 기계 노동이 프로그램에 넘겨져 배치 작업 및 반복 노동 문제를 해결하는 것을 의미합니다. 두 번째 단계는 기계가 사람을 대체하는 것, 즉 기계가 사람을 위해 수행 할 수있는 것입니다. 일정량 판단 후 자기 선택은 인력을 해방시킨다. 그러나 두 번째 단계는 우리가 추구해온 이상적인 상태로 지금까지 max mem의 동적 조정 및 기타 매우 간단한 기능과 같은 매우 간단한 작은 기능 만 완료했습니다.

Weibo 데이터베이스 최적화 및 설계

다음으로 Weibo 데이터베이스 플랫폼의 최근 개선 및 최적화를 소개합니다.

데이터베이스 플랫폼은 MySQL뿐만 아니라 Redis, Memcached, HBase와 같은 데이터베이스 서비스이기도합니다. 캐시가 왕이라는 추세에 따라 Weibo는 2015 년 Redis에 연구 개발 노력을 집중했습니다.

Weibo는 이전에 Redis를 사용했고 처음에는 볼륨이 커서 실제 사용 과정에서 많은 실제 문제가 발생했습니다. 우리의 내부 브랜치 버전은 이러한 실제 문제에 최적화되어 있으며 더 특징적인 문제가 있습니다. 다음은 몇 가지입니다.

• POS 기반 동기화 기능 추가. 버전 2.4에서는 Redis의 동기화가 중단되면 마스터 데이터베이스의 "모든"데이터를 슬레이브 데이터베이스로 재전송하여 즉각적인 네트워크 대역폭 피크를 유발하고 데이터 볼륨이 큰 비즈니스의 경우 슬레이브 데이터베이스로 다시 전송합니다. 복구 시간이 느립니다. 따라서 공동 아키텍처 그룹의 학생들은 MySQL의 마스터-슬레이브 동기화 복제 메커니즘에서 배우고 Redis의 AOF를 변환하여 pos 비트를 기록하고 슬레이브 데이터베이스가 동기화 된 pos 비트를 기록하도록하여 네트워크에서 변동이 발생하도록합니다. 재전송 되더라도 데이터의 일부일 뿐이며 비즈니스에 영향을 미치지 않습니다.
• 온라인 핫 업그레이드. 사용 초기에는 많은 새로운 기능이 추가되어 Redis 버전이 지속적으로 업그레이드되었습니다. 비즈니스에 영향을주지 않기 위해 각 업그레이드마다 메인 라이브러리 스위치가 필요하여 운영 및 유지 관리에 큰 어려움을 초래하여 핫 업그레이드 메커니즘이 개발되었습니다. libredis.so를 동적으로로드하여 버전 변경을 달성하고, 메인 라이브러리를 전환 할 필요가 없으며, 운영 및 유지 관리의 효율성을 크게 향상시키고 변경 위험을 줄입니다.
• 맞춤형 변환. Redis 사용 후기 단계에서는 Weibo 제품에 대한 많은 기술적 요구 사항으로 인해 Redis와 호환되는 redisscounter가 기술 데이터를 저장하기 위해 특별히 개발되었으며, 해시 테이블 대신 배열을 사용하여 메모리 사용량을 크게 줄였습니다. 이후 판단 시나리오의 요구를 해결하기 위해 블룸 필터 기반의 팬텀이 개발되었습니다.

Redis 미들웨어
는 2015 년 자체 개발 한 Redis 미들웨어 부족 시스템의 개발 및 출시를 완료했습니다. Tribe는 중앙 노드가있는 프록시 아키텍처 설계를 채택하고 구성 서버를 통해 클러스터 노드를 관리하며 공식 Redis 클러스터 슬롯 분할 설계 아이디어를 도출합니다. 데이터 저장을 완료하기 위해 라우팅, 조각화, 자동 마이그레이션 및 장애 조치와 같은 기능이 마침내 실현되고 운영 및 모니터링을위한 API 인터페이스가 다른 자동화 된 운영 및 유지 관리 시스템과 인터페이스하도록 예약되어 있습니다.

부족 개발의 주된 목적은 자동 마이그레이션 문제를 해결하는 것입니다. Redis 메모리 사용량이 변동성을 보이기 때문에 전날은 여전히 ​​10 %이고 다음날에는 80 %가 될 수 있습니다. 이때 수동 마이그레이션은 확실히 비즈니스 변화에 대응할 수 없으며, 이때 물리적 메모리 병목 현상이 발생하면 더욱 번거로울 수 있습니다. 비즈니스 재구성과 관련된 데이터 해시로 인해 오류가 발생할 수 있습니다.

슬롯 기반 동적 마이그레이션은 먼저 비즈니스 감각이없고, 두 번째로 전체 서버가 더 이상 필요하지 않습니다. 슬롯의 일부를 마이그레이션하기 위해 사용 가능한 메모리가있는 서버를 찾으면 확장 및 마이그레이션 문제를 직접 해결하여 서버의 활용률을 크게 높일 수 있습니다. , 비용을 낮추십시오.

제공된 라우팅 기능은 개발 임계 값을 낮출 수 있습니다. 더 이상 리소스 로직 구성을 코드 나 프런트 엔드 구성 파일에 쓸 필요가 없으며 변경할 때마다 온라인으로 전환 할 필요가 없습니다. 이렇게하면 개발 효율성이 크게 향상되고 온라인 변경으로 인한 실패의 위험을 피하기 위해 결국 실패의 90 %는 활성 변경으로 인해 발생합니다.

추가해야 할 한 가지는 바퀴를 재창조하는 것과 관련하여 개인적으로 모든 회사가 자체 시나리오를 가지고 있다고 생각합니다. 오픈 소스 소프트웨어는 우리에게 좋은 솔루션을 제공 할 수 있지만 응용 프로그램 시나리오에 100 % 적용 할 수는 없으므로 리팩토링이 용납 될 수 없습니다. 예, 타협해야 할 몇 가지가 있습니다.

Databus
MySQL이 먼저 있고 Redis 및 HBase 데이터베이스가 있기 때문에 데이터가 MySQL에 기록되었지만 이러한 데이터를 다른 데이터베이스와 동기화해야하는 시나리오가 있습니다. 따라서 우리는 MySQL을 기반으로 할 수있는 Databus를 개발했습니다. binlog는 데이터를 다른 이기종 데이터베이스와 동기화하고 맞춤형 비즈니스 로직을 지원합니다. MySQL에서 Redis로, MySQL에서 HBase 로의 데이터 흐름이 실현되었습니다. 다음 단계는 Redis에서 MySQL 로의 데이터 흐름을 개발하는 것입니다.

데이터 버스 개발에 대한 우리의 원래 의도는 Redis 작성 문제를 해결하는 것이 었습니다. 일부 데이터는 Redis뿐 아니라 MySQL에도 작성되어야하기 때문입니다. 프런트 엔드에서 이중 쓰기를 사용하면 해결할 수 있지만 코드 복잡성이 발생합니다. 백 엔드에서 데이터 링크가 구현되면 코드가 더 명확 해지고 데이터의 최종 일관성도 보장 될 수 있습니다. 나중에 실제 애플리케이션에서 데이터 버스는 점차 데이터를 안내하는 기능을 맡기 시작했습니다.

Weibo에 축적 된 현재 데이터베이스 디자인 습관에 대해 이야기하겠습니다. 일반적으로 말해서, 우리는 "반 패러다임"디자인 아이디어를 채택 할 것이며, "반 패러다임"디자인은 편리함을 가져오고 특히 데이터 규모가 커진 후에 몇 가지 문제를 야기합니다. 다음과 같은 몇 가지 솔루션이 있습니다.

• 사전 분할. 수요를 받으면 용량을 미리 평가하여 수직, 수평으로 분할하여 시간 차원에 따라 설계 할 수 있다면 아카이빙 메커니즘에 포함시킨다. 데이터베이스의 데이터베이스 테이블을 분할하여 용량 저장 문제를 해결합니다.
• 메시지 대기열을 소개합니다. 중복 데이터의 다중 쓰기 요구 사항을 충족하려면 큐 또는 다중 큐의 단일 쓰기 다중 읽기 기능을 사용하지만 최종 일관성 만 보장 할 수 있으며 중간에 데이터 지연이 발생할 수 있습니다.
• 인터페이스 레이어를 소개합니다. 데이터는 서로 다른 비즈니스 모듈의 인터페이스를 통해 요약 된 다음 애플리케이션 계층으로 반환되어 애플리케이션 계층 개발의 코딩 복잡성을 줄입니다.

또 다른 요점은 예상되는 데이터베이스 양이 상대적으로 큰 경우 블로그 게시물의 디자인 아이디어를 참조하여 맨 처음에 인덱스와 콘텐츠를 분리하고 후속 분할을 최소화하기 위해 해시 및 시간 차원 하위 ​​테이블을 디자인한다는 것입니다. 시간 공유에서 발생할 수있는 문제와 어려움.

Weibo 데이터베이스 플랫폼에 대한 향후 계획

마지막으로 Weibo 데이터베이스 플랫폼 개발에 대한 몇 가지 생각을 공유하고 싶습니다. 몇 가지 아이디어를 제공 할 수 있기를 바랍니다. 물론 우회와 함정을 피할 수 있도록 몇 가지 제안과 의견도 주셨으면합니다.

사업이 발전함에 따라 점점 더 많은 시나리오를 접하게 될 것이며, PostgreSQL, SSDB 등 시나리오 문제 해결에 가장 적합한 데이터베이스를 도입하고자합니다. 동시에 MySQL 5.7의 병렬 복제, GTID, BP의 동적 조정과 같은 MySQL 새 버전의 기능을 사용하여 기존 서비스의 성능과 안정성을 지속적으로 최적화합니다.

또한 기존 NoSQL 서비스의 서비스 화를 촉진하고 프록시를 사용하여 스토리지 노드를 구성하여 외부 서비스를 제공하여 개발자의 개발 복잡성과 외부 리소스 획득의 섬세함을 줄이고 내부 단일 머신의 활용도를 높이고 리소스 계층 수평 문제를 해결합니다. 확장의 병목 현상.

동시에 주요 클라우드 컴퓨팅 리소스를 사용하여 캐시 계층의 동적 확장 및 축소를 실현하고 클라우드 컴퓨팅의 탄력적 리소스를 최대한 활용하며 비즈니스 액세스 변동 문제를 해결하십시오.

Q & A

1. 데이터와 인덱스의 분리는 비즈니스 계층 또는 미들웨어에 의해 수행됩니까? 미들웨어가 많은 일을했다고 생각하는데,이 부분을 조금 확장 할 수 있나요?
   분할 및 재구성시 미들웨어 계획을 고려하지 않았기 때문에 현재의 인덱스와 콘텐츠 분리는 비즈니스 로직에서 실현됩니다. 제 개인적인 경험으로는 미들웨어 솔루션을 사용하더라도 비즈니스 로직 레이어에서 인덱스와 콘텐츠를 분리해야합니다.

미들웨어의 핵심 기능은 프로그램과 백엔드 자원을 분리하는 것입니다. 백엔드에 얼마나 많은 자원이 있더라도 프로그램의 통합 진입 점입니다. 따라서 미들웨어는 수평 분할 문제를 해결하고 인덱스와 콘텐츠는 분리됩니다. 수직 분할의 범위에 속하며 개인적으로 미들웨어로 해결해서는 안된다고 생각합니다.

2. 가장 기억에 남는 데이터베이스 서비스 실패를 기억하고 몇 가지주의 할 점을 말씀해 주시겠습니까?
   가장 인상적인시기는 데이터베이스 서비스의 실패 였다고 말하면 그 당시 동료가 실수로 테이블 삭제 명령을 실행했습니다. 데이터베이스를 아는 사람이라면 누구나이 명령이 얼마나 강력한 지 알고 있습니다. 아키텍처를 사용하여이를 해결하기 위해 긴급히 단일 테이블을 수행했습니다. 복구, 잠시 다운 그레이드되었지만 사용자 전체에 영향을 미치지 않았습니다.

이것에 대해 말하고 싶은 예방 조치는 표준입니다. 이후 모든 테이블 삭제 요구 사항의 프로세스를 수정하고 엄격한 구현을 보장하며, 삭제 요구 사항이 아무리 시급하더라도 다음과 같이 24 시간 동안 냉각되어야합니다.
테이블 이름 변경 작업을 수행하여 테이블 이름을 테이블로 변경합니다.
드롭 작업을 수행하기 전에 24 시간을 기다리십시오.

3. Weibo의 급성장 단계에서 테이블 분할 "인덱스와 콘텐츠를 해시 한 다음 시간 위도에 따라 분할"하는 부분이 해싱의이 부분을 확장 할 수 있습니까?
   이것은 실제로 그렇게 복잡하지 않습니다. 먼저 1 년에 대략적인 수준 수를 추정 한 다음 분할해야하는 테이블 수를 계산하고 3 천만 행의 레코드 내에서 각 테이블을 제어하려고합니다 (물론 이것은 희망일 뿐이며 현실은 계획이 변경 사항을 따라갈 수 없음을 증명합니다). 예를 들어, 모듈로 1024 방법을 사용하여 생성 된 모든 블로그 게시물을 블로그 게시물 ID에 따라 1024 개의 테이블로 나눕니다 (이 블로그 게시물 ID는 uuid 글로벌 발급자도 포함하며 확장되지 않음).

Weibo 사용자가 생성하는 대부분의 콘텐츠는 시간과 연결되기 때문에 시간 차원은 우리에게 강력한 속성이며 기본적으로 가질 것입니다. 매월 테이블이 작성된다고 가정하면 월 1024 테이블에 해당합니다. 데이터베이스의 용량이 병목이되면 ​​2010 년의 모든 테이블을 다른 데이터베이스로 마이그레이션하는 등 시간 차원에 따라 해결할 수 있습니다.

4. Linkedin은 수년 전에 데이터 버스와 유사한 프로젝트를 시작했으며 MySQL에서 HBase, ES 등으로의 데이터 동기화를 지원하는 오픈 소스 프로젝트도 있습니다. Weibo 접근 방식을 확장 할 수 있습니까?
   이기종 데이터의 동기화는 많은 회사에서 존재하며, 제가 아는 한 Ali의 DRC는 동일한 작업을 수행합니다. 우리의 구현 아이디어는 주로 MySQL binlog에 의존합니다. 모든 사람은 MySQL binlog가 행 형식으로 설정 될 때 영향을받는 모든 데이터를 로그에 기록하여 모든 데이터 변경 사항을 제공한다는 것을 알고 있습니다.

MySQL binglog를 행 형식으로 구문 분석하여 데이터 변경 사항을 데이터 버스로 읽은 다음 필요한 실제 비즈니스 논리를 전달합니다. so 파일을 데이터 버스에로드하면 데이터 버스가 비즈니스 로직에 따라 데이터 변경 사항을 재 처리 한 다음 다운 스트림 리소스로 출력합니다.

우리는 데이터 버스 프로젝트를 오픈 소스 화했으며 GitHub에서 직접 "MyBus"를 검색 할 수 있습니다.

5. 질문 1에서 언급 한 색인은 무엇이며 해당 콘텐츠에 대한 알고리즘을 찾는 방법은 무엇입니까?
   색인은 실제로 콘텐츠 알고리즘을 참조하지 않습니다. 예를 들어 블로그 게시물을 저장해야하는 경우 불가피하게 고유 ID를 저장하여이를 구별 한 다음 게시물을 게시 한 사람과시기 등 블로그 게시물이 게시되었을 때의 일부 상태를 저장해야합니다. 우리는 이러한 상태와 ID가 인덱스라고 생각하고 블로그 게시물의 내용은 실제 내용이라고 생각합니다. 내용이 비교적 크기 때문에 인덱스와 함께 저장하면 MySQL의 성능이 저하되고 많은 쿼리가 마지막으로 블로그 게시물 ID를 가져 오면됩니다. 실제 블로그 게시물을 얻는 것과 같습니다.

최종적으로 사용자에게 출력 될 인덱스 목록을 가져 오기 위해 인덱스를 필터링 한 다음이 목록을 기반으로 콘텐츠 라이브러리에서 실제 콘텐츠를 조회하여 MySQL의 반환 결과 집합이 작을수록 성능이 높아진다는 규칙을 준수 할 수 있습니다. 효과를 최적화합니다.

6. NoSQL은 어떤 역할을합니까?
   NoSQL은 Weibo에서 점점 더 중요한 역할을 해왔습니다. 예를 들어, 자체 개발 한 카운팅 서비스 인 rediscounter는 모든 카운트가 업데이트 세트 카운트 = 카운트 +1이기 때문에 단일 행에 대한 높은 동시성이므로 원래 카운트는 MySQL에 저장됩니다. 데이터 쓰기 작업으로 인해 MySQL 다중 잠금이 발생하고 동시성이 높을수록 잠금이 더 강해집니다.
   아래 그림에서 볼 수 있듯이 단일 행의 동시 작업이 500 개 이상에 도달하면 tps가 수만에서 수백으로 변경되므로 MySQL이 아무리 최적화되어 있어도이 비즈니스 시나리오를 잘 지원할 수 없으며 Redis는 할 수 있습니다.
   

저는 개인적으로 NoSQL이 만능 칼과 같다고 생각합니다. 가장 잘 맞는 최상의 솔루션입니다. 개인적으로 이것이 NoSQL의 향후 개발 방향이라고 생각합니다. 각각 최적의 시나리오를 가지고 있습니다.

7. 우리 회사는 앞으로 많은 스마트 기기를 갖게 될 것입니다. 올해는 20,000 개 이상의 기기가있을 수 있으며 1 년에 두 배로 늘어날 수 있습니다. 수집되는 데이터는 모두 JSON 메시지 형식입니다. JSON의 필드는 다양한 유형의 메시지를 식별합니다. 참조 varchar 또는 longtext 필드를 문자열로 저장하는 것은 적합하지 않은 것 같습니다 .DB 스토리지는 MYSQL 5.7의 기본 JSON을 최대한 활용하고 스토리지에 확장 불가능한 "와이드 컬럼"을 사용하거나 POSTGRES 또는 기타 DB를 사용하는 대신 하나의 컬럼 만 저장할 수 있습니까? 더 편리한 보관을 제공 할 수 있습니까? 초기 단계에서 여전히 사용되었을 때 MySQL 5.7은 최종 버전이 아닙니다. mariadb 다중 마스터를 사용하여 N 다중 장치 액세스, DB 쓰기 계층의 부하를 공유하는 경우 많은 장치가 데이터를 전송해야하는 쓰기 시나리오에 대해 어떤 지침이 있습니까?
   실제로 MySQL 5.7의 새로운 기능 중 JSON이 데이터베이스 디자인에 더 큰 영향을 미칠 것입니다. 귀하의 진술에 따르면 varchar 또는 text와 같은 필드를 사용해서는 안되지만 개인적으로 스마트 장치 시나리오를 권장합니다. , 가능하다면 HBase로 직접 이동하는 것이 가장 좋습니다. 조만간 MySQL이 지원하는 데이터 양이 어려워 지므로 본질적으로 이점이 없습니다.

8. "개별 데이터 및 인덱스"는 무엇을 의미합니까? 데이터 파일과 인덱스 파일이 서로 다른 시스템에 별도로 저장됩니까?
   내용과 색인이 있어야 이해하기 쉽기 때문에 모든 사람이 이것을 비즈니스 계층에서 수직 분할로 이해합니다. 수직 분할로 인해 서로 다른 데이터베이스 인스턴스에 존재해야하므로 하나의 물리적 시스템 또는 서로 다른 물리적 시스템에 배치 할 수 있습니다. 우리는 서로를 피하기 위해 습관에 따라 서로 다른 물리적 시스템에 배치됩니다. 간섭.

9. MySQL에는 어떤 정보가 저장됩니까? 어떤 NoSQL 스토리지입니까? 어떤 NoSQL을 사용하고 있습니까?
   여기에는 계층 적 스토리지 문제가 포함됩니다. 현재 우리의 주류는 MySQL + Redis + mc입니다. mc와 Redis는 모두 핫스팟과 피크에 저항하는 데 사용되며 MySQL은 원본 데이터를 최종적으로 확인할 수 있도록 데이터 랜딩에 사용됩니다. 대부분의 요청은 mc 또는 Redis 계층으로 반환되며 데이터의 1 % 미만이 MySQL로 이동합니다.

물론 앞서 언급 한 카운팅 서비스와 같은 특별한 것도 있는데, 처음에는 저장 및 사용을 위해 rediscounter를 사용했으며 나중에 MySQL에 더 이상 데이터를 저장하지 않습니다.

마지막으로, 개인적으로 NoSQL의 가장 큰 장점은 개발의 편의성이라고 생각합니다 .KV 구조이기 때문에 개발자가 MySQL보다 NoSQL을 사용하기가 더 쉽습니다. 모든 쿼리는 기본 키 쿼리입니다. 인덱스 최적화 및 테이블 작성 방법을 고려할 필요가 없습니다. , 이것은 현재 인터넷 속도에 치명적입니다.

10. 글로벌 고유 발급 사 및 비즈니스를위한 자동 ID 생성의 장점과 단점은 무엇입니까?
    글로벌 유일 발행자를위한 많은 구현 체계가 있으며, 우리는 mc 프로토콜에 의해 수정 된 Redis를 사용하며 주요 목표는 성능입니다. 또한 MySQL의 자체 증가 ID를 발급자로 사용하는 것을 보았지만 MySQL 잠금이 너무 무거워 사업 시작 후 문제가 자주 발생하여 포기했습니다.

또 다른 이점에 대해 이야기 해 보겠습니다. 글로벌 고유 발급자의 개발은 어렵지 않습니다. 원하는 속성 중 일부를 uuid로 캡슐화 할 수 있습니다. 예를 들어 id 형식은 "타임 스탬프 + 비즈니스 플로그 + 자체 증가 시퀀스 번호"가 될 수 있습니다. 이런 종류의 id는 이번에 직접 알 수있는 시간과 해당 서비스를 알 수 있으며, MySQL 자체의 간단한 문제는 일련 번호에 비해 이해가되지 않으며 더 많은 일을 할 수 있습니다.

Weibo 기술 팀에서 공유 한 다른 기사에 대해 알아보십시오.

• Upsync : Nginx 컨테이너를 기반으로하는 Weibo 오픈 소스 동적 트래픽 관리 솔루션
• Weibo : Motan에서 수 천억 건의 호출을 지원하는 경량 RPC 프레임 워크
• Weibo Docker 기반 하이브리드 클라우드 플랫폼 설계 및 실습
• Weibo의 배포 경험에 대한 토론 "다양한 장소에 거주"
• Weibo의 Docker 컨테이너 기반 하이브리드 클라우드 마이그레이션 전투
• MySQL 최적화 및 운영 및 단일 테이블에서 60 억 개의 레코드 유지
• 대규모 및 고부하 시스템에서 Weibo의 문제 해결 방법

Weibo 기술 팀은 데이터베이스 MySQL / NoSQL DBA, 빅 데이터 엔지니어, C / C ++, Java, 운영 및 유지 관리 및 기타 기술 직책을 비롯한 다양한 기술 인재를 모집합니다. 엔지니어는 모두 MacBook Pro 및 DELL 대형 화면 디스플레이를 갖추고 있으며 풍부한 개발 비밀을 가지고 있습니다. 그리고 교육 문서는 엔지니어가 기술적 가치를 구현하고 개인 능력을 향상시키는 데 가장 적합한 선택입니다. 작업 세부 정보를 보려면 QR 코드를 스캔하십시오.

이 기사는 Li Qingfeng이 기획하고, Liu Yun이 편집하고, Ye Qing이 방송하고, Tim Yang이 검토했습니다. 데이터베이스 설계 및 최적화에 대한 더 많은 기사를 보려면이 공개 계정을 참조하십시오. 고 가용성 프레임 워크 "ArchNotes"WeChat 공식 계정에서 가져온 것임을 표시하고 다음 QR 코드를 포함하십시오.