데이터베이스 업계에서는 Uber가 올해 PostgreSQL을 MySQL로 전환하는 큰 사건을 냈다는 사실을 모두가 알고 있으며 당시 커뮤니티에서 많은 소란이 일어났습니다. 반년이 넘었는데, 이 두 관계형 데이터베이스 중 어느 것이 더 나은지 다시 논의하고 싶지 않습니다. 나는 단지 당신이 당신의 선택 뒤에 숨은 이유에 대해 생각하도록 유도하고 싶습니다.
이 사건에서 Uber가 마이그레이션을 제안한 중요한 이유는 다음과 같습니다. PostgreSQL은 업데이트된 다수의 비즈니스 시나리오에서 SSD 또는 PCI-E를 사용하기 위해 IO 오버헤드(주로 스토리지 구조에서 발생)가 너무 많습니다. 카드 장치는 기본적으로 쓰기 증폭을 허용할 수 없으며 동시에 다음 요구 사항이 제시됩니다.
쓰기 버퍼링 기능이 필요합니다. 데이터베이스에 대한 지속성이 실패하는 경우에도 여전히 가능합니다. 나중에 다시 시도하세요.
다운스트림 종속성을 알리는 방법이 필요하며, 데이터 변경 사항은 손실 없이 알려야 합니다.
에는 보조 색인이 필요합니다.
시스템은 연중무휴 서비스를 지원할 수 있을 만큼 견고해야 합니다.
가장 중요한 점은 SchemaLess 스토리지 지원이 필요하다는 점입니다.
서버 추가를 통해 동적으로 용량을 확장하는 능력. 서버를 추가하면 사용 가능한 하드 디스크 용량이 늘어날 뿐만 아니라 시스템 응답 시간도 줄어듭니다.
이러한 요구에 부응하여 다른 인터넷 제조사와 마찬가지로 Uber도 Cassandra, Riak, MongoDB를 시도하고 자체 개발도 고려했지만 결국 MySQL을 스토리지 레이어로 선택했습니다. 질문은 다음과 같습니다. MySQL이 위의 요구 사항을 충족할 수 있습니까? 예:
SchemaLess 스토리지 지원
쓰기 버퍼링 기능, 빠른 장애 조치
확장성 향상
MySQL도 NoSQL화되기 시작했고, json 타입을 지원하고, json 지원도 추가되었다고 볼 수 있습니다. 느껴보세요:
상호작용 오버헤드를 줄이고, 메시지 크기를 줄이고, 파이프라인 처리 및 알림 처리를 지원하는 완전히 새로운 프로토콜