精华内容
下载资源
问答
  • 在大多数情况下,为了充分发挥Windows NT 4.0系统效能,内存的作用比起处理器的处理能力更具有影响力,特别是在客户/服务器模式环境...本文主要介绍利用如何优化SQLServer数据库服务器内存配置提出一些认识和看法。
  • 数据库服务器虚拟内存设置

    千次阅读 2018-01-16 15:21:09
    今天收到一台数据库服务器的磁盘空间告警邮件,如下所示,C盘总共60G,只剩下3.13G大小空间,Free Rate 为5.22%。 因为msdb、tempdb等系统数据库都不在系统盘(C盘),对于突然出现的系统盘磁盘空间不足,...

    问题场景

    今天收到一台数据库服务器的磁盘空间告警邮件,如下所示,C盘总共60G,只剩下3.13G大小空间,Free Rate 为5.22%。

    clip_image001

    因为msdb、tempdb等系统数据库都不在系统盘(C盘),对于突然出现的系统盘磁盘空间不足,感觉有点奇怪,想了解一下到底是什么原因导致这种情况出现。于是用TreeSize 工具扫描了一下C盘,除了目录C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log下将近600M的错误日志文件,罪魁祸首居然是虚拟内存页面文件pagefile.sys,居然有36G大小,而整个系统盘只分配了60G大小的空间。如下图所示:

    clip_image002

    其实,关于虚拟内存页面文件的设置,公司的文档是有明确规定的:

    When a SQL Server is configured correctly, it doesn’t use the page file for memory. In theory, we don’t need a page file at

    all. Properly configure the Page File settings

        a. Ensure the sum of all page files is equal to the amount of memory in server.

        b. Do not let the system manager your page file.

        c. Ensure the Initial Size and Maximum Size have the same settings.

    只是我一直忽略了这个,不大关心服务器的虚拟内存配置,因为公司DBA与系统管理员是职责分明的,只是突然发现这台服务器设置有些异常,原因在于这台服务器RAM 为32G,但是关于虚拟内存的配置是自动管理驱动器的分页文件大小。如下所示

    clip_image003

    可以看到虚拟内存页面文件pagefile.sys全部位于C盘,让系统自动管理其大小,所以才会出现pagefile.sys增长到36G大小,同事给予的建议是将虚拟内存设置为32G,C、D、E、F四个盘设置4个虚拟内存页面文件,每个文件初始大小为8G,最大大小也为8G。这样可以达到最佳优化配置。

    clip_image004

    clip_image005

    网上关于虚拟内存的优化方法,其实是上面关于虚拟内存配置的详细解释:

    1、分割存于多个硬盘

    将虚拟内存设在较快的硬盘上,的确可使虚拟内存的运作更有效率。但是若电脑上两个硬盘速度一样快,则应将虚拟内存平均分配在两个不同的硬盘上(并非同一硬盘的不同分区)。因为同步进行读写操作会更有效地提高系统整体的虚拟内存性能。例如,我将上面位于C盘的32G大小的虚拟内存文件,分为4份,每份8G大小置于C、D、E、F四个盘。理论上这样做会加快虚拟内存整体的读写操作.但是我没有一个好的测试案例来验证结果。

    2、硬盘需有足够空间

    如果你不是很有经验的电脑用户,又或者没有特殊的使用要求,在Windows XP中选择“系统管理的大小”的方法来自动处理虚拟内存,一般情况下应该会比选择“自定义大小”的方法来得安全和稳定。不过,有一点大家必须注意,由于虚拟内存的“页面文件”(pagefile.sys)会随着电脑使用过程进行收缩和扩展,为使系统管理虚拟内存能够进行得顺利和更具弹性,必须保证分页文件所在的硬盘拥有足够的可用空间。

    3、最小值等于最大值

    选择“自定义大小”的方法来处理虚拟内存,并将最大值和最小值都设为同一数值。有很多人都相信用这种方法来处理虚拟内存有助于提高系统的性能。他们所持的理由是,当最大值和最小值都相等时,系统无需时刻进行收缩和扩展页面文件的动作。省去了这些工作,相应地就是提高系统效率。

    这种方法,很多人坚信有效,但同样地,也有人指出其实并没有效果。但不管怎样也好,如要将最大值和最小值设为相等,必须坚守一个原则,那就是虚拟内存的大小必须足够,否则系统轻则会出现效率下降(要进行更多复写动作来腾出空间),严重的更会造成系统不稳定。

    展开全文
  • 你在为大型系统设计数据库系统时,能够买到有许多硬盘和充足内存的大型数据库服务器。以下是你在设计系统时应当遵守的一些基本原则。 存储系统 人们在设计磁盘阵列时最常犯下的错误就是,只计算所需的闲置容量...
         随着服务器硬件的功能变得越来越强大,而价格一路急剧下跌,许多公司(尤其是小公司)发现如今购买数据库服务器面临众多选择。这意味着,经验相对欠缺的数据库管理员们也被要求设计功能越来越强大的系统。你在为大型系统设计数据库系统时,能够买到有许多硬盘和充足内存的大型数据库服务器。以下是你在设计系统时应当遵守的一些基本原则。

      存储系统

      人们在设计磁盘阵列时最常犯下的错误就是,只计算所需的闲置容量。闲置容量只是设计存储子系统时要考虑的一部分而已;另一个部分就是存储系统需要支持的输入/输出操作次数。

      应当遵守的一条基本原则就是,写操作频繁的数据库最好使用RAID 10阵列,而读操作频繁的数据库通常最好使用RAID 5阵列。原因在于,如果把数据写到RAID 5阵列,性能会受到影响。由于把数据写到RAID 5阵列上,存储系统必须在写数据之前计算出奇偶检验位,而算出奇偶检验位需要相当长的时间,这意味着写到RAID 5阵列上的性能会降低。

      由于这种性能影响,我们总是建议你应当把事务日志放到RAID 10阵列上。事务日志是写操作始终很频繁的文件,不管数据库是以读操作为主的数据库,还是以写操作为主的数据库。tempdb数据库也应当放在RAID 10阵列上,具体来说放在与事务日志文件所在阵列不同的另一个RAID 10阵列上。

      对每个磁盘阵列进行分区时,应当确保分区正确对齐。默认情况下,Windows 2003及以下版本没有正确对齐分区,这会导致磁盘子系统的性能达不到最理想水平。可以通过使用diskpart.exe实用程序(Windows 2000中的diskpar.exe)创建分区来解决这个问题。这样创建的每个分区其对齐偏移量应为64kb;在默认情况下,创建的每个分区其对齐偏移量为32kb。Windows 2008在默认情况下创建的分区其对齐偏移量为128kb。

       物理数据库构建

      微软最近开始推荐使用的一项比较新的技术就是,针对两个至四个CPU核心当中的每个核心,数据库应当有一个物理数据库文件。应当为数据库里面的每个文件组做到这一点。

      如果你的服务器有两个四核CPU,那么共有八个核心。我们假定数据库有两个文件组,一个名为Data,另一个名为Indexes。那么每个文件组都应当有两个至四个物理文件。这项技术让SQL Server可以对磁盘输入/输出进行优化。可能的话,你应当尽量分散文件,以便位于每个存储阵列上的文件尽可能少。

      tempdb数据库的配置应有点不同。配置tempdb数据库时,建议针对每个CPU核心,数据库应当有一个物理文件。这样系统就可以为tempdb数据库尽量加快输入/输出操作。与用户数据库一样,放在每个磁盘阵列上的文件也应当尽可能少。

      你在数据库里面应当始终至少有两个文件组。第一个文件组包括表,第二个组包括索引。你需要让它们位于不同的文件组,那样查询索引时,装入到表的操作不会受到影响,反之亦然。

      系统内存

      在过去,购买只安装了数GB内存的数据库服务器相当常见。那是因为内存的价格还很昂贵。

      如今,内存价格相当便宜;只要你能承受得了,应当购买尽量多的内存。内存越多,数据库的运行速度几乎总是越快。例外情况就是,如果你安装的内存超过了数据库的大小。举例来说,如果你有3 GB大小的数据库,但安装了8GB内存,那么为服务器添加更多内存对提升数据库的性能没有帮助,因为SQL Server可能已经能把整个数据库装入到内存中。

      在决定为SQL Server分配多大内存时,绝对不要让SQL Server把所有内存都分配给它。因为Windows操作系统需要内存来运行,安装在数据库服务器上的其他任何软件同样需要内存来运行,比如备份软件和反病毒软件等。 建议留出一两GB内存用于操作系统及所用的其他软件。这个内存量的大小取决于安装了哪些软件。

      因为没有两个数据库服务器是一样的,所以没有明确的原则规定你的硬件解决方案应当是什么样子。你有众多选择;要设计一款将来可以使用多年的可靠的解决方案,关键在于明白自己的数据库需求,明白自己使用的硬件,明白这些需求在哪些环节得到了满足,以便既没有购买对现在而言配置过低的硬件,也没有购买对下一年而言配置过高的硬件。

    转载于:https://www.cnblogs.com/sql4me/archive/2009/07/09/1519740.html

    展开全文
  • 有时候我们的服务器使用MSSQL数据库,但如果MSSQL数据库占用内存过大可能导致服务器死机,这里分享下解决方法, 需要的朋友可以参考下
  • 当一个新的业务系统开发完成后,需要在一个区域乃至全国推广此应用软件,如何根据业务规模来选择服务器配置、内外置磁盘大小、以及网络带宽,是一件复杂的事情。 一个最真实的评估,是建立一个接近真实业务应用的...

    转自:http://blog.chinaunix.net/uid-5715-id-2734517.html

     

    学习如何根据业务模型来计算tpcc值,挺有帮助的。

     

    当一个新的业务系统开发完成后,需要在一个区域乃至全国推广此应用软件,如何根据业务规模来选择服务器配置、内外置磁盘大小、以及网络带宽,是一件复杂的事情。

    一个最真实的评估,是建立一个接近真实业务应用的操作环境,进行各种压力测试,测算出不同的用户数量下,系统的响应时间和吞吐量,并得出当时服务器的各种资源的利用率情况,对硬件资源的完整评估,需要考虑下列三个方面:

    •   服务器性能的评估 

    •   客户端工作站或前端桌面的评估 

    •   通讯网卡和网络带宽的评估 

    如果不能建立准确的压力测试环境,需要根据工业界的Benchmark对服务器进行评估,推算出符合业务规模的服务器配置,同时要考虑在做系统管理时所消耗的资源,如在做备份、恢复、问题诊断、性能分析时、软件维护时都会对资源带来附加的消耗,对重要资源要考虑为将来留下升级和可扩展的余地,下列是一些通用的原则:

    •   处理器:要考虑高峰时的处理器的能力,并适当保留一些缓冲,确保在业务增长时,系统有扩展的余地。如果要保持快速的响应能力,应当为CPU保留20%至40%的富余量。 

    •   内存:要为运行在此服务器的所有应用软件考虑内存,所需要的内存主要依赖于用户数、应用程序类型、进程的方式、和应用程序处理的数据量决定。 

    •   磁盘:评估业务的实际用户的数据量,以此推算出磁盘的最小个数,不要忘记选择备份设备(如磁带机)。 

    •   IO槽:尽量保留更多的IO槽,防止将来插更多的PCI卡。 

    •   网络:选择合适的网卡,保证网络不是系统的瓶颈。 

    在评估数据库服务器性能时,最困难的事情是如何把握准确度问题,到底考虑哪些因素等。理想情况下,应考虑下列要素:

    •   交易的复杂性 

    •   交易率 

    •   数据读/写比例 

    •   并发连接数目 

    •   并发交易数目 

    •   数据库最大表的大小 

    •   性能度量的目标 

        根据各种Benchmark测试结果和对各种生产系统的检测,下表概括了CPU、磁盘、内存页面、网络和虚存页交换的利用率,可看出一个服务器如果其利用率保持在Good 所标示的范围内时,是一种理想的模式。

    2、         基于rPerf的推算,评估数据库服务器的CPU

    rPerf(Relative performance)是从IBM公司解析模型得出的商务处理性能估计值。该模型模拟部分系统的操作,如中央处理器、高速缓存和内存,该模型没有模拟磁盘和网络的输入/输出操作。虽然采用了一般数据库和操作系统的参数,但该模型不能反映出具体的数据库或AIX版本。除非单独说明,否则rPerf均在系统推出时估计。IBM pSeries 640-B80为基准参照系统,其值为本。虽然rPerf可用于比较商业处理性能,但实际的系统性能可能不同,取决于许多因素,包括系统硬件配置和软件设计与配置。

    评估数据库服务器的性能,需要理解交易的类型、高峰期的情况、用户数量、在高峰时每个用户的交易数量。假如在高峰时,有三种典型的交易类型:轻的、一般的、重的。需要知道高峰时,每种交易的并发用户数目。假定高峰时间为:10:00-11:00,每个用户的交易数目如下:

    轻的交易  =120 交易/用户

    一般的交易= 60 交易/用户

    重的交易 = 15交易/用户

    2.1、每个交易所使用的CPU秒

    评估出交易类型后,需要评估出运行每个交易所消耗的CPU秒,如果假定B80服务器每秒中支持10个交易,则每个交易需要消耗0.1个CPU秒。如果不知道如何评定CPU秒,则根据应用类型参照下列表。

    2.2、评估服务器所需的rPerf值

    服务器所需要的rPerf值=SUM(NU * TX * CS/PP) / MC

    NU:高峰时并发的用户数

    TX:高峰时每个用户的交易数量

    CS:在rPerf=1的服务器上,每个交易所需要的CPU秒

    PP:高峰持续的时间

    MC:最大的CPU利用率(推荐< 70%)

    下面举例说明如何计算所需的rPerf值,假定某公司的情况如下:

    业务高峰时间:  10:00-11:00=1Hour=3600秒

    交易类型:      无复杂查询的简单应用

    相对交易类型,用户数目分布:轻的=2000,   一般=50,   重的=5

    在高峰时,每个用户的交易数量:

       轻的=120交易/用户

       一般=60交易/用户

       重的=15交易/用户

    对于rPerf=1的服务器,每个交易响应的CPU秒

       轻的=1

       一般=3

       重的=15

    最大的CPU利用率:60%

    根据上述公式,可推算出不同交易类型所对应的rPerf值。

    轻的交易:NU*TX*CS/PP=2000*120*1/3600=66.0

    一般交易:NU*TX*CS/PP=50*60*3/3600=2.5

    重的交易:NU*TX*CS/PP=5*15*15/3600=0.3

    所需的总的rPerf/MC=(66.0+2.5+0.3)/0.7=98.3 rPerf

    3、基于TPC-C的推算,评估数据库服务器的CPU

    TPC-C基准是事务处理委员会建立的一个专门演示在线事务处理性能(OLTP)的性能基准,它的测量方法是为了使客户能够评估不同的在线事务处理系统的性能,这些事务进程于一个可控制的状态下在一个标准的数据库中运行。

    TPC-C测试包括5个典型的OLTP事务,它们是:

    新订单 :一个用户提交一个新的订单

    支付  :更新用户的账户余额以反映一个支付

    交付  :订单的交付(通过一个批事务处理实现)

    订单状态:返回用户最新订单的状态

    库存水平:监控当前仓库库存

    TPC-C的事务处理是在一个9个表的数据库上实现的事务处理过程包括:更新、插入、删除、终止,以及对主和次级键的访问,每种事务处理90%的响应时间应小于或等于5秒,其中,库存水平的响应时间可以在20秒以内。

    TPC-C的吞吐量值是终端活动水平的直接结果,如每一个仓库有10个终端,在每一个终端上上述5个事务都是可用的,一个远程的终端仿真器被用来在性能测试过程中进行必要的事务混合工作。这个混合代表着一个完整的订单商务处理流程:录入、支付、检验、交付。更专业的是,这个必要的混合被定义为产生一个相等数量的新订单和支付事务,以及在每10个新订单事务中产生一个交付事务,一个订单状态检验事务和一个库存水平检验事务

    远程终端仿真器也被用来测量每一个事务的响应时间,以及用来模拟键入时间及思考时间,键入时间是指在终端上录入数据所花费的时间,思考时间是指操作人员在终端读取事务的结果,进行下一个事务请求之前所花费的时间。每一个事物都有一个最小键入时间和最小思考时间。另外,这个响应时间必须在一个给定的极限值之下。

    TPC-C基准测试的结果--TPC-C的吞吐量(tpmC),代表的是系统的最大的持续性能,它被定义为系统每分钟可以处理多少个新订单事务,与此同时,系统还在处理其他四种事务类型(支付、订单状态、交付、库存水平)。所有5个TPC-C事务都有某个限定的用户响应时间要求,其中新订单事务的响应时间是5秒以内。因此如果一个系统的TPC-C值是100tpmC/min,说明该系统在每分钟处理其他的混合的TPC-C事务的工作的同时,可以产生100个新订单事务。

    3.1、如何使用TPC-C进行服务器的评估

    由上可知,TPC-C测试基准主要用于测试主机服务器每分钟能够处理的联机交易笔数,测试产生的单位结果是TPM值(Transaction Per Minute,即每分钟处理的交易比数)。

    TPC-C虽然客观的反映了各个计算机厂商的系统处理性能,并且测试基准也在不断完善以更加贴近现实应用的交易环境,但是仍然无法与纷繁多样的各类实际应用完全吻合;而且参加TPC测试的主机系统都做了适当程度的系统优化。因此,在实际业务应用系统选择主机服务器乘载体时,必须考虑到多方面的因素,以最大程度的做到适合应用系统的生产需求。

    以下计算公式是IBM公司在金融综合业务系统的实际应用中总结的经验方法论,基本反映了金融业务特点对主机处理能力的需求:

    TPM=TASK x 80% x S x F / (T x C)

    其中:

    TASK:为每日业务统计峰值交易量

    T:为每日峰值交易时间,假设每日80%交易量集中在每天的4小时,即240分钟内完成:T=240

    S为实际银行业务交易操作相对于标准TPC-C测试基准环境交易的复杂程度比例。由于实际的金融业务交易的复杂程度与TPC‑C标准测试中的交易存在较大的差异,须设定一个合理的对应值。以普通储蓄业务交易为例,一笔交易往往需要同时打开大量数据库表,取出其相关数据进行操作,相对于TPC-C标准交易的复杂度,要复杂很多;根据科学的统计结果,每笔交易操作相比较于TPC标准测试中的每笔交易的复杂度此值可设定为10~20。

    C:为主机CPU处理余量。实际应用经验表明,一台主机服务器的CPU利用率高于80%则表明CPU的利用率过高会产生系统瓶颈,而利用率处于75%时,是处于利用率最佳状态。因此,在推算主机性能指标时,必须考虑CPU的冗余,设定C=75%

    F:为系统未来3~5年的业务量发展冗余预留。

    综上所述,为保障联机业务处理性能要求,我们可推算得出主机所需的处理能力,据此得出相应的机型和配置。

    4、举例说明,使用TPC-C进行数据库服务器评估

      下面针对XYZ行的网上银行业务的需求,我们进行数据库服务器的选型分析。

    由于目前XYZ行只有17个分行开通了网上银行业务,据我们估计,按照目前的客户数量,全部分行都开通网上银行业务后,总的客户数量可以达到10万。考虑INTERNET在我国的迅猛发展,客户数量的年增长率按照50%计算,那么,3年后的客户数量将达到10万×(1+50%)3≈34万。

      这些客户当中,至少有一半是个人客户,另一半是企业客户。企业客户的交易频率比较高,我们按平均每个企业客户每天做1.5笔交易计算;个人客户常用的交易是查询、取款、存款,并且每个月还要交电话费,因此我们假定个人客户平均每个月做4次交易;那么,每天的交易量就是:

      34万×50%×1.5+34万×50%×(4÷30) ≈28万笔

      假设网上银行的交易复杂度达到15,那么,每天的数据库操作数达到:

      28万×15=420万次

    高法诉讼费缴费:

      由于诉讼费的增长量不大,我们按年递增率5%计算。根据XYZ总行的统计,全国共37家分行,缴费量比较大的分行可以达到25000笔每月,占分行总数的20%;缴费量中等的省可达到15000笔每月,占分行总数的30%;缴费量小的省可达到7000笔每月,占分行总数的50%;按一个月20个工作日计算。这样,三年后每天的交易数量可以达到:

      (25000×20%+15000×30%+7000×50%)×37÷20×(1+5%)3≈28740笔

      我们假设高法诉讼缴费的交易复杂度达到13,那么每天的数据库操作达到:

      28740*13=373620次

    4.1、整体性能要求:

      总的数据库操作次数是:4200000+373620=4573620

      假设每天的交易的80%集中在4小时内发生,那么高峰交易时间内每分钟的数据库联机交易次数为:4573620×80%÷(4×60)≈15250

    要为将来陆续加入的应用预留40%的处理能力;另外,考虑到CPU的繁忙时间低于70%时,系统的性能较好,我们把这个比例定在65%。所以系统的TPC-C值应达到:15250÷(1-40%)÷65%≈39000


    4.2、内存容量需求分析

    首先根据数据库容量算出所需的数据库缓存大小,再估计出操作系统、系统软件等所需内存,合计即是所需的内存容量。

    网银数据量分析:

      XYZ总行网上银行系统的数据库由CIF信息,交易日志、交易流水三部分组成。

      其中:CIF信息包括企业客户和个人客户信息,企业客户信息平均大小为20K左右,个人客户信息平均大小为5K左右;每一笔交易都要记交易日志,日志的平均大小为4K左右;每一笔转帐交易都要记交易流水,交易流水的大小为2K左右。

      这些客户当中,至少有一半是个人客户,另一半是企业客户。企业客户的交易频率比较高,我们按平均每个企业客户每天做1.5笔交易计算;个人客户常用的交易是查询、取款、存款,并且每个月还要交电话费,因此我们假定个人客户平均每个月做4次交易;那么,每天的交易量就是:

      所有的交易日志和交易流水都要保留三个月。由于个人客户的转帐交易非常少,可以忽略不计;假定企业客户的转帐交易占总交易量的70%。我们就可以计算网上银行对存储系统容量的要求:

    CIF信息容量=20K×(34万×50%)+5K×(34万×50%)=3.25GB+421MB ≈ 4GB

      交易日志容量=[34万×50%×1.5+34万×50%×(4÷30)] ×4K×30×3  =277667×4K×30×3  ≈95GB

      交易流水容量=(34万×50%×1.5)×70%×2K×30×3  ≈30GB

    XYZ网上银行总体数据容量要求:=4GB+95GB+30GB=129GB

    高法诉讼费数据量分析:

      高法的交易数据按要求要保留三年,每笔交易记录的大小为512字节,总体容量为:(25000×20%+15000×30%+7000×50%)×37×12×3×0.5K≈8.2GB

    因此,数据库的总数据量为: 129GB+8.2GB=137.2GB

      数据库系统在缓存容量达到数据库总容量的5%时性能较好,因此,数据库缓存大小为:6.86GB。

    从而计算出系统内存需求为:

     

    1.AIX操作系统所占的内存 128MB 
    2.数据库管理系统所占的内存   256MB
    3.双机热备等系统软件所占的内存  128MB
    4.应用程序所占的内存 256MB
    5.数据库缓存 6.86GB
    6.合理的内存利用率 75%
     总计 10GB
       

     

    4.3、  存储容量需求分析

      除了上述的XYZ网上银行系统和高法诉讼费缴费系统的存储容量要求之外,还有异步查询下载服务的存储要求。

      异步查询下载服务每隔1小时生成一个下载数据包,每个数据包的大小为3MB,需要下载的数据包是上午十点生成的数据包,这个数据包需要保存2年,其它数据包只要保存3个月。因此,存储容量为:

      23×3M×30×3+1×3M×365*2=6GB+2GB=8GB

      为避免存储系统成为系统性能的瓶颈,系统存储系统的使用率应小于40%,建议采用镜像方式存储数据,因此总的存储容量为:

      (137.2GB+8GB)÷40% ×2= 766GB

    转载于:https://www.cnblogs.com/kuang17/p/9438918.html

    展开全文
  • 常用内存数据库介绍

    万次阅读 2018-07-09 23:18:55
    1. 内存数据库简介 1.1 概念 一、什么是内存数据库 传统的数据库管理系统把所有数据都放在磁盘上进行管理,所以称做磁盘数据库(DRDB:Disk-Resident Database)。磁盘数据库需要频繁地访问磁盘来进行数据的操作,...

    1. 内存数据库简介

    1.1 概念

    一、什么是内存数据库

    传统的数据库管理系统把所有数据都放在磁盘上进行管理,所以称做磁盘数据库(DRDB:Disk-Resident Database)。磁盘数据库需要频繁地访问磁盘来进行数据的操作,由于对磁盘读写数据的操作一方面要进行磁头的机械移动,另一方面受到系统调用(通常通过CPU中断完成,受到CPU时钟周期的制约)时间的影响,当数据量很大,操作频繁且复杂时,就会暴露出很多问题。

    近年来,内存容量不断提高,价格不断下跌,操作系统已经可以支持更大的地址空间(计算机进入了64位时代),同时对数据库系统实时响应能力要求日益提高,充分利用内存技术提升数据库性能成为一个热点。

    在数据库技术中,目前主要有两种方法来使用大量的内存。一种是在传统的数据库中,增大缓冲池,将一个事务所涉及的数据都放在缓冲池中,组织成相应的数据结构来进行查询和更新处理,也就是常说的共享内存技术,这种方法优化的主要目标是最小化磁盘访问。另一种就是内存数据库(MMDB:Main Memory Database,也叫主存数据库)技术,就是干脆重新设计一种数据库管理系统,对查询处理、并发控制与恢复的算法和数据结构进行重新设计,以更有效地使用CPU周期和内存,这种技术近乎把整个数据库放进内存中,因而会产生一些根本性的变化。两种技术的区别如下表:

    内存数据库系统带来的优越性能不仅仅在于对内存读写比对磁盘读写快上,更重要的是,从根本上抛弃了磁盘数据管理的许多传统方式,基于全部数据都在内存中管理进行了新的体系结构的设计,并且在数据缓存、快速算法、并行操作方面也进行了相应的改进,从而使数据处理速度一般比传统数据库的数据处理速度快很多,一般都在10倍以上,理想情况甚至可以达到1000倍。

      而使用共享内存技术的实时系统和使用内存数据库相比有很多不足,由于优化的目标仍然集中在最小化磁盘访问上,很难满足完整的数据库管理的要求,设计的非标准化和软件的专用性造成可伸缩性、可用性和系统的效率都非常低,对于快速部署和简化维护都是不利的。

    2. 内存数据库历史和发展

    一、雏形期
    从上个世纪60年代末到80年代初。在这个时期中,出现了主存数据库的雏形。1969年IBM公司研制了世界上最早的数据库管理系统——基于层次模型的数据库管理系统IMS,并作为商品化软件投入市场。在设计IMS时,IBM考虑到基于内存的数据管理方法,相应推出了IMS/VS Fast Path。Fast Path是一个支持内存驻留数据的商业化数据库,但它同时也可以很好地支持磁盘驻留数据。在这个产品中体现了主存数据库的主要设计思想,也就是将需要频繁访问,要求高响应速度的数据直接存放在物理内存中访问和管理。在这个阶段中,包括网状数据库、关系数据库等其他各种数据库技术也都逐渐成型。
    二、技术理论成熟期
    1984年,D J DeWitt等人发表了《主存数据库系统的实现技术》一文。第一次提出了Main Memory Database(主存数据库)的概念。预言当时异常昂贵的计算机主存价格一定会下降,用户有可能将大容量的数据库全部保存在主存中,提出了AVL树、哈希算法、主存数据库恢复机制等主存数据库技术的关键理论,为主存数据库的发展指出了明确的方向 。
    1984年,D J DeWitt等人提出使用非易逝内存或预提交和成组提交技术作为主存数据库的提交处理方案,使用指针实现主存数据库的存取访问。
    1985年,IBM推出了IBM 370上运行的OBE主存数据库
    1986年,RB Hagman提出了使用检查点技术实现主存数据库的恢复机制。威斯康星大学提出了按区双向锁定模式解决主存数据库中的并发控制问题。并设计出MM-DBMS主存数据库。贝尔实验室推出了DALI主存数据库模型。
    1987年,ACM SIGMOD会议中提出了以堆文件(HEAP FILE)作为主存数据库的数据存储结构。Southern Methodist大学设计出MARS主存数据库模型。
    1988年普林斯顿大学设计出TPK主存数据库。
    1990年普林斯顿大学又设计出System M主存数据库。
    三、产品发展期和市场成长期
    随着互联网的发展,越来越多的网络应用系统需要能够支持大用户量并发访问、高响应速度的的数据库系统,主存数据库市场成熟
    半导体技术快速发展,半导体内存大规模生产,动态随机存取存储器(DRAM)的容量越来越大,而价格越来越低,这无疑为计算机内存的不断扩大提供了硬件基础,使得主存数据库的技术可行性逐步成熟
    1994年美国OSE公司推出了第一个商业化的,开始实际应用的主存数据库产品Polyhedra
    1998年德国SoftwareAG推出了Tamino Database。
    1999年日本UBIT会社开发出XDB主存数据库产品。韩国Altibase推出Altibase
    2000年奥地利的QuiLogic公司推出了SQL-IMDB
    2001年美国McObject推出eXtremeDB。加拿大Empress公司推出EmpressDB


    四、几种主存技术应用的比较
    第一代:用户定制的主存数据库。通过应用程序来管理内存和数据;不支持SQL语句, 不提供本地存储, 没有数据库恢复技术;性能好但很难维护和在别的应用中不能使用;应用在实时领域比如工厂自动化生产。
    第二代:简单功能的内存数据库。能够快速处理简单的查询;支持部分的 SQL语句和简单的恢复技术;主要目的是能够快速处理大量事务;针对简单事务处理领域,尤其是交换机, 移动通信等。
    第三代:通用的主存数据库。针对传统的商业关系型数据库领域,能够提供更高的性能、通用性以及稳定性;提供不同的接口来处理复杂的SQL语句和满足不同的应用领域;可以应用在计费、电子商务、在线安全领域,几乎包括磁盘数据库的所有应用领域。
    五、目前几种常见的通用内存数据库
    eXtremeDB:eXtremeDB实时数据库是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库,只有50K到130K的开销,速度达到微秒级。eXtremeDB完全驻留在主内存中,不使用文件系统(包括内存盘)。eXtremeDB采用了新的磁盘融合技术,将内存拓展到磁盘,将磁盘当做虚拟内存来用,实时性能保持微秒级的同时,数据管理量在32BIT下能达到20G。
    Oracle TimesTen:Oracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库,它为应用程序提供了实时企业和行业(例如电信、资本市场和国防)所需的即时响应性和非常高的吞吐量。Oracle TimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中,它利用标准的 SQL 接口对完全位于物理内存中的数据存储区进行操作。
    SolidDB:Solid Information Technology 成立于 1992 年,全球总部位于加州Cupertino,
    Solid数据管理平台将基于内存和磁盘的全事务处理数据库引擎、载体级高可用性及强大的数据复制功能紧密地融为一体。

    ALTIBASE公司从1999年就一直致力于内存数据库软件和其应用的开发,提供高性能和高可用性的软件解决方案。特别适合通信、网上银行、证券交易、实时应用和嵌入式系统领域。目前占据80%以上内存数据库市场,可以说是当今数据库软件技术的领导者。目前Altibase在国内成功案例也比较多,尤其是在电信行业,已经得到了广泛认可.

    4. 常用内存数据库

    4.1 SQLite

    SQLite是一个小型的C程序库,实现了独立的,可嵌入的,零配置的SQL数据库引擎。特性包括:

    • 事务操作是原子,一致,孤立,并且持久的(ACID),即使在系统崩溃和电源故障之后。
    • 零配置——不需要安装和管理。
    • 实现了绝大多数SQL92标准。
    • 整个数据库存储在一个单一的文件中。
    • 数据库文件可以在不同字节序的机器之间自由地共享。
    • 支持最大可达2T的数据库。 (241 字节)
    • 字符串和BLOB类型的大小最大可达 2G 字节(231字节)。
    • 小的代码: 完整配置的少于250KB,忽略一些可选特性的少于150KB。
    • 在大多数常见操作上比流行的客户/服务器数据库引擎更快
    • 简单,易于使用的API
    • 内建TCL绑定 另外提供可用于许多其他语言的绑定。
    • 具有良好注释的源代码,95%经过测试。
    • 独立:没有外部依赖。
    • 源代码位于公共域。 可用于任何用途。

    SQLite发行版包含一个独立的命令行访问程序(sqlite),可用于管理SQLite数据库,并适合作为一个如何使用SQLite库的例子。

    License: SQLite使用Public domain授权(注),对于个人使用和商业使用都是免费的。

    技术上的优点和特性
    SQLite是一个轻量级、跨平台的关系型数据库。


    ◇轻量级

    先说它的第一个特色:轻量级。想必SQLite的作者很看重这个特性,连它的Logo都是用的“羽毛”,来显摆它的轻飘飘。SQLite和C/S模式的数据库软件不同,它是进程内的数据库引擎,因此不存在数据库的客户端和服务器。使用SQLite一般只需要带上它的一个动态库,就可以享受它的全部功能。而且那个动态库的尺寸也挺小,以版本3.6.11为例,Windows下487KB、Linux下347KB。

    ◇ 绿色软件

    SQLite的另外一个特点是绿色:它的核心引擎本身不依赖第三方的软件,使用它也不需要“安装”。所以在部署的时候能够省去不少麻烦。

    ◇单一文件

    所谓的“单一文件”,就是数据库中所有的信息(比如表、视图、触发器、等)都包含在一个文件内。这个文件可以copy到其它目录或其它机器上,也照用不误。

    ★技术上的缺点和不足

    ◇并发访问的锁机制
    SQLite在并发(包括多进程和多线程)读写方面的性能一直不太理想。数据库可能会被写操作独占,从而导致其它读写操作阻塞或出错。

    SQL标准支持不全
    在它的官方网站上,具体列举了不支持哪些SQL92标准。我个人感觉比较不爽的是不支持外键约束。

    ◇网络文件系统(以下简称NFS)
    有时候需要访问其它机器上的SQLite数据库文件,就会把数据库文件放置到网络共享目录上。这时候你就要小心了。当SQLite文件放置于NFS时,在并发读写的情况下可能会出问题(比如数据损坏)。原因据说是由于某些NFS的文件锁实现上有Bug。

    ★编程语言接口
    SQLite支持很多种语言的编程接口。这对于我这种喜欢混用多种编程语言的人来说,是很爽的。下面我大概介绍一下。

    ◇C/C++
    由于SQLite本身是C写的,它自带的API也是C接口的。所以C/C++用起来最直接了。假如你不喜欢面向过程的C API风格,可以另外找个C++的包装库。想重新发明轮子的同学,也可以自己包装一个。
    ◇Java
    如果要用Java访问SQLite,可以通过SQLite的JDBC驱动,或者通过专门的SQLite包装库。我个人建议走JDBC方式,万一将来要换数据库,代码就不用大改。
    ◇Python
    pysqlite是Python操作SQLite的首选。从Python 2.5开始,它已经被整合到Python的标准库中。看来Python社区还是蛮喜欢SQLite嘛。
    ◇.Net
    对于喜欢.Net的同学,可以通过SQLite的ADO.NET驱动来访问。
    ◇Ruby
    Ruby可以通过SQLite-Ruby操作SQLite数据库,不过我没用过。
    ◇Perl
    在CPAN上有DBD::SQLite,不过我也没用过。

    ★一些非技术的参考因素

    需要根据“如何选择开源项目”里面提到的几个参考因素,再评估一下。
    ◇授权协议(License)
    SQLite使用的是Public Domain协议,这是最爽一种,可以放心大胆地用。
    ◇用户的普及程度
    最近这几年,使用SQLite的人越来越多。包括一些大公司也开始把它整合到产品中(比如Google的Gears、Apple的Safari、Adobe的AIR)。
    ◇开发的活跃程度
    如果到SQLite的Change Log上大致了解一下,可以看出最近5年基本上每1-2个月都会有更新。说明开发的活跃度还是非常高的。

    SQLite不同于其他大部分的SQL数据库引擎,因为它的首要设计目标就是简单化:

    • 易于管理
    • 易于使用
    • 易于嵌入其他大型程序
    • 易于维护和配置

    许多人喜欢SQLite因为它的小巧和快速. 但是这些特性只是它的部分优点, 使用者还会发现SQLite是非常稳定的. 出色的稳定性源于它的简单, 越简单就越不容易出错. 除了上述的简单、小巧和稳定性外, 最重要的在于SQLite力争做到简单化.

    简单化在一个数据库引擎中可以说是一个优点, 但也可能是个缺点, 主要决定于你想要做什么. 为了达到简单化, SQLite省略了一些人们认为比较有用的特性, 例如高并发性、 严格的存取控制、丰富的内置功能、 存储过程、复杂的SQL语言特性、 XML以及Java的扩展, 超大的万亿级别的数据测量等等. 如果你需要使用上述的这些特性并且不介意它们的复杂性, 那么SQLite也许就不适合你了. SQLite没有打算作为一个企业级的数据库引擎, 也并不打算和Oracle或者PostgreSQL竞争.

    仅凭经验来说SQLite适用于以下场合: 当你更看中简单的管理、使用和维护数据库, 而不是那些企业级数据库提供的不计其数的复杂功能的时候,使用SQLite是一个比较明智的选择. 事实也证明, 人们在许多情况下已经清楚的认识到简单就是最好的选择.

    4.1.1 SQLite最佳试用场合

    · 网站

    作为数据库引擎SQLite适用于中小规模流量的网站(也就是说, 99.9%的网站). SQLite可以处理多少网站流量在于网站的数据库有多大的压力. 通常来说, 如果一个网站的点击率少于100000次/天的话, SQLite是可以正常运行的. 100000次/天是一个保守的估计, 不是一个准确的上限. 事实证明, 即使是10倍的上述流量的情况下SQLite依然可以正常运行.

    · 嵌入式设备和应用软件

    因为SQLite数据库几乎不需要管理, 因此对于那些无人值守运行或无人工技术支持的设备或服务, SQLite是一个很好的选择. SQLite能很好的适用于手机, PDA, 机顶盒, 以及其他仪器. 作为一个嵌入式数据库它也能够很好的应用于客户端程序.

    · 应用程序文件格式

    SQLite作为桌面应用程序的本地磁盘文件格式取得了巨大成功.例如金融分析工具、CAD 包、档案管理程序等等. 一般的数据库打开操作需要调用sqlite3_open()函数,并且标记一个显式本地事务的起始点(BEGIN TRANSACTION)来保证以独占的方式得到文件的内容. 文件保存将执行一个提交(COMMIT)同时标记另一个显式本地事务起始点. 这种事务处理的作用就是保证对于应用程序数据文件的更新是原子的、持久的、独立的和一致的.

    数据库里可以加入一些临时的触发器,用来把所有的改变记录在一张临时的取消/重做日志表中. 当用户按下取消/重做按钮的时候这些改变将可以被回滚. 应用这项技术实现一个无限级的取消/重做功能只需要编写很少的代码.

    · 替代某些特别的文件格式

    许多程序使用fopen(), fread(), 或 fwrite()函数创建和管理一些自定义的文件用来保存数据. 使用SQLite替代这些自定义的文件格式将是一种很好的选择.

    · 内部的或临时的数据库

    对于那些有大量的数据需要用不同的方式筛选分类的程序, 相对于编写同样功能的代码, 如果你把数据读入一个内存中的SQLite数据库, 然后使用连接查询和ORDER BY子句按一定的顺序和排列提取需要的数据, 通常会更简单和快速. 按照上述的方法使用内嵌的SQLite数据库将会使程序更富有灵活性, 因为添加新的列或索引不用重写任何查询语句.

    · 命令行数据集分析工具

    有经验的SQL用户可以使用SQLite命令行程序去分析各种混杂的数据集. 原是数据可以从CSV(逗号分隔值文件)文件中导入, 然后被切分产生无数的综合数据报告. 可能得用法包括网站日志分析, 运动统计分析, 编辑规划标准, 分析试验结果.

    当然你也可以用企业级的客户端/服务器数据库来做同样的事情. 在这种情况下使用SQLite的好处是: SQLite的部署更为简单并且结果数据库是一个单独的文件, 你可以把它存储在软盘或者优盘或者直接通过email发给同事.

    · 在Demo或测试版的时候作为企业级数据库的替代品

    如果你正在编写一个使用企业级数据库引擎的客户端程序, 使用一个允许你连接不同SQL数据库引擎的通用型数据库后台将是很有意义的. 其更大的意义在于将SQLite数据库引擎静态的连接到客户端程序当中,从而内嵌SQLite作为混合的数据库支持. 这样客户端程序就可以使用SQLite数据库文件做独立的测试或者验证.

    · 数据库教学

    因为SQLite的安装和使用非常的简单(安装过程几乎忽略不计, 只需要拷贝SQLite源代码或sqlite.exe可执行文件到目标主机, 然后直接运行就可以) 所以它非常适合用来讲解SQL语句. 同学们可以非常简单的创建他们喜欢的数据库, 然后通过电子邮件发给老师批注或打分. 对于那些感兴趣怎样实现一个关系型数据库管理系统(RDBMS)的高层次的学生, 按照模块化设计且拥有很好的注释和文档的SQLite源代码, 将为他们打下良好的基础. 这并不是说SQLite就是如何实现其他数据库引擎的精确模型, 但是很适合学生们了解SQLite是如何快速工作的, 从而掌握其他数据库系统的设计实现原则.

    · 试验SQL语言的扩展

    SQLite简单且模块化的设计使得它可以成为一个用来测试数据库语言特性或新想法的优秀的原型平台

    4.1.2 哪些场合适合使用其他的关系型数据库管理系统(RDBMS)

    · 客户端/服务器程序

    如果你有许多的客户端程序要通过网络访问一个共享的数据库, 你应当考虑用一个客户端/服务器数据库来替代SQLite. SQLite可以通过网络文件系统工作, 但是因为和大多数网络文件系统都存在延时, 因此执行效率不会很高. 此外大多数网络文件系统在实现文件逻辑锁的方面都存在着bug(包括Unix 和windows). 如果文件锁没有正常的工作, 就可能出现在同一时间两个或更多的客户端程序更改同一个数据库的同一部分, 从而导致数据库出错. 因为这些问题是文件系统执行的时候本质上存在的bug, 因此SQLite没有办法避免它们.

    好的经验告诉我们, 应该避免在许多计算机需要通过一个网络文件系统同时访问同一个数据库的情况下使用SQLite.

    · 高流量网站

    SQLite通常情况下用作一个网站的后台数据库可以很好的工作. 但是如果你的网站的访问量大到你开始考虑采取分布式的数据库部署, 那么你应当毫不犹豫的考虑用一个企业级的客户端/服务器数据库来替代SQLite.

    · 超大的数据集

    当你在SQLite中开始一个事务处理的时候(事务处理会在任何写操作发生之前产生, 而不是必须要显示的调用BEGIN…COMMIT), 数据库引擎将不得不分配一小块脏页(文件缓冲页面)来帮助它自己管理回滚操作. 每1MB的数据库文件SQLite需要256字节. 对于小型的数据库这些空间不算什么, 但是当数据库增长到数十亿字节的时候, 缓冲页面的尺寸就会相当的大了. 如果你需要存储或修改几十GB的数据, 你应该考虑用其他的数据库引擎.

    · 高并发访问

    SQLite对于整个数据库文件进行读取/写入锁定. 这意味着如果任何进程读取了数据库中的某一部分, 其他所有进程都不能再对该数据库的任何部分进行写入操作. 同样的, 如果任何一个进程在对数据库进行写入操作, 其他所有进程都不能再读取该数据库的任何部分. 对于大多数情况这不算是什么问题. 在这些情况下每个程序使用数据库的时间都很短暂, 并且不会独占, 这样锁定至多会存在十几毫秒. 但是如果有些程序需要高并发, 那么这些程序就需要寻找其他的解决方案了.

    方面

    具体要求

    必要条件

    详细描述

    License

    是否收费

    免费使用

    是否开源

    开源

    是否有技术支持

    主要是社区支持,如果需要专业支持需要购买

    商业目的的分发版本是否仍要收费

    免费

    其他

    性能

    数据容量支持100000条以上记录

    支持

    并发查询处理能力

    SQLite在并发(包括多进程和多线程)读写方面的性能一直不太理想。数据库可能会被写操作独占,从而导致其它读写操作阻塞或出错。

    查询速度

    修改速度

    平台支持

    32/64位

    全部支持

    Linux/window/UNIX/mobile

    支持Linux/Mac OS/Windows

    运行方式支持

    支持嵌入式

    支持

    支持独立运行

    不支持

    连接方式支持

    支持ODBC

    默认不支持,必须通过第三方的ODBC驱动

    支持JDBC

    默认不支持,必须通过第三方的JDBC驱动

    支持内存访问

    通过c接口(专用API)

    支持网络访问

    不支持

    SQL支持

    支持SQL

    支持

    支持Index,Trigger,

    Constrains,Views

    支持,有资料说其不支持外键约束。

    管理界面

    支持管理界面

    支持CLI

    管理界面友好程度

    较差

    4.2 Altibase

    Altibase™内存数据库管理系统(DBMS),内存数据管理系统的最新技术,是一个在事务优先的环境中提供高性能和高可用性的软件解决方案。Altibase提供极限性能、容错能力和事务管理的方便性,特别是在通信、网上银行、证券交易、实时应用和嵌入式系统领域。Altibase能够最大限度的发挥数据库服务系统的潜力,使用Altibase能大大增强您公司的数据服务器的处理能力。

    Altibase™内存DBMS为需要容错服务的系统提供实时数据库复制的功能。采用Altibase数据库复制的系统可以实现高性能、高可用性、数据库一致性、负载平衡和系统可伸缩性。如果您希望您的业务能够实现最大的成功,请在您的事务优先的系统中使用我们的Altibase数据库复制解决方案。

    资料比较少,且需要商业License,没有详细去研究

    4.3 Oracle 内存数据库系列 Berkeley DB 和 TimesTen

    Oracle是最重要的商业数据库产品提供商,它也有内存数据库的产品系列:主要就是Oracle Berkeley DB 和 Times Ten.前者是只支持嵌入式内存数据,后者是独立的内存优化数据库。

    4.3.1 Oracle Berkeley DB

    Oracle Berkeley DB是Oracle 收购了开源数据库厂商后推出的产品,其前身是Berkeley DB。它有开源版本,但且对于开源软件免费。商业版本是要付费。

    Oracle Berkeley DB 系列的可嵌入开源数据库为开发人员提供了无需管理的快速、可靠的本地持久性。Oracle Berkeley DB 系列通常部署为“前沿”数据库,为不需要 SQL 的应用程序用例提供很高的性能、可靠性、可伸缩性以及可用性。

    Oracle Berkeley DB 产品系列

    Berkeley DB — 事务处理式存储引擎,用于基本键/值数据结构中的非类型化数据 — 新增!版本 4.7 现已推出

    — 针对 Java 环境优化的纯 Java 版 Berkeley DB — 新增!版本 3.3

    Berkeley DB XML — 原生 XML 数据库,可基于 XQuery 访问容器中存储的文档,并根据其内容进行索引 — 新增!版本 2.4 现已推出

    4.3.2 Oracle TimesTen

    Oracle 内存数据库 TimesTen 是一个针对内存进行了优化的关系数据库,它为应用程序提供了当今实时企业和行业(如电信、资本市场和国防)所需的即时响应性和非常高的吞吐量。Oracle 内存数据库 TimesTen 作为独立或嵌入式数据库部署在应用层中,利用标准的 SQL 接口对完全位于物理内存中的数据库进行操作。它也可以用作 Oracle 数据库的内存中数据库缓存,以改进用户应用程序的响应时间和吞吐量。

    4.4 eXtremeDB

    eXtremeDB内存式实时数据库是为实时系统及嵌入式系统而特别设计的数据库。与同类产品不同,eXtremeDB不是通过 对企业数据库面向实时嵌入式应用进行剪裁而来;而是总结了30年来McObject公司在编译器、实时编程、数据管理、内核级驱 动软件等领域的经验,面向实时嵌入式应用从头开发的最新实时数据管理技术。

    eXtremeDB满足了您对实时数据库的一切期待:高级数据定义语言、并行访问、基于交易及灵活的索引… …等等。不仅如此,出乎您的意外,eXtremeDB在紧凑的引擎中还提供诸如事件触发、目标历史等等功能。

    eXtremeDB嵌入式数据库满足更多的实时开发的要求。

    · 最快的内存数据库。

    · 极小尺寸和极小的内存消耗

    · 多种索引支持

    · 高可用性-组合选项

    · 非常灵活的数据存储: 内存式,磁盘式或混合式

    · 多种应用接口: 两种 SQL, 两种更快的原始接口

    · 几乎牢不可破 -

    又一个商业内存数据库产品,这个特点是实时数据库,号称最快。

    4.5 H2 Database

    h2是Thomas Mueller提供的一个开源的、纯java实现的关系数据库,官方网站:http://www.h2database.com/html/main.html

    它的主要特性是:

    • 非常速的数据库引擎
    • 开源、免费数据库
    • 支持 JDBC和ODBC API,支持SQL
    • 支持嵌入式,服务器和集群模式。支持内存数据库。
    • 提供基于浏览器的管理控制台
    • 整个应用本身只有1MB左右。

    其他特性还包括

    • 基于磁盘或内存的数据库、表,支持只读数据库、临时表。
    • 两段式事务支持
    • 支持多个连接。表级别的锁。
    • 基于成本的优化,为复杂查询使用遗传算法,零管理。
    • 滚动的、可修改的result set支持。支持大结果集、外部结果排序。
    • 加密数据库(AES或XTEA),SHA-256密码加密。

    性能比较(摘自h2database网站)

    嵌入模式下H2的性能比较

    Test Case

    Unit

    H2

    HSQLDB

    Derby

    Simple: Init

    ms

    610

    657

    3187

    Simple: Query (random)

    ms

    297

    312

    1828

    Simple: Query (sequential)

    ms

    203

    266

    1766

    Simple: Update (random)

    ms

    1078

    1484

    22031

    Simple: Delete (sequential)

    ms

    234

    281

    7407

    Simple: Memory Usage

    MB

    6

    7

    11

    BenchA: Init

    ms

    859

    438

    4047

    BenchA: Transactions

    ms

    5266

    2875

    17500

    BenchA: Memory Usage

    MB

    9

    14

    10

    BenchB: Init

    ms

    4016

    2687

    16875

    BenchB: Transactions

    ms

    2609

    3282

    4250

    BenchB: Memory Usage

    MB

    9

    10

    8

    BenchC: Init

    ms

    891

    594

    5766

    BenchC: Transactions

    ms

    4359

    75438

    11718

    BenchC: Memory Usage

    MB

    9

    18

    9

    Executed statements

    #

    594255

    594255

    594255

    Total time

    ms

    20422

    88314

    96375

    Statements per second

    #

    29098

    6728

    6166

    .Net使用H2
    • 嵌入式应用。有一个项目在为.Net使用H2,使用CLI重新编译H2。还没有深入关注。
    • ODBC。但性能一般。

    4.5 其他内存数据库

    包括Derby, HSQLDB等.

    ——————————————————————————————————————————————————————-

    In-memory database in wikipedia: (http://en.wikipedia.org/wiki/In-memory_database)

    Products

    Product nameLicenseDescription
    Adaptive Server Enterprise (ASE) 15.5Proprietaryenterprise database from Sybase)[4]
    Apache DerbyApache License 2.0Java RDBMS
    AltibaseProprietaryhas in-memory and disk table; HYBRID DBMS
    BlackRayGNU General Public Licence (GPLv2) and BSD License
    CSQLGNU General Public Licence or proprietary
    DatablitzProprietaryDBMS
    EloqueraProprietaryIn-memory, In-memory:persist modes
    eXtremeDBcommercial productDBMS, also check out its open source PERST dbms.
    FleetDBMITNOSQL db with Writing to an append-only log to provide durability.
    H2Mozilla Public License or Eclipse Public Licensehas a memory-only mode
    HSQLDBBSD licensehas a memory-only mode
    IBM TM1Proprietaryin-memory BI and data analysis
    InfoZoomProprietaryin-memory BI and data analysis
    KDBProprietaryDBMS, also supports disk based data
    membaseApache LicenseNoSQL, hybrid
    MicroStrategy in-memory BI for MicroStrategy 9
    MonetDBMonetDB License
    MySQLGNU General Public License or proprietaryhas a cluster server which uses a main-memory storage engine
    Oracle Berkeley DBSleepycat Licensecan be configured to run in memory only
    Panorama for Windows and Macintosh, both single user and server versions
    ParAccelProprietaryin-memory, columnar, relational, ACID-compliant; disk-based mode as well
    Polyhedra IMDBProprietaryrelational, supports High-Availability; acquired in 2001 by ENEA
    QlikView BI-tool developed by QlikTech
    RDM EmbeddedProprietaryincluding hybrid
    RDM ServerProprietaryincluding hybrid
    RedisBSDNoSQL
    solidDB by IBM including hybrid, HSB-based HA, Shared memory, embedded, XA, etc.
    SAP HANA databaseProprietaryDatabase engine of the SAP In-Memory Appliance (SAP HANA) produced by SAP AG
    SQLitePublic domainhybrid, RAM and disk dbs can be used together
    Starcounter in-memory object relational dbms
    TimesTen by Oracle in memory only or as a cache for Oracle Database
    VertipaqProprietaryMicrosoft PowerPivot and Microsoft Analysis Services in-memory BI engine
    VoltDBGNU General Public License v3in-memory
    TREX search engine in the SAP NetWeaver integrated technology platform produced by SAP AG
    Xcelerix by Frontex commercial product

    展开全文
  • 服务器中,数据库是必不可少的部分,作为数据存取中心,有时候的系统的操作涉及到数据的快速读写,在这种情况下,我们通常不会中规中矩地直接读写像MySQL的持久性数据库的数据,因为像MySQL这一类关系型的数据库...
  • 数据库服务器的安装与配置

    万次阅读 多人点赞 2017-04-18 13:02:25
    数据库服务器主要用于存储、查询、检索企业内部的信息,因此需要搭配专用的数据库系统,对服务器的兼容性、可靠性和稳定性等方面都有很高的要求。   1、基本概念 数据库服务器其实就是装有一台数据库的Server,...
  • 内存数据库从范型上可以分为关系型内存数据库和键值型内存数据库。在实际应用中内存数据库主要是配合oracle或mysql等大型关系数据库使用,关注性能,作用类似于缓存,并不注重数据完整性和数据一致性。基于键值型的...
  • 数据库服务器对硬件配置的五个要求 2013年07月04日 09点02分 来源:河南亿恩 有0人参与 着运营时间的增加,那些以数据库为主要支撑的应用例如ERP系统、论坛系统,在具备一定规模之后,对服务器硬件的设备...
  • 【1】使用H2这类内存数据库进行单元测试。 【2】使用MySQL数据库,测试后回滚。 两种方案各有利弊,个人倾向于前者。 网上有很多示例,都是很多案例没有给出可运行的项目源码,搭建过程中会遇到很多坑,本文文末...
  • H2内存数据库

    千次阅读 2017-05-21 18:10:02
    之前项目中用到了H2内存数据库,做下整理: H2数据库介绍 常用的开源数据库:H2,Derby,HSQLDB,MySQL,PostgreSQL。其中H2,HSQLDB类似,十分适合作为嵌入式数据库使用,其它的数据库大部分都需要安装独立的...
  • nosql数据库与内存数据库

    千次阅读 2015-09-29 11:27:45
    1. nosql NoSQL = Not Only SQL,泛指非关系型的数据库。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题。NoSQL数据库没有标准的查询语言...3、对数据库性能要求较高; 4
  • 主流内存数据库对比

    万次阅读 2016-10-09 19:58:15
    原文地址:http://blog.csdn.net/nanfeiyannan/article/details/9003009   名称 开源或商业 主要特点 ...1. 符合RDBMS标准的独立内存数据库服务。 2.支持S
  • Redis内存数据库的简介

    千次阅读 2019-08-21 09:22:12
    redis是一个开源的底层第用ANSI C语言编写的key-value型存储数据库,可用于缓存,事件发布订阅,高速队列等场景 redis支持数据类型 redis支持丰富的数据类型,包括string(字符串)、list(链表)、set(集合)、zset(sorted.....
  • 内存数据库与磁盘数据库

    千次阅读 2018-09-02 10:26:34
    1、磁盘数据库需要频繁地访问磁盘来进行数据的操作,由于对磁盘读写数据的操作一方面要进行磁头的机械移动,另一方面受到系统调用(通常通过CPU中断完成,受到CPU时钟周期的制约)... 内存数据库数据处理速度比传统...
  • 内存数据库技术选型

    千次阅读 2017-08-27 12:37:24
    最近一段时间研究了内存数据库,总结了一下,分享给大家。我们先从应用场景说起。 一. 内存数据库的应用场景 数据缓存:将经常使用的数据存放在内存中,全局共享,减少和数据库之间的交互频率,提升数据访问速度...
  • 应用服务器和数据库服务器有什么区别

    万次阅读 多人点赞 2018-07-03 10:11:21
    数据库服务器一般都装有数据库如oracle,mssql,mysql等,如:oracle的linux服务器, 应用服务器是你的应用得服务器,提供应用服务,如你的j2ee中间件:基于jboss,weblogic等的应用,也可以是自己的网络应用服务器...
  • SAP HANA 高性能内存数据库

    千次阅读 2019-10-27 10:31:20
    最近,用到了SAP HANA内存数据库,听过这套集群搭建公司已花费超过2亿RMB。今天对于这款德国SAP制造的内存数据库做一个简单的介绍和总结。 虽然在处理大数据方面性能很赞,但是花费太高,不是一般小公司能够承担起...
  • 内存数据库、关系型数据库和非关系型数据库 一、内存数据库、关系型数据库和非关系型数据库 1.个人观点: 二、内存数据库(Redis,MongoDb,SQLite,Oracle等): 三、Raft分布式协议: 四、Redis出现宕机,...
  • 内存数据库-H2简介与实践

    万次阅读 2017-09-17 23:40:06
    一、H2数据库介绍  H2是一个开源的嵌入式(非嵌入式设备)数据库引擎,它是一个用Java开发的类库,可直接嵌入到应用程序中,与应用程序一起打包...这是典型Client/Server模式,因此同时需要服务器 三、H2数据库实践
  • ...内存数据库就是将数据放在内存中直接操作的数据库,它利用内存的读写速度比磁盘快、内存是随机访问而磁盘是顺序访问这两个特点,将数据保存在内存中,在内存中模仿建立表结构和索引结构并
  • 常用内存数据库

    千次阅读 2014-12-04 06:10:58
    如果你有许多的客户端程序要通过网络访问一个共享的数据库, 你应当考虑用一个客户端/服务器数据库来替代SQLite. SQLite可以通过网络文件系统工作, 但是因为和大多数网络文件系统都存在延时, 因此执行效率不会很高...
  • 2G内存的MYSQL 数据库服务器优化.
  • 搭建Oracle数据库服务器

    万次阅读 2018-01-10 11:56:14
    Oracle数据库经过这么多年的产品积累发布,从最开始的二代版本到现在的oracle 12c,产品功能越发强大,数据库管理员需要学习和了解的知识点也逐步增加学习。俗话说得好:“工欲善其事必先利其器”,学习Oracle数据库...
  • 内存数据库从范型上可以分为关系型内存数据库和键值型内存数据库。 在实际应用中内存数据库主要是配合oracle或mysql等大型关系数据库使用,关注性能。 作用类似于缓存,并不注重数据完整性和数据一致性。 基于...
  • 初次接触嵌入式数据库(Embedded Database)可能对这个概念总不是很清楚,它究竟与数据库服务器(Database Server)有什么区别,它们又分别适用于那些应用场景呢,这是需要解决的问题。 在谈区别之前,先来个感性...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 558,129
精华内容 223,251
关键字:

内存数据库服务器要求