什么时候应该考虑使用内存数据库，什么是要注意的问题？ [英] When should I consider using a in memory database and what are the issue to look out for?
问题描述
我只是认为现在在您的数据库服务器上有足够的RAM来缓存您的完整数据库为什么是内存数据库（例如 TimesTen ，另请参阅维基百科页面），这些都是少数几个几年前没有使用更多？
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?
似乎是随着时间的推移，没有使用基于磁盘的数据库更少，例如大多数应用程序现在建立在常规理性数据库。我会预期相反，因为RAM正在接近许多服务器是免费的。
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
这是很重要的，因为Stack
Overflow的数据库几乎是
完全在RAM和加入仍然
确切太高的成本。
This is significant because Stack Overflow's database is almost completely in RAM and the joins still exact too high a cost.
但是我不认为这将是一个问题，如果指针和集合而不是正常的btree。 Btree是一个非常聪明的磁盘访问速度的圆限制，例如他们交易CPU使用，以减少磁盘使用。
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
- 锁定
- 死锁检测
- 交易记录
- 恢复
- Etc
- Locking
- Deadlock detection
- Transaction logging
- Recovering
- Etc
很难。
@S .Lott，考虑到我们花了这么长的时间选择索引，避免连接和调查数据库性能问题。必须有一个更好的方法。几年前我们被告知内存数据库是更好的方法。因此，在我开始使用一个etc，我想知道为什么其他人不使用它们。
@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.
（我不太可能使用TimesTen自己，因为它是高定价（ $ 41,500.00 /处理器），我不喜欢与Oracle销售人员交谈 - 我宁愿花时间编写代码。）
(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.)
另请参阅：
- Alternative to the TimesTen in memory database
- Has anyone published a detailed comparison between different in-memory RDBMSs?
更新：
Update:
我之前问过这个问题 LONG ，这些天Microsoft SQL Server有内存中OLTP ，它是集成到SQL Server引擎中的内存优化数据库引擎。
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.
推荐答案
很可能在某些工作负载上，这不是便宜，但似乎非常快只是没有内存数据库的成熟产品，可以用作完全替代传统数据库。
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.
这篇关于什么时候应该考虑使用内存数据库，什么是要注意的问题？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
