某些用户会关注一些关键字 如:西瓜 牛奶 香蕉 等,大概如下结构:
{'key_1':[u1,u2,u3,u4]} {'key_2':[u4]} {'key_3':[u2,u3,u4]} 恩,其实就是一个 key 对应多个用户.
如果以用户角度来看,其实就是:
{u1:[key_1]} {u2:[key_1,key_3]} .... 现在有大量文本需要检测是否包含上面所有的 key.如果包含 就取到对应的 key 与 id[ux] 这种数据应该怎么存储比较合适呢并检索? 如果有可用的工具 最好越轻越好.. key 大概 2w-5w 备注:文本大概 100 字以内
1.如果经济条件欠发达，建议用时间换成本的做法：
3 个表：用户表、关键词表、关键词与用户对应表。
每个表都不能有重复的，来节约存储空间与内存，但牺牲的是计算量、计算时间。
2.如果经济条件发达，玩法就完全不一样了，核心原则就变成了节约时间：
2.1 用户数据相关的 2 种表：
2.1.1 用户表：
可以重复的用户表。用户数据录入到这个表，但不从这个表取数据。
不可重复的用户表，数据是从上表，通过最终一致性 + 散列分布式 + 流式处理到该表里。数据取出也是从这个表取，这样子处理，取出速度最快。
2.2.2 用户-关键词表：
该表本质是用于节约时间，是一种冗余表。这种表也同上，做两款，一款拿来录入数据，允许重复；一款拿来高速取出数据，不允许数据重复。
2.2 关键词数据相关的表：
同与上面的用户数据表，一共 2 种：关键词表与冗余的关键词-用户表。做法也同上，每种表也做重复与不重复两套。
总结一下，以上一共 8 个表，为节约时间服务，也就是为高速取出数据服务，牺牲了存储空间与内存。
另外，如果存储用的是高级存储设备或做了软阵列或分布式副本提速，需要考虑数据录入速率与存储底层条带化结构（ raid 0 ）或分布式散列结构的关系，以及数据取出时与存储底层镜像化（ raid 1 ）或分布式副本化的关系。也就是在读写时，画个流程图，思考一下底层存取逻辑与读写性能的关系。
可以 key 生成树，然后文本中，按树节点取匹配吧。