Uber의 MySQL 선택에 대한 생각

데이터베이스 업계에서는 Uber가 올해 PostgreSQL을 MySQL로 전환하는 큰 사건을 냈다는 사실을 모두가 알고 있으며 당시 커뮤니티에서 많은 소란이 일어났습니다. 반년이 넘었는데, 이 두 관계형 데이터베이스 중 어느 것이 더 나은지 다시 논의하고 싶지 않습니다. 나는 단지 당신이 당신의 선택 뒤에 숨은 이유에 대해 생각하도록 유도하고 싶습니다.

이 사건에서 Uber가 마이그레이션을 제안한 중요한 이유는 다음과 같습니다. PostgreSQL은 업데이트된 다수의 비즈니스 시나리오에서 SSD 또는 PCI-E를 사용하기 위해 IO 오버헤드(주로 스토리지 구조에서 발생)가 너무 많습니다. 카드 장치는 기본적으로 쓰기 증폭을 허용할 수 없으며 동시에 다음 요구 사항이 제시됩니다.

• 쓰기 버퍼링 기능이 필요합니다. 데이터베이스에 대한 지속성이 실패하는 경우에도 여전히 가능합니다. 나중에 다시 시도하세요.

• 다운스트림 종속성을 알리는 방법이 필요하며, 데이터 변경 사항은 손실 없이 알려야 합니다.

• 에는 보조 색인이 필요합니다.

• 시스템은 연중무휴 서비스를 지원할 수 있을 만큼 견고해야 합니다.

• 가장 중요한 점은 SchemaLess 스토리지 지원이 필요하다는 점입니다.

• 서버 추가를 통해 동적으로 용량을 확장하는 능력. 서버를 추가하면 사용 가능한 하드 디스크 용량이 늘어날 뿐만 아니라 시스템 응답 시간도 줄어듭니다.

이러한 요구에 부응하여 다른 인터넷 제조사와 마찬가지로 Uber도 Cassandra, Riak, MongoDB를 시도하고 자체 개발도 고려했지만 결국 MySQL을 스토리지 레이어로 선택했습니다. 질문은 다음과 같습니다. MySQL이 위의 요구 사항을 충족할 수 있습니까? 예:

• SchemaLess 스토리지 지원

• 쓰기 버퍼링 기능, 빠른 장애 조치

• 확장성 향상

호기심에 사로잡혀 MySQL을 다시 살펴보면 Uber의 요구 사항을 정확하게 충족하는 두 가지 강력한 기능이 MySQL 5.7에서 도입되었음을 알 수 있습니다.

MySQL도 NoSQL화되기 시작했고, json 타입을 지원하고, json 지원도 추가되었다고 볼 수 있습니다. 느껴보세요:

• CRUD와 같은 기존 SQL 작업을 지원합니다. NoSQL 인터페이스를 더 잘 지원하기 위해 이를 기반으로 하는 또 다른 헤비급 프로토콜인 X-프로토콜이 출시되었습니다. 뿐만 아니라 다양한 프로그램을 위한 수많은 mysqlsh 및 드라이버를 시작합니다. 지금 이해하지 못한다면 곧 종료될 수도 있습니다
• X-Protocol

  상호작용 오버헤드를 줄이고, 메시지 크기를 줄이고, 파이프라인 처리 및 알림 처리를 지원하는 완전히 새로운 프로토콜

더욱 친숙한 NoSQL 지원, 더 풍부한 데이터 처리 인터페이스,

더 빠른 쿼리 응답

을 달성하기 위한 데이터 샤딩 고려

위의 두 기능은 MySQL 8.0이 중점을 두는 두 가지 기능이기도 합니다. 지식은 매우 빠르게 업데이트됩니다. 이 두 가지의 특징을 모른다면 시간을 들여 지식을 업데이트해야 합니다. MySQL은 그 위력을 발휘하기 시작했으며 최근에는 매우 빠르게 업데이트되었습니다.

Uber의 요구 사항을 정확히 충족하는 것은 이 두 가지 기능입니다. NoSQL 인터페이스 스토리지를 기반으로 기본 데이터는 MySQL의 복제 복제를 사용하도록 보장됩니다(MySQL 그룹 복제는 곧 GA될 예정입니다). 데이터 분할 및 라우팅 설정은 NoSQL 인터페이스 계층에서 쉽게 수행할 수 있으며, 기본 복제를 통해 데이터 가용성과 보안을 더 잘 보장할 수 있습니다.