使用FriendFeed来提升MySQL性能的方法(friend怎么用)

推荐整理分享使用FriendFeed来提升MySQL性能的方法(friend怎么用)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:friendly 用法,friend用法总结,friendly 用法,friend用法总结,friend用法总结,friends用法,friend的用法和短语,friends用法,内容如对您有帮助，希望把文章链接给更多的朋友！

背景

我们使用MySQL存储了FriendFeed的所有数据。数据库随着用户基数的增长而增长了很多。现在已经存储了超过2.5亿条记录与一堆涵盖了从评论和“喜欢”到好友列表的其他数据。

随着数据的增长，我们也曾迭代地解决了随着如此迅猛的增长而带来的扩展性问题。我们的尝试很有代表性，例如使用只读mysql从节点和memcache来增加读取吞吐量，对数据库进行分片来提高写入吞吐量。然而，随着业务的增长，添加新功能比扩展既有功能以迎合更多的流量变得更加困难。

特别的，对 schema 做改动或为超过 - 万行记录的数据库添加索引会将数据库锁住几个小时。删除旧索引也要占用这么多时间，但不删除它们会影响性能;因为数据库要持续地在每个INSERT上读写这些没用的区块，并将重要的区块挤出了内存。为避免这些问题需要采取一些复杂的措施（例如在从节点上设置新的索引，然后将从节点与主节点对调），但这些措施会引发错误并且实施起来比较困难，它们阻碍了需要改动 schema/索引才能实现的新功能。由于数据库的严重分散，MySQL 的关系特性(如join）对我们没用，所以我们决定脱离 RDBMS。

虽然已有许多用于解决灵活 schema 数据存储和运行时构建索引的问题(例如 CouchDB)的项目。但在大站点中却没有足够广泛地用到来说服人们使用。在我们看到和运行的测试中，这些项目要么不稳定，要么缺乏足够的测试(参见这个有点过时的关于 CouchDB 的文章)。MySQL 不错，它不会损坏数据；复制也没问题，我们已经了解了它的局限。我们喜欢将 MySQL 用于存储，仅仅是非关系型的存储。

几经思量，我们决定在 MySQL 上采用一种无模式的存储系统，而不是使用一个完全没接触过的存储系统。本文试图描述这个系统的高级细节。我们很好奇其他大型网站是如何处理这些问题的，另外也希望我们完成的某些设计会对其他开发者有所帮助。

综述

我们在数据库中存储的是无模式的属性集(例如JSON对象或python字典)。存储的记录只需一个名为id的字节的UUID属性。对数据库而言实体的其他部分是不可见的。我们可以简单地存入新属性来改变schema(可以简单理解为数据表中只有两个字段：id,data;其中data存储的是实体的属性集)。

我们通过保存在不同表中的索引来检索数据。如果想检索每个实体中的三个属性，我们就需要三个数据表-每个表用于检索某一特定属性。如果不想再用某一索引了，我们要在代码中停止该索引对应表的写操作，并可选地删除那个表。如果想添加个新索引，只需要为该索引新建个MySQL表，并启动一个进程异步地为该表添加索引数据(不影响运行中的服务)。

最终，虽然我们的数据表增多了，但添加和删除索引却变得简单了。我们大力改善了添加索引数据的进程(我们称之为“清洁工")使其在快速添加索引的同时不会影响站点。我们可以在一天内完成新属性的保存和索引，并且我们不需要对调主从MySQL数据库，也不需要任何其他可怕的操作。

细节

MySQL 使用表保存我们的实体，一个表就像这样 :

之所以使用 added_id 个字段是因为 InnoDB 按物理主键顺序存储数据，自增长主键确保新实例在磁盘上按顺序写到老实体之后，这样有助于分区读写（相对老的实体，新实体往往读操作更频繁，因为 FriendFeed 的 pages 是按时间逆序排列）。实体本身经 python 字典序列化后使用 zlib 压缩存储。

索引单独存在一张表里，如果要创建索引，我们创建一张新表存储我们想要索引的数据分片的所有属性。例如，一个 FriendFeed 实体通过看上去是这样的：

我们索引实体的属性 user_id，这样我们可以渲染一个页面，包含一个已提交用户的所有属性。我们的索引表看起来是这样的：

我们的数据存储会自动为你维护索引，所以如果你要在我们存储上述结构实体的数据存储里开启一个实例，你可以写一段代码（用 python）：

上面的 Index 类在所有实体中查找 user_id，自动维护 index_user_id 表的索引。我们的数据库是切分的，参数 shard_on 是用来确定索引是存储在哪个分片上（这种情况下使用 entity["user_id"] % num_shards)。

你可以使用索引实例（见上面的 user_id_index.get_all）查询一个索引，使用 python 写的数据存储代码将表 index_user_id 和表 entities 合并。首先在所有数据库分片中查询表 index_user_id 获取实体 ID 列，然后在 entities 提出数据。

新建一个索引，比如，在属性 link 上，我们可以创建一个新表：

我们可以修改数据存储的初始化代码以包含我们的新索引：

我可以异步构建索引（特别是实时传输服务）：

一致性与原子性

由于采用分区的数据库，实体的索引可能存储在与实体不同的分区中，这引起了一致性问题。如果进程在写入所有索引表前崩溃了会怎样？

许多有野心的 FriendFeed 工程师倾向于构建一个事务性协议，但我们希望尽可能地保持系统的简洁。我们决定放宽限制：

因此，往数据库中写入实体时我们采用如下步骤:

我们要记住从索引表中取出的数据可能是不准确的（例如如果写操作没有完成步骤2可能会影响旧属性值）。为确保采用上面的限制能返回正确的实体，我们用索引表来决定要读取哪些实体，但不要相信索引的完整性，要使用查询条件对这些实体进行再过滤：

1.根据查询条件从索引表中取得 entity_id

2.根据 entity_id 从 entities 表中读取实体

3.根据实体的真实属性（用 Python）过滤掉不符合查询条件的实体

为保证索引的持久性和一致性，上文提到的“清洁工”进程要持续运行，写入丢失的索引，清理失效的旧索引。它优先清理最近更新的实体，所以实际上维护索引的一致性非常快(几秒钟). 性能

我们对新系统的主索引进行了优化，对结果也很满意。以下是上个月 FriendFeed 页面的加载延时统计图（我们在前几天启动了新的后端，你可以根据延时的显著回落找到那一天）。

特别地，系统的延时现在也很稳定（哪怕是在午高峰期间）。如下是过去小时FriendFeed页面加载延时图。

与上周的某天相比较：

系统到目前为止使用起来很方便。我们在部署之后也改动了几次索引，并且我们也开始将这种模式应用于 MySQL 中那些较大的表，这样我们在以后可以轻松地改动它们的结构。

MySQL中修改表结构时需要注意的一些地方 MySql在修改表结构的时候可能会中断产品的正常运行影响用户体验，甚至更坏的结果，丢失数据。不是所有的数据库管理员、程序员、系统管理员都非常

浅谈InnoDB隔离模式的使用对MySQL性能造成的影响 在这篇文章里我将讨论一个相关的主题?InnoDB事务隔离模式，还有它们与MVCC（多版本并发控制）的关系，以及它们是如何影响MySQL性能的。MySQL手册提供

使用cgroups来限制MySQL企业备份服务对资源的占用 今天我遇到一个问题，MySQL企业版备份引起I/O子系统负载过大，应用响应缓慢，导致系统不可用。所以我想限制mysqlbackup的进程，使它不会引起更多的问