您好：[] []
Facebook用闪存来存储MySQL数据库
发表于：12年06月01日 11:00 [编译]
[导读]Facebook正在它的数据中心中用Fusion-io服务器闪存卡来存储MySQL数据。数据处理速度得到了提升，因为闪存比磁盘驱动器更好。
DOSTOR存储在线 6月1日国际报道：Facebook正在它的数据中心中用Fusion-io服务器闪存卡来存储MySQL数据。数据处理速度得到了提升，因为闪存比磁盘驱动器更好。 Piper Jaffray分析师Andrew Nowinski告诉我们说Facebook正在使用Fusion-io ioDrive
PCIe闪存卡来增加容量，并通过闪存高速缓存来提升性能。 &Fusion-io产品现在用于大容量存储用途。Facebook订购了新的ioDrive2卡来代替主要的后端存储&&我们想被代替的后端存储应该是LSI和它们的RAID(独立磁盘冗余阵列)以及相应的1.5万转磁盘驱动器。这笔交易的金额实际上高于被代替的系统。Fusion-io解决方案的性优势远远超过了HDD(硬盘驱动器)解决方案，使它的性价比更具吸引力。& Facebook现在将&它的MySQL数据库托管在Fusion-io卡上而不是使用来自LSI的HDD解决方案&。Nowinski告诉我们说其中一个理由就是MySQL有一个日志系统，在这个系统中，每条数据都被写入两次，一次写入数据库表，另一次写入日志中以备冗余和故障保护。这个机制占用了存储容量并降低了性能。 他表示：&通过使用Fusion-io卡和新的SDK，客户可以关闭这个日志系统，因为Fusion-io卡也有一个专利的日志系统来保护电源丢失后的数据。在关闭日志后，和HDD存储相比，客户可以将数据存储量减少50%，将吞吐率提升33%，延迟时间降低50%。& Nowinski同时还认为：&随着Fusion-io扩展到除了iCloud以外其他容量导向型的应用程序，苹果实际可以代替Facebook成为Fusion-io的头号客户。& 苹果接受Fusion的背景是这样的： &Fusion-io在苹果的市场始于它们代替了一家网络存储厂商并支持iCloud应用程序。Fusion-io在这个项目中击败了Oracle
Exadata，因为它们的解决方案可以提供4倍于Exadata的性能并只要一半的成本，也就是16倍的性价比优势。这么明显的成本是来自于它合并了苹果原来为承载Oracle数据库而支付的Oracle软件许可证费用。& 苹果按对来部署ioDrive卡以获得冗余度，这样性价比优势就降到了8倍，不过仍然很可观。 他认为思科UCS服务器对ioDrive卡的认证进展良好。
[责任编辑：王振]
昆腾公司已经算是存储行业的“老手”了，在磁带市场一直保持着优势。随着存储技术的发展，昆腾又适时做出调整，开展磁盘方面的业务。
存储风云榜”是由DOIT传媒主办的年度大型活动。回顾2014年，存储作为IT系统架构中最基础的元素，已经成为了推动信息产业发展的核心动力，存储产业的发展迈向成熟，数据经济的概念顺势而为的提出。
华为OceanStor V3系列存储系统是面向企业级应用的新一代统一存储产品。在功能、性能、效率、可靠性和易用性上都达到业界领先水平，很好的满足了大型数据库OLTP/OLAP、文件共享、云计算等各种应用下的数据存储需求。
联想携ThinkServer+System+七大行业解决方案惊艳第十六届高交会Facebook如何实现PB级别数据库自动化备份
-------------
新增文件夹...
新增文件夹
(多个标签用逗号分隔)
Facebook的MySQL数据库，是世界上最庞大的MySQL数据库之一，在不同地区有数千个数据库服务器。因此，备份对他们来说是个巨大的挑 战。为了解决这个问题，他们构建了一个高度自动化、非常有效的备份系统，每周移动多个PB的数据。Facebook数据团队的Eric Barrett通过分享了他们的做法。
他们没有采用大量前载（front-loaded）测试，而是强调快速检测失败，并且进行快速、自动化纠正。部署几百个数据库服务器，只需很少人力干预。使用下面的三个措施，他们做到了有节奏的增长，同时具备支持上十亿用户的灵活性。
措施1：二进制日志和mysqldump
第一道防线称为“措施1”，或“机架”备份（rack backup），简称RBU。在每个数据库机架上，不论其类型为何，都有两个RBU存储服务器。以RBU作为数据库服务器放在同一个机架中，这可以保证最 大的带宽和最小的延迟，它们同时可以作为缓存，在备份的下个措施使用。
收集二进制日志，是这些服务器的工作之一。二进制日志会不断以流形式，通过模拟从进程（simulated slave process）输送到RBU主机中。这样一来，不需要运行mysqld，RBU就可以接收到同样的更新作为复制版本。
在RBU上保存同步的二进制日志很重要：如果一个主数据库服务器离线，该服务器上的用户将无法更新状态或是上传照片。出现问题后，他们需要保证修复 时间越短越好。有可用的二进制日志，就能让他们在数秒内启动另一个数据库作为主数据库。由于RBU中有秒级的二进制日志，即使某个旧主数据库完全不可用， 也没有关系，只要利用将记录下的事务恢复到上一个备份中即可完成立即恢复。
RBU服务器的第二个工作是执行传统备份。MySQL备份有两种方式：二进制和逻辑（mysqldump）。Facebook使用逻辑备份，因为它与版本无关，提供更好的数据完整性，更紧凑，恢复起来更省事。不过，当为某个数据库构建全新复制时，他们仍然使用二进制拷贝。
mysqldump的一个主要好处是：磁盘上的数据损坏不会影响到备份中。如果磁盘某个扇区出现问题，或是写入错误，InnoDB页面校验和就会出 错。在组合备份流时，MySQL会从内存中读取正确的内容，或是去磁盘读取，然后遇到错误的校验和，停止备份（以及数据库进程）。mysqldump的问 题是：污染用来缓存InnoDB块的LRU缓存。不过，新版本的MySQL中，会将LRU插入操作从扫描时放到缓存结束。
对在自己权限范围内的所有数据库，每个RBU都有一个夜间备份。尽管有着天量级别的数据，Facebook的团队还是可以在几个小时内完成对所有数据的备份。
如果RBU失败，自动化软件会将其职责分配给同一集群中其他系统。当它恢复上线后，职责会自动返回到最初的RBU主机。
Facebook团队不会过分担心单个系统的数据保留问题，因为他们有措施2。
措施2：Hadoop DFS
在每个备份和二进制日志收集完成后，他们会马上将其复制到他们的大型定制化Hadoop集群中。这些集群是非常稳定的复制数据集，并有固定的保留时 间。因为磁盘大小增长很快，较老的RBU可能不足以保存一到两天的备份。不过他们会按需要增长Hadoop集群，同时不需要担心底层硬件情况。 Hadoop的分布式特性让他们有足够带宽，完成快速数据恢复。
不久，他们会把非实时数据分析放到这些Hadoop集群中。这可以降低数据库中非关键读的次数，让Facebook网站的响应速度更快。
措施3：长期存储
每周，他们会从Hadoop备份移动到另一个地区的分散存储中。这些系统是最新而且安全的存储系统，在他们的日常数据管理工具流程之外。
除常用的系统监控外，他们还会捕捉很多特定的统计数据，比如binlog集合延迟、系统容量等等。
为备份失败打分，是他们最有价值的工具。因为Facebook的数据库和同时运行的维护任务量级，错过某些备份也不奇怪。广泛的失败和多日没有成功 的单个备份，这都是他们要注意的重点。因此，某个错过备份的得分会随着时间呈指数级增长，这些得分的不同聚合，让团队能对备份的整体健康度有一个有效而快 速的了解。
比如，在一天内，某个数据错失一次备份，得1分，一天错失50次备份，就是50分。但在三天内的一次数据库错失，就是27分（3的3次幂），三天内 50次，这是很严重的问题，得分就是1350（50乘以3的3次幂）。这会在他们的监控图上出现一个巨大的波峰，团队会马上对其采取行动。
在系统管理员中有句老话：“如果你没有测试过你的备份，就等于没有备份。”
因此，Facebook团队构建了一个测试系统，会持续地从措施2开始，将数据恢复到测试服务器上。恢复完成后，他们会执行多次数据完整性检查。如 果有任何反复出现的问题，系统就会报警，提醒相关人员关注、审核。该系统可以发现所有问题，包括MySQL的bug，到备份过程中的纰漏，并可以让他们更 灵活地应对备份环境中的变化。
他们构建了一个名为ORC（ORC恢复协调器的递归缩写）的系统，工程师如何需要恢复他们所用工具的数据库的过去版本，就可以以自服务方式使用该系统恢复数据。对于快速开发来说还是挺方便的。
在结尾，Eric Barrett说道：
备份不是最迷人的工程工作。它们即是技术活，又是重复性的，如果一切正常，没人会注意。它们也是跨学科和团队的，需要懂得系统、网络和软件等多方面的专业知识。但是，确保你的记忆和联系安全无误，这是无比重要的事情，而且到最后，也是充满回报的事情。
有网友问到：
在不运行mysqld的RBU上，你们如何完成二进制日志的流传送？什么是模拟从进程？
Facebook的MySQL性能工程师Harrison Fisk给出了答案：
我们使用mysqlbinlog的–never–选项，并有一个用python开发的小包装程序，会监控并保证mysqlbinlog运行成功。
相关资讯 　—　
相关文档 　—　
发布时间： 09:22:59
同类热门经验
4838次浏览
2154次浏览
1955次浏览
3750次浏览
3264次浏览
OPEN-OPEN, all rights reserved.您好：[] []
Facebook用闪存来存储MySQL数据库
发表于：12年06月01日 11:00 [编译]
[导读]Facebook正在它的数据中心中用Fusion-io服务器闪存卡来存储MySQL数据。数据处理速度得到了提升，因为闪存比磁盘驱动器更好。
DOSTOR存储在线 6月1日国际报道：Facebook正在它的数据中心中用Fusion-io服务器闪存卡来存储MySQL数据。数据处理速度得到了提升，因为闪存比磁盘驱动器更好。 Piper Jaffray分析师Andrew Nowinski告诉我们说Facebook正在使用Fusion-io ioDrive
PCIe闪存卡来增加容量，并通过闪存高速缓存来提升性能。 &Fusion-io产品现在用于大容量存储用途。Facebook订购了新的ioDrive2卡来代替主要的后端存储&&我们想被代替的后端存储应该是LSI和它们的RAID(独立磁盘冗余阵列)以及相应的1.5万转磁盘驱动器。这笔交易的金额实际上高于被代替的系统。Fusion-io解决方案的性优势远远超过了HDD(硬盘驱动器)解决方案，使它的性价比更具吸引力。& Facebook现在将&它的MySQL数据库托管在Fusion-io卡上而不是使用来自LSI的HDD解决方案&。Nowinski告诉我们说其中一个理由就是MySQL有一个日志系统，在这个系统中，每条数据都被写入两次，一次写入数据库表，另一次写入日志中以备冗余和故障保护。这个机制占用了存储容量并降低了性能。 他表示：&通过使用Fusion-io卡和新的SDK，客户可以关闭这个日志系统，因为Fusion-io卡也有一个专利的日志系统来保护电源丢失后的数据。在关闭日志后，和HDD存储相比，客户可以将数据存储量减少50%，将吞吐率提升33%，延迟时间降低50%。& Nowinski同时还认为：&随着Fusion-io扩展到除了iCloud以外其他容量导向型的应用程序，苹果实际可以代替Facebook成为Fusion-io的头号客户。& 苹果接受Fusion的背景是这样的： &Fusion-io在苹果的市场始于它们代替了一家网络存储厂商并支持iCloud应用程序。Fusion-io在这个项目中击败了Oracle
Exadata，因为它们的解决方案可以提供4倍于Exadata的性能并只要一半的成本，也就是16倍的性价比优势。这么明显的成本是来自于它合并了苹果原来为承载Oracle数据库而支付的Oracle软件许可证费用。& 苹果按对来部署ioDrive卡以获得冗余度，这样性价比优势就降到了8倍，不过仍然很可观。 他认为思科UCS服务器对ioDrive卡的认证进展良好。
[责任编辑：王振]
昆腾公司已经算是存储行业的“老手”了，在磁带市场一直保持着优势。随着存储技术的发展，昆腾又适时做出调整，开展磁盘方面的业务。
华为OceanStor V3系列存储系统是面向企业级应用的新一代统一存储产品。在功能、性能、效率、可靠性和易用性上都达到业界领先水平，很好的满足了大型数据库OLTP/OLAP、文件共享、云计算等各种应用下的数据存储需求。
12月15日，中国闪存联盟成立，同时IBM Flash System卓越中心正式启动
DOIT、DOSTOR、易会移动客户端播报中国存储峰会盛况。您所在的位置： &
MySQL数据库的发展历程
MySQL数据库的发展历程
此文章主要和大家分享的是MySQL数据库的发展历程，以及对MySQL数据库的未来的预示，以下就是文章的详细内容描述。
此文章主要向大家描述的是数据库的发展轨迹，我们大家都知道MySQL最开始的是玩具数据库发展为现在在&世界上最流行的开源数据库&，其中的过程伴随着产品版本升级， 以及一些新功能（特别是企业数据库功能）的增加。
现在，随着MySQL 5.0被完美地开发出来，已经很少有人将MySQL数据库称为&玩具数据库&了。
MySQL的丰富功能满足了许多用户的需求，Oracle最近的动作表明了他们 对待MySQL非常重视&&Oracle曾几次三番的表示有意收购MySQL。让我们先从MySQL的较有影响的版本产品开始，看一下MySQL的更新换 代。
MySQL 4.0 MySQL 4.0是在2003年3月发布的，该版本使新的基于MySQL的应用程序获得了更广泛的应用。但是在4.0版中，MySQL不支持存储过程、触发程序、服 务器端指针或视图。MySQL 4.0是从3.23发展而来，较之3.23版本有了很大的提高，主要适用于Web站点，这时候的MySQL还不是一个企业级数据库。
以下是MySQL 4.0的主要新特性： FULLTEXT索引：最值得用户期待的可能就是FULLTEXT索引。 FULLTEXT在文本字段创建索引，为对该索引执行布尔搜索提供了一个强大而灵活的机制。依照一般的开发经验，开发人员通常必须创建索引并访问文本数据，而FULLTEXT索引比想象中的还要好得多。
许多解决方案仅限于全字索引，FULLTEXT索引没有这种限制，允许开发人员添加或拆分词组。 ANSI SQL UNION：支持ANSI SQL UNION语句，该语句将询问结果汇集到一个结果集。
多表操作：可以执行多表UPDATE和DELETE。 新语句：增加了其他DBMS用户所熟悉的一些非标准的新语句（如IDENTITY和TRUNCATE TABLE），以及FOUND_ROWS()等新功能，这些功能可以返回无需LIMIT子句就能返回的纪录的编号。 InnoDB存储引擎：InnoDB存储引擎在当时作为服务器的标准特性，在4.0版本中成为一个附加选项。
InnoDb是允许ACID兼容事务的表类型，而非默认的MyISAM表类型，它可以加快一般性使用的速度，但对于关键操作不是十分有用。InnoDB表使用行级别锁定特性，这意味着对一个记录的更新只锁定该记录，而不是整个表。当选择访问大量的数据库时（对于大多数Web站点而 言），锁定整个表相当快，但是当插入和更新的数量接近于选项的数量时，则速度较慢。
长期以来，对MySQL数据库的批评一直集中在MyISAM表的安全性和一致 性问题，兼容ACID的InnoDB表在解决这些问题上走过了很长一段路。 查询缓存：MySQL 4.0在某些情况下可以更快捷。这主要通过查询缓存得以实现，它将重复的查询结果存储起来，使速度得以提高，尽管许多成熟的应用程序在某个代码级别上执行自己的查询缓存功能。
某些语句在速度上也有所提高。 Embededded Server：MySQL 4.0附带了一个Embededded Server库，允许应用程序以MySQL作为底层数据库。 latin1_de ：MySQL 4.0支持一个额外字符集latin1_de，它可确保正确存储德语单词。 MyISAM：MySQL 4.0中的MyISAM表目前在表级别上支持符号链接，所以Windows用户可以在表级别上创建符号链接（这对于Unix用户始终有效）。
安全模型：MySQL 4.0的安全模型得到了增强，允许管理员更加细致地授权许可。新的权限允许用户创建临时表、锁定表、执行某些复制任务、查看所有现有的数据库，甚至在达到 最大连接限度时还能进行连接&&对于DBA执行紧急任务非常有用，甚至允许运行存储过程（在MySQL 5中实现了此功能）。DBA依靠增强的安全模式也可以限制用户每小时的连接、更新或查询次数。
MySQL 4设计运行在Novell Netware 6.0之上。另外，MySQL服务器变量中有不少可以在不重新启动服务器的情况下进行更改，由于重新启动会恢复旧的设置，因此这个特性非常有用。
MySQL 4.1 MySQL 4.1推出之后，对于某些用户而言，4.1比MySQL 4.0具有更激动人心的升级可能： MySQL 4.1支持子查询 不使用子查询时，许多查询可以更有效地编写，但是会有例外。子查询是标准ANSI SQL特性。 支持Unicode (UTF-8)，允许更广泛地进行国际化。 每个列、表或数据库都可以设置不同的字符集，如果以多种语言存储数据，这就很有必要了。 支持地理数据（OpenGIS） 增强的警告发送。
如果一个不够，MySQL 4.1可以将多个警告发送到客户端，这样就对于整体数据处理十分有用。 提高了一些速度。但这些速度提高可能被MySQL 4.1所承担的所有额外部分抵消。 尽管MySQL手册是发布的最好手册之一，MySQL 4.1还是附带了仅适用于该版本的HELP命令。 支持派生表，例如：
SELECT table1.field1 FROM table, (SELECT * FROM table2) table3 WHERE table1.field1=table3.field1 支持多行查询，允许运行多个查询，然后读取最终结果。 各种维护语句将存入二进制日志中，在复制时您可以简化维护任务。 CREATE...LIKE允许开发人员按现有表的精确结构轻松地创建新表。 另外，MySQL 4.1的三个显著功能包括：稳定的OpenSSL支持、更多的测试准备语句、更多的测试一个表的多个字符集。
MySQL 4.1或许是第一个实际&长大成人&的MySQL数据库版本。由于4.1版本中一些新增加的特性和功能（例如地理数据、子选择语句、派生表），Oracle第一次开始真正关注MySQL。 MySQL 5.0 支持存储过程。存储过程是一个开发人员在其他数据库环境最常用的ANSI SQL标准，对于MySQL来说，这已经姗姗来迟了。MySQL 5.0所支持的存储过程的语法类似于Oracle PL/SQL和T-SQL。 触发程序（发生某个事件时所称的存储过程） 支持指针
真正支持VARCHAR数据类型，解决了一个长期存在的MySQL VARCHAR bug。
在MyISAM表中对RTREE索引的支持，将使访问地理数据变得很容易。
MySQL 5.1 相对于5.0版本，MySQL 5.1实现了一些新的功能： 联机备份（允许添加replication slave，而不必关闭主服务器）。
BIT类型，实际占用1位，而不是1个字符。
失败保护（failsafe）复制
原文标题：看MySQL的发展轨迹&
连接：/hustcat/articles/1585602.html
【编辑推荐】
【责任编辑： TEL：（010）】
关于的更多文章
MySQL是完全网络化的跨平台关系型数据库系统，同时是具有客户机/
数据库产品
数据库综合
数据库新闻
维基百科将切换到另外一款开源数据库MariaDB
SQL Server 2008提供了全民啊行的空间支持，但同时空
你的SQL Server代码安全吗？请你与我一起跟随作者来探
为什么会发生死锁？如何利用SQL Server Profiler分析
该书为C#经典名著！是Wrox红皮书中最畅销的品种之一。从第1版开始就名满天下；其第3版被评选为2005年最权威的十大IT图书之一；并
51CTO旗下网站Advertisement
HBase在淘宝的应用和优化小结
导读：本文作者在淘宝从事Hadoop及HBase相关的应用和优化，对Hadoop、HBase都有深入的了解，本文就是其在工作中对HBase的应用优化小结，分享给大家。关键词：&&&&
　　1 前言　　hbase是从hadoop中分离出来的apache顶级开源项目。由于它很好地用java实现了google的bigtable系统大部分特性，因此在数据量猛增的今天非常受到欢迎。对于淘宝而言，随着市场规模的扩大，产品与技术的发展，业务数据量越来越大，对海量数据的高效插入和读取变得越来越重要。由于淘宝拥有也许是国内最大的单一hadoop集群(云梯)，因此对hadoop系列的产品有比较深入的了解，也就自然希望使用hbase来做这样一种海量数据读写服务。本篇文章将对淘宝最近一年来在online应用上使用和优化hbase的情况做一次小结。　　2 原因　　为什么要使用hbase?　　淘宝在2011年之前所有的后端持久化存储基本上都是在mysql上进行的(不排除少量oracle/bdb/tair/mongdb等)，mysql由于开源，并且生态系统良好，本身拥有分库分表等多种解决方案，因此很长一段时间内都满足淘宝大量业务的需求。　　但是由于业务的多样化发展，有越来越多的业务系统的需求开始发生了变化。一般来说有以下几类变化：　　a) 数据量变得越来越多，事实上现在淘宝几乎任何一个与用户相关的在线业务的数据量都在亿级别，每日系统调用次数从亿到百亿都有，且历史数据不能轻易删除。这需要有一个海量分布式文件系统，能对TB级甚至PB级别的数据提供在线服务　　b) 数据量的增长很快且不一定能准确预计，大多数应用系统从上线起在一段时间内数据量都呈很快的上升趋势，因此从成本的角度考虑对系统水平扩展能力有比较强烈的需求，且不希望存在单点制约　　c) 只需要简单的kv读取，没有复杂的join等需求。但对系统的并发能力以及吞吐量、响应延时有非常高的需求，并且希望系统能够保持强一致性　　d) 通常系统的写入非常频繁，尤其是大量系统依赖于实时的日志分析　　e) 希望能够快速读取批量数据　　f ) schema灵活多变，可能经常更新列属性或新增列　　g) 希望能够方便使用，有良好且语义清晰的java接口　　以上需求综合在一起，我们认为hbase是一种比较适合的选择。首先它的数据由hdfs天然地做了数据冗余，云梯三年的稳定运行，数据100%可靠己经证明了hdfs集群的安全性，以及服务于海量数据的能力。其次hbase本身的数据读写服务没有单点的限制，服务能力可以随服务器的增长而线性增长，达到几十上百台的规模。LSM-Tree模式的设计让hbase的写入性能非常良好，单次写入通常在1-3ms内即可响应完成，且性能不随数据量的增长而下降。region(相当于数据库的分表)可以ms级动态的切分和移动，保证了负载均衡性。由于hbase上的数据模型是按rowkey排序存储的，而读取时会一次读取连续的整块数据做为cache，因此良好的rowkey设计可以让批量读取变得十分容易，甚至只需要1次io就能获取几十上百条用户想要的数据。最后，淘宝大部分工程师是java背景的同学，因此hbase的api对于他们来说非常容易上手，培训成本相对较低。　　当然也必须指出，在大数据量的背景下银弹是不存在的，hbase本身也有不适合的场景。比如，索引只支持主索引(或看成主组合索引)，又比如服务是单点的，单台机器宕机后在master恢复它期间它所负责的部分数据将无法服务等。这就要求在选型上需要对自己的应用系统有足够了解。　　3 应用情况　　我们从2011年3月开始研究hbase如何用于在线服务。尽管之前在一淘搜索中己经有了几十节点的离线服务。这是因为hbase早期版本的目标就是一个海量数据中的离线服务。2009年9月发布的0.20.0版本是一个里程碑，online应用正式成为了hbase的目标，为此hbase引入了zookeeper来做为backupmaster以及regionserver的管理。.90.0版本是另一个里程碑，基本上我们今天看到的各大网站，如facebook/ebay/yahoo内所使用于生产的hbase都是基于这一个版本(fb所采用的0.89版本结构与0.90.x相近)。bloomfilter等诸多属性加入了进来，性能也有极大提升。基于此，淘宝也选用了0.90.x分支作为线上版本的基础。　　第一个上线的应用是数据魔方中的prom。prom原先是基于redis构建的，因为数据量持续增大以及需求的变化，因此我们用hbase重构了它的存储层。准确的说prom更适合0.92版本的hbase，因为它不仅需要高速的在线读写，更需要count/group by等复杂应用。但由于当时0.92版本尚未成熟，因此我们自己单独实现了coprocessor。prom的数据导入是来源于云梯，因此我们每天晚上花半个小时将数据从云梯上写入hbase所在的hdfs，然后在web层做了一个client转发。经过一个月的数据比对，确认了速度比之redis并未有明显下降，以及数据的准确性，因此得以顺利上线。　　第二个上线的应用是TimeTunnel，TimeTunnel是一个高效的、可靠的、可扩展的实时数据传输平台，广泛应用于实时日志收集、数据实时监控、广告效果实时反馈、数据库实时同步等领域。它与prom相比的特点是增加了在线写。动态的数据增加使hbase上compact/balance/split/recovery等诸多特性受到了极大的挑战。TT的写入量大约一天20TB，读的量约为此的1.5倍，我们为此准备了20台regionserver的集群，当然底层的hdfs是公用的，数量更为庞大(下文会提到)。每天TT会为不同的业务在hbase上建不同的表，然后往该表上写入数据，即使我们将region的大小上限设为1GB，最大的几个业务也会达到数千个region这样的规模，可以说每一分钟都会有数次split。在TT的上线过程中，我们修复了hbase很多关于split方面的bug，有好几个commit到了hbase社区，同时也将社区一些最新的patch打在了我们的版本上。split相关的bug应该说是hbase中会导致数据丢失最大的风险之一，这一点对于每个想使用hbase的开发者来说必须牢记。hbase由于采用了LSM-Tree模型，从架构原理上来说数据几乎没有丢失的可能，但是在实际使用中不小心谨慎就有丢失风险。原因后面会单独强调。TT在预发过程中我们分别因为Meta表损坏以及split方面的bug曾经丢失过数据，因此也单独写了meta表恢复工具，确保今后不发生类似问题(hbase-0.90.5以后的版本都增加了类似工具)。另外，由于我们存放TT的机房并不稳定，发生过很多次宕机事故，甚至发生过假死现象。因此我们也着手修改了一些patch，以提高宕机恢复时间，以及增强了监控的强度。　　CTU以及会员中心项目是两个对在线要求比较高的项目，在这两个项目中我们特别对hbase的慢响应问题进行了研究。hbase的慢响应现在一般归纳为四类原因：网络原因、gc问题、命中率以及client的反序列化问题。我们现在对它们做了一些解决方案(后面会有介绍)，以更好地对慢响应有控制力。　　和Facebook类似，我们也使用了hbase做为实时计算类项目的存储层。目前对内部己经上线了部分实时项目，比如实时页面点击系统，galaxy实时交易推荐以及直播间等内部项目，用户则是散布到公司内各部门的运营小二们。与facebook的puma不同的是淘宝使用了多种方式做实时计算层，比如galaxy是使用类似affa的actor模式处理交易数据，同时关联商品表等维度表计算排行(TopN)，而实时页面点击系统则是基于twitter开源的storm进行开发，后台通过TT获取实时的日志数据，计算流将中间结果以及动态维表持久化到hbase上，比如我们将rowkey设计为url+userid，并读出实时的数据，从而实现实时计算各个维度上的uv。　　最后要特别提一下历史交易订单项目。这个项目实际上也是一个重构项目，目的是从以前的solr+bdb的方案上迁移到hbase上来。由于它关系到己买到页面，用户使用频率非常高，重要程度接近核心应用，对数据丢失以及服务中断是零容忍。它对compact做了优化，避免大数据量的compact在服务时间内发生。新增了定制的filter来实现分页查询，rowkey上对应用进行了巧妙的设计以避免了冗余数据的传输以及90%以上的读转化成了顺序读。目前该集群存储了超过百亿的订单数据以及数千亿的索引数据，线上故障率为0。　　随着业务的发展，目前我们定制的hbase集群己经应用到了线上超过二十个应用，数百台服务器上。包括淘宝首页的商品实时推荐、广泛用于卖家的实时量子统计等应用，并且还有继续增多以及向核心应用靠近的趋势。　　4 部署、运维和监控　　Facebook之前曾经透露过Facebook的hbase架构，可以说是非常不错的。如他们将message服务的hbase集群按用户分为数个集群，每个集群100台服务器，拥有一台namenode以及分为5个机架，每个机架上一台zookeeper。可以说对于大数据量的服务这是一种优良的架构。对于淘宝来说，由于数据量远没有那么大，应用也没有那么核心，因此我们采用公用hdfs以及zookeeper集群的架构。每个hdfs集群尽量不超过100台规模(这是为了尽量限制namenode单点问题)。在其上架设数个hbase集群，每个集群一个master以及一个backupmaster。公用hdfs的好处是可以尽量减少compact的影响，以及均摊掉硬盘的成本，因为总有集群对磁盘空间要求高，也总有集群对磁盘空间要求低，混合在一起用从成本上是比较合算的。zookeeper集群公用，每个hbase集群在zk上分属不同的根节点。通过zk的权限机制来保证hbase集群的相互独立。zk的公用原因则仅仅是为了运维方便。　　由于是在线应用，运维和监控就变得更加重要，由于之前的经验接近0，因此很难招到专门的hbase运维人员。我们的开发团队和运维团队从一开始就很重视该问题，很早就开始自行培养。以下讲一些我们的运维和监控经验。　　我们定制的hbase很重要的一部分功能就是增加监控。hbase本身可以发送ganglia监控数据，只是监控项远远不够，并且ganglia的展示方式并不直观和突出。因此一方面我们在代码中侵入式地增加了很多监控点，比如compact/split/balance/flush队列以及各个阶段的耗时、读写各个阶段的响应时间、读写次数、region的open/close，以及具体到表和region级别的读写次数等等。仍然将它们通过socket的方式发送到ganglia中，ganglia会把它们记录到rrd文件中，rrd文件的特点是历史数据的精度会越来越低，因此我们自己编写程序从rrd中读出相应的数据并持久化到其它地方，然后自己用js实现了一套监控界面，将我们关心的数据以趋势图、饼图等各种方式重点汇总和显示出来，并且可以无精度损失地查看任意历史数据。在显示的同时会把部分非常重要的数据，如读写次数、响应时间等写入数据库，实现波动报警等自定义的报警。经过以上措施，保证了我们总是能先于用户发现集群的问题并及时修复。我们利用redis高效的排序算法实时地将每个region的读写次数进行排序，能够在高负载的情况下找到具体请求次数排名较高的那些region，并把它们移到空闲的regionserver上去。在高峰期我们能对上百台机器的数十万个region进行实时排序。　　为了隔离应用的影响，我们在代码层面实现了可以检查不同client过来的连接，并且切断某些client的连接，以在发生故障时，将故障隔离在某个应用内部而不扩大化。mapreduce的应用也会控制在低峰期运行，比如在白天我们会关闭jobtracker等。　　此外，为了保障服务从结果上的可用，我们也会定期跑读写测试、建表测试、hbck等命令。hbck是一个非常有用的工具，不过要注意它也是一个很重的工操作，因此尽量减少hbck的调用次数，尽量不要并行运行hbck服务。在0.90.4以前的hbck会有一些机率使hbase宕机。另外为了确保hdfs的安全性，需要定期运行fsck等以检查hdfs的状态，如block的replica数量等。　　我们会每天根踪所有线上服务器的日志，将错误日志全部找出来并且邮件给开发人员，以查明每一次error以上的问题原因和fix。直至错误降低为0。另外每一次的hbck结果如果有问题也会邮件给开发人员以处理掉。尽管并不是每一次error都会引发问题，甚至大部分error都只是分布式系统中的正常现象，但明白它们问题的原因是非常重要的。　　5 测试与发布　　因为是未知的系统，我们从一开始就非常注重测试。测试从一开始就分为性能测试和功能测试。性能测试主要是注意基准测试，分很多场景，比如不同混合读写比例，不同k/v大小，不同列族数，不同命中率，是否做presharding等等。每次运行都会持续数小时以得到准确的结果。因此我们写了一套自动化系统，从web上选择不同的场景，后台会自动将测试参数传到各台服务器上去执行。由于是测试分布式系统，因此client也必须是分布式的。　　我们判断测试是否准确的依据是同一个场景跑多次，是否数据，以及运行曲线达到99%以上的重合度，这个工作非常烦琐，以至于消耗了很多时间，但后来的事实证明它非常有意义。因为我们对它建立了100%的信任，这非常重要，比如后期我们的改进哪怕只提高2%的性能也能被准确捕捉到，又比如某次代码修改使compact队列曲线有了一些起伏而被我们看到，从而找出了程序的bug，等等。　　功能测试上则主要是接口测试和异常测试。接口测试一般作用不是很明显，因为hbase本身的单元测试己经使这部分被覆盖到了。但异常测试非常重要，我们绝大部分bug修改都是在异常测试中发现的，这帮助我们去掉了很多生产环境中可能存在的不稳定因素，我们也提交了十几个相应的patch到社区，并受到了重视和commit。分布式系统设计的难点和复杂度都在异常处理上，我们必须认为系统在通讯的任何时候都是不可靠的。某些难以复现的问题我们会通过查看代码大体定位到问题以后，在代码层面强行抛出异常来复现它。事实证明这非常有用。　　为了方便和快速定位问题，我们设计了一套日志收集和处理的程序，以方便地从每台服务器上抓取相应的日志并按一定规律汇总。这非常重要，避免浪费大量的时间到登录不同的服务器以寻找一个bug的线索。　　由于hbase社区在不停发展，以及线上或测试环境发现的新的bug，我们需要制定一套有规律的发布模式。它既要避免频繁的发布引起的不稳定，又要避免长期不发布导致生产版本离开发版本越来越远或是隐藏的bug爆发。我们强行规定每两周从内部trunk上release一个版本，该版本必须通过所有的测试包括回归测试，并且在release后在一个小型的集群上24小时不受甘扰不停地运行。每个月会有一次发布，发布时采用最新release的版本，并且将现有的集群按重要性分级发布，以确保重要应用不受新版本的潜在bug影响。事实证明自从我们引入这套发布机制后，由发布带来的不稳定因素大大下降了，并且线上版本也能保持不落后太多。　　6 改进和优化　　Facebook是一家非常值得尊敬的公司，他们毫无保留地对外公布了对hbase的所有改造，并且将他们内部实际使用的版本开源到了社区。facebook线上应用的一个重要特点是他们关闭了split，以降低split带来的风险。与facebook不同，淘宝的业务数据量相对没有如此庞大，并且由于应用类型非常丰富，我们并们并没有要求用户强行选择关闭split，而是尽量去修改split中可能存在的bug。到目前为止，虽然我们并不能说完全解决了这个问题，但是从0.90.2中暴露出来的诸多跟split以及宕机相关的可能引发的bug我们的测试环境上己经被修复到接近了0，也为社区提交了10数个稳定性相关的patch，比较重要的有以下几个：　　https://issues.apache.org/jira/browse/HBASE-4562　　https://issues.apache.org/jira/browse/HBASE-4563　　https://issues.apache.org/jira/browse/HBASE-5152　　https://issues.apache.org/jira/browse/HBASE-5100　　https://issues.apache.org/jira/browse/HBASE-4880　　https://issues.apache.org/jira/browse/HBASE-4878　　https://issues.apache.org/jira/browse/HBASE-4899　　还有其它一些，我们主要将patch提交到0.92版本，社区会有commitor帮助我们backport回0.90版本。所以社区从0.90.2一直到0.90.6一共发布了5个bugfix版本后，0.90.6版本其实己经比较稳定了。建议生产环境可以考虑这个版本。　　split这是一个很重的事务，它有一个严重的问题就是会修改meta表(当然宕机恢复时也有这个问题)。如果在此期间发生异常，很有可能meta表、rs内存、master内存以及hdfs上的文件会发生不一致，导致之后region重新分配时发生错误。其中一个错误就是有可能同一个region被两个以上的regionserver所服务，那么就可能出现这一个region所服务的数据会随机分别写到多台rs上，读取的时候也会分别读取，导致数据丢失。想要恢复原状，必须删除掉其中一个rs上的region，这就导致了不得不主动删掉数据，从而引发数据丢失。　　前面说到慢响应的问题归纳为网络原因、gc问题、命中率以及client的反序列化问题。网络原因一般是网络不稳定引起的，不过也有可能是tcp参数设置问题，必须保证尽量减少包的延迟，如nodelay需要设置为true等，这些问题我们通过tcpdump等一系列工具专门定位过，证明tcp参数对包的组装确实会造成慢连接。gc要根据应用的类型来，一般在读比较多的应用中新生代不能设置得太小。命中率极大影响了响应的时间，我们会尽量将version数设为1以增加缓存的容量，良好的balance也能帮助充分应用好每台机器的命中率。我们为此设计了表级别的balance。　　由于hbase服务是单点的，即宕机一台，则该台机器所服务的数据在恢复前是无法读写的。宕机恢复速度决定了我们服务的可用率。为此主要做了几点优化。首先是将zk的宕机发现时间尽量缩短到1分钟，其次改进了master恢复日志为并行恢复，大大提高了master恢复日志的速度，然后我们修改了openhandler中可能出现的一些超时异常，以及死锁，去掉了日志中可能发生的open…too long等异常。原生的hbase在宕机恢复时有可能发生10几分钟甚至半小时无法重启的问题己经被修复掉了。另外，hdfs层面我们将socket.timeout时间以及重试时间也缩短了，以降低datanode宕机引起的长时间block现象。　　hbase本身读写层面的优化我们目前并没有做太多的工作，唯一打的patch是region增加时写性能严重下降的问题。因为由于hbase本身良好的性能，我们通过大量测试找到了各种应用场景中比较优良的参数并应用于生产环境后，都基本满足需求。不过这是我们接下来的重要工作。　　7 将来计划　　我们目前维护着淘宝内基于社区0.90.x而定制的hbase版本。接下来除继续fix它的bug外，会维护基于0.92.x修改的版本。之所以这样，是因为0.92.x和0.90.x的兼容性并不是非常好，而且0.92.x修改掉的代码非常多，粗略统计会超过30%。0.92中有我们非常看重的一些特性。　　0.92版本改进了hfile为hfileV2，v2版本的特点是将索引以及bloomfilter进行了大幅改造，以支持单个大hfile文件。现有的HFile在文件大到一定程度时，index会占用大量的内存，并且加载文件的速度会因此下降非常多。而如果HFile不增大的话，region就无法扩大，从而导致region数量非常多。这是我们想尽量避免的事。　　0.92版本改进了通讯层协议，在通讯层中增加了length，这非常重要，它让我们可以写出nio的客户端，使反序列化不再成为影响client性能的地方。　　0.92版本增加了coprocessor特性，这支持了少量想要在rs上进行count等的应用。　　还有其它很多优化，比如改进了balance算法、改进了compact算法、改进了scan算法、compact变为CF级别、动态做ddl等等特性。　　除了0.92版本外，0.94版本以及最新的trunk(0.96)也有很多不错的特性，0.94是一个性能优化版本。它做了很多革命性工作，比如去掉root表，比如HLog进行压缩，replication上支持多个slave集群，等等。　　我们自己也有一些优化，比如自行实现的二级索引、backup策略等都会在内部版本上实现。　　另外值得一提的是hdfs层面的优化也非常重要，hadoop-1.0.0以及cloudera-3u3的改进对hbase非常有帮助，比如本地化读、checksum的改进、datanode的keepalive设置、namenode的HA策略等。我们有一支优秀的hdfs团队来支持我们的hdfs层面工作，比如定位以及fix一些hdfs层面的bug,帮助提供一些hdfs上参数的建议，以及帮助实现namenode的HA等。最新的测试表明，3u3的checksum+本地化读可以将随机读性能提升至少一倍。　　我们正在做的一件有意义的事是实时监控和调整regionserver的负载，能够动态地将负载不足的集群上的服务器挪到负载较高的集群中，而整个过程对用户完全透明。　　总的来说，我们的策略是尽量和社区合作，以推动hbase在整个apache生态链以及业界的发展，使其能更稳定地部署到更多的应用中去，以降低使用门槛以及使用成本。
原文出处：/?p=57
DBMS是现代化应用的核心，选择合适的数据库技术将会对IT项目成败起到决定性的作用。本文介绍了不同类型的数据库产品与其应用场景。
《DBA修炼之道：数据库管理员的第一本书》作者克雷格·穆林斯接受了TechTarget的独家专访，探讨了DBA在过去几年中的角色变化。
《DBA修炼之道：数据库管理员的第一本书》作者克雷格·穆林斯与TechTarget记者探讨了DBA的生存法则。
SSL通过加密网络防止有针对性的监听。在与正确的服务器进行交互时，可以有效应对中间人攻击。本文介绍了不同的使用MySQL数据库的SSL配置方法。
如果随着数据的增殖，类似电子取证和记录管理的流程变得更加冗长繁琐和昂贵，那么它们也就变得更加重要。
TechTarget中国官方微信
要成为一名DBA，你需要具备哪些素质？DBA的薪酬待遇如何？DBA的职业道路究竟可以走向何方？我们将在本次的技术手册中为您一一解答。
本专题为QL&SELECT语句基础。侧重概述了如何使用SELECT来访问SQL数据库中所有内容以及组成SELECT语句的许多子句名称和功能；同时还阐述了如何使用DISTINCT关键字消除重复的行，以及如何正确使用ORDER&BY子句来排序数据。
本技术专题主要围绕sql server设计这个话题展开，侧重介绍了sql server集簇索引的设计、如何创建sql server索引、如何优化索引、索引的能与不能、处理sql server 2000索引碎片技巧以及维护sql server索引以实现查询优化等等。
在本次技术手册中，我们将对SQL&Server存储过程的调试进行详细的介绍，包括了基础的调试方法和在调试过程中出现的T-SQL性能问题和解决方法。
微软最新的数据库管理平台SQL Server 2008 R2正式发布已经有半年多的时间了，虽然真正部署的用户并不多，但是有许多企业已经在筹划将SQL Server迁移到R2平台了。