为快速查找和持久性优化数据结构存储

脚本

我有以下方法:

public void AddItemSecurity(int itemId, int[] userIds)
public int[] GetValidItemIds(int userId)

最初我在考虑在表单上存储:

itemId -> userId, userId, userId

和

userId -> itemId, itemId, itemId

AddItemSecurity 基于我如何从第三方API获取数据, GetValidItemIds 我想在运行时使用它。

可能有2000个用户和1000万个项目。 项目ID在表格上:2007123456,2010001234(前四位代表年份的10位数字)。

附加安全性 不一定要表现得非常快,但是 GetValidIds 需要处于劣势。此外,如果现有的 itemId 我需要删除列表中不再存在的用户的itemID。

我正在考虑如何以最佳方式存储这个。最好在磁盘上(带缓存),但我希望代码可以维护和清理。

如果项ID从0开始,我考虑创建一个字节数组,其长度为 MaxItemId / 8 对于每个用户,如果该项存在或不存在,则设置一个真/假位。这将限制每个用户的数组长度不超过1MB,并提供快速查找以及更新每个用户列表的简单方法。通过坚持这一点 Memory Mapped Files 有了.NET 4框架,我想我也可以得到不错的缓存(如果机器有足够的RAM),而不需要自己实现缓存逻辑。解析ID、剥离年份并每年存储一个数组可能是一个解决方案。

itemID->userid[]列表可以直接序列化到磁盘,并使用普通 FileStream 以便持久化列表,并在发生更改时对其进行比较。

每次添加新用户时,所有列表也必须更新,但这可以在夜间完成。

问题

我应该继续尝试这种方法吗,还是有其他的方法也应该探索?我认为SQL Server的执行速度不够快,这会带来开销(至少如果它托管在不同的服务器上),但我的假设可能是错误的。对这件事的任何想法或见解都表示赞赏。我想尝试在不添加太多硬件的情况下解决它。)

[更新2010-03-31]

我现在已经在以下条件下使用SQL Server 2008进行了测试。

• 具有两列(userid、itemid)的表都是int
• 两列上的聚集索引
• 为180个用户增加了约800.000项-共有1.44亿行
• 为SQL Server分配了4GB RAM
• 双核2.66GHz笔记本电脑
• 固态硬盘
• 使用sqldatareader将所有itemID读取到列表中
• 循环所有用户

如果我运行一个线程,它的平均值是0.2秒。当我添加第二个线程时,它会上升到0.4秒,这仍然可以。从那里开始,结果是减少的。添加第三个线程会带来多达2个seond的大量查询。第四个线程,最长4秒,第五个线程将一些查询的峰值提高到50秒。

在这过程中,CPU正在工作,即使是在一个线程上。我的测试应用程序需要一些由于快速循环,和SQL其余。

这让我得出这样的结论:它不能很好地扩展。至少在我测试过的硬件上没有。有没有优化数据库的方法,比如为每个用户存储一个int数组,而不是为每个项目存储一条记录。但这使得移除物品变得更加困难。

[更新2010-03-31 2]

我用同样的数据做了一个快速测试,把它作为位放在内存映射文件中。它的性能要好得多。六个线程产生0.02s到0.06s之间的访问时间。纯内存限制。映射的文件由一个进程映射,其他六个进程同时访问。当SQL数据库占用4GB时,磁盘上的文件占用23MB。