本文地址：https://www.askmac.cn/archives/nosql-real-world-mongodb-shutterfly.html
最近掀起的一波非关系数据库浪潮，也称“NoSQL”热潮，它引起了人们的热烈反映。大肆的宣传炒作下，真实情况到底如何就很难说了。人们的谈论很多，但在现实世界NoSQL到底有多牛逼？在这个系列中，我们将看到一些真实世界的NoSQL。
Shutterfly的是一种流行的，基于互联网的，照片共享和个人出版公司，管理着超过60亿图像的持久性存储，每秒的事务处理率高达10,000次操作。数据架构师Kenny Gorman接受了帮助Shutterfly的任务，选择并替换其现有的关系型数据库管理系统：Oracle的RDBMS。
最初，Shutterfly考虑过如MySQL和PostgreSQL的开源数据库。但是，在评估和重新架构应用程序的过程中，非关系型数据库似乎更符合Shutterfly的数据的需求，它有可能改善程序员的工作效率以及性能和可扩展性。“我们有过权衡，最后不得不说服自己，不太成熟的非事务性数据存储在这里也OK，” Gorman说。
Shutterfly在选定MongoDB这个面向文档的数据库之前，考察过各种各样的数据库系统，包括Cassandra，CouchDB和BerkeleyDB。 MongoDB在JSON（JavaScript对象符号）格式的变体中存储数据；每个文档是自描述，并且可以具有一个复杂的内部结构。
MongoDB的面向文档的思想与Shutterfly现有的XML格式一致，同时提供强劲横向扩展和故障切换复制。迁移到文档模式不算是个大步骤，Gorman说道：“若你对mongodb的可扩展性十分感兴趣，那么你可能会想到你需要对你的数据反范式化。”
像大多数NoSQL解决方案，MongoDB提供了一个非常不同的模式进行事务处理和保持一致性 – 一般不会立即提供一致的或多个文档的事务。因此，Shutterfly部署的MongoDB仅用于该应用程序的一部分，如严格的一致性不重要的部分，如与上传的照片相关的元数据。对于需要更强一致性的应用程序，或者更丰富的事务模式的部分 – 可能是计费和账户管理 ，传统的RDBMS还是需要的。被转移到MongoDB的那些部分应用经过充分考虑了简单的事务模式后被重新设计。
尽管需要大量的努力并伴随重大架构转变的风险，Shutterfly在上市周期内的报告显示迁移后再成本和性能方面还是有显著的回报。此外，MongoDB已缓解了应用程序的对象模型和底层数据库模型之间的不匹配。在关系型世界中，这种不匹配通常是由Object Relational Mapping（ORM）隐藏的，它在对象和关系模型之间进行转译。然而，这种混淆导致性能和可管理性的问题。” 在MongoDB中没有ORM的复杂性，你有更好的整体性能，” Gorman说。 “至少这是我们希望的。”
MongoDB所要求的妥协，尤其是更改数据模型和事务范式需要Shutterfly大量的技术投资。但到目前为止，Shutterfly对它的决定感到满意。 “我确信选择了正确的工具来做正确的工作，MongoDB在这里配合的很好，且没有让我们做出太多的妥协，” Gorman说。 “根据我们的情实际况，已经付出的妥协是比较小的。”
Comment