27

我只是认为现在您的数据库服务器上通常有足够的 RAM 来缓存您的完整数据库，为什么几年前风靡一时的内存数据库专家 （例如TimesTen，另见Wikipedia 页面）没有被使用更多的？

似乎随着时间的推移，非基于磁盘的数据库的使用越来越少，例如，现在大多数应用程序都建立在传统的理性数据库之上。我本来预计会出现相反的情况，因为许多服务器的 RAM 越来越接近免费。

我在问这个，因为我刚刚阅读了 stack-overflow-architecture 并且页面上说

这很重要，因为 Stack Overflow 的数据库几乎完全在 RAM 中，而且连接的成本仍然太高。

但我认为如果使用“指针”和“集合”而不是普通的 btree，这将不是问题。Btree 是一种非常聪明的对磁盘访问速度进行限制的方法，例如，它们交换 CPU 使用率以减少磁盘使用率。但是我们现在有这么匹配的 ram。

但是我们仍然需要数据库，就像自己做的那样

  • 锁定
  • 死锁检测
  • 事务日志
  • 恢复
  • ETC

非常难。

@S.Lott，鉴于我们都花了很长时间选择索引、避免连接和调查数据库性能问题。肯定有更好的办法。几年前，我们被告知“内存数据库”是更好的方法。所以在我开始使用一个 etc 之前，我想知道为什么其他人没有更多地使用它们。

（我自己不太可能使用 TimesTen，因为它价格高（41,500.00 美元/处理器）而且我不喜欢与 Oracle 销售人员交谈——我宁愿花时间编写代码。）

也可以看看：

更新：

很久以前我问过这个问题，现在 Microsoft SQL Server 有“内存中 OLTP ”，这是一个集成到 SQL Server 引擎中的内存优化数据库引擎。它并不便宜，但对于某些工作负载来说似乎非常快。

4

9 回答 9

13

没有人真正回答“我什么时候应该考虑使用内存数据库以及需要注意什么问题？”这个问题。所以我会试一试。

在以下情况下，您应该考虑使用内存数据库： 1. 目标系统有数据要管理，但没有持久性媒体 2. 持久性数据库根本无法满足性能要求

对于 #1，请考虑机顶盒 (STB) 中的电视指南。低端机顶盒（即没有 DVR 功能的机顶盒）没有持久存储，也不需要持久存储。但包含 400 个频道、14 天的电视指南的数据库并非易事。这里也有性能要求，因为数据从转发器轮播高速到达，这是“捕获它或等到轮播再次出现”的情况。但是没有必要坚持。我们都看到了这一点；当您在家中断电时，当它重新出现在电视指南上时，会显示“很快就会可用”，因为它正在从转发器或电缆前端进行自我配置。网络路由器具有相同的特性：没有持久存储，需要快速，

#2 的例子数不胜数：军事系统、高频交易系统等中的实时定位。

关于问题的第二部分，“需要注意的问题”：有很多。

如果您需要只有内存数据库才能提供的性能，请确保您正在评估一个真正的内存数据库。缓存持久性数据库是不一样的。在 RAM 驱动器中投入持久性数据库是不一样的。使用固有地执行事务日志记录的内存数据库（如 TimesTen）是不一样的（即使您登录到 /dev/null）。

确保您正在评估数据库系统，而不仅仅是缓存（例如 memcache）。数据库系统将支持具有 ACID 属性的事务、多个索引选项、支持并发访问等。

关于 ACID：内存数据库系统不缺少“D”（持久性）。它只需要在上下文中进行。持久数据库中的事务只有在其存储的介质是持久的时才持久。内存数据库也是如此。无论哪种情况，如果您关心耐用性，最好有一个备份。

于 2012-12-05T23:59:31.717 回答
5

趋势似乎是积极缓存并使用数据库填充缓存。无论数据库位于何处，连接仍然很昂贵，因此首选似乎是执行一次连接并将结果缓存在Memcached或Velocity之类的东西中。

周围仍然有内存数据库并且它们被使用，但这取决于您想要使用它们的上下文。例如，在测试数据层时， SQLite通常用作内存数据库。

于 2009-10-20T10:52:07.740 回答
5

很可能没有成熟的内存数据库产品可以完全替代经典数据库。

关系数据库是一个非常古老的概念。尽管有许多方法可以推进和开发新技术，例如。面向对象的数据库，关系数据库并没有真正改变它们的概念。不要期望事情变化太快，因为数据库在过去十年或十五年甚至更长时间内没有太大变化。

我认为，技术的发展并没有人们想象的那么快。新概念的成熟和确立需要几十年的时间。首先是数据库技术，成熟度比其他任何事情都重要得多。

十年或二十年后，数据库可能不再像今天一样。如果内存数据库是未来——今天没有人能说清楚——他们只需要更多的时间来开发。

于 2009-10-21T08:39:23.243 回答
4

最重要的原因是货物文化，以及IT知识水平非常低。无论使用哪种持久性解决方案，大多数应用程序都能很好地工作，而且随着计算机每年的速度越来越快，没有足够的人能感受到痛苦并能够查明问题所在。

微软和甲骨文通过他们的数据库产品赚了太多钱，以至于他们（政治上）有可能想出更好的方法。

使用关系数据库的开发成本不透明，因此管理层不知道存在问题，更不用说解决方案了。

于 2011-08-28T15:43:12.037 回答
2

嗯，内存数据库本质上通常缺乏ACID（原子性、一致性、隔离性、持久性）中的D（持久性）。这可以通过“混合”方法在一定程度上克服，但是，在某些时候必须将某些东西（数据本身或事务日志）保存在某个地方以提供持久性方面。这通常会降低性能或将其他不受欢迎的属性引入内存数据库解决方案

相比之下，当今的大多数 RDBMS 都具有 ACID 的完整补充，并且在它们背后有数十年的发展。这导致基于磁盘的数据库系统具有非常高的性能，尤其是在现代 RDBMS 系统经历了多年的改进和优化之后（您的BTree示例只是其中之一）。

另一个因素是我们作为应用程序开发人员通过缓存等机制减少数据库负载的能力，从而从应用程序的数据层挤压更多感知性能。事实上，缓存本身近年来已经有了广泛的发展，现在分布式缓存很常见（例如，看看memcached 的用户数量）。

具有讽刺意味的是，现代缓存系统在许多方面都在慢慢变形为类似于真正的内存数据库系统的东西。内存数据库，就像面向对象的数据库一样，在很大程度上是“新的孩子”，所以看看所有这些及时去哪里会很有趣。甲骨文现在已经收购了 TimesTen，根据这篇维基百科文章，微软正在考虑很快进入内存数据库市场。这是传统 RDBMS 领域的两个现代“大玩家”，他们正在认真对待内存数据库系统。

于 2009-10-20T10:58:03.993 回答
1

这也是一个选项：http ://www.memsql.com/

我没有亲自使用过它，但它应该类似于内存中 MySQL 的替代品。

于 2013-03-15T02:57:45.140 回答
0

各种便携式 SQL 版本，以相同的效率工作，主要为移动设备设计。

SQLite

SQL Server 精简版

这些只是大玩家，可能还有其他选择，但是大玩家在发布它时会处理最低要求.. :)

并且在内存数据库中，如果出现波动或断电，您会不断备份数据，您可能会丢失整个数据。与其他将作为其在辅助内存（HDD）中处理的一样，与内存数据库相比，丢失的机会将是 10%。

我希望这可能会有所帮助:)

于 2013-03-15T10:43:04.253 回答
0

数据库最典型的用例是持久性，这使得大多数内存数据库不适合。使用内存数据库的一个普遍原因是出于测试目的。但这需要您使用既可以设置为内存中的数据库，也可以设置为其他数据库。

该领域的流行选择似乎是适用于 .Net 开发人员的 RavenDB 和适用于 Java 开发人员的 OrientDB。因为两者都可以用作内存数据库，并且根据配置“其他”，所以您可以根据您的配置使用其中一种（.Net 中的 app.config、Java 中的 Maven 或 Ant 设置）。

于 2013-03-15T10:58:21.940 回答
-1

数据处理需求变得越来越复杂，产品生态系统也在不断发展以满足这些新需求。基于磁盘的 RDBMS、内存缓存和内存数据库用于满足不同的需求。你应该选择适合你需要的东西 -

传统的 RDBMS：你的 MySQL 集群足够快，足够容易维护，并且你喜欢 ACID 兼容的可靠性。

内存中分布式cahce：您的应用程序需要进行快速读取和写入，而不必过多担心一致性或复杂事务。

内存 RDBMS：

  1. （速度）：您的应用程序需要比基于磁盘的数据库更快地处理数据/请求。
  2. （复杂性）：您需要使用连接和聚合进行复杂的事务性读取和写入，并且喜欢使用 SQL 的强大功能。
  3. （可扩展性）：您需要在不停机的情况下水平扩展数据库。
  4. （可维护性）：您需要数据库提供高可用性、复制、负载平衡和灾难恢复，而不会增加您的维护工作量。
  5. （警告）：您的数据应该适合内存（通常以 TB 为单位）。
于 2016-02-25T14:33:03.793 回答