问用于快速查找和持久化的数据结构的优化存储

EN

场景

我有以下方法：

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

一开始，我在考虑表格上的存储：

itemId -> userId, userId, userId

和

userId -> itemId, itemId, itemId

AddItemSecurity是基于如何从第三方API获取数据的，GetValidItemIds是我希望在运行时使用它的方式。

可能有2000名用户和1 000万件物品。id项在表单上: 2007123456,2010001234 (前四位代表年份)。

AddItemSecurity不需要执行超快，但是GetValidIds需要次秒级。另外，如果对现有的itemId进行了更新，我需要为不再在列表中的用户删除该itemId。

我正在考虑如何以一种最佳的方式储存这个。最好在磁盘上(带缓存)，但我希望代码可维护和干净。

如果项id从0开始，我考虑为每个用户创建一个长度为MaxItemId / 8的字节数组，并在项目是否存在时设置一个true/false位。这将使每个用户的数组长度限制在略大于1mb，并提供快速查找以及更新每个用户列表的简单方法。通过在内存映射文件 4框架中将其作为.Net保持下来，我想我也会得到很好的缓存(如果机器有足够的内存)，而无需自己实现缓存逻辑。解析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笔记本电脑
• SSD磁盘
• 使用SqlDataReader将所有项读入列表
• 遍历所有用户

如果我运行一个线程，它的平均值为0.2秒。当我添加第二个线程时，它上升到0.4秒，这仍然是可以的。从那时起，结果越来越少。添加第三个线程会给查询带来最多2秒的时间。第四个线程最多可达4秒，第五个线程将一些查询提高到50秒。

CPU正在屋顶运行，甚至在一个线程上也是如此。我的测试应用程序采用了一些由于快速循环，其余的sql。

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

更新2010-03-31 #2

我对相同的数据进行了快速测试，将其作为位放在内存映射文件中。表现要好得多。六个线程产生在0.02s到0.06s之间的访问时间。纯粹的记忆束缚。映射的文件由一个进程映射，另有6个进程同时访问。由于sql基的容量为4gb，磁盘上的文件占用23 as。