存储含约束列表的键值对数据结构，应选用何种数据库？

根据你的需求——整数键对应“元素为正、总和为1”的列表，且不关心键之间的关联——我给你梳理几个最适配的选项，分场景来看：

1. 键值型数据库（优先推荐） #

这绝对是最贴合你当前需求的类型，因为你的数据就是标准的键值映射：

• Redis：读写速度拉满，不管是频繁存取还是高并发场景都能hold住。你可以把列表序列化成JSON字符串存进去，比如用SET 4 "[0.34, 0.66]"存，GET 4取，然后在应用层把JSON转成列表就行。至于“元素为正、总和为1”的约束，完全可以在存数据之前做校验，或者在应用层读取后验证。
• LevelDB：如果你不需要分布式能力，只是单机存储，LevelDB是个轻量又高效的选择，占用资源少，适合小体量但需要快速读写的场景。

2. 文档型数据库（适合有潜在扩展需求的情况） #

如果以后你可能需要给这些数据加些额外信息（比如记录列表的创建时间、备注），文档库会更灵活：

• MongoDB：把每个键值对存成一个独立文档，比如{ "_id": 4, "weights": [0.34, 0.66] }。现在你不需要键之间的关联，但万一以后要做些简单的数组查询（比如找所有包含大于0.5的元素的列表），MongoDB的查询语法能轻松搞定。约束同样可以在应用层校验，或者用MongoDB的文档验证规则强制保证数据合规。

3. 关系型数据库（适合需要结构化查询的场景） #

虽然你现在不关心键的关联，但如果未来有统计、复杂查询的需求，关系型数据库会更顺手：

• PostgreSQL/MySQL：可以设计两张表，主表存整数键，子表存对应的权重值；或者PostgreSQL直接支持数组类型，把列表存在一个FLOAT[]字段里，比如weights FLOAT[]，还能用SQL直接做数组计算，比如SELECT sum(weights) FROM your_table WHERE id=4来验证总和是否为1。不过这种方式对当前需求来说有点“重”，适合有潜在扩展计划的情况。

4. 本地文件（极简小体量场景） #

如果你的数据量很小，也没有并发读写的需求，直接用JSON/CSV文件存储就够了——把整个字典存成一个JSON文件，读写都在本地操作。但这种方式只适合小数据量、低访问频率的场景，数据量大了会很卡。

总结 #

• 只需要简单存取、追求速度：选Redis或LevelDB
• 可能需要扩展元信息或简单数组查询：选MongoDB
• 有结构化统计/查询需求：选PostgreSQL
• 极小数据量、极简场景：用本地JSON文件

内容的提问来源于stack exchange，提问作者Elmex80s