来源：数据分析师 CPDA | 时间：2018-03-24 | 作者：admin
内存数据库是什么?
内存数据库，顾名思义就是将数据放在内存中直接操作的数据库。相对于磁盘，内存的数据读写速度要高出几个数量级，将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。
内存数据库系统带来的优越性能不仅仅在于对内存读写比对磁盘读写快上，更重要的是，从根本上抛弃了磁盘数据管理的许多传统方式，基于全部数据都在内存中管理进行了新的体系结构的设计，并且在数据缓存、快速算法、并行操作方面也进行了相应的改进，从而使数据处理速度一般比传统数据库的数据处理速度快很多，一般都在10倍以上，理想情况甚至可以达到1000倍。
而使用共享内存技术的实时系统和使用内存数据库相比有很多不足，由于优化的目标仍然集中在最小化磁盘访问上，很难满足完整的数据库管理的要求，设计的非标准化和软件的专用性造成可伸缩性、可用性和系统的效率都非常低，对于快速部署和简化维护都是不利的。
定义：设有数据库系统DBS，DB为DBS中的数据库，DBM(t)为在时刻t，DB在内存的数据集，DBM(t)属于DB。TS为DBS中所有可能的事务构成的集合。AT(t)为在时刻t处于活动状态的事务集，AT(t)属于TS。
Dt(T)为事务T在时刻t所操作的数据集，Dt(T)属于DB。若在任意时刻t，均有:
任意T属于AT(t) Dt(T)属于DBM(t)
成立，则称DBS为一个内存数据库系统，简称为MMDBS;DB为一个内存数据库，简称为MMDB。
常见的例子有MySQL的MEMORY存储引擎、eXtremeDB、TT、FastDB、SQLite、Microsoft SQL Server Compact等。
下面介绍几种常用的内存数据库：
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是一个比较明智的选择. 事实也证明, 人们在许多情况下已经清楚的认识到简单就是最好的选择.
通过上面的介绍，大家可能对内存数据库有了一定的了解，我们将持续更新关于内存数据库的专业知识观点，更多数据类及大数据的资讯内容可以关注CPDA数据分析师官网。
