为什么 Pinterest 使用 MySQL 而不是 NoSQLs 作为数据存储?

因为 MySQL 是经过验证的技术,对他们来说效果很好。
SQL 与 NoSQL 有很多混淆和炒作,但这些只是营销术语,并没有真正描述可用的不同类型的数据库。这是一个简短的列表:
* 关系型
* 核心价值
* 文档存储
* 图表
* 柱状

关系变体(MySQL、PostgreSQL、SQL Server、Oracle 等)通常被称为 SQL 数据库,因为它们将 SQL(结构化查询语言)实现为…
虽然我不为 Pinterest 工作,但我的假设是他们可能混合使用关系和非关系存储技术,每种技术都基于每种技术对预期目的的适用性。
我必须指出,NOSQL 不是一个平台,就像 NoPear 不是苹果一样。所有非关系平台都没有共同的属性,除了它们可能没有全部或部分利用传统的关系数据引擎。
各种非关系数据管理技术各有优缺点、成本和优势。一些,比如 MongoDB,是很好的消息存储,为个性化等提供灵活的选项,非常适合具有小型(通常是单消息有效负载)的高并发读取。
Hadoop 本质上是一个分布式日志文件存储,具有出色的文本解析工具。非常适合存储大量的多结构化和非结构化文本内容。非常适合离线研究和分析。基于元组的更新和删除非常糟糕。在网络规模的实时查询响应方面表现不佳。
还有许多其他主要和次要形式的非关系存储,都具有针对特定范围的特性和功能进行优化的工具和引擎(高并发 -> 低并发、实时响应 -> 离线响应、大型表单事务 -> 小型事务,内存中 -> 磁盘主控,高粒度 -> 低粒度…)
关键是,Pinterest 有一些非常聪明的工程师,他们构建了一个包含关系和非关系技术的大规模、多平台系统。企业级非关系技术的出现并没有使企业级关系技术的使用失效。它只是为我们提供了一套更广泛的工具来实现伟大的事物。
首先,Facebook 和许多其他大型互联网公司已经证明,MySQL + 适当的 Sharding 策略可以成为为数百万甚至十亿以上用户构建服务的非常可扩展的解决方案。
其次,MySQL 是一项非常成熟的技术,已经存在了 20 多年。很容易找到经验丰富的 MySQL 工程师或 DBA。
此外,Pinterest 确实将 NoSQL 数据存储用于 MySQL 无法轻易满足的用例。例如,本文讨论了 Pinterest 如何使用 HBase 为其以下提要提供支持。