Let’s look at the performance-related complexities that teams commonly face with write-heavy workloads and discuss your options for tackling them 読み重いデータベースワークロードは、読み重いデータベースよりも明らかに異なる課題を伴います。 スケーリングはコストが高く、特に操作ごとに支払う場合、書き込みは読み込みよりも5倍高くなります。 Locking can add delays and reduce throughput. ロッキングは遅延を加え、通過量を減らすことができます。 I/O ボトルネックは、書き込み強化を引き起こし、事故回復を複雑にする可能性があります。 データベースバックプレッシャーは、入力するロードを投げ込むことができます。 コストは重要ですが、多くの場合、これはここで取り上げたいテーマではありません。むしろ、チームが一般的に直面するパフォーマンス関連の複雑さに焦点を当てて、それらに対処するための選択肢について議論しましょう。 「リアルタイムで書く重労働量」とは? まず、「リアルタイムで書く重い」ワークロードを意味することを明確にしましょう。 大量のデータ(例えば、50K OPSを超える) 読むよりも書く方が多い。 厳格な遅延 SLA (たとえば、1 桁のミリ秒 P99 遅延) 野生では、オンラインゲームからリアルタイムの証券取引所まで、あらゆる場面で起こります。 物のインターネット(IoT)のワークロードには、時間連続データの小さな、しかし頻繁な添付書類が含まれる傾向があります。ここでは、摂取率は主にデータを収集するエンドポイントの数によって決定されます。 Logging and Monitoring systems also deal with frequent data ingestion, but they do not have a fixed ingestion rate. They may not necessarily attach only, as well as may be prone to hotspots, such as when one endpoint misbehaves. ログリングおよびモニタリングシステムはまた、頻繁なデータの摂取に対処します。 オンラインゲームプラットフォームは、ゲームの状態の変更、プレイヤーのアクション、メッセージを含むリアルタイムのユーザーインタラクションを処理する必要があります。ワークロードは急激なアクティビティの増加を伴う傾向にあります。 電子商取引および小売業のワークロードは、通常、アップデートに重く、しばしばバッチ処理を含む。これらのシステムは、正確な在庫レベルを維持し、顧客レビューを処理し、注文の状態を追跡し、通常、アップデートする前に既存のデータを読み取る必要があるショッピングカートの操作を管理する必要があります。 広告テクノロジーとリアルタイムの入札システムは、割り当ての決定を必要とします。これらのシステムは、印刷追跡や競売結果を含む複雑な入札処理を処理し、クリックやコンバージョンなどのユーザーの相互作用を同時に監視します。 リアルタイムの証券取引システムは、高頻度の取引操作、継続的な株価更新、複雑なオーダーマッチングプロセスをサポートする必要があります - すべては、絶対的なデータの一貫性と最小限の遅延を維持しながら。 次に、書くパフォーマンスに影響を与える重要なアーキテクチャと構成の考慮事項を見ていきましょう。 ストレージエンジンアーキテクチャ ストレージエンジンアーキテクチャの選択は、データベースの書き込みパフォーマンスに根本的に影響を与えます. Two primary approaches exist: LSM trees and B-Trees. ScyllaDB、Apache Cassandra、HBase、Google BigTableなどのデータベースは、Log-Structured Merge Trees (LSM) を使用しています。このアーキテクチャは、大量の書き込みを処理するのに最適です。書き込みがメモリに直ちに付属しているため、最初のストレージが非常に速くなります。メモリの「memtable」が満たされると、最近の書き込みがディスクに分類された順序で洗浄されます。 たとえば、以下は ScyllaDB 書き込みパスがどう見えるかです。 B-tree 構造では、各書き込み操作は、木内のノードの位置付けと変更を必要とし、これは順序的およびランダム I/O を含みます。データセットが成長するにつれて、木は追加のノードと再バランスを必要とし、より多くのディスク I/O を生成し、パフォーマンスに影響を与えることができます。 Payloadサイズ Payload サイズもパフォーマンスに影響します。小さな payload では、パフォーマンスは良好ですが、CPU 処理は主なボトルネックです。 結局のところ、小さな書き込みは通常、すべてのバッファに適合し、すべてを非常に迅速に処理することができます。それゆえ、高いパワフルさを得るのは簡単です。より大きなパワフルさの場合、より大きなバッファや複数のバッファを割り当てる必要があります。 圧縮 ディスクの利用は、書き込みが重いワークロードで注意深く観察するものですが、ストレージは絶えず安くなっていますが、まだ無料ではありません。 圧縮は物事をコントロールするのに役立ちますので、圧縮戦略を賢く選択してください。より速い圧縮速度は、書くのに重いワークロードにとって重要ですが、利用可能なCPUとメモリリソースも考慮してください。 確実に観察して下さい The 圧縮は基本的にデータを小さいブロック(またはブロック)に分割し、それぞれのブロックを別々に圧縮します。この設定を調節する際には、より大きなブロックが読書に優れ、より小さいブロックが書き込みに優れていることに気付いて、使用量の大きさを考慮してください。 コンプレックス チャンクサイズ パラメータ 共感 LSM ベースのデータベースの場合、選択した圧縮戦略は書き込みパフォーマンスにも影響を与えます. 圧縮は、複数の SSTables をより少ない、より組織化されたファイルに統合し、読み取りパフォーマンスを最適化し、ディスクスペースを回収し、データの断片化を減らし、全体的なシステム効率を維持することを意味します。 圧縮戦略を選択する際には、読み取りを可能な限り効率的にする低読み取り強化をターゲットにすることができるか、圧縮があまりにも攻撃的であることを避けることによって低書き強化をターゲットにすることができるか、または、低読み取り強化を優先して、圧縮浄化データを可能な限り効率的に取得することができる。 (そしてCassandraは同様のものを提供しています): 複数のコンパクト戦略 サイズ層圧縮戦略(STCS):システムが十分に(デフォルトで4つ)同じサイズのSSTablesを持っているときに起動します。 Leveled Compression Strategy (LCS): システムは、異なるレベルに分布する小さな固定サイズ(デフォルトで160 MB)の SSTables を使用します。 増加圧縮戦略(ICS):STCSと同じ読み書き強化要因を共有するが、2倍の臨時空間強化問題を修正し、より小さい(デフォルトでは1GB)、重複しないSSTablesの分類されたセットから構成されるSSTable runに巨大なstablesを破る。 タイムウィンドウ圧縮戦略(TWCS):タイムシリーズデータのための設計。 書き込みが重いワークロードの場合、あらゆる費用で均等な圧縮を避けるようユーザーに警告します。この戦略は読み込みが重い使用ケースのために設計されています。 バッチャン ScyllaDB および Cassandra のようなデータベースでは、バッチングは実際には少しの落とし穴になる可能性があります - 特に書き込みの重いワークロードの場合。 あなたがリレーショナルデータベースに慣れている場合、バッチングは、大量の書き込みを処理するための良いオプションのように思えるかもしれません。 しかし、それは慎重に行わなければ事態を遅らせることができます。 主に、それは、大きなまたは構造化されていないバッチがノード間で多くの連携とネットワークのオーバーヘッドを作り出すために終わるからです。 しかし、それは本当に ScyllaDB のような分散データベースで望まないものです。 ここでは、あなたが重い書き込みに取り組んでいるときにバッチングについて考える方法です。 Batch by the Partition Key: Partition key によって書き込みをグループ化して、バッチはデータを所有する調整ノードに移動します。このようにして、調整者は追加のデータのための他のノードにアクセスする必要はありません。 バッチを小さく、ターゲット化する: バッチを分割して大きなバッチを小さいバッチに分割すると、物事が効率的になります。 それはネットワークの過剰負荷を回避し、各ノードが持っているデータのみで作業できるようにします。 Unlogged Batches: Considering you follow the previous points, it's best to use unlogged batches. ログインされたバッチは、書き込みを本当に遅らせることができる追加の一貫性チェックを追加します。 したがって、あなたが書くことが困難な状況にいる場合は、大きなクロスノードのバッチが導入できる遅延を避けるために、あなたのバッチを慎重に構成してください。 Wrapping Up 私たちはいくつかの警告を提供しましたが、心配しないでください。学習したレッスンのリストをまとめるのは簡単でした、なぜなら多くのチームがリアルタイムの書き込みで重いワークロードで非常に成功しているからです。 もっと知りたい場合は、非常に興味深い書き込みの難題に対処したチームからの第一手の見解を以下に示します。 Zillow:複数のデータプロデューサーからのレコードを消費し、間違ったアップデートを引き起こす可能性のあるオーダー外の書き込みを引き起こした。 Tractian: IoTデバイスからの高周波データの10倍の成長の準備 Fanatics: Heavy write operations such as handling orders, shopping carts, and product updates for this online sports retailer. このオンラインスポーツ小売店のための注文処理、ショッピングカート、および製品アップデートなどの重い書き込み操作 ZILLOW トラクション ファンタジー また、以下のビデオを見て、これらの重い書き込みの課題についてさらに深く学び、ScyllaDBでこれらのワークロードがどう見えるかについてもご覧ください。
