メモリストア

*このコンテンツは、ベータ版のAI(人工知能)を使用して翻訳されており、エラーが含まれている可能性があります。このページを英語で表示するには、 こちら をクリックしてください。

MemoryStoreService は、ライブセッションのすべてのサーバーからアクセス可能な高速なメモリデータストレージサービスで、メモリストアを使用すると、メモリストアを使用するたびに高速にアクセスできます。 メモリストア は、メモ

データ構造

ローカルデータに直接アクセスする代わりに、メモリストアには、クエール処理のための 3つの原始データ構造 がサーバー間で共有されています:ソートされたマップキュー、および ハッシュマップ。各データ構造は特定のユースケースに最適です:

  • スキルベースのマッチメイキング - 共有の キュー の中のユーザー情報(スキルレベルなど)を保存し、ロビーサーバーを使用してマッチメイキングを期間的に実行します。
  • サーバー間の取引とオークション - ユーザーが実時間の価格の変更がある、キーバリューのペアでアイテムに入札できる、サーバー間のユニバーサルな取引とオークションを有効にします。 ソートされたマップ のユースによるキー値のペアでアイテムに入札できます。
  • グローバルリーダーボード - 共有リーダーボード内のユーザーランキングを保存し、更新する。
  • 共有インベントリ - 共有 ハッシュマップ でインベントリアイテムと統計を保存し、ユーザーがインベントリアイテムを共同で使用できます。
  • 持続データのキャッシュ - 持続データをデータストアに同期し、メモリストアにハッシュマップしてパフォーマンスを向上させます。

一全般に、特定のキーに基づくデータにアクセスする必要がある場合は、ハッシュマップを使用します。データをソートする必要がある場合は、ソートされたマップを使用します。データを特定の順序で処理する必要がある場合は、キューを使用します。

限定とクオータ

スケールアビリティとシステムパフォーマンスを維持するために、メモリストアにはメモリサイズ、API リクエスト、データ構造サイズのデータ使用量の制限があります。

メモリストアには、有効期限に基づく退出ポリシーがあります。これは、時間を生きる (TTL) という名前の時間に基づく退出時間に基づく退出ポリシーです。アイテムは有効期限が切れると退出され、メモリのクオーターは新しいアイテムのために解放されます。メモリの上限に到達すると、すべての以降の書き込みリクエストが失敗するまでアイ

メモリサイズクオット

メモリークオタは、エクスペリエンスが消費できるメモリーの合計量を制限します。これは固定の値ではありません。代わりに、エクスペリエンスのユーザー数に応じてメモリーの消費量を変更します。形式は、次の式に従って変更されます: 64KB + 1KB * [ユーザーの数] 。クオータはサー

ユーザーがエクスペリエンスに参加すると、追加のメモリクオータはすぐに利用可能になります。ユーザーがエクスペリエンスを離れると、クオータはすぐに減少しません。ユーザーがクオータを更新するまでのトレースバック期間は 8 日です。クオータが更新されると、トレースバック期間は 8 日になります。

エクスペリエンスがメモリサイズのクオータに到達すると、メモリサイズを拡大するための API リクエストは常に失敗します。メモリサイズを縮小するためのリクエストはまだ成功します。

With the 観視性 dashboard, you can view the memory size quota of your experience in real-time using the メモリ使用 chart.

API リクエスト制限

API リクエスト制限には、 Class.MemoryStoreService のすべての API コール に適用される リクエストユニット があります。リクエストユニットは、2>1000+100 * [並列ユーザーの数]2> です。

ほとんどのAPI コールは、いくつかの例外を除き、1つのリクエストユニットを消費します:

  • MemoryStoreSortedMap:GetRangeAsync()

    返されたアイテムの数に基づくユニットを消費します。たとえば、このメソッドが 10 個のアイテムを返すと、呼び出しは 10 個のリクエストユニットとしてカウントされます。空の返信を返すと、1 個のリクエストユニットとしてカウントされます。

  • MemoryStoreQueue:ReadAsync()

    返されたアイテムの数に基づくユニットを消費します。MemoryStoreSortedMap:GetRangeAsync() のように、読み込み時に追加のユニットを消費しますが、読み込み時に waitTimeout パラメーターで最大の読み込み時間を指定します。

  • MemoryStoreHashMap:UpdateAsync()

    最小 2 個のユニットを消費します。

  • MemoryStoreHashMap:ListItemsAsync()

    [パーティションのスキャン数] + [返されたアイテム] を消費します。

エクスペリエンスレベルでリクエストの制限を適用することで、サーバーレベルではなくエクスペリエンスレベルでリクエストを分配できます。これにより、リクエストの合計数が制限を超えていても、リクエストをサーバー間で分配することができます。リクエストを超えると、サービスがリクエストを制限することでエラーが発生します。

観察可能性 機能を使用可能にすると、エクスペリエンスのリアルタイムのリクエストユニットのクオータを見ることができます。

データ構造サイズ制限

単一のソートされたマップまたはキューの場合、次のサイズとアイテム数の制限が適用されます:

  • アイテムの最大数: 1,000,000
  • 最大総サイズ (ソートされたマップのキーを含む): 100 MB

パーティション間の制限

パーティション間制限 を参照してください。

ベストプラクティス

メモリの使用パターンを最適に保ち、制限 をヒットすることなく、次のベストプラクティスを実装してください:

  • 処理されたアイテムを削除します。 クエールを使用して MemoryStoreQueue:RemoveAsync() メソッドで読み込みを一貫して処理し、キューに MemoryStoreSortedMap:RemoveAsync() を使用してソートされたマップを更新できます。メモリを解放し、データ構造を更新できます。

  • データを追加するときに、デフォルトの有効期限を45日とすることができますが、短縮された有効期限は、 MemoryStoreQueue:AddAsync()MemoryStoreSortedMap:SetAsync() の両方において、最小の時間枠でデータを追加することができます。 デフ

    • 有効期限が長すぎると、メモリのオーバーヘッドにリスクがあり、エクスペリエンス全体を損なう可能性があります。
    • 必要ないアイテムを明示的に削除するか、短いアイテムの有効期限を設定します。
    • 一般的に、メモリとアイテムの有効期を安全メカニズムとして解放するために明示的な削除を使用するべきです。
  • 必要な値をメモリにのみ保持します。

    たとえば、オークションハウスエクスペリエンスの場合、あなたは最高の落札を維持するだけです。 MemoryStoreQueue:UpdateAsync() を使用して、データ構造uraのすべての落札を保持する代わりに、最高の落札を維持することができます。

  • 凸状減算バックオフを使用して、API リクエストの制限を下回るようにします。

    たとえば、DataUpdateConflict を受信した場合、2秒後に再試行し、4秒、など、常に Class.MemoryStoreService にリクエストを送信して、正しい応答を取得することができます。

  • 巨大なデータ構造を 分割する によって、より小さな構造に分割します。

    データを小さな構造で管理することは、大きなデータ構造をストアすることよりも簡単です。このアプローチは、使用とレートの制限を避けるのにも役立つことがあります。たとえば、キーにプレフィックスを使用するソートされたマップを持っている場合は、それぞれのプレフィックスを別のソート

  • ストアされた値を圧縮します。

    たとえば、LZW アルゴリズムを使用して、ストレージされた値のサイズを小さくすることを考慮してください。

可視性

観視性ダッシュボード は、メモリストアの使用をモニタリングおよびトラブルシューティングするための洞察と分析を提供します。メモリストアの使用に関するリアルタイムのチャートを更新し、異なるメモリストアの使用方法と API リクエストについてのチャートを実時間で表示し、メモリストアの使用パターン

次の表には、オープンビジビリティダッシュボードのリクエストカウント とリクエストバイ API x ステータス のチャート2>で利用可能なすべてのステータスコードがリストされています。エラーの詳細については、5>トラ

ステータスコード説明
成功成功。
データ構造メモリーオーバーリミットデータ構造レベルのメモリサイズ制限を超えます (100MB)。
データ更新コンフリクト同時に更アップデートされるためのコンフリクト。
アクセスが拒否されましたエクスペリエンスデータにアクセスする権限がありません。このリクエストはリクエストユニットを消費したり、クオータを使用したりしません。
内部エラー内部エラー。
無効なリクエストリクエストに必要な情報がありませんか、または不正な情報が含まれています。
データ構造アイテムの上限データ構造レベルのアイテム数制限を超えます (1M)。
NoItemFound Class.MemoryStoreQueue:ReadAsync() または MemoryStoreSortedMap:UpdateAsync() では、ReadAsync() のパートナーは見つかりませんでした。1> Class.MemoryStoreSortedMap:UpdateAsync()1> のパートナーは、キューにあるアイテムを読み込まれるまで、毎2秒ごとに4>このステータスコードを返します4>。
データ構造リクエストの上限データ構造レベルのリクエストユニットの上限を超えます (100,000 リクエストユニットごとに 1分)。
パーティションリクエストオーバーライムパーティションリクエストユニットの制限を超えています。
トータルリクエストオーバーライムユニバースレベルのリクエストユニットの制限を超えています。
トータルメモリーオーバーリミットユニバースレベルのメモリクオートを超えています。
アイテムの値が大きすぎます値サイズが制限を超えます (32KB)。

次の表には、現在、[オブザビリティダッシュボード]で利用できないクライアント側のコードがリストされています。

ステータスコード説明
内部エラー内部エラー。
公開されていない場所MemoryStoreService を使用するには、この場所を公開する必要があります。
無効なクライアントアクセスMemoryStoreService は、サーバーから呼び出されなければなりません。
無効な有効期限「有効期限」時間は 0 から 3,888,000 の間でなければなりません。
無効なリクエスト値をJSON に変換できません。
無効なリクエストsor트キーを有効な数値または文字列に変換できません。
TransformCBックアップ失敗変換コールバック関数を呼び出すことに失敗しました。
リクエストが制限されています最近のメモリストアリクエストは、1つまたは複数の制限にヒットしました。
UpdateConflict最大数の再試行を超えました。

トラブルシューティング

次の表には、各応答ステータスコードの推奨ソリューションがリストされています:

エラートラブルシューティングオプション
データ構造の制限 / パーティションの制限

    情報を別の変数に保存し、特定のタイムアウト間隔 (例: 30 秒) で再チェックして、より多くの「成功」レポートを受信しているこ

    • データ構造を拡張する/縮小する
    • 場合、データ構造を拡張する/縮小するのは、 データ構造の受信 / パーティションの受信 の大量によります。 エクスポジションバックオフを実装して、合理的なリクエストレートを送信する

トータルリクエストオーバーライム
データ構造アイテムの上限

  • メモリサイズを減少するために最高の実践を適用してください。
  • >

データ構造メモリーオーバーリミット
トータルメモリーオーバーリミット
データ更新コンフリクト

  • 短い遅延を実装して、複数のリクエストを同時に更新することなく同じキーを更新する 複数のリクエストを同時に更新することを避けます。
  • for sortされたマップの場合、 Class.MemoryStoreQueue:RemoveAsync() メソッドを使用して、

    1> 同じマップを複数のリクエストで更新する1>

内部エラー

  • Roblox ステータスページをチェックします。
  • .

  • バグレポートをファイルし、エクスペリエンスのユニバース ID で問題を説明する。
  • >

無効なリクエスト
  • リクエストに正しく有効なパラメーターを含めることを確認してください。不正なパラメーターの例は次のとおりです:
    • 空の文字列
    • 長さ制限を超える文字列
アイテムの値が大きすぎます
  • アイテムの値を複数のキーに分割または分割します。
    • グループ化されたキーを整理するには、キーに prefix を追加してアルファベット順に並べ替えます。
  • 保存された値を暗号化または圧縮する。

スタジオでテストとデバッグ

データは MemoryStoreService の間で Studio とプロダクションの間で隔絶されているため、Studio のデータを変更すると、プロダクションの動作に影響しません。これにより、Studio の API からの呼び出しはプロダクションのデータにアクセスできないため、安全にメモリストアと新機能をプロダクションに移行することができます。

Studio テストは、同じ限界とクオータ を持つプロダクションと同じです。ユーザー数に基づくクオータは、ユーザーのみをテストするため、プロダクションと同じくレイテンシーが非常に小さくなります。Studio テストからは、アクセスと権限を確認するために実行される追加のチェック</

ライブエクスペリエンスでメモリストアをデバッグする方法や、スタジオでテストする方法については、開発者コンソール を使用してください。