在软件开发领域，数据持久化方案在最近数年中已经取得长足发展。除了先前持久化的默认选项——关系数据库系统，数据库的疆土上出现了更多样化的选择。在日前举行的 Lone Star Software Symposium 软件研讨会上，Scott Leberknight 做了一次题为“ Polyglot Persistence ”演讲，讨论现在的新情况，即开发者们在选取数据持久化方案时可以有众多备选的数据库产品，诸如 Amazon SimpleDB 、Google Bigtable 、Microsoft SQL Data Services ( SDS ) 和 CouchDB 等。
早在 2006 年 12 月，Neal Ford 就写过一篇“ Polyglot Programming（多语编程）”，预言了我们现在所见的一波趋势，即为手头的特定工作选用最适合的语言。与确立一种“默认”语言（如Java 或C#）的做法相比，多语编程要点是为特定工作挑选适当的语言，而不仅仅是挑选框架。这番说法用在持久化方面也成立。
Scott 说开发者在 MVC 和 AJAX 框架等领域有许多选择，如 Struts、Apache MyFaces、Spring MVC、Wicket、Rails、Grails、jQuery、dojo、Ext JS……而在解决企业应用的数据持久化问题上，开发者同样拥有众多选择。“多语”持久化着眼于考虑持久化需求，然后选取一种最能满足需求的持久化机制。
由于企业应用在功能和技术需求上的多样性，不可能有普适的方案。以下是一些推动数据持久化领域创新的因素：
- 可伸缩性
- 高可用性
- 容错能力
- 可分布性
- 灵活性（即“schemaless”数据库）
- 新类型的应用，如社交网络网站
应用管理之下的数据，其类型也有很大区别。可能是结构化的（关系数据）、半结构化的（如医疗记录系统中的文档）或者是无结构的（音频 / 视频流）。面向对象的数据库、面向文档的数据库、Bigtable、键值存储、实体属性（Entity Attribute）值数据库等不同类型的数据库纷纷出现，各自瞄准了不同的数据持久化需求。
他还谈到ACID 和BASE 的概念会极大地影响数据库系统的事务和可用性。ACID 和BASE 提供的保证不同、代价也不同。例如，ACID 系统以可用性为代价去保证数据的一致性，所以在两段式提交中，只要有一项事务性的资源倒下，系统的可用性就是零。而BASE 牺牲即时的数据一致性去换取高可用性的分区容忍性。问题的具体情况决定了我们是否可以牺牲一致性去换取高可用性、容错、冗余等好处。
面向文档的数据库的例子有 Lotus Notes ,、Apache CouchDB、Amazon SimpleDB 和 ThruDB 。Scott 演示了通过 REST API 访问 Simple DB 数据库和 CouchDB 视图，并根据数据库中的文档生成汇总和报表。
Project Voldemort 是另一个数据持久化方案，它是一个分布式的键 - 值存储系统，并有跨服务器自动复制、透明的服务器失效处理、自动数据项目版本化等特性。 LinkedIn 用它解决高伸缩性存储的问题，适用于简单的功能分区力所不及的场合。来自 LinkedIn 的 Jay Kreps 将于即将召开的 QCon 大会上介绍Voldemort 项目。
Scott 也讨论了其他数据库产品，如 Amazon 的 Dynamo ——一个键 - 值数据存储系统、Apache HBase ——开源、分布式、面向列的存储模型，仿照了 Google Bigtable 实现。数据持久化的疆域上还活跃着更多的物种，如 XML 数据库、Semantic Web/RDF、 Triplestores 、 Tuplespaces 等等。
大多数新的数据持久化系统都提供了基于 REST 的 API，API 语言也有 Java、C#、PHP、Visual Basic 和 Ruby 等。Scott 建议开发者考虑数据库方案的时候，应该思考自己的应用到底需要什么，而不要去想现在流行什么。决策时应该从以下方面去考查：
- 项目需求
- 分布式部署
- 容错
- 查询功能的丰富性
- Schema 演进
- 可伸缩能力的极限
- 强制施加关系的能力
- ACID 还是 BASE
- 键 / 值存储
暂无签名
《研发效能 100 问》上册
第一本研发效能领域的问答工具书，集结来自腾讯、字节、自如等企业的专家，解答研发效能领域高频问题。
评论