开源内存数据库的调研与分析
开源内存数据库的调研与分析
开源内存数据库的调研与分析一、内存数据库具备的一些基本功能1）：数据的管理，内存数据库机制是支持永久数据的管理的，包括数据库的的定义、存储、维护等功能。
2）：数据的操作，内存数据库支持对数据进行增，删，改，查，数据完整性校验等一些基本功能。
3）：事务管理，内存数据库支持调度，进程间、线程间的一些并发等操作。
4）：数据恢复备份机制，内存数据库支持在线备份和系统崩溃后的自动恢复。
二、FastDBFastDB是一个高效率的内存数据库系统，在磁盘上的数据库文件和使用该数据库的每一个应用程序占用的虚拟内存空间相映射，这样取消了数据文件和缓冲池中的数据传输。
再将整个文件数据读入内存，并且使用了高性能的锁工具实现了只读模式线程间、单个更改模式线程和多个只读模式线程间的并发执行。
FastDB通过位图实现对内存进行分配，最小单位块是分配量子（16字节）。
如此大大提高了数据引用的局部性（对象数据尽可能分配在连续的内存区域），最小化了修改页的数目和减少了事务提交时间。
事务提交协议基于一个影子根页算法，对数据库执行原子更新操作，恢复效率很高，在存储数据结构上可以采用T-tree结构（T-tree和A VL-tree相似，只是T-tree中每个节点中顺序存储了多个值），对于大量相似重复性数据的查询性能相当高；也可以采用Hash存储，这是用关键字段定位表中记录的最好办法（采用等号进行查询）。
影子根页算法概述：FastDB数据库中每条对象都具有唯一的标识符（OID），用作一个数组（对象索引）的下标，元素值表示对象的一个句柄，在FastDB数据库中存在两个索引（当前索引和影子索引），当某个对象第一次被修改时，它会创建一个副本，当前索引中的对象句柄被修改指向副本，影子索引仍然包含一个指向该对象原始版本的句柄。
所有更改发生在副本上，FastDB在对象索引的一个特殊位图页上标记出哪个索引包含修改过的对象句柄。
当一个事务被提交时，FastDB首先检查对象索引的尺寸的大小，若增长了，还会重新为对象索引的影子副本重新分配内存，然后释放“旧对象”占用的内存，释放后，将修改过的所有位图页flush到磁盘上，然后FastDB将改变数据库头部中的当前对象索引指示符，以切换对象索引的角色。
数据库开源发展研究报告
数据库开源发展研究报告
《数据库开源发展研究报告》是一份对数据库开源项目的发展情况进行研究和总结的报告。
报告主要分析数据库开源项目的发展趋势、市场规模、技术特点以及应用领域等方面的内容。
报告首先介绍了数据库开源项目的背景和概况，包括数据库开源的定义、发展历程、开源许可协议等方面的内容。
随后，报告分析了数据库开源项目的发展趋势，从增长率、用户群体以及企业支持等方面探讨了数据库开源项目的发展前景。
报告还对数据库开源项目的市场规模进行了深入研究，分析了数据库开源项目在全球范围内的市场份额、主要竞争对手以及市场竞争格局等方面的内容。
此外，报告还对数据库开源项目的技术特点进行了评估，包括数据存储、事务处理、性能优化等方面的特点。
最后，报告还对数据库开源项目的应用领域进行了探讨，涵盖了企业领域、云计算、大数据分析等多个领域。
报告指出，数据库开源项目在应用领域的广泛应用将进一步推动其发展，并提出了一些未来的发展方向和挑战。
总的来说，《数据库开源发展研究报告》通过对数据库开源项目的综合研究，全面了解数据库开源项目的发展情况，为相关行业和企业提供了重要的参考和指导。
该报告对于推动数据库开源项目的发展，促进数据库开源技术的应用具有重要意义。
内存数据库相关技术的研究与分析
观点二， 数据库常驻磁盘， 在事务 执行前将所 需数据集调人内 存，
提交时所有对数据库的修改必须写 回磁盘 。观点三 ， 数据库常驻
磁盘ｔ 存中开 在内 辟一个大缓冲区（ ａ ｅ 通过适当的缓冲 或Ｃｃ ） ｈ， 管
理以减少内外存 Ｕ Ｏ操作
锁解锁而被挂起次数 的减少 往往意味着 Ｃ Ｕ ｃｅ Ｐ ｃ ｈ 刷新次数的 ａ
执行从开始到提交， 均不与外存打交道。当事务提交时数据库的 “ 外存版木” 〔 置于外存的 库部分） 数据 可以不必立即 反映出 事务提
交后 的结果， 并且当系统出现故障时应首 先恢 复在内存 中的数据
收 稿 日期 ；０７ ０－１ ２０ －９ ０
库的存储结构 及存取方法， 提高空间利用率。为此， 以 首先讨论了内 存数据库的定义， 接着分析了并发控制、 Ｍ Ｂ的逻拜优化规则、 Ｍ Ｄ 动
态降低锁拉度和动态提高锁粒度 ， 最后做了总结 关键词： 内存数 据库； 并发拉制 ； 逻辑优化
中图分 ７ ３１ 类号，Ｐ１
文献标识码， Ａ
１内存数 据库 的定义
内存 数据库是 一 个较新的研究领域 ， 什么是内存数据库 有 对 几 种不同的说法 ： 观点一 ， 整个数据 库全部常驻 内存． 存取数据 时 无须 １ ／ ０操作 这就要求 内容足够大 ，以容纳数据库 的所有数据
库主拷贝
需要指出的是， 传统磁盘数据库， 对于 即使其缓冲区足够大 大到可以容纳所有数 其 ‘ 作版本” 据或 ＇ Ｔ （ 如前所述第二、 只种观 点也不能 ） 算是一个 Ｍ Ｄ Ｍ Ｂ因为它是针对磁盘特性、 在假定数据
本 栏 目资任 编 辑 ：闻 翔军
选择合适的提高锁粒度的方法很重要 ， 既不能妨碍现有事务
浅析内存数据库
浅析内存数据库摘要:随着各个领域对实时数据处理的需求不断增长，基于磁盘的数据库系统已无法满足实时处理及近实时处理的需求，通过将数据库核心数据乃至所有数据放在内存中，内存数据库能够满足数据并发访问控制的要求。
本文描述了内存数据库的产生背景，阐述了内存数据库的体系结构及其优劣势，对内存数据库做了一个较为全面的介绍。
关键词：实时处理；内存；数据库一、内存数据库产生背景1.内存数据库的产生内存数据库就是把数据放到存储器中进行运算的数据库系统。
相比于磁盘,内存的数据读取速率要提高好几个数量级,把大量数据记录到内存中比在硬盘上存取更可以大大提高实际应用的能力。
随着科学技术迅猛发展，应用于传统数据管理领域的基于磁盘结构的数据库系统由于较高的延迟已经不能够满足人们对数据库系统的实时的要求，而随着内存价格越来越低以及存储芯片集成度越来越高，这使得存储容量已经不再是限制基于内存的数据库系统产生的瓶颈。
2.内存数据库与磁盘数据库的差异存储介质性质不同。
内存数据库将数据存储在内存中。
内存作为易失存储介质，仅能在通电的情况下保存数据。
磁盘数据库将数据存储在磁盘中，磁盘作为永久存储介质，能够永久保存数据，并且断电后数据不会丢失。
数据读取差异。
在内存数据库中，内存数据库通过指针直接访问数据，使得内存数据库的查询优化与磁盘数据库不同。
当数据存储在磁盘上时，无论是数据编址方式还是数据索引方式的优化措施均是以降低I/O次数为最终目的。
磁盘数据库通常使用B树、B+树或Hash等索引技术。
二、内存数据库关键技术内存数据库存储管理的内容就是确定内存数据库数据的组织结构。
内存数据库在RAM中存储数据，而内存可以被 CPU直接访问，所以内存数据库数据组织结构的设计目标是为内存数据库的关系表数据和索引提供合适的数据结构以加速数据操作速度和提升有限内存空间的利用率。
1.组织结构内存数据库中关系的存储通常采用基于关系模型的分级结构，同时还强调了元数据与数据应分区组织以提高数据安全性。
开源数据库数据存储策略探析
连 续 ６ 个 页 组 成 一 个 区 ４
１ ８ 区组 成 一 个 单 兀 ２个
பைடு நூலகம்
下 分 裂 ： 空 间 不 足 时 分 裂 ； 连 续 从 同 块 当
一
，ｎ ｏ Ｂ是 目前 Ｍｙｑ 缺 省 的 存 储 引 ｓｌ 数 据 存 储 策 略 ， 似 于 Ｄ ２的 Ｓ （ 类 Ｂ ＭＳ 系统 间 ）Ｉｎ Ｄ
在 管 理 表 空 间 ） 方 式 ， 助 操 作 系 统 来 完 擎 ， 性 能 和 可靠 性 方 面 表 现 优 秀 。 的 借 成 部 分 必 要 的功 能 。
用 缺 省 目录 作 为 数 据 库 存 储 数 据 文 件 的 图 １所 示 。
的形式 。 在 Ｉｎ ｂ ｓ 中 ， — ｅ ｎ ｏ ａｅ Ｂ Ｔｒｅ在 两 种 情 况
位 置 。在 Ｐ ｓｇｅ ＱＬ ． ｏｔｒＳ ８ ０之 前 ， 目录对 于
数 据 库 来 说 是 唯 一 的 ， 且 在 创 建 数 据 库 并
Ｍ ｙＱＬ 可 能 是 目前 能 得 到 的 、 快 的 数 过 周 期 性 地 手 工 执 行 该 命 令 的 方 法 重 建 于 两 个 段 ， 叶 子 节 点 在 一 个 段 中 ， 子 Ｓ 最 非 叶
据 库 之 一 ， 见 开 发 者 对 Ｍ ｙ ＱＬ 速 度 的 聚 集 。记 录 的 读 取 可 以通 过 顺 序 扫 描 整 个 节 点 数 据 在 一 个 段 中 。这 样 是 为 了保 证 叶 可 Ｓ 在 自信 。研 究 开 源 数 据 库 的实 现 方 式 ， 以 关 系 ， 这 种 情 况 下 记 录 的获 取 顺 序 依 赖 子 节 点 的数 据 在 磁 盘 上 尽 量 连 续 。 — ｒｅ 可 Ｂ Ｔ ｅ 会 给我们 以策 略上和技 术上的启迪 ， 并给 实 于 存 储 的 方 式 。 当 有 索 引 存 在 时 ， 按 照 的 节 点 对 应 着 数 据 文 件 的一 个 块 ， 根 节 其 现 设 计 的策 略 提 供 实 现 的 平 台 。 索引的顺序来获取记 录。
内存数据库(数据仓库与数据挖掘)
出现背景及主要应用
主要用在通信领域及大型的电信企业，银 行的解决方案 。 如：电信的二次批价和实时累账是计费系 统中的两个必备功能。
二次批价是相对于一次批价来说的。比如: 全球通每分钟本地通话为0.4元，在一次批 价完成后，会根据这个用户的套餐进行再一 次的计算。以全球通用户接听4分钟的电话 为例，一次批价完成后，这条话单的价格是 1.6元，如果这个用户参加了10元包月接听 套餐，那么在二次批价后，这次通话的费用 就为0元。一次批价是用于各大运营商之间 结算的，而二次批价是针对用户个人的。
内存数据库与传统数据库的异同
内存数据库所处理的数据通常是“短暂”的，即有一 定的有效时间，过时则有新的数据产生，而当前的决 策推导变成无效。所以，实际应用中采用内存数据库 来处理实时性强的业务逻辑处理数据。而传统数据库 旨在处理永久、稳定的数据，其性能目标是高的系统 吞吐量和低的代价，处理数据的实时性就要考虑的相 对少一些。实际应用中利用传统数据库这一特性存放 相对实时性要求不高的数据。 在实际应用中这两种数据库常常结合使用，而不是以 内存数据库替代传统数据库。
2.学习体会 学习体会
目前市场上流行的实时数据库产品仅仅局限于某一领域的应 用，尚未建立统一的通用型商业平台，实时数据库在不同应 用领域中有一些技术差异。 实时数据库理论方面的研究热点：还是有大量的人员研究数 据和数据库的结构与组织，包括事务模型的建立和事务的调 度算法。 关于磁盘历史数据压缩技术方面，在几年前对实时数据相当 重要，现在我感觉硬盘的容量方面扩容的速度和海量存储设 备的发展现在速度非常快，所以在数据压缩这一块，现在这 块的压力在逐步减弱。
数据仓库与数据挖掘
1.对RTDB的认识 2.学习体会 3.学习中发现的研究点
开源数据库MySQL的性能优化技术研究
开源数据库MySQL的性能优化技术研究随着互联网的蓬勃发展，数据库成为了互联网世界中不可或缺的一部分。
开源数据库MySQL，因其性能稳定、可靠性高、易于运维等优点得到了广泛应用。
然而，在实际业务场景中，MySQL数据库的性能问题也是无处不在的。
因此，本文将围绕开源数据库MySQL的性能优化技术展开讨论。
一、MySQL性能问题的原因MySQL的性能问题主要由以下几个方面造成：1. 数据库设计不合理：当数据库表结构不够规范、表之间的关联设计不合理，或者存在过多冗余数据时，会导致查询、插入、更新等操作速度变慢。
2. 索引过多或过少：索引是提高MySQL查询效率的重要手段。
过多的索引会影响写入性能，过少的索引则会降低查询效率。
3. 查询语句不合理：MySQL查询语句的编写非常重要。
如果查询语句中使用了太多的子查询或者没有使用合适的索引，都会导致查询效率变慢。
4. MySQL版本不合适：由于MySQL在不同版本中会有不同的性能优化，而且不同版本间也会存在一些性能差异，因此选择合适的MySQL版本对性能优化也是非常重要的。
5. 数据库连接池设置不合理：连接池是在服务器端设立的一组连接缓存，用于缓存数据库连接，避免反复创建新的连接。
连接池的大小设置直接影响数据库访问的并发数和性能。
二、MySQL性能优化的实现针对以上性能问题，下面将分别从不同角度进行MySQL性能优化的技术探讨。
1. 数据库设计优化对于数据库表的设计，需要注意以下几个方面：1）合理的表结构设计合理的表结构设计应该遵循正规化原则，避免存在重复数据或多余数据，并尽量把不同的数据存放到不同的表中。
对于大表，可以对其进行分区或者使用其他分库分表技术。
2）适当的索引设计合理的索引设计可以避免查询时全表扫描的情况。
需要根据具体业务场景合理地添加索引，并定期进行索引的优化和清理。
3）合理的关联设计合理的关联设计可以保证查询速度的快速响应。
需要避免过多的关联，尽可能使用JOIN操作来减少关联次数。
开源数据库的特点与应用MySQLPostgreSQLMongoDB等
开源数据库的特点与应用MySQLPostgreSQLMongoDB等开源数据库的特点与应用MySQL，PostgreSQL，MongoDB等开源数据库作为开放源代码软件，具有众多特点和广泛的应用。
本文将围绕开源数据库的特点和应用，以MySQL、PostgreSQL和MongoDB为例，进行详细探讨。
一、开源数据库的特点1. 开放源代码：开源数据库的源代码可以被公开查看、使用和修改，使得用户能够自由地定制和扩展数据库功能，提高数据库的灵活性和可定制性。
2. 易于获取和安装：开源数据库一般可以免费获取，并且具有简单、快速的安装过程，降低了用户的使用门槛。
3. 高度灵活可定制：由于开源数据库的开放性，用户可以根据自身需求灵活地扩展数据库功能，定制适合自己业务场景的数据库系统。
4. 移植性强：开源数据库常被开发为跨平台软件，支持多种操作系统，如Windows、Linux等，可以在不同平台上实现数据库的快速迁移和部署。
5. 社区支持活跃：开源数据库通常有庞大的用户社区，用户可以通过社区互助、交流和共享经验，获得及时的技术支持和问题解决方案。
二、MySQL的应用MySQL是一款轻量级、高效的开源数据库，被广泛应用于各种规模的应用系统中。
1. Web应用开发：MySQL作为服务器端数据库，被广泛用于支撑Web应用程序的后端存储。
其高度可靠性和高并发性能，使得它成为了许多大型互联网企业的首选数据库。
2. 企业信息管理系统：由于MySQL具有方便的安装和维护、低成本等特点，许多中小型企业选择MySQL作为其信息管理系统的数据库平台，以满足日常的业务需求。
3. 数据仓库：MySQL提供了丰富的数据分析和处理功能，可以被用作数据仓库，支持大规模数据处理、统计分析和决策支持等业务场景。
三、PostgreSQL的应用PostgreSQL是一款功能强大、可扩展性好的开源关系型数据库，被广泛应用于各种应用领域。
1. 地理信息系统（GIS）：由于PostgreSQL具备空间数据处理和查询的能力，它在GIS领域得到了广泛应用。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
一、内存数据库具备的一些基本功能1）：数据的管理，内存数据库机制是支持永久数据的管理的，包括数据库的的定义、存储、维护等功能。
2）：数据的操作，内存数据库支持对数据进行增，删，改，查，数据完整性校验等一些基本功能。
3）：事务管理，内存数据库支持调度，进程间、线程间的一些并发等操作。
4）：数据恢复备份机制，内存数据库支持在线备份和系统崩溃后的自动恢复。
二、FastDBFastDB是一个高效率的内存数据库系统，在磁盘上的数据库文件和使用该数据库的每一个应用程序占用的虚拟内存空间相映射，这样取消了数据文件和缓冲池中的数据传输。
再将整个文件数据读入内存，并且使用了高性能的锁工具实现了只读模式线程间、单个更改模式线程和多个只读模式线程间的并发执行。
FastDB通过位图实现对内存进行分配，最小单位块是分配量子（16字节）。
如此大大提高了数据引用的局部性（对象数据尽可能分配在连续的内存区域），最小化了修改页的数目和减少了事务提交时间。
事务提交协议基于一个影子根页算法，对数据库执行原子更新操作，恢复效率很高，在存储数据结构上可以采用T-tree结构（T-tree和A VL-tree相似，只是T-tree中每个节点中顺序存储了多个值），对于大量相似重复性数据的查询性能相当高；也可以采用Hash存储，这是用关键字段定位表中记录的最好办法（采用等号进行查询）。
影子根页算法概述：FastDB数据库中每条对象都具有唯一的标识符（OID），用作一个数组（对象索引）的下标，元素值表示对象的一个句柄，在FastDB数据库中存在两个索引（当前索引和影子索引），当某个对象第一次被修改时，它会创建一个副本，当前索引中的对象句柄被修改指向副本，影子索引仍然包含一个指向该对象原始版本的句柄。
所有更改发生在副本上，FastDB在对象索引的一个特殊位图页上标记出哪个索引包含修改过的对象句柄。
当一个事务被提交时，FastDB首先检查对象索引的尺寸的大小，若增长了，还会重新为对象索引的影子副本重新分配内存，然后释放“旧对象”占用的内存，释放后，将修改过的所有位图页flush到磁盘上，然后FastDB将改变数据库头部中的当前对象索引指示符，以切换对象索引的角色。
当前对象索引将变成影子索引之后，FastDB 把修改过的所有句柄从新的对象索引中复制到先前是影子的、现在已成为当前的对象索引中。
此时，两个索引都得到了同步。
优点：具备实时能力及便利的C++接口。
FastDB针对应用程序通过控制读访问模式作了优化。
通过降低数据传输的开销和非常有效的锁机制提供了高速的查询。
对每一个使用数据库的应用数据库文件被影射到虚拟内存空间中。
因此查询在应用的上下文中执行而不需要切换上下文以及数据传输。
fastdb中并发访问数据库的同步机制通过原子指令实现，几乎不增加查询的开销。
fastdb假定整个数据库存在于RAM中，并且依据这个假定优化了查询算法和接口。
此外，fastdb 没有数据库缓冲管理开销，不需要在数据库文件和缓冲池之间传输数据。
Fastdb支持事务、在线备份以及系统崩溃后的自动恢复。
事务提交协议依据一个影子根页面算法来自动更新数据库。
恢复可以执行得非常快，为临界应用提供了高可用性。
此外，取消事务日志改进了整个系统的性能，并且使得可以更有效的利用系统资源。
fastdb是一个面向应用的数据库，数据库表通过应用程序的类信息来构造。
fastdb支持自动的模式评估。
fastdb提供一个灵活方便的接口来从数据库中获取数据。
使用一个类SQL的查询语言进行指定的查询。
通过一些后关系特性如非原子字段，嵌套数组，用户定义类型和方法，对象间直接引用简化了数据库应用程序的设计并使之更有效率。
缺点：尽管fastdb的优化是立足于假定整个数据库配置在计算机的物理内存中，但是也有可能出现使用的数据库的大小超过了系统物理内存的大小的情况，在这种情况下标准的操作系统交换机制就会工作。
但是整个fastdb的搜索算法和结构是建立在假定所有的数据都存在于内存中的，因此数据换出的效率不会很高。
FastDB不支持client-server架构因而所有使用FastDB的应用程序必须运行在同一主机上。
部署方法：应用程序编译环境需求，首先是任何一个FastDB应用程序必须包含头文件：fastdb.h；然后是可以选择调用库文件（FastDB编译后提供静态库(libfastdb_r.a)和共享库两种库(libfastdb_r.so/ libfastdb_r.so.2)给调用）；最后是FastDB提供很多编译选项接口，用户可以根据需要进行设置，比如：容错支持，无盘模式，锁检测清理机制等等功能。
运行系统环境需求：理论上说，内存加载的数据库文件规模最小是1MB，上限就是内存和磁盘的容量了（FastDB 的整个优化设计是基于真个数据库系统存放在机器物理内存中，但是它依然支持将应用在规模超过物理内存的数据库上，只是效率不会很高）接口调用方法：1）：打开或创建数据库：dbDatabase db(parameter);db.open(parameter);mode的有：dbReadOnly，dbAllAccess，dbConcurrentRead，dbConcurrentUpdate四模式2)：FastDB支持的数据类型：类型描述bool 布尔类型(true,false)int1 一个字节的带符号整型(-128..127)int2 两个字节的带符号整型(-32768..32767)int4 四个字节的带符号整型(-2147483648..2147483647)int8 八个字节的带符号整型(-2**63..2**63-1)real4 四个字节的ANSI 浮点型real8 八个字节的双精度浮点型char const* 非中断整型dbReference<T> 到类T 的指针dbArray<T> 元素类型是T 的动态数组3)：FastDB对表的接口描述C++需要用类的形式来定义表结构，然后一一映射到表的fields，如果类有方法就得用宏：CLASS_DESCRIPTOR(name,field_list)，进行描述，还有方法宏TYPE_DESCRIPTOR(field_list)最后只需要将类进行注册：REGISTER(Class Name);4)：游标游标有两种模式：dbCursorViewOnly，dbCursorForUpdate定义举例dbCursor<Class Name> instance (dbCursorForUpdate);性能测试：不同事务模式下的插入性能比较：1)：磁盘模式我们首先按照批量事务处理的模式将intKey从1到nRecords(记录条数)，并指定相应的strKey，分别调用相应的接口(均为原始API)插入到两张表中，这里的批量事务处理模式指的是，比如插入10000条记录，插第一条之前开始事务，最后一条之后结束事务。
此时在插入不同数目记录时的表现分别如下(一万条、十万条、72万条、一百万条)：批量事务提交：E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe[FASTDB] Elapsed time for inserting 10000 record: 63 msE:\intrest\FastDB\PerfTest\Debug>PerfTest.exe[FASTDB] Elapsed time for inserting 100000 record: 1186 msE:\intrest\FastDB\PerfTest\Debug>PerfTest.exe[FASTDB] Elapsed time for inserting 7200000 record: 152460 msE:\intrest\FastDB\PerfTest\Debug>PerfTest.exe[FASTDB] Elapsed time for inserting 1000000 record: 15522 ms逐条事务模式：E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe[FASTDB] Elapsed time for inserting 10000 record: 57315 msE:\intrest\FastDB\PerfTest\Debug>PerfTest.exe[FASTDB] Elapsed time for inserting 10000 record: 59967 ms从中可以看出，FastDB在这种情形下的性能急遽降低，降到一个几乎不能接收的水平。
原因是因为FastDB在每次事务提交时，都会将变更的数据内容同步到磁盘文件中，因此造成性能的显著降低。
直观上看，解决FastDB的这个问题有两种办法，一是避免每次事务提交时同步到磁盘，因为在这种应用中，这种同步操作并不需要实时进行，通常每隔一段时间同步一次就可以了(比如1S、1Min、等根据具体项目的可靠性需要)；二是使用前面提到的FastDB无盘(DISKLESS)模式。
对于第一种方案，FastDB为数据库提供了precommit的接口，用于完成除sync到磁盘文件外的所有事物操作。
同时提供了backup接口，用来完成内存数据到磁盘文件的备份，甚至支持打开数据库时同时指定定时备份到磁盘文件的间隔。
这样一来，每次事务提交的效率理论上会得到大大提高，并且通过定时备份机制可以保证数据的可靠性。
使用precommit进行逐条事务提交：E:\intrest\FastDB\PerfTest\Debug>PerfTest[FASTDB] Elapsed time for inserting 10000 record: 62 msE:\intrest\FastDB\PerfTest\Debug>PerfTest[FASTDB] Elapsed time for inserting 100000 record: 1170 msE:\intrest\FastDB\PerfTest\Debug>PerfTest[FASTDB] Elapsed time for inserting 1000000 record: 8081 ms2）：FastDB无盘模式FastDB采用无盘(通过编译选项控制生成DISKLESS版本)模式，此时FastDB初始化一段共享内存(shmat or mmap)，这个初始大小通常很大，并且运行期不能扩展（无盘模式的劣势）。
将初始共享内存设置为1G，得到的测试结果如下：E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe[FASTDB] Elapsed time for inserting 100000 record: 624 ms (批量事务提交)E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe[FASTDB] Elapsed time for inserting 100000 record: 7410 ms (逐条事务提交)E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe[FASTDB] Elapsed time for inserting 1000000 record: 134660 msE:\intrest\FastDB\PerfTest\Debug>PerfTest.exe[FASTDB] Elapsed time for inserting 250000 record: 23666 ms查询性能比较：下面都使用磁盘模式的precommit方式，再来看索引查询的性能表现，测试时都是先插入十万条数据后，再分别对该十万条数据进行查询，同时对FastDB是否增加HASH索引的性能进行了横向测评，FastDB增加HASH索引很简单，通过修改TYPE- DESCRIPTOR来完成，上面的class中改为TYPE_DESCRIPTOR((KEY(intKey, INDEXED), KEY(strKey, INDEXED)));即为intKey增加了Hash索引。