利用固态硬盘（SSD）技术的优势设计数据库应用架构是非常有吸引力的一件事。特别值得注意的是，固态硬盘并行访问数据的能力已经有了很大的提升。这些提升使得固态硬盘对于许多类型的数据库应用几乎能达到了随机访问内存存储的性能，而成本只是其八分之一。

在过去的几年里，固态硬盘的性能得到了突飞猛进的增长，同时相比于传统硬盘和RAM，其成本却在持续降低。但是要利用好这些改进的优势，需要掌握存储特性选择合适的AWS实例大小，理解应用特性并利用合适的编程语言。

掌握AWS选项

AWS IaaS EC2实例可以配置不同级别的存储：

A）内存。对应于传统物理计算机的RAM。

B）实例存储。也称为临时存储。它对应于传统物理计算机的磁盘大小。

C）灵活的持久化补充存储（比如EBS和S3）。基本上可以把它视为物理PC的网络存储。

Amazon现在把SSD作为部署临时存储和通用存储的默认配置，也是EBS的默认配置（早期的实例类型默认不是SSD）。EBS的其它好处是存储系统可以在数据库服务器本身退役以后仍然继续可用。

此外，AWS还提供SSD存储作为Amazon DynamoDB的默认选项。SSD同时也是Amazon RDS和Amazon Redshift的可选配置。这个配置非常好，它可以降低数据库应用需要的开发代价。但是，如果企业需要部署其它数据库，也有很多其它可配置项可以帮助他们利用到SSD的并行特性。

并行存储的物理原理

物理计算机通常设置有三种主要存储类型。RAM安装在主板上，紧挨着CPU，它提供最高的性能，成本代价也最高，计算机关闭以后内容不会保存。SSD和传统硬盘是连接到计算机上的补充存储，通过PCI-e，SCSI和SATA线缆连接，或者在网络上通过eSATA或者光纤通道连接。

传统硬盘包含有一个物理读写头，一次可以跨多个物理盘片读取数据流。如果数据可以顺序读取（比如读取较大的多媒体视频音频文件），或者对于一些数据库分析应用（比如Hadoop应用），这种模式都非常合适。然而，如果读取数据要搜索盘片的多个扇区，那么传统硬盘读写头的性能会急剧下降。

与此相反，闪存驱动的物理构成就是成百上千个可以随机访问的块，是由分散的许多芯片组成的，读取哪一块的数据不会影响访问性能。闪存盘有两个瓶颈：第一就是计算机处理器和个体芯片储存区之间的存储控制器；第二是不能从单个芯片上的不同块区同时读取随机数据。

当今时代的大部分数据库引擎都没有利用闪存盘访问数据随机位的功能优势。其结果是，数据库都比较慢，或者虽然其访问模式可以被缓存，但需要更多RAM才能实现同样的性能效果。而RAM存储肯定比闪存盘速度快，不过对于相同数量的存储空间，RAM的成本是闪存盘的十倍。在物理层面上，RAM比SSD有更好的IO处理能力，但是成本也是其大约三到四倍。这些相对成本也被反映到了Amazon Web服务上可用的不同计算机实例相对成本上。

写入队列

利用跨多个芯片并行访问数据能力优势的关键在于编写程序时要考虑到队列深度这一特性。在数据库应用中增加队列深度可以使应用从SSD不同个体芯片中并行读写数据，这对提高数据库性能有直接的效果。

如果队列深度设置过大，访问同一芯片中不同数据位的可能性就增大了，这也会破坏性能。因此，大部分应用的最佳队列深度是每驱动器32到64个并发请求，尽管驱动器本身支持更多并发请求。通过优化数据库应用访问SSD的队列深度，应用程序可以花更少的代价就能达到用更昂贵RAM才能实现的更佳性能状态。

在应用层面，开发者需要考虑如何实现应用对存储系统的请求队列化，以实现并行处理。但是，软件方面要获得较好的并行有许多陷阱。要用像JavaScript、Ruby和Python这样的编程语言实现并行是很困难的，因为这些语言对实现多线程支持的不太好，Java和C#相对更容易一些。

C和C++是实现高并发系统代码最合适的编程语言，因为它们直接操作操作系统核心功能。例如，互斥扩展（也叫互斥量）就是简化编程生成低级系统并行调用的语言特性。另一种选择是使用自带SSD存储优化方案的商业数据库，比如Aerospike。

为应用选择合适的架构

不是所有的数据库应用都需要闪存存储功能来并行访问随机数据。处理大量并发用户Web请求的数据库很容易看到闪存存储的最大优势。

与此相反，像Hadoop这种分析应用在某种意义上是并行的，但是通常这些应用最后都需要访问存储驱动器上的大量数据流来完成数据访问。例如，处理一个月的用户日志来分析其行为或者分析用户，本质上都要按顺序提取数据，因此迁移到SSD并不能带来太多益处。在这两种极端场景之间，还有一些实时分析类型的应用，它们既需要一定的随机搜索和也需要数据流处理。

专家建议，充分利用各种层次成本差异的一种方式是，配置数据库利用临时存储读取数据以获得最佳性能。这一点可以通过存储在EBS持久化数据层的数据进行备份。这种方案提供了AWS上价格和性能的最佳平衡组合。

后台进程也需要考虑

数据库应用架构师还应该考虑其它细微特征。要理解数据库软件如何利用RAM，如何把数据刷到磁盘，这些对于优化SSD应用配置非常重要。这对于评估数据库与文件系统交互的各种方式也非常重要。最明显的读负载繁重会有大量后台IO竞争。而其他进程像报表系统、日志文件生成是需要后台维护的。

要想找到合适的平衡点，专家建议以真实世界部署的强大指标为基准进行参考。这样可以帮助企业判断部署和优化SSD系统有多大益处。不过，在RAM和SSD之间选择，最重要的考虑因素是深刻掌握要处理的数据集大小。

配置合适的SSD和RAM容量有许多种组合，会增加数据库更高的复杂度。更多的是传统数据库系统，它们会部署一台主服务器和许多备用服务器用于故障恢复，除了在磁盘级别的情况它们的配置都很简单。另一方面，分布式数据库系统根据节点数量不同，RAM数量和网络设置的不同会有更多的变化。

尽管在大多数情况下，如果你关注技术的力量和数据库系统的可操作性作为选择硬件驱动器的考虑因素，那么你需要比较评估的系统应该相对不会很多。