Pinterest MySQL利用分片来解决百亿数据存储问题的示例剖析
发布时间：2022-02-19 05:23:21 所属栏目：MySql教程 来源：互联网
导读：这篇文章将为大家详细讲解有关Pinterest MySQL利用分片来解决百亿数据存储问题的示例分析，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。 Pinteres 是你感兴趣的所有东西的发现引擎。从数据的角度来说，Pinterest 是
|
这篇文章将为大家详细讲解有关Pinterest MySQL利用分片来解决百亿数据存储问题的示例分析，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。 Pinteres 是你感兴趣的所有东西的发现引擎。从数据的角度来说，Pinterest 是世界上最大的人类兴趣图集。有超过500亿的 Pin 被 Pin 友们保存在10亿块图板上。 用户再次 Pin，喜欢其他人的 Pin（粗略地说是一个浅显的复制品），关注其他 Pin 友，画板和兴趣，然后查看主页上所订阅Pin友的所有资讯。 太好了！ 现在让它扩大规模！ 业务要求 我们的全部系统需要非常稳定，易于操作和易于扩展。 我们希望支持数据库能从开始的小存储量，能随着业务发展而扩展。 所有 Pin友 生成的内容在网站上必须随时可以访问。 支持以确定的顺序请求访问 N 个 Pin在画板中展示（像按照创建的时间，或者按照用户特定的顺序）。对于喜欢的 Pin 友和 Pin友的 Pin 列表等也能按照特定的顺序展示。 为了简单起见，更新一般要保证最好的效果。为了获取最终一致性，你需要一些额外的东西，如分布式 事务日志。这是一件有趣并（不）简单的事情。 解决思路及要点备注 解决方案由于需要将海量的数据切片分布到多个数据库实例上，不能使用关系数据库的连接、外键或索引等方法整合整个数据。想想就知道，关联的子查询不能跨越不同的数据库实例。 我们的方案需要负载平衡数据访问。我们憎恨数据迁移，尤其是逐个记录进行迁移，因关系的复杂性，这样非常容易发生错误且加重系统不必要的复杂性。如果必须要迁移数据，最好是逻辑节点集的整体迁移。 为了达到方案实施的可靠迅速，我们需要在我们的分布式数据平台上使用最易于实现、最健壮的技术方案。 每个实例上的所有的数据将被完全复制到一个从实例上，作为数据备份。我们使用的是高可用性的 MapReduce (分布式计算环境) 的 S3 。我们前端的业务逻辑访问后台数据，只访问数据库的 主实例。永远不要让您的前端业务去读写访问从实例 。因为它与 主实例 数据同步存在延迟，会造成莫名其妙的错误，一旦将数据切片并分布，没有一丝理由让你前端业务从 从实例 上读写数据。 最后，我们需要精心设计一个优秀的方案生成和解析我们所有数据对象的 全局唯一标识（ UUID ） 。 我们的切片方案 不管怎样，我们需要设计符合我们需求的，健壮的，性能优良和可维护的数据分布解决方案。换句话说，它不能稚嫩（未经广泛验证）。因此，我们的基础设计建立在 MySQL 之上，参见 we chose a mature technology（选择成熟技术） 。设计之初，我们自然会跳开不用那些号称具有自动分布（auto-scaling）新技术能力的数据库产品，诸如 MongoDB，Cassandra 和 Membase 之类的产品，因为它们似乎实施简单却适用性太差（常常发生莫名其妙的错误导致崩溃）。 （编辑：云计算网_泰州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330476号