データベース界では、Uber が今年、PostgreSQL を MySQL に切り替えるという大きなイベントを行ったことは誰もが知っています。当時、コミュニティでは大騒ぎがありました。半年以上が経過しましたが、これら 2 つのリレーショナル データベースのどちらが優れているかについては、もう一度議論したくありません。ただ、その選択の背後にある理由を皆さんに考えてもらいたいと思っています。このインシデントで、Uber が移行を提案した重要な理由は次のとおりです。PostgreSQL は、多数の更新されたビジネス シナリオにおいて、IO オーバーヘッド (主にストレージ構造による) が多すぎるため、SSD または PCI-E カード デバイスを使用しているユーザーにとっては、基本的には移行できません。書き込み増幅を許容し、同時に次の要件が提示されます:
好奇心に駆られて MySQL をもう一度見てみましょう。MySQL 5.7 から、Uber のニーズを正確に満たす 2 つの強力な機能が導入されていることがわかります:
DocumentStore
MySQL 5.7 以降、MySQL も NoSQL になり始め、json タイプをサポートし、さらに json サポートを追加したと考えることができます。ぜひ体感してください:
CRUD などの従来の SQL 操作をサポートします。 NoSQL インターフェイスをより適切にサポートするために、これに基づいて別の強力なプロトコル、X プロトコルが開始されました。さまざまなプログラム用の多数の mysqlsh とドライバーも起動します。今理解できなければ、すぐに挫折してしまうかもしれません
X-Protocol
インタラクションのオーバーヘッドを削減し、メッセージ サイズを削減し、パイプライン処理をサポートし、通知処理をサポートする新しいプロトコルです
NoSQL のよりフレンドリーで豊富なサポートデータを考慮したデータ処理インターフェイス
を実現するためのシャーディング 上記 2 つの機能は、MySQL 8.0 が重点を置く 2 つの機能でもあります。知識の更新が非常に早いので、これら 2 つの特徴を知らない場合は、時間をかけて知識を更新する必要があります。 MySQL はその威力を発揮し始めており、最近非常に速く更新されています。
Uber のニーズを正確に満たすのはこれら 2 つの機能です。NoSQL インターフェイス ストレージに基づいて、基盤となるデータは MySQL のレプリケーション レプリケーションを使用することが保証されています (MySQL グループ レプリケーションは間もなく GA になります)。データの分割とルーティングの設定は NoSQL インターフェイス層で簡単に実現でき、基盤となるレプリケーションによりデータの可用性とセキュリティをより確実に確保できます。
MySQL は、元々あったリレーショナル データベースではなくなりました。今では、さらに深く掘り下げる必要がある機能があります
上記は、MySQL を選択する際の Uber の考えに関するものです。詳細については、PHP に注目してください。中国語のウェブサイト (www .php.cn)!