目前我使用SQLite (w/ SQLAlchemy) 来存储大约 5000 个 dict 对象。每个 dict 对象对应于 PyPI 中带有键的条目 - （名称、版本、摘要 .. 有时“描述”可能与项目文档一样大）。
将这些条目（从 JSON）写回磁盘（SQLite 格式）需要几秒钟，而且感觉很慢。
每天写一次的频率很高，但根据键（通常是名称或描述）读取/搜索特定条目的频率很高。
就像 apt-get。
是否有一个与 Python 一起使用的存储库比 SQLite 更适合我的需求？
【问题讨论】：
标签： python sqlite data-storage
您是否在名称和描述上添加了索引？搜索 5000 个索引条目应该基本上是即时的（当然 ORM 会让你的生活变得更加艰难，因为它们通常会这样做[即使是相对较好的，比如 SQLAlchemy，但尝试“原始 sqlite”，它绝对应该会飞）。
只写更新的条目（再次使用真正的 SQL）也应该基本上是即时的 - 理想情况下，一个更新语句应该可以完成，但即使是一千个也不应该是真正的问题，只需确保在开始时关闭自动提交循环的（如果你想稍后再把它转回来）。
【讨论】：
INSERT 都是一个事务，至少需要 2 次磁盘旋转才能完成（写入和验证）。如果您将整个作品包装在 BEGIN..COMMIT 块中，您可以避免这种情况并获得更快的吞吐量 - sqlite.org/atomiccommit.html 和 sqlite.org/speed.html
这对您的应用程序来说可能有点矫枉过正，但您应该检查无模式/面向文档的数据库。我个人是couchdb 的粉丝。基本上，不是将记录存储为表中的行，而是像 couchdb 存储键值对，然后（在 couchdb 的情况下）您在 javascript 中编写视图以剔除您需要的数据。这些数据库通常比关系数据库更容易扩展，并且在您的情况下可能更快，因为您不必将数据锤炼成适合关系数据库的形状。另一方面，这意味着有另一个服务在运行。
【讨论】：
鉴于所述对象的大致数量（大约 5,000 个），SQLite 可能不是速度背后的问题。是中介措施；例如 JSON 或 SQLAlChemy 的非最佳使用。
试试这个（即使是百万个对象也相当快）： y_serial.py 模块 :: 使用 SQLite 存储 Python 对象
“序列化 + 持久化:: 在几行代码中，将 Python 对象压缩和注释为 SQLite；然后在不使用任何 SQL 的情况下通过关键字按时间顺序检索它们。数据库存储无模式数据的最有用的“标准”模块。”
http://yserial.sourceforge.net
对您的键的 yserial 搜索是使用 SQLite 端的正则表达式（“regex”）代码完成的，而不是 Python，因此还有另一个显着的速度改进。
让我们知道结果如何。
【讨论】：
我现在正在为自己解决一个非常相似的问题，使用Nucular，这可能适合您的需求。这是一个基于文件系统的存储，看起来确实非常快。 （它带有一个示例应用程序indexes the whole python source tree）它是并发安全的，不需要外部库并且是纯python。它搜索速度很快，并具有强大的全文搜索、索引等功能——类似于流行的 Couchdb 和 mongodb 的方式，一种专门的、进程内的、本地的 python-dict 存储，但更轻。
不过，它确实有局限性——它不能存储或查询嵌套字典，所以不是每个 JSON 类型都可以存储在其中。此外，虽然它的文本搜索功能强大，但它的数字查询很弱且没有索引。尽管如此，它可能正是您所追求的。
【讨论】：