ユーザー検索のベストプラクティス

ユーザー検索に関するベストプラクティスを以下に示します。

にリクエストを送信するには、トークンが必要です。詳しくは、Management API Access Tokens を参照してください。
ユーザー検索リクエストを実行するには、read:users スコープが必要です。
非決定的検索を活用してください。アプリケーションで検索結果の順序が一貫している必要がなく、クエリが短くてページネーションに依存しない場合は、クエリパフォーマンスを向上させるために primary_order=false を設定してください。
最新の検索結果を取得するには、認証プロセス中に 即時整合性 のあるエンドポイントを使用してください。たとえば、Get Users by ID や Get Users by Email があります。これらのエンドポイントを使用した検索には、リクエストの直前に発生したものを含め、成功したすべての書き込み操作の結果が反映されます。
メタデータには、よく知られたスキーマを使用してください。
- プロパティには一貫したデータ型を使用してください。
- 動的なプロパティ名は避けてください。
- スキーマサイズが大きくなりすぎることや、構造が深くなりすぎることは避けてください。
- 認証および認可に不要なデータは保存しないでください。
検索クエリは、2 秒以内に完了しない場合、タイムアウトします (HTTP ステータスコード 503) 。時間がかかるクエリは、負荷の高いクエリであるか、すぐに完了しない原因となるエラーが含まれていることを示しています。
app_metadata および user_metadata のユーザー定義属性を含む検索クエリでは、タイムアウトが発生する場合があります。重要な処理には List or search users を使用しないことを推奨します。
大量のデータセット (1000 件を超える結果) を返す検索条件は使用しないでください。
存在確認クエリ (たとえば、「値に関係なく、あるプロパティを持つすべてのユーザーを取得する」など) は使用しないでください。
検索 API をポーリングしないでください。
Rules や post-login Actions など、ログインフローの拡張ポイント内でユーザー検索リクエストを実行しないでください。
大きなメタデータフィールドは使用しないでください (メタデータフィールドは 2 KB 以下に抑えるようにしてください) 。
検索でワイルドカードを使用すると、パフォーマンスに影響する場合があります。場合によっては、大規模なデータセットに対するワイルドカード検索でタイムアウトエラーが発生することがあります。また、検索語の前にワイルドカードを付けるのは避け、後ろに付けることを推奨します。後方一致のほうがパフォーマンスは高くなります。
パフォーマンス向上のため、スペース文字はエスケープしてください (例: q=name:John Doe ではなく q=name:John\ Doe と記述します) 。