内存数据库

发布于 2024-07-15 11:03:10 字数 249 浏览 9 评论 0原文

我正在使用 SqlServer 来驱动 WPF 应用程序，我当前正在使用 NHibernate 并预读取所有数据，以便出于性能原因对其进行缓存。这适用于单个客户端应用程序，但我想知道是否有一个可以使用的内存数据库，以便我可以在同一台计算机上的多个应用程序之间共享信息。理想情况下，这将位于我的 NHibernate 堆栈下方，因此我的代码不必更改。实际上，我希望将我的数据库从服务器上的传统格式移动为客户端上的内存数据库。

注意我只需要选择功能。

原文

分享到QQ

分享到微博

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

发布评论

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

菊凝晚露 2024-07-22 11:03:10

如果您甚至需要将所有信息加载到内存中，我会感到非常惊讶。我这样说是因为，作为一个例子，我目前正在开发一个 Web 应用程序，该应用程序（由于各种原因）在许多页面上加载数千条记录。这就是PHP+MySQL。即便如此，它也能在 100 毫秒内完成并渲染页面。

在你走这条路之前，请确保你必须这样做。首先使您的数据库尽可能高性能。现在显然这包括拥有适当的索引和调整数据库之类的事情，但即使是本末倒置。

首先，您需要确保拥有一个良好的关系数据模型：适合高性能查询的模型。这既是艺术，也是科学。

另外，您可能喜欢 NHibernate，但ORM 并不总是最佳选择。有一些极端情况，例如，手工编码的 SQL 会非常优越。

现在假设您有一个良好的数据模型，并假设您已经优化了索引和数据库参数，然后您已经正确配置了 NHibernate，那么只有这样，当且仅当性能仍然是一个问题时，您才应该考虑将数据存储在内存中。

从长远来看，我唯一需要这样做的时候是在每天需要执行数百万笔交易的系统上。

避免内存缓存的原因之一是它增加了很多复杂性。您必须处理缓存过期、对底层数据存储的独立更新、是否使用同步或异步更新、如何为客户端提供一致（如果不是最新）的数据视图、如何处理等问题具有故障转移和复制等功能。需要付出巨大的复杂性成本。

假设您已完成上述所有操作并且仍然需要它，那么在我看来您需要的是缓存或网格解决方案。这是Java 网格/集群解决方案概述，但其中许多（例如 Coherence、memcached）也适用于 .Net。 .Net 的另一个选择是 Velocity。

需要指出并强调的是，像 NHibernate 这样的东西只有在没有任何外部更新数据库的情况下才是一致的，并且只有一个支持 NHibernate 的进程（除非是集群解决方案）。如果两台不同 PC 上的两个桌面应用程序都使用 NHibernate 更新同一个数据库，则缓存根本无法工作，因为持久性单元根本不知道对方所做的更改。

I would be incredibly surprised if you even need to load all your information in memory. I say this because, just as one example, I'm working on a Web app at the moment that (for various reasons) loads thousands of records on many pages. This is PHP + MySQL. And even so it can do it and render a page in well under 100ms.

Before you go down this route make sure that you have to. First make your database as performant as possible. Now obviously this includes things like having appropriate indexes and tuning your database but even though are putting the horse before the cart.

First and foremost you need to make sure you have a good relational data model: one that lends itself to performant queries. This is as much art as it is science.

Also, you may like NHibernate but ORMs are not always the best choice. There are some corner cases, for example, that hand-coded SQL will be vastly superior in.

Now assuming you have a good data model and assuming you've then optimized your indexes and database parameters and then you've properly configured NHibernate, then and only then should you consider storing data in memory if and only if performance is still an issue.

To put this in perspective, the only times I've needed to do this are on systems that need to perform millions of transactions per day.

One reason to avoid in-memory caching is because it adds a lot of complexity. You have to deal with issues like cache expiry, independent updates to the underlying data store, whether you use synchronous or asynchronous updates, how you give the client a consistent (if not up-to-date) view of your data, how you deal with failover and replication and so on. There is a huge complexity cost to be paid.

Assuming you've done all the above and you still need it, it sounds to me like what you need is a cache or grid solution. Here is an overview of Java grid/cluster solutions but many of them (eg Coherence, memcached) apply to .Net as well. Another choice for .Net is Velocity.

It needs to be pointed out and stressed that something like NHibernate is only consistent so long as nothing externally updates the database and that there is exactly one NHibernate-enabled process (barring clustered solutions). If two desktop apps on two different PCs are both updating the same database with NHibernate the caching simply won't work because the persistence units simply won't be aware of the changes the other is making.

回复收藏 0 原文