スケーリングと制限

storhはファイルを中心とするストレージであり、リレーショナルクエリエンジンではありません。実用上の目安は、ベンチマーク（Apple M1 Pro、50kレコード）の数値を参考にしてください。

• ファイル数を処理できるファイルシステムとUUID末尾シャーディングを使うコレクションでは、点アクセスの規模に実質的な上限はありません。点読み取りは数マイクロ秒、永続化する単一レコードの書き込みはfsyncがボトルネックとなり、毎秒数千件です。
• セグメント化ログのスキャン、カーソル読み取り、時間範囲読み取りは、用途に合わせてセグメントサイズを設定すれば、およそ1Mレコードまで快適に使えます。一括追記は毎秒数万件に達し、途中で切れた末尾の復旧では、再オープン時に毎秒数十万件を再生します。
• キュー操作はコンパクトなイベントを1つの永続ログに追記するため、エンキュー、取得、完了、再キュー、パージの際にジョブごとのファイルでディレクトリが煩雑になることはありません。一括取得と完了では、バッチ全体でロックとfsyncのコストを分散できます。
• DocStoreでファイルごとにフィールドをスキャンする方式は、一致するたびに個別のファイルをたどるため、およそ10kレコードを超えると遅くなります。絞り込みに使うフィールドにはindexesを宣言してください。インデックスを使った等価クエリなら、コレクションのサイズにかかわらず約1ミリ秒で結果を返します。
• storhは、その場で行うリレーショナルクエリ、結合、セカンダリーインデックスを多用する絞り込み、多数のフィールドにわたる分析スキャンには向いていません。こうした読み取りが必要なら、コレクションをSQLミラーに移してください。複数レコードのトランザクションが必要な場合は、信頼できるデータベースを主要なデータ保存先として使ってください。

点読み取りが中心ならDocStore、追記と順序どおりの読み取りが中心ならSegmentedLog、シンプルで永続的な作業振り分けにはQueueを使ってください。横並びの比較はエンジンの選び方をご覧ください。