我只是认为现在在数据库服务器上有足够的RAM来缓存整个数据库很常见为什么memory database中的专家（例如TimesTen），另见Wikipedia page）几年前风靡一时不再使用？
似乎随着时间的推移，没有一个基于磁盘的数据库使用得更少，例如，大多数应用程序现在都建立在传统的理性数据库上。我原本期望相反，因为RAM越来越接近许多服务器的免费。
我问这个，因为我刚刚阅读了堆栈溢出架构，页面上写着
这很重要，因为Stack 溢出的数据库差不多 完全在RAM和连接仍然 确实太高了。
但是如果使用“指针”和“集合”而不是普通的btree，我认为这不会是一个问题。 Btree非常聪明地限制磁盘访问速度，例如它们交换CPU使用以减少磁盘使用。但是我们现在匹配ram。
但我们仍然需要数据库，就像做自己的
一样很难。
@ S.Lott，鉴于我们都花了这么长时间选择索引，避免加入和调查数据库性能问题。肯定有更好的办法。几年前，我们被告知“内存数据库”是更好的方法。所以在我开始使用其他之前，我想知道为什么其他人不再使用它们。
（我不太可能自己使用TimesTen，因为价格很高（$41,500.00 / Processor）而且我不喜欢和Oracle销售人员交谈 - 我宁愿花时间编写代码。）
另见：
更新
我问这个问题 LONG 时间以前，现在Microsoft SQL Server的“In-Memory OLTP”是一个集成到SQL Server引擎中的内存优化数据库引擎。它并不便宜，但对某些工作负载似乎非常快。
答案 0 :(得分：12)
没有人真正回答这个问题“我应该何时考虑使用内存数据库以及需要注意的问题？”所以我会试一试。
在以下情况下，您应该考虑使用内存数据库： 1.目标系统有要管理的数据，但没有持久性媒体 2.持久数据库无法满足性能要求
对于＃1，请考虑机顶盒（STB）中的电视指南。低端STB（即没有DVR能力的STB）没有持久存储，也不需要持久存储。但是，一个400频道，14天电视指南的数据库是非常重要的。这里也有一个性能要求，因为数据从转发器转盘高速到达，这是“捕获它或等到转盘再次出现”的情况。但是没有必要坚持下去。我们都看到了这一点;当您在家中断电时，当电视机返回电视指南时“很快就会提供”，因为它是从发送应答器或有线电视前端进行配置的。网络路由器具有相同的特征：没有持久存储，需要快速，并且可以从外部源（网络上的对等路由器，在这种情况下，重新填充路由表）中配置数据库。
有无数的第二种例子：军事系统，高频交易系统等的实时目标。
关于问题的第二部分，“需要注意的问题”：有很多。
如果您需要只有内存数据库可以提供的性能，请确保您正在评估真正的内存数据库。缓存持久性数据库是不一样的。在RAM驱动器中抛出持久性数据库是不一样的。使用本质上执行事务日志记录的内存数据库（如TimesTen）是不一样的（即使您登录到/ dev / null）。
确保您正在评估数据库系统，而不仅仅是缓存（例如memcache）。数据库系统将支持具有ACID属性的事务，多个索引选项，支持并发访问等。
关于ACID：内存数据库系统不缺少'D'（持久性）。它只需要在上下文中采取。只要存储在其中的媒体是持久的，持久数据库中的事务就是持久的。对于内存数据库也是如此。在任何一种情况下，如果您关心耐久性，最好备份。
答案 1 :(得分：5)
趋势似乎是积极缓存并使用数据库填充缓存。无论数据库在哪里，连接仍然很昂贵，因此首选项似乎是连接一次并将结果缓存为Memcached或Velocity。
仍然存在内存数据库并且它们被使用，但它取决于您想要使用它们的上下文。例如，SQLite通常在测试数据层时用作内存数据库。
答案 2 :(得分：5)
很可能没有成熟的内存数据库产品可以用作经典数据库的完全替代品。
关系数据库是一个非常古老的概念。虽然有很多方法可以推进和开发新技术，例如。面向对象的数据库，关系数据库并没有真正改变他们的概念。不要指望事情变化太快，因为数据库在过去十年或十五年甚至更长时间内没有太大变化。
我认为，技术的发展并不像人们想象的那么快。新概念需要数十年才能成熟和建立。首先是数据库技术，成熟度比其他任何事情都要重要得多。
在十年或二十年内，数据库可能与现在不一样了。如果内存数据库是未来 - 今天没人能说出来 - 他们只需要更多的时间来开发。
答案 3 :(得分：4)
最重要的原因是货运文化，以及IT的知识水平非常低。无论使用何种持久性解决方案，大多数应用程序都可以正常工作，并且由于计算机每年仍然变得越来越快，没有足够的人感受到疼痛并且能够找到问题所在。
微软和甲骨文用他们的数据库产品赚了太多钱，使他们（在政治上）有可能提出更好的方法。
使用关系数据库的开发成本并不透明，因此管理层不知道存在问题，更不用说解决方案了。
答案 4 :(得分：2)
嗯，内存数据库通常在 D （原子性，一致性，隔离性，持久性）中缺少 ACID （持久性）他们的本性。这可以通过“混合”方法克服到某种程度，但是，某些时候（数据本身或事务日志）必须持久存储某处以提供持久性方面。这通常会降低性能或将其他不需要的属性引入内存数据库解决方案
相比之下，今天的大多数RDBMS都拥有完整的ACID，并且拥有数十年的开发经验。这导致基于磁盘的数据库系统非常高效，特别是现代RDBMS系统已经看到多年的改进和优化（您的BTree示例只是其中之一）。
另一个因素是我们作为应用程序开发人员通过caching等机制减少数据库负载的能力，从而从应用程序的数据层中挤出更多感知的性能。事实上，近年来缓存本身已经出现了广泛的发展，现在分布式缓存很常见（例如，只看users of memcached的数量）。
具有讽刺意味的是，现代缓存系统在很多方面都在慢慢变形为类似于真正的内存数据库系统的东西。内存数据库，如面向对象的数据库，非常像“块中的新孩子”，所以看到所有这些都及时发生将会很有趣。甲骨文现在已经收购了TimesTen，根据this wikipedia article，微软正在考虑很快进入内存数据库市场。这是传统RDBMS领域的两个现代“大玩家”，他们认真对待内存数据库系统。答案 5 :(得分：1)
这也是一个选项：http://www.memsql.com/
我个人没有使用它，但它应该是MySQL内存中替代品的替代品。
答案 6 :(得分：0)
各种便携式SQL版本，效率相同，主要是为移动设备设计的。
这些只是其他选项可能存在的大玩家，但是大玩家可以通过释放它来处理最低要求.. :)
并且在内存数据库中，如果出现波动或断电，您可以连续备份数据，这可能会损失整个数据库。与其他将在二级存储器（HDD）中处理的一样，与内存DB相比，丢失的几率为10％。
我希望这可能有所帮助：）
答案 7 :(得分：0)
数据库最典型的用例是持久性，这使得大多数内存数据库不合适。使用内存数据库的一个常见原因是出于测试目的。但这需要您使用可以在内存和其他内容中设置的数据库。
该领域的热门选择似乎是针对.Net开发人员的RavenDB和针对Java开发人员的OrientDB。因为两者都可以作为内存数据库，而“其他”取决于配置，所以您可以使用其中一个，具体取决于您的配置（Java中的.Net，Maven或Ant设置中的app.config）。
答案 8 :(得分：-1)
数据处理需求变得越来越复杂，产品生态系统也在不断发展以满足这些新需求。基于磁盘的RDBMS，内存缓存和内存数据库用于满足不同的需求。你应该选择适合自己需要的东西 -
传统RDBMS：您的MySQL群集足够快，易于维护，并且您希望具备ACID合规性的可靠性。
内存分布式：您的应用程序需要执行快速读写操作，而不必过多担心一致性或复杂事务。
内存中的RDBMS：