需要非常快的线程安全收集或内存数据库

发布于 2024-11-08 07:04:58 字数 237 浏览 3 评论 0 原文

我从外部应用程序获取数据:

class DataItem
{
   public string key;
   public int Attribute1;
   public string Attribute2;
}

一个线程将其存储在集合中。 其他线程 (3-10) 按键 (90%) 和属性 (10%) 查询集合。

如果我收藏了 10、100、1000 多个项目,那么实现此目的的最佳方法是什么?

I get data from external application:

class DataItem
{
   public string key;
   public int Attribute1;
   public string Attribute2;
}

One thread store it in collection.
Other threads (3-10) query collection by key (90%) and attributes (10%).

What is the best way to implement this If I have 10, 100, 1000+ items in collection?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

扬花落满肩 2024-11-15 07:04:58

如果您确实想要内存数据库,则使用 托管数据提供商将是您的最佳选择。但是,我怀疑在这种情况下,您可以使用 ConcurrenctDictionary。该集合可以轻松处理 1000 多个项目和许多并行访问它的线程。使用此集合的注意事项是,您只能为集合中的每个条目指定一个键。您可能需要为要查找的每个属性使用单独的集合。话又说回来,如果按属性进行的查找不够频繁,那么您可以选择枚举整个集合来查找匹配的属性,而无需单独的集合。

If you are really wanting an in-memory database then Sqlite using the managed data provider would be your best option. However, I suspect in this case you would be okay with the ConcurrenctDictionary. This collection could easily handle 1000+ items and many threads accessing it in parallel. The caveat with using this collection is that you can specify only one key for each entry in the collection. You may need to use separate collections for each attribute you want to lookup. Then again, if lookups by an attribute are infrequent enough then you could opt for enumerating the entire collection to find matching attributes without the need for separate collections.

梦过后 2024-11-15 07:04:58

如果集合在初始化后是不可变的(只读,永不更改),并且集合在任何线程可以访问它之前就已初始化,则不需要执行任何特殊操作。多个线程可以同时读取集合或字典,不会出现任何问题。

仅当共享对象(集合)由于多个线程的操作而改变状态时,才会出现问题。当多个线程正在读取集合时更新集合,或者集合维护内部缓存列表或诸如此类的情况都会给多线程访问带来问题。

如果将集合设置为在其静态构造函数中初始化的静态对象,则甚至不需要显式锁来在初始化期间保护集合。 .NET 将保证该类在首次使用之前被初始化。

如果你能重新定义问题,使集合在初始化后不可变,你就可以省去很多麻烦和工作。

If the collection is immutable (read-only, never changing) after initialization, and the collection is initialized before any threads can get to it, you don't need to do anything special. Multiple threads can read from a collection or dictionary concurrently without any problems.

Problems only arise when the shared object (collection) changes state as a result of actions by multiple threads. Updating the collection while multiple threads are reading from it, or if the collection maintained internal cache lists or whatnot would create a problem for multithread access.

You don't even need explicit locks to protect the collection during intialization, if you set up the collection as a static object initialized in its static constructor. .NET will guarantee that the class is initialized before first use.

You can save yourself a lot of headaches and work if you can redefine the problem so that the collection is immutable after initialization.

诗化ㄋ丶相逢 2024-11-15 07:04:58

内存中的集合是只读的吗?它会对您最终使用的产品产生影响。

我的建议 -
只读:使用 ConcurrentDictionary
阅读并阅读编写:使用 DataSet

在我看来,最好的并发或线程安全模型是 DataSet - 请参阅:ADO.Net 解决数据并发问题MSDN 数据集。开发 DataSet 是为了处理多个客户端的内存数据存储。请注意 MSDN 的说法:

这种类型对于多线程读取操作是安全的。您必须同步所有写入操作。

正如 Brian Gideon 所建议的那样,您确实有 DataSet 的替代方案 - ConcurrentDictionary。

使用 DataReader,您可以直接从 DataReader 填充自定义对象,例如 DataItem

无论哪种方式,这两种解决方案都将允许您快速、并发地访问内存中的数据。

Is the in-memory collection intended to be read only? It will make a difference in what you end up using.

My recommendations -
Read only: use ConcurrentDictionary
Read & Write: use DataSet

The best concurrent, or Thread-Safe, model, in my opinion, would be the DataSet - see: ADO.Net Tackle Data Concurrency and MSDN DataSet. The DataSet was developed to handle in-memory data storage for multiple clients. NOTE what MSDN says:

This type is safe for multithreaded read operations. You must synchronize any write operations.

You do have an alternative to a DataSet, as Brian Gideon suggests - a ConcurrentDictionary.

With a DataReader, you can fill custom objects, like DataItem, directly from the DataReader.

Either way, both of these solutions will allow you quick and concurrent in-memory data access.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文