Mysql必读使用FriendFeed来提升MySQL性能的方法

《Mysql必读使用FriendFeed来提升MySQL性能的方法》要点：
本文介绍了Mysql必读使用FriendFeed来提升MySQL性能的方法，希望对您有用。如果有疑问，可以联系我们。

MYSQL入门 配景

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

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

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

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

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

MYSQL入门综述

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

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

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

MYSQL入门细节

MYSQL入门MySQL 使用表保留我们的实体,一个表就像这样 :
 

MYSQL入门
CREATE TABLE entities (
  added_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  id BINARY(16) NOT NULL,
  updated TIMESTAMP NOT NULL,
  body MEDIUMBLOB,
  UNIQUE KEY (id),
  KEY (updated)
) ENGINE=InnoDB;

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

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

MYSQL入门
{
  "id": "71f0c4d2291844cca2df6f486e96e37c",
  "user_id": "f48b0440ca0c4f66991c4d5f6a078eaf",
  "feed_id": "f48b0440ca0c4f66991c4d5f6a078eaf",
  "title": "We just launched a new backend system for FriendFeed!",
  "link": "http://friendfeed.com/e/71f0c4d2-2918-44cc-a2df-6f486e96e37c",
  "published": 1235697046,
  "updated": 1235697046,
}

MYSQL入门我们索引实体的属性 user_id,这样我们可以渲染一个页面,包括一个已提交用户的所有属性.我们的索引表看起来是这样的：

MYSQL入门
CREATE TABLE index_user_id (
  user_id BINARY(16) NOT NULL,
  entity_id BINARY(16) NOT NULL UNIQUE,
  PRIMARY KEY (user_id, entity_id)
) ENGINE=InnoDB;

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

MYSQL入门
user_id_index = friendfeed.datastore.Index(
  table="index_user_id", properties=["user_id"], shard_on="user_id")
datastore = friendfeed.datastore.DataStore(
  mysql_shards=["127.0.0.1:3306", "127.0.0.1:3307"],
  indexes=[user_id_index])
 
new_entity = {
  "id": binascii.a2b_hex("71f0c4d2291844cca2df6f486e96e37c"),
  "user_id": binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"),
  "feed_id": binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"),
  "title": u"We just launched a new backend system for FriendFeed!",
  "link": u"http://friendfeed.com/e/71f0c4d2-2918-44cc-a2df-6f486e96e37c",
  "published": 1235697046,
  "updated": 1235697046,
}
datastore.put(new_entity)
entity = datastore.get(binascii.a2b_hex("71f0c4d2291844cca2df6f486e96e37c"))
entity = user_id_index.get_all(datastore, user_id=binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"))

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

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

MYSQL入门新建一个索引,好比,在属性 link 上,我们可以创建一个新表：
 

MYSQL入门
CREATE TABLE index_link (
  link VARCHAR(735) NOT NULL,
  entity_id BINARY(16) NOT NULL UNIQUE,
  PRIMARY KEY (link, entity_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

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

MYSQL入门
user_id_index = friendfeed.datastore.Index(
  table="index_user_id", properties=["user_id"], shard_on="user_id")
link_index = friendfeed.datastore.Index(
  table="index_link", properties=["link"], shard_on="link")
datastore = friendfeed.datastore.DataStore(
  mysql_shards=["127.0.0.1:3306", "127.0.0.1:3307"],
  indexes=[user_id_index, link_index])

MYSQL入门我可以异步构建索引(特别是实时传输服务)：
 

MYSQL入门
./rundatastorecleaner.py --index=index_link

MYSQL入门一致性与原子性

MYSQL入门由于采用分区的数据库,实体的索引可能存储在与实体不同的分区中,这引起了一致性问题.如果进程在写入所有索引表前瓦解了会怎样?

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

•     保留在主实体表中的属性集是规范完整的
•     索引不会对真实实体值产生影响

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

•     使用 InnoDB 的 ACID 属性将实体写入 entities 表.
•     将索引写入所有分区中的索引表.

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

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

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

MYSQL入门3.根据实体的真实属性(用 Python)过滤掉不符合查询条件的实体

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

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

MYSQL入门

MYSQL入门特别地,系统的延时现在也很稳定(哪怕是在午高峰期间).如下是过去24小时FriendFeed页面加载延时图.

MYSQL入门

MYSQL入门与上周的某天相比拟：

MYSQL入门

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

《Mysql必读使用FriendFeed来提升MySQL性能的方法》是否对您有启发，欢迎查看更多与《Mysql必读使用FriendFeed来提升MySQL性能的方法》相关教程，学精学透。维易PHP学院为您提供精彩教程。

转载请注明本页网址：
http://www.vephp.com/jiaocheng/9846.html