我什么时候应该考虑使用内存数据库？需要注意哪些问题？
我只是认为现在在数据库服务器上有足够的 RAM 来缓存完整的数据库是很常见的为什么内存数据库（例如 TimesTen，另请参阅维基百科页面）几年前的风靡没有被更多地使用吗？
似乎随着时间的推移，基于磁盘的数据库的使用越来越少，例如，大多数应用程序现在都构建在传统的理性数据库上。我原本的预期是相反的，因为许多服务器的 RAM 已经接近免费。
我问这个，因为我刚刚阅读了堆栈溢出架构，页面上写着
这很重要，因为堆栈 溢出的数据库差不多 完全在 RAM 中并且连接仍然存在 成本确实太高了。
但我认为如果使用“指针”和“集合”而不是普通的 btree，这不会成为问题。 Btree 非常聪明地绕过了磁盘访问速度的限制，例如，它们通过交换 CPU 使用率来减少磁盘使用率。然而我们现在已经有了如此匹配的内存。
但我们仍然需要数据库，因为自己做
- 锁定、
- 死锁检测、
- 事务日志记录
- 、恢复
- 等
非常困难。
@S.Lott，考虑到我们都花了很长时间选择索引、避免连接并调查数据库性能问题。一定有更好的方法。几年前，我们被告知“内存数据库”是更好的方法。因此，在我开始使用它们之前，我想知道为什么其他人不更多地使用它们。
（我自己不太可能使用 TimesTen，因为它价格很高（$41,500.00 / 处理器），我不喜欢与 Oracle 销售人员交谈 - 我宁愿花时间编写代码。）
另请参阅：
更新：
我很久前就问过这个问题，这些天 Microsoft SQL Server 有“内存中 OLTP" 是集成到 SQL Server 引擎中的内存优化数据库引擎。它并不便宜，但对于某些工作负载来说似乎非常快。
I was just think that now it is common to have enough RAM on your database server to cache your complete database why are the specialist in memory database (e.g TimesTen, see also Wikipedia page) that were all the rage a few years ago not being used more?
It seems to be that as time go on, none disk based databases are being used less, e.g most applications are now built on conventional rational databases. I would have expected the opposite as RAM is getting close to being free for a lot of servers.
I am asking this, as I just read up on the stack-overflow-architecture and the page says
This is significant because Stack
Overflow's database is almost
completely in RAM and the joins still
exact too high a cost.
But I don’t think this would be a problem if “pointers” and “collections” were used instead of the normal btree. Btree are a very clever to get round limits on disk access speed, e.g they trade CPU useage to reduce disk usage. However we now have so match ram.
But we still need database, as doing your own
- Locking
- Deadlock detection
- Transaction logging
- Recovering
- Etc
Is very hard.
@S.Lott, Given we all spend so long choosing indexes, avoiding joins and investigating database performance problems. There must be a better way. A few years ago we were told the “in memory databases” was the better way. So before I jump into using one etc, I wish to know why other people are not using them more.
(I am unlikely to use TimesTen myself, as it is high priced ($41,500.00 / Processor) and I don’t like talking to Oracle sales people - I rather spend my time writing code.)
See also:
- Alternative to the TimesTen in memory database
- Has anyone published a detailed comparison between different in-memory RDBMSs?
Update:
I asked this question a LONG time ago, these days Microsoft SQL Server have "In-Memory OLTP" that is a memory-optimized database engine integrated into the SQL Server engine. It is not cheap, but seems to be very fast for some workloads.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
没有人真正回答“我什么时候应该考虑使用内存数据库以及需要注意什么问题？”这个问题。所以我会尝试一下。
如果出现以下情况，您应该考虑使用内存数据库：
1. 目标系统有数据需要管理，但没有持久介质
2. 持久性数据库根本无法满足性能要求
对于#1，请考虑机顶盒 (STB) 中的电视指南。低端机顶盒（即不具备DVR功能的机顶盒）没有持久性存储，也不需要持久性存储。但包含 400 个频道、为期 14 天的电视指南的数据库并非易事。这里也有一个性能要求，因为数据从应答器传送带高速到达，并且这是“捕获它或等待传送带再次出现”的情况。但没必要坚持。我们都看到过这一点；当您家里断电时，当它恢复时，电视指南上会显示“很快就会可用”，因为它正在从应答器或电缆头端进行自我配置。网络路由器具有相同的特征：没有持久存储，需要快速，并且可以从外部源配置数据库（在这种情况下，网络上的对等路由器用于重新填充路由表）。
#2 的例子不胜枚举：军事系统、高频交易系统等中的实时定位。
关于问题的第二部分“需要注意的问题”：有很多。
如果您需要只有内存数据库才能提供的性能，请确保您正在评估真正的内存数据库。缓存持久数据库是不一样的。将持久数据库放入 RAM 驱动器中是不一样的。使用本质上执行事务日志记录的内存数据库（如 TimesTen）是不一样的（即使您记录到 /dev/null）。
确保您正在评估数据库系统，而不仅仅是缓存（例如内存缓存）。数据库系统将支持具有 ACID 属性的事务、多个索引选项、支持并发访问等等。
关于 ACID：内存数据库系统不缺少“D”（持久性）。它必须结合上下文来理解。持久数据库中的事务只有在其存储的介质具有持久性的情况下才具有持久性。对于内存数据库来说也是如此。无论哪种情况，如果您关心耐用性，最好有一个备份。
Nobody really answered the question "When should I consider using a in memory database and what are the issue to look out for?" so I'll give it a go.
You should consider an in-memory database if:
1. The target system has data to manage, but no persistent media
2. The performance requirement simply cannot be met with a persistent database
For #1, think of the TV Guide in your set-top box (STB). Low-end STB (i.e. those with no DVR capability) have no persistent storage, and need no persistent storage. But the database for a 400-channel, 14-day TV Guide is non-trivial. There's a performance requirement here, too, because data arrives from the transponder carousel at a high speed and it's a case of 'capture it or wait until the carousel comes around again'. But there's no need for persistence. We've all seen this; when you lose power at your home, when it comes back on the TV Guide says "will be available shortly" because it's provisioning itself from the transponder or cable head-end. Network routers share the same characteristics: no persistent storage, need to be fast, and the database can be provisioned from an external source (peer routers on the network, in this case, to repopulate the routing table).
There are endless examples of #2: Real-time targetting in military systems, high-frequency trading systems, and more.
Regarding the second part of the question, "issue to watch out for": There are many.
Make sure you're evaluating a true in-memory database if you need the performance that only an in-memory database can deliver. Caching a persistent database is not the same. Throwing a persistent database in a RAM-drive is not the same. Using an in-memory database that inherently does transaction logging (like TimesTen) is not the same (even if you log to /dev/null).
Make sure you're evaluating a database system, and not merely a cache (e.g. memcache). A database system will have support for transactions with the ACID properties, multiple indexing options, support concurrent access, and more.
About ACID: in-memory database systems do not lack the 'D' (durability). It simply has to be taken in context. Transactions in a persistent database are durable only so long as the media it's stored on is durable. The same thing is true for in-memory databases. In either case, if you care about durability, you better have a backup.
很可能还没有成熟的内存数据库产品可以完全替代经典数据库。
关系数据库是一个非常古老的概念。尽管有许多方法可以推进和开发新技术，例如。与面向对象数据库相比，关系数据库并没有真正改变它们的概念。不要期望事情变化得太快，因为数据库在过去十年、十五年甚至更长时间里并没有太大变化。
我认为，技术的发展并不像人们想象的那么快。新概念的成熟和确立需要数十年的时间。首先在数据库技术中，成熟度比其他任何事情都重要得多。
十年或二十年后，数据库可能不再像今天一样。如果内存数据库是未来——今天没有人能说出这一点——他们只是需要更多的时间来开发。
Most probably there are just no mature products of memory databases which could be used as a full replacement for a classic database.
Relational database are a very old concept. Although there were many approaches to move forward and develop new technologies, eg. object oriented databases, the relational databases didn't really change their concepts. Don't expect things to change too fast, since databases didn't change much in the last ten or fifteen years or even longer.
I think, development of technologies is not as fast as one might believe. It takes decades for new concepts to be matured and established. First of all in database technologies, where maturity is much more important then anything else.
In ten or twenty years, databases are probably not the same anymore as they are today. If in-memory databases are the future - nobody can tell this today - they just need some more time to develop.
趋势似乎是积极缓存并使用数据库来填充缓存。无论数据库位于何处，连接仍然很昂贵，因此首选似乎是执行一次连接并将结果缓存在类似 Memcached 或 速度。
仍然存在内存数据库并且它们被使用，但这取决于您想要使用它们的上下文。例如，SQLite 在测试数据层时经常用作内存数据库。
The trend seems to be to cache aggressively and use the database to populate the cache. Regardless of where the database lives, joins are still expensive so the preference seems to be to do the join once and cache the result in something like Memcached or Velocity.
There are still in-memory databases around and they are used, but it depends upon the context you want to use them. SQLite for example is often used as an in-memory database when testing data layers.
最重要的原因是货运文化，以及IT知识水平很低。无论使用哪种持久性解决方案，大多数应用程序都能很好地工作，并且由于计算机每年都在变得越来越快，没有足够的人感受到痛苦并能够查明问题。
微软和甲骨文通过他们的数据库产品赚了太多钱，使他们（政治上）有可能想出更好的方法。
使用关系数据库的开发成本并不透明，因此管理层不知道存在问题，更不用说解决方案了。
The most important reason is cargo culture, and the very low knowledge level in IT. Most applications work sufficiently well whatever the persistence solution used, and as computers are still getting faster each year, not enough people feel the pain and are capable of pinpointing the problem.
Microsoft and Oracle make too much money with their database products to make it (politically) possible for them to come up with better approaches.
The development costs of using a relational database are not made transparent so management has no idea that there is a problem, let alone a solution.
嗯，内存数据库通常缺乏 D （持久性）ACID（原子性、一致性、隔离性、持久性）就其本质而言。这可以在一定程度上通过“混合”方法来克服，但是，在某些时候，某些东西（数据本身或事务日志）必须保存在某处以提供持久性方面。这通常会降低内存数据库解决方案的性能或引入其他不需要的属性。
相比之下，当今的大多数 RDBMS 都具有 ACID 的完整补充，并且背后有数十年的发展。这导致基于磁盘的数据库系统性能非常好，特别是经过现代 RDBMS 系统多年的改进和优化（您的 BTree 示例只是众多示例之一）。
另一个因素是我们作为应用程序开发人员通过缓存等机制减少数据库负载的能力，从而从应用程序的数据层中挤出更多感知性能。事实上，缓存本身近年来已经得到了广泛的发展，分布式缓存现在很常见（只需看看 例如，memcached 的用户）。
具有讽刺意味的是，现代缓存系统在很多方面正在慢慢转变为类似于真正的内存数据库系统。内存数据库，就像面向对象的数据库一样，都是“新事物”，所以看看所有这些随着时间的推移会发生什么将会很有趣。 Oracle 现已收购 TimesTen，并且根据这篇维基百科文章，微软正在考虑很快进入内存数据库市场。这是传统 RDBMS 领域的两个现代“大玩家”正在认真对待内存数据库系统。
Well, in-memory databases generally lack the D (durability) in ACID (atomicity, consistency, isolation, durability) by their very nature. This can be overcome to an extent with "hybrid" approaches, however, at some point something (either the data itself, or a transaction log) has to be persisted somewhere to provide the durability aspect. This can generally slow down performance or introduce other non-desirable properties to an in-memory database solution
In contrast, most of todays RDBMS's have the full complement of ACID, as well as having many decades of development behind them. This has resulted in disk-based database systems that are very performant, especially with the many years of improvements and optimisations that modern day RDBMS system have seen (your BTree example being just one of many).
Another factor is our ability as application developers to reduce the load on the database by such mechanisms as caching, thereby squeezing much more perceived performance from the data layer of an application. Indeed, caching itself has seen extensive developments in recent years with distributed caching being common nowadays (just look at the number of users of memcached, for example).
Ironically, the modern day caching systems are, in many ways, slowly transmogrifying into something akin to a true in-memory database system. In-memory databases, like object-oriented databases, are very much the "new kids on the block", so it will be interesting to see where all of this goes in time. Oracle has now acquired TimesTen, and, according to this wikipedia article, Microsoft are looking at getting into the in-memory database market quite soon. That's two modern day "big players" in the traditional RDBMS field that are taking in-memory database systems seriously.
这也是一个选项： http://www.memsql.com/
我个人没有使用过，但是它应该是内存中 MySQL 的直接替代品。
This is also an option: http://www.memsql.com/
I have not used it personally, but it's supposed to be along the lines of a drop-in replacement for MySQL in-memory.
主要为移动设备设计的各种可移植版本的 SQL，具有相同的效率。
SQLite
SQL Server Compact Edition
这些只是大玩家，可能还有其他选项，但大玩家满足最低要求随着它的释放..:)
并且在内存数据库中，您不断备份数据，如果出现波动或断电，您可能会丢失整个数据。与其他情况一样，它将作为辅助存储器 (HDD) 进行处理，与内存 DB 相比，丢失的可能性为 10%。
我希望这会有所帮助:)
Various Portable versions of SQL, that will work with same efficiency, designed for mobile devices mainly.
SQLite
SQL Server Compact Edition
These are just big players other options may be there, but big players handle minimum requirements with release of it.. :)
and in memory database, you have continuously back up the data if fluctuation or powercut arises you may loss the whole bunch. as in other that will be handled as its in secondary memory(HDD) and the chances of loss will be 10% compare to memory DB.
I hope this may help :)
数据库最典型的用例是持久性，这使得大多数内存数据库不适合。使用内存数据库的一个常见原因是出于测试目的。但这要求您使用既可以设置为内存数据库也可以设置为其他数据库的数据库。
该领域流行的选择似乎是针对 .Net 开发人员的 RavenDB 和针对 Java 开发人员的 OrientDB。因为两者都可以用作内存数据库，并且根据配置而可以作为“其他东西”，所以您可以根据您的配置使用其中之一（.Net 中的 app.config、Java 中的 Maven 或 Ant 设置）。
The most typical use-case for a database is persistence, which makes most in-memory databases unsuitable. One popular reason to use an in-memory database is for testing purposes. But this requires you use either a database that can be set up both as in-memory and something else.
Popular choices in this area seems to be RavenDB for .Net developers and OrientDB for Java developers. Because both can function as in-memory databases, and "something else" depending on configuration, so you can use one or the other depending on your configuration (app.config in .Net, Maven or Ant settings in Java).
数据处理需求变得越来越复杂，产品生态系统也在不断发展以满足这些新需求。基于磁盘的RDBMS、内存缓存和内存数据库可以满足不同的需求。您应该选择适合您需求的方式 -
传统 RDBMS： 您的 MySQL 集群足够快，足够容易维护，并且您喜欢具有 ACID 合规性的可靠性。
内存中分布式 cahce：您的应用程序需要快速读取和写入，而不必过多担心一致性或复杂事务。
内存中 RDBMS：
Data processing needs are getting more complex and the product ecosystem is evolving to meet these new needs. Disk-based RDBMS, in-memory cache, and in-memory databases are used to satisfy different needs. You should go with what suits your need -
Traditional RDBMS: Your MySQL cluster is fast enough, easy enough to maintain, and you like having the reliability of ACID-compliance.
In-memory distributed cahce: Your application needs to do fast reads and writes without worrying too much about consistency or complex transactions.
In-memory RDBMS: