# 扩展与限制

storh 是以文件为先的存储方案，并非关系型查询引擎。以下实际限制以 [基准测试](https://storh.inline0.dev/zh/docs/benchmarks)中的数字为参考
（50k 条记录，Apple M1 Pro）：

- 当文件系统能够处理相应文件数量，且集合使用 UUID 尾部字符分片时，点查几乎不受规模限制。一次点查只需几微秒；持久化单记录写入受 fsync 限制，每秒可达数千次。
- 当分段大小根据工作负载配置时，分段日志扫描、游标读取和时间范围读取在约 1M 条记录以内都能轻松处理。批量追加每秒可达数万条记录；重新打开时，残缺日志尾部恢复每秒可重放数十万条记录。
- 队列操作会将精简事件追加到一个持久化日志中，因此入队、认领、完成、重新入队和清空操作无需频繁在目录中创建每个任务对应的独立文件。批量认领和完成操作可将锁和 fsync 开销分摊到整个批次。
- 在 `DocStore` 中，按文件执行字段扫描在超过约 10k 条记录后会变慢，因为每次匹配扫描都必须遍历各个文件。请为要筛选的字段声明[索引](https://storh.inline0.dev/zh/docs/indexes)；无论集合大小如何，索引相等查询都能在约一毫秒内返回结果。
- storh 不适用于临时关系型查询、联接、大量二级索引筛选或跨多个字段的分析扫描。需要这些读取模式时，请将集合推送到 [SQL 镜像](https://storh.inline0.dev/zh/docs/sql-mirror)；需要多记录事务时，请将权威数据保留在真正的数据库中。

点查为主时使用 `DocStore`，追加和有序读取为主时使用 `SegmentedLog`，简单的持久化任务分发则使用 `Queue`。请参阅[选择引擎](https://storh.inline0.dev/zh/docs/engines#choosing-an-engine)，查看并列比较。