MySQLシャーディングとMySQL Cluster


12

パフォーマンスのみを考慮すると、MySQL ClusterはカスタムデータシャーディングMySQLソリューションを打ち負かすことができますか?シャーディング=水平分割

シャーディングについて言及するとき、たとえば、独立したMySQLインスタンス間でレコードを均等に分散するなど、アプリケーション層で行われるシャーディングを検討しています。2台のサーバーの場合、(key mod 2)になる可能性があります。

回答:


21

開示:私はMySQLの従業員で、MySQL Clusterに取り組んでいます。

MySQL Clusterは、シャードされたMySQL + InnoDBよりも高いスループット/ホストを達成できると言えます。

  • クエリは簡単です
  • すべてのデータがメモリ内に収まる

レイテンシに関しては、MySQL ClusterにはシャードMySQLよりも安定したレイテンシが必要です。純粋にメモリ内のデータの実際のレイテンシは同様の可能性があります。

クエリがより複雑になり、データがディスクに保存されると、パフォーマンスの比較がより複雑になります。より具体的な回答を得るには、アプリケーションと実行するクエリ、さらにホストの数とデータの量について詳しく説明する必要があります。MySQL Clusterは最近、並列ローカライズされたクエリ実行(AQL)を獲得しました。これは、複数のホストにデータが分散されているにもかかわらず、スタンドアロンMySQLDと競合できることを意味します。

MySQL Clusterは現在、48ホスト以上の「シャーディング」に制限されています。理論上、シャードMySQLには制限がありません。ただし、特定のターゲットスループットに対して、シャードされたMySQLホストよりも少ないMySQL Clusterホストが必要になる場合があります。

より興味深い違いは、パフォーマンス以外の領域を見るときです:

  • MySQL Clusterはすべてのシャードにわたる任意のクエリをサポートします
  • MySQL Clusterはすべてのシャードにわたる任意のトランザクションをサポートします
  • MySQL Clusterは、自動フェイルオーバーおよびリカバリを使用してシャードの同期レプリケーションをサポートします
  • MySQL Clusterはオンラインノード追加(クラスター拡張)をサポートします
  • 断片化されたMySQLはより「独自のロール」です

アプリケーションにシャーディングが組み込まれていると、最大限のスケーリングの可能性が得られますが、クロスシャードクエリと操作に関して複雑さが増し、柔軟性が制限されます。シャーディングが時期尚早の場合は、問題の原因になっている可能性があります。MySQL Clusterを使用すると、アプリケーションをシングルシャードのみに制限することなく、シャーディングの利点の一部を利用できます。

前の回答に関して、いくつかの説明:

「MySQL ClusterはACIDに準拠していますが、複合キーを持つデータに適したストレージエンジンを提供していません。」

MySQL Clusterは、複合プライマリキーとセカンダリキーをサポートしています。何が「適切」ではないのかわかりません。おそらく、前のポスターで説明できますか?

「同じ重要な特性を持つデータを特定のデータノードのセットに保存するには、次のようにします。

  1. すべてのデータノードをオフラインにし、同じ主要な特性を持つデータを格納するデータノードのみを残します。
  2. データをMySQL Clusterにロードします。これにより、選択したデータノードのみが入力されます
  3. すべてのデータノードをオンラインに戻す」

これは間違っています。データの分散は、いつどのノードがオンラインになっているかとは無関係です。MySQL Clusterは、説明した最適化をサポートするために、さまざまなデータ分散スキームをサポートしています。ここでのブログ投稿でMySQL Clusterのデータ分布について説明します:MySQL Clusterのデータ分布


やあ、フレイジャー。あなたが提供したリンクを読みます。明確にするために、私の「複合キー」コメントは、一意でないインデックスに基づいていました。私の雇用主の会社は、2007年第1四半期頃にMySQL Clusterを試用しましたが、パフォーマンスが低いために気に入らませんでした。私見、それはキー(小さな基数)と彼のクエリに対するクライアントの悪い選択でした。それ以降、MySQL Clusterはリンクに基づいてさらに成熟している必要があります。2番目のステートメントについては、これは特定のシャードにデータを取り込むMongoDBユーザーの数です。私の雇用主のクライアントの一部は、カスタムMySQLセットアップでこれを行っています。
RolandoMySQLDBA

リンクでは、一致する行が1つのテーブルフラグメントに格納されることが保証されていないため、整理できない「順序付けられたインデックススキャン」について言及しました。これが、データが拡散する場所を最小限に抑えるために、特定のシャード(データノード)にデータを分離することを提案していた理由です。あなたの答えはMySQL Clusterの良い面を引き出すので、元の投稿された質問によりよく適合します。私の答えは、今日のMySQL Clusterの力にやや素朴であり、注意、悲観論に賛成して間違っています。
RolandoMySQLDBA

私の暴言と絶賛の代わりに、あなたの答えを+1してください!!!
RolandoMySQLDBA

こんにちは、ローランド、声明を明確にしていただきありがとうございます。すべてのデータノードが関係しているため、非プルーニングの順序付けされたインデックススキャンがクラスタで「高価」であることは事実です。低カーディナリティーインデックスでのこれらのスキャンは、どのシステムでも高価になるようですが、クラスターでは目に見えて高価になります。あなたの注意と悲観論があなたを二度以上救ったことは間違いありません:) +1をありがとう
Frazer Clement
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.