我什么时候应该考虑使用内存数据库,需要注意哪些问题?[英] When should I consider using a in memory database and what are the issue to look out for?

本文是小编为大家收集整理的关于我什么时候应该考虑使用内存数据库,需要注意哪些问题?的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

我只是认为现在在数据库服务器上有足够的RAM来缓存您的完整数据库为什么专家内存数据库(E.G timesten ,另请参见 wikipedia page )几年前,这一切都没有被更多地使用吗?

似乎随着时间的流逝,没有基于磁盘的数据库的使用更少,例如,大多数应用程序现在构建在常规合理数据库上.我本来会期望与RAM接近很多服务器的免费.

我在问这个,因为我刚刚在堆栈跨流程结构上阅读,并且页面说

这很重要,因为堆栈 Overflow的数据库几乎是 完全在RAM中,连接仍然 完全太高的成本.

,我认为如果使用"指针"和"收藏"而不是普通的btree,这不会是一个问题. BTREE非常聪明,可以在磁盘访问速度上进行圆形限制,例如,他们交易CPU使用以减少磁盘使用情况.但是,我们现在有如此匹配RAM.

,但我们仍然需要数据库,因为您自己做

  • 锁定
  • 死锁检测
  • 交易记录
  • 恢复
  • etc

很难.

@s.lott,鉴于我们所有人都花了很长时间选择索引,避免加入并调查数据库性能问题.一定会有更好的办法.几年前,我们被告知"记忆数据库"是更好的方法.因此,在我开始使用一个等等之前,我希望知道为什么其他人不再使用它们.

(我不太可能自己使用Timesten,因为它的价格高( $ 41,500.00/处理器)而且我不喜欢与Oracle销售人员交谈 - 我宁愿花时间编写代码.)

另请参见:

更新:

我问了这个问题 long 时间前,这些天Microsoft SQL Server具有" 内存OLTP "这是集成在SQL Server引擎中的内存优化数据库引擎.它不是便宜的,但似乎很快对于某些工作负载.

推荐答案

很可能没有存储数据库的成熟产品,可以用作经典数据库的完整替代品.

关系数据库是一个非常古老的概念.尽管有许多方法可以向前发展和开发新技术,例如.面向对象的数据库,关系数据库并没有真正改变其概念.不要指望情况会改变太快,因为数据库在过去的十或十五年甚至更长的时间内都不会发生太大变化.

我认为,技术的开发并不像人们认为的那么快.新概念成熟和建立需要数十年.首先,数据库技术中的成熟度比其他任何事物都重要得多.

在十或二十年的时间里,数据库可能不再与今天一样.如果内存数据库是未来的 - 今天没有人可以告诉这个 - 他们只需要更多时间来开发.

其他推荐答案

没有人真正回答"我什么时候应该考虑在内存数据库中使用一个问题?所以我去吧.

您应该考虑以下记忆数据库 1.目标系统有数据要管理,但没有持续的媒体 2.持续数据库

根本无法满足性能要求

对于#1,请在您的机顶盒(STB)中考虑电视指南.低端STB(即没有DVR功能的人)没有持久存储,也不需要持久存储.但是400次通道,14天的电视指南的数据库是非平凡的.这里也有一个性能要求,因为数据以高速从应答器旋转木马到达,这是"捕获它或等到旋转旋转木马再次出现"的情况.但是不需要坚持.我们都看过这一点;当您在家里失去电力时,当它回到电视指南时说"将很快可用",因为它是从应答器或电缆头端提供的.网络路由器共享相同的特征:无持续存储,需要快速,并且可以从外部源提供数据库(在这种情况下,在网络上的peer路由器,以重新填充路由表).

.

有无数的例子:军事系统中的实时目标,高频交易系统等等.

关于问题的第二部分,"要注意":有很多.

如果您需要仅使用内存数据库可以提供的性能,请确保您评估一个真正的内存数据库.缓存持续数据库不是相同的.将持久数据库扔在RAM驱动器中并不相同.使用内在进行事务记录的内存数据库(如Timesten)是不相同的(即使您登录到/dev/null).

确保您正在评估数据库系统,而不仅仅是缓存(例如memcache).数据库系统将对具有酸性属性,多个索引选项,支持并发访问等交易提供支持.

关于酸:内存数据库系统不缺少" D"(耐用性).它只是必须在上下文中进行.持续数据库中的交易仅耐用,只要其存储在媒体上是耐用的.对于内存数据库而言,同样的事情也是如此.无论哪种情况,如果您关心耐用性,最好有备份.

其他推荐答案

这种趋势似乎是积极缓存并使用数据库来填充缓存.无论数据库所处的位置,加入仍然很昂贵,因此偏好似乎是进行一次加入并缓存结果,例如 memcached velocity .

周围仍有内存数据库,它们被使用,但这取决于您要使用它们的上下文. sqlite 例如,在测试数据层时,通常用作内存数据库的内存数据库.

本文地址:https://www.itbaoku.cn/post/597699.html

问题描述

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:

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.

推荐答案

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.

其他推荐答案

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.

其他推荐答案

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.