検索

ホームページ  >  に質問  >  本文

mongodb sharding 的chunksize 的值设置为多少比较合理?

RT,

听人说过:
20M的情况下插入1百万的数据进行分片,会丢数据
63M的情况下插入6千万条的数据进行分片也有丢数据的情况
不同的mongodb版本也有差异

大伙对这个值有经验吗?

阿神阿神2757日前1018

全員に返信(1)返信します

  • 高洛峰

    高洛峰2017-05-02 09:20:15

    「データの損失」とチャンクサイズは無関係な 2 つのことであり、直接の論理的関連性はありません。誰がこの 2 つのことをまとめて説明するのかわかりません。データ損失が具体的にどのようなシナリオを指しているのかわからないため、私が知っていることに基づいて役立つ可能性のあるいくつかの回答を提供します。
    チャンクサイズではなく、データ損失の問題を懸念しているようです。さらに、通常、チャンクサイズはデフォルト値のままであれば問題ないため、チャンクサイズの問題は省略します。
    「データの損失」に関するいくつかの説明。どのデータベースにとっても、理由もなくデータが失われることは容認できません。つまり、データが失われる状況が発生する可能性があります

    1. 停電、ハードウェアの損傷、ネットワーク障害など、抗えない要因があります

    2. 構成理由

    3. ソフトウェアに重大なバグがあります。
      とにかく 1 については何もできません。これは ReplicaSet のレプリケーション機能によって最小限に抑える必要があります。

    ポイント 2: ジャーナルを開いていない場合 (デフォルトで開いています)、停電やプログラムのクラッシュが発生した場合、30 ミリ秒以内にデータが失われる可能性があります。データが非常に重要であり、30 ミリ秒の損失を許容できない場合は、j パラメーターをオンにしてください:
    mongodb://ip:port/db?replicaSet=rs&j=1
    (上記のパラメーターは、次のコードで指定することもできます)単一リクエストの粒度については、使用しているドライバーのドキュメントを確認してください)
    このパラメーターにより、ジャーナルがディスクに書き込まれるまでデータの書き込みがブロックされます。
    しかし、ダウンロードされたデータは安全だと思いますか?これは分散環境であり、単一マシンのデータ セキュリティがクラスターを表すものではないことに注意してください。したがって、緊急の場合、ジャーナルは配置されていますが、レプリカの他のノードにコピーされる時間がありません。その後、ロールバックと呼ばれる興味深い状況が発生します。興味のある方は読んでみてください。もちろん、コピー速度は通常非常に速く、ロールバックは非常にまれです。まあ、それでも十分安全ではないと感じるかもしれませんが、使用できる w パラメータがあります: primary正当掉了,就会有其他结点通过选举成为新的primary mongodb://ip:port/db?replicaSet=rs&j=1&
    w=1 w パラメータは、データが複数のノード (w=1/2/3...n) に到達するまで、書き込み操作はブロックされます。
    これは安全ですか?申し訳ありませんが、特に不運な状況 (本当に宝くじを購入する必要があります) で、データを複数のノードにコピーしましたが、このノードのセットが同時に失敗した場合はどうなるでしょうか。したがって、w=majority(多数派)になります。クラスターでほとんどのノードが失われると、クラスターは読み取り専用になるため、新しいデータは書き込まれず、ロールバックも行われなくなります。すべてが復元されても、データはまだそこに残っています。
    上記はデータ損失が発生するいくつかの状況ですが、w と j の構成がデータのセキュリティを確保しながら書き込み効率に大きく影響することが想像できます。これは実際には、データ損失の許容範囲に基づいてカスタマイズするポリシーである必要があり、バグとはみなされません。
    もう一つ思い出すのは、コミュニティでこのようなことをするのが好きな人たちによく出会うということです。
    リーリー

    私に言わせれば、なぜ蚊が来たらすぐに大砲を使うのですか?この場合のデータ損失は当然としか言いようがありません。実は

    リーリー

    安全ですが、-9 はあなたのせいです。

    ポイント 3 に関しては、mongodb の開発プロセス中にデータ損失につながるバグが発生しましたが、3.0.8 ~ 3.0.10 は最も大きな被害を受けているため、これらのバージョンは避けてください。そうは言っても、どのソフトウェア開発プロセスに問題がないのでしょうか? 3.0.10 で問題が発見されたのと同じ日に 3.0.11 がリリースされましたが、修復速度はすでに非常に速かったです。

    さて、ここまで言いましたが、質問者さんにとって役に立つかどうかは分かりません。問題をできるだけ明確に説明してください。そうでない場合は、私と同じように、どのようなシナリオでどのような問題が発生したかを推測することしかできません。最も可能性の高い状況は、次のような古い格言です。

    ゴミは入る、ゴミは出る

    返事
    0
  • キャンセル返事