在windows下用哪些内存数据库，类似redis的

内存数据库从范型上可以分为关系型内存数据库和键值型内存数据库。在实际应用中内存数据库主要是配合oracle或mysql等大型关系数据库使用，关注性能。

作用类似于缓存，并不注重数据完整性和数据一致性。

基于键值型的内存数据库比关系型更加易于使用，性能和可扩展性更好，因此在应用上比关系型的内存数据库使用更多。

比较FastDB、Memcached和Redis主流内存数据库的功能特性。

FastDB的特点包括如下方面：

1、FastDB不支持client-server架构因而所有使用FastDB的应用程序必须运行在同一主机上；

2、fastdb假定整个数据库存在于RAM中，并且依据这个假定优化了查询算法和接口。

3、fastdb没有数据库缓冲管理开销，不需要在数据库文件和缓冲池之间传输数据。

4、整个fastdb的搜索算法和结构是建立在假定所有的数据都存在于内存中的，因此数据换出的效率不会很高。

5、Fastdb支持事务、在线备份以及系统崩溃后的自动恢复。

6、fastdb是一个面向应用的数据库，数据库表通过应用程序的类信息来构造。

FastDB不能支持Java API接口，这使得在本应用下不适合使用FastDB。

Memcached

Memcached是一种基于Key-Value开源缓存服务器系统，主要用做数据库的数据高速缓冲，并不能完全称为数据库。

memcached的API使用三十二位元的循环冗余校验（CRC-32）计算键值后，将资料分散在不同的机器上。当表格满了以后，接下来新增的资料会以LRU机制替换掉。由于 memcached通常只是当作缓存系统使用，所以使用memcached的应用程式在写回较慢的系统时（像是后端的数据库）需要额外的程序更新memcached内的资料。

memcached具有多种语言的客户端开发包，包括：Perl、PHP、JAVA、C、Python、Ruby、C#。

Redis

Redis是一个高性能的key-value数据库。redis的出现，很大程度补偿了memcached这类keyvalue存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了C++、Java、Python，Ruby，Erlang，PHP客户端。

方式一：使用tmpfs作为文件系统

方式二：使用ramfs作为文件系统

这两种方式的思路都差不多，使用一个内存模拟文件系统，由于替换了磁盘文件系统，数据就保留在内存中。

方式三：修改源码设置in_memory参数

其实wiredtiger本身就支持将数据保留在内存中不刷盘，MongoDB的内存引擎估计也是利用wt的这一特性。wiredtigerin文件中，wiredtiger_open()函数会传入配置信息config，函数前面的注释详细解释了有哪些配置项，其中就列出了in_memory配置，如下图说明。

如果修改源码传入in_memory=true编译还是会报错，提示incompatible argument in-memor。

报上述错误是因为开源版本对这个参数进行了检查，如果设置了就会传回错误码，修改方式很简单，令它不返回错误码就行了。

就这样我们将MongoDB改成了内存数据库。

由上至下的文件位置分别在：

src/third_party/wiredtiger/src/include/wiredtigerin

src/mongo/db/storage/wiredtiger/wiredtiger_kv_enginecpp

src/third_party/wiredtiger/src/conn/conn_ckptc

最近重新使用这个内存数据库，发现报出新的错误，提示in_memory与log不能同时设置，这个log的设置默认为true，如果指定nojournal，那么会置为false。不过先检查后重置，所以报错。

解决方法是在检查之前就加入log=(enabled=false)

前言

NDatabase是一个易于使用的 NET对象数据库 为了避免关系数据库带来的开销 可以尝试用NDatabase NDatabase是新一代的面向对象数据库 个原生的 NET数据库持久层 它的主要特征有

·简单 NDatabase非常简单 很容易学习上手使用 它API是简单 不需要学习任何数据库映射技术 不需要对象和存储持久层之间的映射 NDatabase以最简单的方式存储对象 不需要安装和管理

·小 NDatabase 运行时小于 Kb 部署程序的时候 很容易集成到 NET应用程序中去

·安全健壮 NDatabase支持ACID事务处理 保证数据的完整性 即使在硬件故障的情况下 所有的提交工作都会应用到数据库 在下一次启动的时候自动执行

·单一数据库文件 NDatabase使用单一的文件存储所有的数据 包括元数据 对象 索引等

·生产率 NDatabase使用很少的代码来进行数据持久化 不需要映射 因此 开发人员可以专注于业务逻辑的实现 而不是在数据持久层浪费时间

NDatabase入门

基础设置

NDatabase中所有的数据库引擎设置都在OdbConfiguration类中 如BTree Validation 和BTree index degree的设置都在这个类里面 打开日志的设置也在这个类里面 NDatabase提供了默认的日志类实现 ConsoleLogger 可以使用OdbConfiguration类中的EnableConsoleLogger方法进行设置 实现好自定义的日志类后 还需要进行注册RegisterLogger方法 才能够使用

OdbConfiguration RegisterLogger（new Log NetLogger（））

使用索引

使用IOdb接口的IndexManagerFor方法可以为指定类型添加索引 如

using （var odb = OdbFactory Open（ index ndb ））

{

var fields = new[] { Name };

odb IndexManagerFor<Player>（） AddUniqueIndexOn（ nameIndex fields）

odb IndexManagerFor<Game>（） AddIndexOn（ nameIndex new[] { Result }）

}

使用事务

NDatabase可以使用事务来保证数据的完整性（ACID:原子性 一致性 隔离性 持久性） 当一个NDatabase被打开后 将会自动创建一个会话 包含一个特殊的当前事务对象 这个事务对象实例管理当前所有的数据和数据 *** 作行为

内存数据库模式

NDatabase可以将数据库所有数据直接加载到内存中 直接使用OdbFactory方法的 OpenInMemory即可

关于触发器

要增加一个触发器 首先要建立一个实现了Trigger 接口（）的类 该接口有 种可用的类型（InsertTrigger UpdateTrigger SelectTrigger DeleteTrigger） 如

public class MyTrigger : InsertTrigger

{

public override bool BeforeInsert（object obj）

{ return true; }

public override void AfterInsert（object obj OID oid）

{ }

}

在使用过程中 打开数据库后 要注册触发器 才能使用

var mage = new Mage（ Merlin ）

var myTrigger = new MyTrigger（）

using （var odb = OdbFactory Open（ inserting_trigger db ））

{

odb TriggerManagerFor<Mage>（） AddInsertTrigger（myTrigger）

odb Store（mage）

}

lishixinzhi/Article/program/net/201311/16138

相对于磁盘，内存的数据读写速度要高出几个数量级，将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。同时，内存数据库抛弃了磁盘数据管理的传统方式，基于全部数据都在内存中重新设计了体系结构，并且在数据缓存、快速算法、并行 *** 作方面也进行了相应的改进，所以数据处理速度比传统数据库的数据处理速度要快很多，一般都在10倍以上。内存数据库的最大特点是其"主拷贝"或"工作版本" 常驻内存，即活动事务只与实时内存数据库的内存拷贝打交道。显然，它要求较大的内存量，但并非任何时刻整个数据库都存放在内存，即内存数据库系统还是要处理I/O。

内存数据库是以牺牲内存资源为代价换取数据处理实时性的，内存数据库和磁盘数据库都是当今信息社会里每个企业所必须的关系型数据库产品，磁盘数据库解决的是大容量存储和数据分析问题，而内存数据库解决的是实时处理和高并发问题。两者的存在是相辅相成的，内存数据库的事务实时处理性能要远强于磁盘数据库。但是相对的，他的数据安全方面还没有达到磁盘数据库比肩的地步。

内存数据库将物理内存作为数据的第一存储介质，而将磁盘作为备份。随着电信业务的发展，系统对实时性的要求和对业务灵活修改的要求非常高，在此种情况下对于内存数据库的需求也越来越高。磁盘数据库的做法是将数据存入内存中进行处理，这种方式的可管理性及数据安全可靠性都没有保障。而内存数据库正是针对这一弱点进行了改进。

实际上，内存数据库并不是一项时髦技术，其出现于上世纪60年代末，但由于市场的需求原因在90年代后期才开始发展。作为新一代数据库，Altibase产品已经走向混合型数据库，其版本Altibase 40已经有一套自带的磁盘数据库，用户一旦购买了Altibase的内存数据库，就无须再购买磁盘数据库。它把热数据（经常被使用的、访问比较高的、经常要运算的数据）放在内存数据库里，而把历史性数据放在磁盘数据库里，可为用户进一步减少投资。

对于内存数据库而言，可以将同样数据库的部分内容存放于磁盘上，而另一部分存放于内存中。用户可以选择将数据存储在内存表中以提供即时的数据访问。若访问时间不紧急或数据存于内存中所占空间过大时，用户可将这些数据存入磁盘表中。

比如，在手机用户开始拔打电话时，如果应用基于内存数据库技术的混合数据管理引擎，就通过内存表检索其服务选项并立即验证用户身份，而将通话清单和计费清单归档到磁盘表中。从而，达到了速度与资源使用的平衡。

内存数据库的技术，一个很重要的特点，是可以对内存中的数据实现全事务处理，这是仅仅把数据以数组等形式放在内存中完全不同的。并且，内存数据库是与应用无关的，显然这种体系结构具有其合理性。内存引擎可以实现查询与存档功能使用的是完全相同的数据库，同时内存表与磁盘表也使用的是完全相同的存取方法。存储的选择，对于应用开发者而言是完全透明的。

对于内存数据库而言，实现了数据在内存中的管理，而不仅仅是作为数据库的缓存。不像其它将磁盘数据块缓存到主存中的数据库，内存数据库的内存引擎使用了为随机访问内存而特别设计的数据结构和算法，这种设计使其避免了因使用排序命令而经常破坏缓存数据库性能的问题。通过内存数据库，减少了磁盘I/O，能够达到了以磁盘I/O 为主的传统数据库无法与其相比拟的处理速度。

因此，内存数据库技术的应用，可以大大提高数据库的速度，这对于需要高速反应的数据库应用，如电信、金融等提供了有力支撑。

由于把大多数数据都放在内存中进行 *** 作，使得内存数据库有着比磁盘数据库高得多的性能表现，这一特点非常契合电信企业运营支撑系统对实时性的要求。

电信业的竞争正在全方位地展开，这种竞争必然带来新的价值链模式以及新的计费方式，这些变化对目前的电信运营支撑系统是一个挑战。比如，多种业务的计费环节将不再是单一的按照时长或通信距离收取费用，而可能是根据时长、内容、使用量等多种参数的组合计费。为了应对这些挑战，电信企业先后引入了内存数据库，以提高后台数据管理的实时性、精确性和灵活性。

尽管内存数据库已不是传统磁盘数据库的概念，但是内存数据库本质上还是数据库，它也具有一般数据库的基本功能:

■ 永久数据的管理，包括数据库的定义、存储、维护等;

■ 完成各种数据 *** 作，如查询处理、存取、完整性检查;

■ 事务管理，包括调度与并发控制等;

■ 对存取的控制和安全性检验;

■ 具有数据库的可靠性恢复机制。

相对于利用程序开发手段调用内存处理来说，内存数据库自有其优势。首先，内存数据库是产品化的数据库管理软件，极大缩短了开发周期; 其次，内存数据库有着开放的平台和接口，程序开发和移植更加灵活便捷，也便于维护和二次开发; 第三，可以通过使用统一的SQL语言方便地查询内存中的数据; 最后，能在数据库中保障数据的安全性和完整性。这些优势，对于快速部署和简化维护都是有利的。

但内存数据库也有其不可避免的缺点，比如: 不容易恢复，内存数据库中的数据不总是永久的，为了保证实时，也不一定是一致和绝对正确的，有的是短暂的，有的是暂时不一致或非绝对正确的。

电信企业一直是内存数据库的主要用户，近几年来，随着计算机硬件技术的飞速发展、内存容量的提高、价格下跌以及计算机进入64位时代 *** 作系统后可以支持更大的地址，为内存数据库的实现提供了可能。目前内存数据库在电信行业的应用也日趋成熟，已有超过90G的电信系统案例，能自动扩展内存空间，不需要重启数据库，提供ESOL自定义存储过程，支持多线程，开发效率高，程序移植容易等等。

下面以两个例子来介绍内存数据库的应用。

电信计费数据的加载

电信的二次批价和实时累账是计费系统中的两个必备功能。

所谓二次批价是相对于一次批价来说的。

一次批价是按照国家标准资费来进行价格计算，比如: 全球通每分钟本地通话为04元，在一次批价完成后，会根据这个用户的套餐进行再一次的计算。以北京全球通用户接听4分钟的电话为例，一次批价完成后，这条话单的价格是16元，如果这个用户参加了10元包月接听套餐，那么在二次批价后，这次通话的费用就为0元。

一次批价是用于各大运营商之间结算的，而二次批价是针对用户个人的。

实时累账是将用户从每月1号到目前为止的所有费用累加起来，也就是用户目前可以通过10086查到截止到前一天的实时话费。累账值可以帮助用户控制高额话费或是供用户即时查询消费信息。

二次批价和实时累账过程涉及用户资料、用户套餐等与用户相关的信息，电信支撑系统在开始批价时必须加载这些数据。稍大一点的省级运营商的这些数据就会超过1000万条，计费处理模型也由于套餐的组合、产品的组合以及不同的优惠规则变得相当复杂，加载这部分数据对系统而言是一笔不小的开销，这就使得现在的计费处理速度比较慢，而且很难做到对数据的实时更新。内存数据库的引入在一定程度上解决了这个问题。

在计费二次批价过程中数据量最大的是详单数据，这部分数据不用放在内存数据库中，每处理完一个话单文件或达到设定的提交记录数时直接 *** 作磁盘数据库，不会影响系统性能。最急切的是将用户资料、套餐、营业套餐和计费套餐对应关系数据、计费套餐模型数据及用户累计数据放到内存数据库中，这部分数据查询 *** 作远比数据新增和更新 *** 作要频繁。除了这些数据外，当然还有应用需要的其他数据也都可以加载到内存数据库。

在采用内存数据库后，用户通过营业部或客户查询实时话费的时候完全可以做到实时，比目前只能提供查询到前一天的实时话费在业务上有了质的飞跃。因为系统在处理这部分数据时查询流程和以前的完全一样，但系统省去了以往内存中的数据和磁盘数据库数据同步的环节，所以就能做到了实时查询。对于信控来说也同样，以往系统在累完账后要按照一定周期刷新信控数据，这就存在一个时间差，不能够完全做到实时。

而采用内存数据库后，信控可以直接取得内存数据库中的实时话费累计表中的数据，完全实现实时预警、停机。二次批价和累账中采用内存数据库后，对防欺诈、收入保障系统也有相当大的好处，这样能够充分保证运营商的切身利益。

另外，在采用内存数据库后，整体提高了系统批价、累账的处理速度，大大缓解访问磁盘数据库的压力，提高数据查询、修改、删除的效率，也为后付费和预付费的融合提供了可能。

电信计费数据的同步

电信营业数据和计费系统中的数据总是在不断的变化中，这就涉及内存数据库中的数据和磁盘数据库数据的同步问题（为了描述清楚，这里的磁盘数据库以Oracle DB为例来说明）。数据同步包括两部分: 从内存数据库到Oracle DB数据同步和从Oracle DB到内存数据库的同步。

1 Oracle DB到内存数据库同步

这部分数据同步采用增量表的方式，营业系统或CRM新增或更新的数据将生成到Oracle的增量表中，计费后台程序先到这些增量表中查询数据。如果能在这些增量表中查到数据就把这些数据更新到内存数据库对应表中，如果查不到，就直接从内存数据库中直接查询，从而保证了数据的完整性和实时性。由于增量表的数据量一般会很小，所以这部分 *** 作不会影响系统的性能。

2 内存数据库到Oracle DB同步

由于Oracle的计费后台批价、累账数据几乎都加载到了内存数据库中，所以Oracle数据库对应的数据表将主要用于对内存数据库的数据备份。

用户最新的实时话费等信息都保存在内存数据库中，实时话费查询将直接连接到内存数据库中查询，保证用户得到最新的费用信息。信控也直接从内存数据库查询数据，因此对Oracle中的这部分数据已经没有实时性的要求。这时内存数据库到Oracle的同步可以由应用程序生成文件，定时地往Oracle数据库中同步备份，或者采用Oracle 存储过程在系统相对空闲时间段进行数据导入就可以了。

总体而言，由于市场与技术的快速发展，电信业务在不断扩充，其运营和管理不断优化，传统的一些支撑系统的架构已经逐渐不能满足日益增长的业务要求和客户需求，引入一些新的技术来解决我们生产中遇到的问题是必然的。比如采用内存数据库来代替以前的共享内存技术，使得原来在内存中不标准的东西，包括接口、格式和管理都标准化了。

内存数据库只是多种新技术中有代表性的一种而已，只要解放思想、选用得当，完全可以在投入不大的情况下克服系统中的瓶颈，以最小的代价获得最大回报。

通用数据库大家见的多了，Oracle、Db2、Sqlserver、Sybase、Informix 还有最近比较火的Mysql、和Pqllite，当然还不能忘记开源的PostgreSQL。通常情况下这些数据库可以承担重要业务，但是在要求高性能方面还是略有不足。在计费系统中如果用户信息常常改变的话延迟方面就会产生比较大的影响，甚至能影响到计费系统的正常运行。

我接触到唯一的内存数据库就是亚信在中移动计费中心稽核系统中使用的。由于稽核系统需要实施同步用户状态信息和订购信息，然后对产生的话单进行稽核，如果响应速度较慢的话就会产生错误的结果。最初没有稽核系统的时候，计费的标准基本是sp发过来的，然而用户方面却经常发现自己没有实际使用或者已经取消这项业务的时候，自己的帐单中仍然收取了费用，因此中移动决心要对sp的话单进行稽核，以自己的数据为标准，彻底剪断sp乱收费的手段。

如果要取到用户状态信息和订购信息的话就要从多个系统中同步过来，同时对话单进行稽核，中间的处理时间要求比较严格（用户可能会在短时间内检查自己的话费信息），对系统响应时间就要尽量短。

通用数据库在这方面处于劣势。亚信就以三台rx8420作为数据库主机，将31个省用户的信息按照数量的多少分担到三台主机，每个省至少有一个入库进程，对于用户比较多的就采用多个进程进行入库。数据的采集来源主要是通过BOSS和计费的一级系统。

由于数据是存储在内存中，所以存储的数据结构和通用数据库有所差异，同时为了保证数据的安全，在磁盘上有一个内存数据的镜像，每隔一定时间将内存中的数据同步到磁盘上，当主机故障时可以通过磁盘恢复数据。当主机故障时，会有备用主机通过HA接管。但是对于数据 *** 作的日志和回滚就没有Oracle做的好了，只提供了简单的恢复机制。

在计费系统中首先要对sp发来的话单进行稽核，主要标准是用户状态和订购信息。例如用户最近7天一直处于关机状态，如果sp的话单中出现新的订购信息就将此条话单作为错单处理。移动通过这种方式在和sp的博弈中取得主动。稽核系统上线后用户对于sp的投诉问题明显减少。

链接一:内存数据库与传统数据库的异同

传统的数据库系统是关系型数据库，开发这种数据库的目的，是处理永久、稳定的数据。关系数据库强调维护数据的完整性、一致性，但很难顾及有关数据及其处理的定时限制，不能满足工业生产管理实时应用的需要，因为实时事务要求系统能较准确地预报事务的运行时间。

对磁盘数据库而言，由于磁盘存取、内外存的数据传递、缓冲区管理、排队等待及锁的延迟等使得事务实际平均执行时间与估算的最坏情况执行时间相差很大，如果将整个数据库或其主要的"工作"部分放入内存，使每个事务在执行过程中没有I/O，则为系统较准确估算和安排事务的运行时间，使之具有较好的动态可预报性提供了有力的支持，同时也为实现事务的定时限制打下了基础。这就是内存数据库出现的主要原因。

内存数据库所处理的数据通常是"短暂"的，即有一定的有效时间，过时则有新的数据产生，而当前的决策推导变成无效。所以，实际应用中采用内存数据库来处理实时性强的业务逻辑处理数据。而传统数据库旨在处理永久、稳定的数据，其性能目标是高的系统吞吐量和低的代价，处理数据的实时性就要考虑的相对少一些。实际应用中利用传统数据库这一特性存放相对实时性要求不高的数据。

在实际应用中这两种数据库常常结合使用，而不是以内存数据库替代传统数据库。

链接二:几款内存数据库产品

■ Oracle TimesTen

Oracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库，它为应用程序提供了实时企业和行业（例如电信、资本市场和国防）所需的即时响应性和非常高的吞吐量。Oracle TimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中，它利用标准的 SQL 接口对完全位于物理内存中的数据存储区进行 *** 作。

■ Altibase

Altibase是一个在事务优先的环境中提供高性能和高可用性的软件解决方案。它提供高性能、容错能力和事务管理能力，特别适合通信、网上银行、证券交易、实时应用和嵌入式系统领域。Altibase能够最大限度地发挥数据库服务系统的潜力，增强数据服务器的处理能力。Altibase支持客户端/服务器架构或嵌入式架构。其中客户端/服务器架构非常适合一般的应用。而嵌入式架构将应用程序嵌入到数据库服务器，适合于有高时效要求的实时系统。

■ eXtremeDB

eXtremeDB实时数据库是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库，只有 50K到130K的开销，速度达到微秒级。eXtremeDB完全驻留在主内存中，不使用文件系统（包括内存盘）。eXtremeDB采用了新的磁盘融合技术，将内存拓展到磁盘，将磁盘当做虚拟内存来用，实时性能保持微秒级的同时，数据管理量在32BIT下能达到20G。

以上就是关于在windows下用哪些内存数据库，类似redis的全部的内容，包括:在windows下用哪些内存数据库，类似redis的、如何将MongoDB改造成内存数据库、C#开源轻量级对象数据库NDatabase介绍[1]等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！