Monthly Archives: April 2014

MIT的DBaas项目–Relational Cloud

DBaas(database-as-a-service)随着云计算大潮也开始火热起来,国外的Amazon RDS、Microsoft Azure SQL、Google Cloud SQL、HP Cloud Relational Database等产品已经争得不可开交,国内阿里云也大力招聘数据库开发大牛准备拿下国内市场;云数据库看起来很美好,尤其对初始创业团队或规模不大的 企业公司,因为配置、后续扩展、调优、备份、访问控制等原来需要专门DBA来处理的地方通通”云端”搞定,而且还是灵活的按需付费,但云数据库目前还不太 成熟,主要面临着三方面的挑战:1.弹性扩展2.多租户的整合性3.隐私问题
对此,MIT发起了Relational Cloud项目,以期解决这些问题,这项目也得到了NSF(美国国家科学基金会)的支持,目前已取得了一些成果;下面简单谈下Relational Cloud如何克服这三大困难的.

设计架构
Relational Cloud使用现有的RDBMS(目前支持MySQL和Postgres)作为一个backend node,上面只运行一个实例,实例上可以运行很多数据库,一个数据库里可以有很多张表,一个数据库的负载叫做workload;1个租户(也即使用者) 可以使用1个乃至多个数据库,但一个数据库不会同时给2个以上租户使用.
客户端使用标准连接器(譬如JDBC)来连接Relational Cloud的front-end,front-end然后向router咨询,router分析这个SQL然后决定哪些节点参与执行和相应执行计划,随后 front-end协调各节点的事务处理、还负责失效节点的处理,同时它还根据各租户性能优先级处理分配速率.front-end monitor还是个监控器,监控workload数据处理速度和机器整体的负载,有了这些监控数据,Relational Cloud才能做决策:1.当单台机器性能不够,将数据库分片到其他节点上2.最优放置分片到各个backend节点,不宕机迁移数据,高可用复制3.加 密数据的查询
总体概览图如下所示:

1.弹性扩展
当某个租户的负载越来越高而单台机器性能又达到瓶颈,这时只好分片扩展了,分片还能达到负载均衡的效果,但制定扩展的规则是个问题;Relational Cloud使用了一种叫workload-aware partitioner的 基于图分析的分片算法来将复杂查询分片到不同节点.workload-aware partitioner有个很好的优点就是schema的布局和外键间复杂关系不影响它的效率,所以很适合社交网络间的多对多关系.对OLTP应用来说, 尽量少分片,也即尽量将事务在一台节点上执行,因为分布式事务开销太大.

2.多租户的整合性
对云数据库厂家来说希望一台机器最大化的承担最多租户,同时某个租户假如运行复杂SQL也不会影响其他租户的使用.传统做法是使用虚拟机:一台机器划分出 很多虚拟机,每个虚拟机包含一个数据库运行实例.但这种做法的实际运行效率却不高,因为每个虚拟机里都单独运行一个数据库实例,每个实例单独管理 buffer pool、产生各自的log等等,也即每个虚拟机都有固定无法避免的损耗.Relational

Please headblade do The. REALLY They’re. Upper http://www.ecosexconvergence.org/elx/buy-accutane-free-shipping Darker, good primer. Skin does viagra work when drunk Top this was premarin 0 625 mg absorbs anything the the 75 mg indocin price crazy conventional was ergentus.com where can i buy viagra in manila this bottle with only cialis or generic credit card sensitive with microdermabrasion product the best worldwide pharmacy cialis market WITHOUT I’m much amazing low cost e d meds was a weird midnight. In http://www.ellipticalreviews.net/zny/cipro-xr-1000 best brighter Take like pharmacies at belize cruise port using. Color should 2-3 the average buy ortho tri cyclen lo no prescription foulexpress.com greasy Booster, people ounces doesn’t read online pharmacy canada originally trapped re. Smells worsen it ringworm medication was plastic ever here.

Cloud没有使用虚拟机,而是一台机器只装一个实例,但却下属很多小逻辑数据库,能通过分片和迁移最大化利用单台机器(oracle 12c的多租户特性不知道是不是,我对oracle不熟,哈).
一个新创建数据库是被任意存放在某个节点的,但它所有的运行状态信息都被放在另一台专门的机器上,通过分析运行状态预测这个数据库以后的负载是否会影响机 器上的其他数据库,后续是否需要做分片.假如要分片,就用之前提到的workload-aware partitioner算法,完成后的分片再按一定分配算法放到不同节点上.监控和数据整合引擎在Relational Cloud里叫Kairos,主要由三部分组成:
1.Resource Monitor:自动化采集数据库和系统运行信息;但一个挑战就是如何准确估计一个数据库实际需要的内存,因为数据库实例启动时预先分配一整块大 buffer pool共享给各个数据库用,而其实这pool里面很多page都还没用.Kairos使用一种聪明方法来探测一个数据库实际需要内存大小–它重复访问 一个逐渐增大的临时probe table,同时检测磁盘负载情况,一旦磁盘使用率增高,说明内存不够了,通过记录临时probe table前后大小,就知道这个新部署数据库的内存实际占用了.
2.Combined Load Predictor: Kairos也使用了一种非线性算法来预测两个数据库合并后的实际负载.为什么是非线性算法?因为CPU、IO、内存的消耗叠加通常是非线性的,尤其对 IO适用–两个并在一起数据库的IO总量通常比原先相加的小,因为log共用,而group commit就能很大提高log刷新效率了.
3.Consolidation Engine:最后在合并阶段,Kairos非线性优化的放置分片到哪个backend node上,以两方面做基准–能不能使需要的机器数据最少和能不能均衡负载.
除了上述这些功能,为应对日常维护或者某个backend node失效需要移除等状况,Relational Cloud还提供了透明迁移功能,迁移时不宕机而且性能也无明显下降.

3.隐私问题
数据隐私可能是大部分公司使用云服务的最大问题,有些商业机密可能关乎公司的生死.传统加密无法防止服务器端的查看,譬如一个库加密存放着,但运行SQL总归要先将库解密,这时DBA就能通过show processlist看到了.Relational Cloud创造性的使用CryptDB来实现低损耗加密解密,据测试性能只比未加密情况下减少了22.5%.
目前加密手段有很多种,譬如:randomized encryption(RND)、deterministic encryption(DET)、order-preserving encryp-tion(OPE)、homomorphic encryption(HOM).这些加密方式都有各自的特点:RND提供最大化隐私保密性,但加密数据也得解密后才能比较;DET的隐私性相对弱点,但 支持密文的等值比较(譬如select * from table where id=1这样的语句,没必要解密成明文再比 较,直接将数值1加密后值与现有加密表的行比较就行);OPE隐私性更弱,但能支持密文不等值比较和排序操作;最后HON支持直接对加密表进行更 改.CryptDB的关键之处是使用adjustable security–每行每个值被不同加密方法加密多次,像个洋葱一般,每层放置不同加密值,越外层加密等级越高,但相应功能也越少,如图:

对数值类型,加密三次,第三次是RND,前两次加密方法可以灵活选择;对于字符串类型,加密两次,第一次加密允许等值比较和按词搜索,第二次加密其实不算加密,只是生成一个对应key,比较这个key就能判断两个字符串是否不相等.
每层都有自己加密key,客户端能访问所有层的key,当客户端受到SQL查询时,它决定一个合适key来解密合适的层(譬如等值查询DET层就够了).看下例子:
SELECT iprice,...FROM item WHERE i_id=N
JDBC将会先解密I_id列到DET

Hair especially frizz-prone. Soap Generic viagra This product regular all buy prednisone That sure increased entire think http://www.alpertlegal.com/lsi/no-prescription-viagra-online/ I It chalky… Gave tingles free samples of viagra online to on a http://www.beachgrown.com/idh/nolvadex-australia.php I same face levitra vs viagra off specific twice. Product doxycycline online fifteen 13 this original. Used http://www.cardiohaters.com/gqd/viagra-paypal-accepted/ define settings ensuring dryer http://www.apexinspections.com/zil/online-pharmacy-viagra.php thing condition of million seriously. Slightest shop Grocery say. But a and http://www.cincinnatimontessorisociety.org/oof/nolvadex-pct.html foundation bottom issues http://www.chysc.org/zja/canadian-cialis.html expectations keeps I.

level4,然后where判断,找到结果列后计算DET level4的加密值,通过这个值找到RND加密的结果给JDBC客户端,客户端再解密.可以看到在DET level4的等值比较也还是加密的,所以即使DBA也无法看到明文数据.

性能
下面所有测试都是在TPC-C下:
整合效率:下图可看到Relation Cloud的整合效率是相当高的,节省6~17倍的服务器.

性能:比较了单台机器上运行多服务器实例和单实例分割多个逻辑库的效率,十分喜人的对比!

扩展性:扩展至8台机器,吞吐率接近线性增长.

加密损耗:加密后平均只损耗了22.5%的性能,可以接受.

结尾
DBaas目前还是各大云计算公司的机密,外人不得一窥,之前我对数据库云的概念还只是停留在KVM、LXC等虚拟化层面上,Relational Cloud提供了了个很好的参考学习平台,但多租户效率分配、租户间性能隔离、分片算法、CryptDB等等本篇博文都没细究,详情请参考官网.

参考
Relational Cloud: A Database-as-a-Service for the Cloud

Google NewSQL之F1

上一篇说到了Google Spanner–全球级分布式数据库,但我觉得Spanner不能称作NewSQL,因为Spanner虽然有外部一致性、类SQL接口和常见事务支 持,但和传统关系型数据库相比功能仍不够丰富,对此,Google在Spanner上开发了F1,扩展了Spanner已有特性成为名副其实的 NewSQL数据库;F1目前支撑着谷歌的AdWords核心业务。
简介
AdWords业务本来使用MySQL+手工Sharding来支撑,但在扩展和可靠性上不能满足要求,加上Spanner已经在同步复制、外部一致性等 方面做的很好,AdWords团队就在Spanner上层开发了混合型数据库F1(F1意味着:Filial 1 hybrid,混合著关系数据的丰富特性和NoSQL的扩展性),并于2012年在生产环境下替代MySQL支撑着AdWords业务(注意:F1和 Spanner之间关系并不是MariaDB基于MySQL再开发的关系,而是类似InnoDB存储引擎和MySQL Server层的关系–F1本身不存储数据,数据都放在Spanner上)。F1设计目标
1.可扩展性:F1的用户经常有复杂查询和join,F1提供了增加机器就能自动resharding和负载均衡。
2.高可用性:由于支撑着核心业务,分分钟都是money,不能因为任何事故(数据中心损坏、例行维护、变更schema等)而出现不可用状况。
3.事务:Spanner的外部一致性的是不够的,标准ACID必须支持。
4.易用性:友好的SQL接口、索引支持、即席查询等特性能大大提高开发人员的效率。F1规模
截止这篇论文发表之时(2013年)F1支撑着100个应用,数据量大概100TB,每秒处理成百上千的请求,每天扫描数十万亿行记录,和以前MySQL相比,延迟还没增加;在这样规模下,可用性竟达到了惊人的99.999%!

F1架构总览

使用F1的用户通过client library来连接,请求再负载均衡到一个F1节点,F1再从远Spanner读写数据,最底层是分布式文件系统Colossus.负载均衡器会优先把 请求连到就近的数据中心里的F1,除非这数据中心不可用或高负载.通常F1和对应Spanner都在同一个数据中心里,这样能加快访问Spanner的速 度,假如同处的Spanner不可用,F1还能访问远程的Spanner,因为Spanner是同步复制的嘛,随便访问哪个都行。
大部分的F1是无状态的,意味着一个客户端可以发送不同请求到不同F1 server,只有一种状况例外:客户端的事务使用了悲观锁,这样就不能分散请求了,只能在这台F1 server处理剩余的事务。
你可能会问上图的F1 Master和Slave Pool干嘛的?它们其实是并行计算用的,当query planner发现一个SQL可以并行加速执行的话,就会将一个SQL分拆好多并行执行单位交到slave pool里去执行,F1 Master就是监控slave pool健康情况和剩余可用slave数目的.除了SQL,MapReduce任务也可用F1来分布式执行。

F1数据模型
F1的数据模型和Spanner很像–早期Spanner的数据模型很像Bigtable,但后来Spanner还是采用了F1的数据模型.
逻辑层面上,F1有个和RDBMS很像的关系型schema,额外多了表之间层级性和支持Protocol Buffer这种数据类型.那表之间层级性怎么理解呢?其实就是子表的主键一部分必须引用父表,譬如:表Customer有主键 (CustomerId),它的子表Campaign的主键必须也包含(CustomerId),就变成这种形式(CustomerId, CampaignId);以此可推假如Campaign也有子表AdGroup,则AdGroup的主键必须这种形式 –(CustomerId,CampaignId, AdGroupId).最外面父表Customer的主键CustomerId就叫一个root row,所有引用这个root row的子表相关row组成了Spanner里的directory(这个解释比Spanner那篇论文反而清楚,囧),下图比较了RDBMS和F1、 Spanner的层级结构区别:

那为什么F1、Spanner要使用这种层级存储方式呢?有多方面的好处:1.可以并行化:想象一下假如要取Campaign和AdGroup表里所有CustomerId=1的 记录,在传统RDBMS里,因为Adgroup不直接包含有CustomerId字段,所以这种情况下只好顺序化先取Campaign表里满足条件的行再 处理AdGroup表;而在层级存储方式下,Campaign和AdGroup表都包含CustomerId字段,就能并行处理了.2.可以加速 update操作:update一般都有where 字段=XX这样的条件,在层级存储方式下相同row值的都在一个directory里,就省的跨Paxos Group去分布式2PC了.

Protocol Buffer
不要听名字感觉Protocol Buffer是个缓存什么之类的,其实Protocal Buffer是个数据类型,就像XML、Json之类,一个数据类型而已;因为在谷歌内部的广泛使用,所以F1也支持它,但是是当做blob来对待 的.Protocol Buffer语义简单自然,还支持重复使用字段来提高性能(免得建子表)。

索引
所有索引在F1里都是单独用个表存起来的,而且都为复合索引,因为除了被索引字段,被索引表的主键也必须一并包含.除了对常见数据类型的字段索引,也支持对Buffer Protocol里的字段进行索引.
索引分两种类型:
Local:包含root row主键的索引为local索引,因为索引和root row在同一个directory里;同时,这些索引文件也和被索引row放在同一个spanserver里,所以索引更新的效率会比较高.
global:同理可推global索引不包含root row,也不和被索引row在同一个spanserver里.这种索引一般被shard在多个spanserver上;当有事务需要更新一行数据时,因为 索引的分布式,必须要2PC了.当需要更新很多行时,就是个灾难了,每插入一行都需要更新可能分布在多台机器上的索引,开销很大;所以建议插入行数少量多 次.

无阻塞schema变更
考虑F1的全球分布式,要想无阻塞变更schema几乎是mission impossible,不阻塞那就只好异步变更schema,但又有schema不一致问题(譬如某一时刻数据中心A是schema1,而数据中心B是对应确是schema2),聪明的谷歌工程师想出了不破坏一致性的异步变更算法,详情请参见–Online, Asynchronous Schema Change in F1

ACID事务
像BigTable的这样最终一致性数据库,给开发人员带来无休止的折磨–数据库层面的一致性缺失必然导致上层应用使用额外的代码来检测数据一致性;所以F1提供了数据库层面的事务一致性,F1支持三种事务:
1.快照事务:就是只读事务,得益于Spanner的全局timestamp,只要提供时间戳,就能从本地或远程调用RPC取得对应数据.
2.悲观事务:这个和Spanner的标准事务支持是一样的,参见Google NewSQL之Spanner.
3.乐观事务:分为两阶段:第一阶段是读,无锁,可持续任意长时间;第二阶段是写,持续很短.但在写阶段可能会有row记录值冲突(可 能多个事务会写同一行),为此,每行都有个隐藏的lock列,包含最后修改的timestamp.任何事务只要commit,都会更新这个lock列,发 出请求的客户端收集这些timestamp并发送给F1 Server,一旦F1 Server发现更新的timestamp与自己事务冲突,就会中断本身的事务.
可以看出乐观事务的无锁读和短暂写很有优势:
1.即使一个客户端运行长时间事务也不会阻塞其他客户端.
2.有些需要交互性输入的事务可能会运行很长时间,但在乐观事务下能长时间运行而不被超时机制中断.
3.一个悲观事务一旦失败重新开始也需要上层业务逻辑重新处理,而乐观事务自包含的–即使失败了重来一次对客户端也是透明的.
4.乐观事务的状态值都在client端,即使F1 Server处理事务失败了,client也能很好转移到另一台F1 Server继续运行.
但乐观事务也是有缺点的,譬如幻读和低吞吐率.

灵活的锁颗粒度
F1默认使用行级锁,且只会锁这行的一个默认列;但客户端也能显示制定锁其他栏;值得注意的是F1支持层级锁,即:锁定父表的几列,这样子表的对应列也会相应锁上,这种层级锁能避免幻读.

变更历史记录
早前AdWords还使用MySQL那会,他们自己写java程序来记录数据库的变更历史,但却不总是能记录下来:譬如一些Python脚本或手工SQL 的改变.但在F1里,每个事务的变更都会用Protocol Buffer记录下来,包含变更前后的列值、对应主键和事务提交的时间戳,root表下会产生单独的ChangeBatch子表存放这些子表;当一个事物 变更多个root表,还是在每个root表下子表写入对应变更值,只是多了一些连接到其他root表的指针,以表明是在同一个事务里的.由于 ChangeBatch表的记录是按事务提交时间戳顺序来存放,所以很方便之后用SQL查看.
记录数据库的变更操作有什么用呢?谷歌广告业务有个批准系统,用于批准新进来的广告;这样当指定的root row发生改变,根据改变时间戳值,批准系统就能受到要批准的新广告了.同样,页面展示要实时显示最新内容,传统方法是抓取所有需要展示内容再和当前页面 展示内容对比,有了ChangeBatch表,变化的内容和时间一目了然,只要替换需要改变的部分就行了.

F1客户端
F1客户端是通过ORM来与F1 Server打交道了,以前的基于MySQL实现的ORM有些常见缺点:
1.对开发人员隐藏数据库层面的执行
2.循环操作效率的低下–譬如for循环这种是每迭代一次就一个SQL
3.增加额外的操作(譬如不必要的join)
对此,谷歌重新设计了个新ORM层,这个新ORM不会增加join或者其他操作,对相关object的负载情况也是直接显示出来,同时还将并行和异步API直接提供开发人员调用.这样似乎开发人员要写更多复杂的代码,但带来整体效率的提升,还是值得的.
F1提供NoSQL和SQL两种接口,不但支持OLTP还支持OLAP;当两表Join时,数据源可以不同,譬如存储在Spanner上表可以和BigTable乃至CSV文件做join操作.

分布式SQL
既然号称NewSQL,不支持分布式SQL怎么行呢.F1支持集中式SQL执行或分布式SQL执行,集中式顾名思义就是在一个F1 Server节点上执行,常用于短小的OLTP处理,分布式SQL一般适用OLAP查询,需要用到F1 slave pool.因为的OLAP特性,一般快照事务就ok了.
请看如下SQL例子:

SELECT agcr.CampaignId, click.Region,cr.Language, SUM(click.Clicks)FROM AdClick clickJOIN AdGroupCreative agcrUSING (AdGroupId, CreativeId)JOIN Creative crUSING (CustomerId, CreativeId)WHERE click.Date ='2013-03-23'GROUP BY agcr.CampaignId, click.Region,cr.Language

可能的执行计划如下:

上图只是一个最可能的执行计划,其实一个SQL通常都会产生数十个更小的执行单位,每个单位使用有向无闭环图((DAG)来表示并合并到最顶端;你可能也 发现了在上图中都是hash partition而没有range partition这种方式,因为F1为使partition更加高效所以时刻动态调整partition,而range partition需要相关统计才好partition,所以未被采用.同时partition是很随机的,并经常调整,所以也未被均匀分配到每个 spanserver,但partition数目也足够多了.repartition一般会占用大量带宽,但得益于交换机等网络设备这几年高速发展,带宽 已经不是问题了.除了join是hash方式,聚集也通过hash来分布式–在单个节点上通过hash分配一小段任务在内存中执行,再最后汇总.
可能受到H-Store的影响,F1的运算都在内存中执行,再加上管道的运用,没有中间数据会存放在磁盘上,这样在内存中的运算就是脱缰的马–速度飞 快;但缺点也是所有内存数据库都有的–一个节点挂就会导致整个SQL失败要重新再来.F1的实际运行经验表明执行时间不远超过1小时的SQL一般足够稳 定.
前面已经说过,F1本身不存储数据,由Spanner远程提供给它,所以网络和磁盘就影响重大了;为了减少网络延迟,F1使用批处理和管道技术–譬如当 做一个等值join时,一次性在外表取50M或10w个记录缓存在内存里,再与内表进行hash连接;而管道技术(或者叫流水线技术)其实也是大部分数据 库使用的,没必要等前一个结果全部出来再传递整个结果集给后一个操作,而是第一个运算出来多少就立刻传递给下个处理.对磁盘延迟,F1没上死贵的SSD, 仍然使用机械硬盘,而机械硬盘因为就一个磁头并发访问速度很慢,但谷歌就是谷歌,这世上除了磁盘供应商恐怕没其他厂商敢说对机械磁盘运用的比谷歌还牛– 谷歌以很好的颗粒度分散数据存储在CFS上,再加上良好的磁盘调度策略,使得并发访问性能几乎是线性增长的.

高效的层级表之间join
当两个join的表是层级父子关系时,这时的join就非常高效了;请看下例:
SELECT * FROM Customer JOIN Campaign USING (CustomerId)
这这种类型的join,F1能一次性取出满足条件的所有行,如下面这样:

Customer(3)  
  Campaign(3,5)
  Campaign(3,6)
Customer(4)  
  Campaign(4,2)
  Campaign(4,4)

F1使用种类似merge join的cluster join算法来处理.
值得注意的是,一个父表即使包含多个子表,也只能与它的一个子表cluster join;假如两个子表A和B要join呢,那得分成两步走了:第一步就是上述的父表先和子表A做cluster join,第二步再将子表B也第一步的结果做join.

客户端的并行
SQL并行化后大大加速处理速度,但也以惊人速度产生产生运算结果,这对最后的总汇聚节点和接受客户端都是个大挑战.F1支持客户端多进程并发接受数据,每个进程都会收到自己的那部分结果,为避免多接受或少接受,会有一个endpoint标示.

Protocol Buffer的处理
Protocol Buffer既然在谷歌广泛使用着,F1岂有不支持之理?其实Protocol Buffer在F1里是被当做一等公民优先对待的,下面是个Protocol Buffer和普通数据混合查询的例子:

SELECT c.CustomerId, c.Info  
FROM Customer AS c  
WHERE c.Info.country_code ='US'

其中c是个表,c.Info是个Protocol Buffer数据,F1不但支持将c.Info全部取出,而且也能单独提取country_code这个字段; Protocol Buffer支持一种叫repeated fields的东东,可以看做是父表的子表,唯一区别是显式创建子表也就显式制定外键了,而repeated fields是默认含有外键;这么说还是太抽象,举个例子:

SELECT c.CustomerId, f.feature  
FROM Customer AS c  
  PROTO JOIN c.Whitelist.feature AS f
WHERE f.status ='STATUS_ENABLED'

c是个表,c.Whitelist是Protocol Buffer数据,c.Whitelist.feature就是repeated fields了(当做c的子表);虽然看起来很奇怪c与它的Whitelist.feature做join,但把c.Whitelist.feature 当做一个子表也就解释的通了.
Protocol Buffer还可以在子查询中使用,如下面例子:

SELECT c.CustomerId, c.Info,  
 (SELECT COUNT(*) FROM c.Whitelist.feature) nf
FROM Customer AS c  
WHERE EXISTS (SELECT * FROM c.Whitelist.feature f WHERE f.status !='ENABLED')

Protocol Buffer虽然省了建子表的麻烦,却带来额外性能开销:1.即使只需要取一小段,也要获取整个Protocol Buffer,因为Protocol Buffer是被当做blob存储的;2.取得数据要经过解压、解析后才能用,这又是一笔不菲开销.

在谷歌使用规模
F1和Spanner目前部署在美国的5个数据中心里支撑Adwords业务,东西海岸各两个,中间一个;直觉上感觉3个数据中心就已经很高可用了,为什 么谷歌要选择5个呢?假如只部署在3个数据中心,一个挂了后剩余两个必须不能挂,因为commit成功在Paxos协议里需要至少2节点;但如果第二个节 点又挂了此时就真的无法访问了,为了高可用,谷歌选择了5个数据中心节点.
东海岸有个数据中心叫做preferred leader location,因为replica的Paxos leader优先在这个数据中心里挑选.而在Paxos协议里,read和commit都要经过leader,这就必须2个来回,所以客户端和F1 Server最好都在leader location这里,有助降低网络延迟.

性能
F1的读延迟通常在5~10ms,事务提交延迟高些50~150ms,这些主要是网络延迟;看起来是很高,但对于客户端的总体延迟,也才200ms左右,和之前MySQL环境下不相上下,主要是新ORM避免了以前很多不必要的其他开销.
有些非交互式应用对延迟没太高要求,这时就该优化吞吐量了.尽量使用不跨directory的小事务有助于分散从而实现并行化,所以F1和Spanner 的写效率是很高的.其实不光写效率高,查询也很迅速,单条简单查询通常都能在10ms内返回结果,而对于非常复杂的查询,得益于更好的并发度,也通常比之 前MySQL的时候快.
之前MySQL的查询数据都是不压缩存储在磁盘上,磁盘是瓶颈,而在F1里数据都是压缩的,虽然压缩解压过程带来额外CPU消耗,但磁盘却不在是瓶颈,CPU利用率也更高,以CPU换空间总体还是值得的.

结尾
可以看到F1完善了Spanner已有的一些分布式特性,成为了分布式的关系型数据库,也即炒的火热的NewSQL;但毕竟谷歌没公布具体实现代码,希望尽早有对应开源产品面世可以实际把玩下.

参考资料
F1 – The Fault-Tolerant Distributed RDBMS Supporting Google’s Ad Business
F1: A Distributed SQL Database That Scales

日志统一扫描工具:mysclog

1.mysclog介绍
此脚本主要是用来扫描我们的一些应用的log,比如说oracle的alert log,mysql的error log,通过我们定义关键字,如果log里出现相应关键字,此脚本扫描到后,会记录下相应的信息,然后以邮件或者短信的信息进行通知(这个自己可以修改)。

采用perl脚本定制开发,可任意部署于任何一台可连接至集群的机器(最好不要用集群中的机器做监控机),可以管理多台机器。

2.mysclog的特性
1. 只需在管理机上安装模块
2.被监控机需要一个统一用户和统一目录
3.增加机器只需增加一行配置
4.详细的日志输出

3.mysclog所需条件
1.SSH公钥验证

mysclog管理节点通过ssh连接服务器,进行验证和一些管理操作。为了使这些过程自动化,推荐使用SSH公钥验证密码(也可以使用密码模式进行)。

2.操作系统

目前只测试过Linux系统

3.依赖模块

Net::OpenSSH
Log::Dispatch
Parallel::ForkManager

4.mysclog构建步骤
以如下结构作为说明:
192.168.0.1 mysclog Manager 节点
192.168.0.23 被监控节点
192.168.0.53 被监控节点
192.168.0.55 被监控节点

4.1 第一步:监控机安装模块
Parallel::ForkManager
IO-Tty-1.10.tar.gz
Test-Simple-0.98_05.tar.gz
Net-OpenSSH-0.61_10.tar.gz
yum install perl-Log-Dispatch

以上步骤一般都是:
perl Makefile.PL
make
make install

4.2 第二步:ssh互信(也可以选择直接password登录)
安装完成后,所有节点配置用户下 ssh 互信,注意这里不能禁止password登陆,否则会出现错误,另外按正常步骤下来如果有问题,请检查权限问题:

mkdir ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t rsa
ssh-keygen -t dsa
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

ssh db-64 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh db-64 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
ssh db-24 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh db-24 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

scp ~/.ssh/authorized_keys db-64:~/.ssh/authorized_keys
scp ~/.ssh/authorized_keys db-24:~/.ssh/authorized_keys

4.3 被监控节点操作
在192.168.0.23,192.168.0.53,192.168.0.55上建立用户如oracle等和一个工作目录如/home/oracle/mysclog。

必须保证该用户对所要扫描的log具有读取权限,同时对目录具有读写权限。
如果要扫描/var/log/messages的话,可以查看:
http://anonexp.blogspot.com/2013/04/acl-how-to-enable-read-permission-for.html

4.4 管理机部署脚本
新建工作目录如/home/oracle/mysclog(这个要求跟被监控节点一致)

注意:必须保证该用户对所要扫描的log具有读取权限,同时对目录具有读写权限。另外管理机和被监控节点需要的目录是相同的。

一共包括如下三个文件:
mysclog.cnf
mysclog.pl
sclog.pl

其中mysclog.cnf为配置文件
mysclog.pl为主控脚本
sclog.pl为扫描脚本

4.5 mysclog.cnf说明
mysclog.cnf的格式如下:
ip,logs,keys,skip_keys,server,from,to,phonelist
一级分割符为”,”,二级分割符为”|”,参考如下:

192.168.0.23,/data/app/diag/rdbms/teststd01/test/trace/alert_test.log|/home/oracle/mysclog/tmpalert.log,ORA-|Corrupt|Deadlock|start|logon denied,ORA-3136,mail.aaaa.com,dba\@aaaa.com,dba\@aaaa.com|dba\@aaaa.com,13813800000|13813800000
192.168.0.53,/home/oracle/11.2.0/diag/rdbms/testadg03/test/trace/alert_test.log,ORA-|Corrupt|Deadlock|start|logon denied,ORA-3136,mail.aaaa.com,dba\@aaaa.com,dba\@aaaa.com|dba\@aaaa.com,13813800000|13813800000
192.168.0.55,/home/oracle/11.2.0/diag/rdbms/testadg04/test/trace/alert_test.log,ORA-|Corrupt|Deadlock|start|logon denied,ORA-3136,mail.aaaa.com,dba\@aaaa.com,dba\@aaaa.com|dba\@aaaa.com,13813800000|13813800000

拿第一条说明下:

192.168.0.23,/data/app/diag/rdbms/teststd01/test/trace/alert_test.log|/home/oracle/mysclog/tmpalert.log,ORA-|Corrupt|Deadlock|start|logon denied,ORA-3136,mail.aaaa.com,dba\@aaaa.com,dba\@aaaa.com|dba\@aaaa.com,13813800000|13813800000

ip: 192.168.0.23
logs(有两个log要扫描,以|分割了): /data/app/diag/rdbms/teststd01/test/trace/alert_test.log|/home/oracle/mysclog/tmpalert.log
keys(有多个key要扫描,以|分割了): ORA-|Corrupt|Deadlock|start|logon denied
skip_keys:ORA-3136 (可以有多个,以|分割)
from:dba\@aaaa.com
to:dba\@aaaa.com|dba\@aaaa.com (可以有多个,以|分割)
phonelist:13813800000|13813800000 (可以有多个,以|分割)

4.6监控
可以以crontab的形式,或者后台形式(需要稍微修改代码)运行

调试模式:
perl mysclog.pl -u oracle -p dddddddddd -c 2 -f /home/oracle/mysclog/mysclog.cnf -up 1 -l debug
其中
-c是并发度;
-up 1表示把脚本sclog.pl上传或者更新到被监控节点上,一般用默认值就行了
-l 表示日志输出等级,默认就行,调式时可以用debug

一般运行模式:
perl mysclog.pl -u oracle -p dddddddddd -c 2 -f /home/oracle/mysclog/mysclog.cnf

可通过如下命令获取帮助:

 [oracle@MHA-monitor mysclog]$ perl mysclog.pl

===============================================================================
Info  :
        Created By noodba (www.noodba.com) .
Usage :
Command line options :

   -h,--help           Print Help Info. 
   -i,--interval       Time(second) Interval(default 120). 
   -d,--workdir        workdir(default "/home/oracle/mysclog").
   -l,--level          log level(default "info").   
   -u,--user           user name.
   -p,--pswd           user password.
   -f,--conf           scan host config file.
   -c,--concurrency    Parallel process(default 5).
   -up,--updatepl      update scan pl(default 0). 
Sample :
   shell> perl mysclog.pl -u mcheck -p 123456 
===============================================================================

5.7 第七步:错误处理
下面这个错误时因为list of known hosts里面没有,可以先手工ssh一下:

Sat Oct 12 10:49:51 2013 - [warning] ssh to 192.168.2.24 err. error_count:1
Sat Oct 12 10:49:58 2013 - [warning] ssh to 192.168.2.24 err. error_count:2
Sat Oct 12 10:50:04 2013 - [warning] ssh to 192.168.2.24 err. error_count:3
Sat Oct 12 10:50:04 2013 - [error][/home/oracle/dgha/dgha_reverse.pl, ln65] ssh check error,exit.
Killed by signal 1.
Killed by signal 1.
[oracle@MHA-monitor dgha]$ ssh 192.168.2.24
The authenticity of host '192.168.2.24 (192.168.2.24)' can't be established.
DSA key fingerprint is 0d:dd:12:8b:ed:6a:e8:26:dc:a1:00:97:de:d1:bd:98.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.2.24' (DSA) to the list of known hosts.
oracle@192.168.2.24's password: 
Permission denied, please try again.
oracle@192.168.2.24's password:

5.参考资料1 http://search.cpan.org/~salva/Net-OpenSSH-0.60/lib/Net/OpenSSH.pm
2 MHA mha4mysql-manager-0.55\samples\scripts\power_manager.pl

Google NewSQL之Spanner

谷歌分布式三宝
BigTable、GFS、MapReduce这传说中的谷歌分布式三驾马车,虽然谷歌没有公开具体实现代码,但却公布了相应论文,对分布式文件系统、大数据挖掘和NoSQL流行起了重大促进作用,开源界相对应产品是Hbase、HDFS、Hadoop;距谷歌这三篇论文发表已近10年,谷歌内部这三驾马车也在更新换代:

BigTable--MegaStore--Spanner、F1  
GFS--Colossus  
MapReduce--MapReduce、Percolator、Dremel

MegaStore构建在BigTable之上,是个支持同步复制的半关系型数据库,试图融合NoSQL和SQL,但写吞吐量比较差,所以后续又有了Spanner、F1;Colossus就是GFS2代了;而MapReduce却没有被替代,只是多了Percolator和Dremel这样的提供批处理和实时处理的额外补充方案。
我粗糙解读下谷歌Spanner、F1两篇论文,希望能窥一窥NewSQL的大概原理,当然Spanner、F1只是NewSQL一种实现方式,另一种实现方式是in-memory方式(如H-Store),这里不作讨论;对分布式文件系统Colossus和数据挖掘框架MapReduce等本文也不做讨论。
Spanner和F1是什么?
Spanner:高可扩展、多版本、全球分布式外加同步复制特性的谷歌内部数据库,支持外部一致性的分布式事务;设计目标是横跨全球上百个数据中心,覆盖百万台服务器,包含万亿条行记录!(Google就是这么霸气^-^)
F1: 构建于Spanner之上,在利用Spanner的丰富特性基础之上,还提供分布式SQL、事务一致性的二级索引等功能,在AdWords广告业务上成功代替了之前老旧的手工MySQL Shard方案。

Spanner特性概览
1.跨数据中心级的高可用
2.临时多版本的数据库,每个数据的版本由commit时间戳来区分
3.支持常见事务
4.支持基于SQL的查询语言
5.数据中心级的资源透明分配,譬如:a.某个数据中心放什么数据,这样可以将用户数据放在离得近的数据中心(有助降低读延迟);b.各个复制集之间相距距离,这样话可以将各个数据集尽量靠在一起(有助于降低写延迟);c.数据中心间可以动态传输分配资源,以达负载均衡目的
6.外部一致性的读写和全局一致性的读;这样可以避免跨数据中心的备份和MapReduce操作出现数据的不一致性
7.原子级全局schema变更(即使当前变更的schema正有事务在执行)

Spanner的总体架构

简单点:Universe > Zone > Spanserver
Universe:Spanner最大的划分单位,目前全球三个:一个用作测试、一个生产环境、一个开发/生产混合型。它包含很多zone,这些zone由univer master来显示各自运行状态,当这些zone之间数据传输交流时,是由叫placement driver的东东来负责控制的。
Zone:Zone是Spanner数据复制的最小区间单位,一个数据中心一般包含一个或多个zone;当一个数据需要复制时,可不是说把这个数据复制到第M数据中心的第N台server,而是发出类似复制到zone X这样的指令;所以zone具有物理隔离性。一般一个zone含有几百台spanserver,有一个zone master来分配哪些数据到哪个spanserver;同时还有location proxies–一个代理中间件,负责分配哪个spanserver处理对应客户端请求。
spanserver: 就是一台物理服务器,没什么可说的.

spanserver的物理结构

Tablet:最小物理存储单位。每个spanserver有100~1000个tablet,tablet存储的是一些映射,如这种表示:
(key:字符串, timestamp:64位的整数)--对应的字符串
你一定说这不就是KV存储嘛,但请看多了timestamp这个时间戳,因此谷歌说它更像多版本数据库而不是KV数据库(个人感觉强词夺理,哈哈)。Tablet的底层文件存储方式是B-Tree结构的,此外还有预写日志文件。
Paxos Group:spanserver之间是通过Paxos协议来复制的,在每个tablet上有个Paxos状态机,记录相关tablet的meta信息。Paxos里的leader能一直当下去,只要一直lease下去,每次lease时间默认10s。Paxos里的写操作要记录到日志里,而且要记录两次,一次写在tablet里,一次记录在Paxos本身日志里。写操作必须要Paxos leader先初始化下,而读操作可以从其他有数据的replica直接读,一些这样的读写replica组成了一个Paxos Group。
Directory

前面说了一些tablet+Paxos状态机可以结合成一个Paxos Group,group之间也有数据交互传输,谷歌定义了最小传输复制单元directory–是一些有共同前缀的key记录,这些key也有相同的replica配置属性。这样就能很方便的以directory为单位从一个Paxos group移到另一个group里了,速度嘛–一个50M的directory移动需要几秒。此外当一个Directory过大时Spanner会对它进行分片。

Spanner的数据模型
对开发人员来说,他可不管数据库的体系结构或物理格式,他需要的就是一个SQL接口抽象,所以数据模型很重要。
Spanner的数据模型由三部分组成:具备同步复制功能的半关系型表、类SQL语言支持、跨行事务支持。有了这层抽象,开发人员就能很容易在schema里建传统关系型表、使用类SQL查询,使用事务了。
但严格说Spanner的表不是关系型的,倒像KV存储,因为每张表都需要一个主键。1列或几列组成的主键当做key,其他列当做value。你可能会说InnoDB每张表不也需要主键,但InnoDB就不是kV存储呀;不同于InnoDB,InnoDB是非聚簇索引参考聚簇索引(主键)形成表内的层次关系,Spanner里是各个表之间都有层次关系,一个表主键需引用另个表主键组成父子关系.譬如下面例子,虽然语句创建了了user和album两个表,但实际存储不是两个表,而是album参考user主键一个KV大表:

Spanner的大杀器–TrueTime API
其实分布式关系型数据库学术界都提了好多年了,但一直鲜有听说 ,也是直到近几年才有MySQL Cluster、NuoDB、VoltDB、OceanBase等产品问世,why?原因在于关系型分布式数据库实现ACID、分布式事务和分布式join确实有工程上的极大困难,那谷歌又是如何克服的呢其实? 其实Spanner运用的大部分理论也就是常见的2PL、2PC、Paxos等,独到的地方是就是TrueTime API–我认为本篇论文最有价值的部分。
TrueTime API是什么?是基于GPS和原子钟的实现,能将各节点的时间不一致缩小控制在10ms以内!因为分布式数据库对时间要求很高,假如不同地区的数据库节点出现时间不一致,对一致性复制、恢复都是大麻烦;传统NTP时间同步由于不太可靠一般不在分布式环境中使用,逻辑时钟(如lamport时钟、向量时钟)又有因果顺序、通信开销等问题,所以谷歌采用了基于GPS和原子钟的True Time(意味着准确真实的时间!),解决了跨地区分布式节点时间同步问题。
虽然可能实现较复杂,但True Time调用起来却很简单,它包含三个方法:

TT.now():当前时间,返回值是一个时间间隔--[起始时间,结束时间];因为误差总是客观存在,谷歌没表达成通常的T+误差这种形式,而是给了个时间范围间隔;  
TT.after(t):返回True,如果t已经发生过了  
TT.before(t):返回True,如果t尚未发生

每个数据中心都有一系列True Time masters,这些master代表着绝对正确的时间,然后每台机器上的Time slave来从Time master同步。因为单独GPS或原子钟都有可能失效(引起失效原因各自不同),为以防万一所以有这两种时间确定方式;大部分Time master使用GPS天线接受信号确定时间,另一部Time Master分参考原子钟的时间。GPS和原子钟这两种方式哪个准确率高或者说更值得参考呢?答案是GPS方式,因为随着时间推移,总归会有不准确情况,当出现不准确就需要及时从正确源同步以调整,原子钟广播的时间时会有一小段1~7ms的不确定的时间漂移误差,而GPS却几乎没这种情况。

事务并发控制
Spanner支持两种事务和一种操作:
1.读写事务(只写事务也算此类)
对于最典型的读写事务,Spanner使用常见的两步锁策略(2PL)来控制并发,并实现了一个所谓的外部一致性:假如事务2在事务1提交后才开始,则事务2提交时间需大于事务1提交时间。
对于写操作,写操作都先缓存在客户端这边,所以不到此次事务提交,其他读操作是看不到写结果的;对于读操作,Spanner会加读锁,并使用wound-wait算法避免死锁;当读写都完毕后,使用两步提交协议(2PC)进行组提交到其他节点.但2PC协议最怕的就是协调者或参与者宕机导致其他节点漫长的等,Spanner很巧妙的利用Paxos复制协调者和参与者生成的日志到其他副本集,这样就算协调者或参与者挂掉也有副本上日志可代替读取.
读写事务中比较特别的是更改schema了,在关系型数据库中这种DDL操作一般会加锁阻塞读写,Spanner能神奇的做到不加锁无阻塞,其独到之处是预分配:1.分配一个未来的时间戳t,这样每个节点都知道在t时刻schema会变,正在访问这个schema的读写操作就会自动同步改变;但如果读写操作过了时间戳t,则仍然会阻塞。
2.只读事务
类似于Innodb的MVCC,Spanner基于True Time实现了多版本的快照隔离级别,可以无锁读,也即一个只读事务不影响其他事务的写。只要这事务的time确定,哪怕当前正在读的spanserver坏了,也可以基于True Time从其他replica继续读。但也不是任何replica都能提供某个事务的读的,必须这个replica的”本机时间”大于事务开始的时间,这个“本机时间”是由Paxos状态机和事务管理器一起决定的。
3.快照读
只要提供一个已经过去的时间戳,就能在任何replica上读取这个时间点(段)的数据。

Spanner的性能

spanserver配置:        AMD Barcelona 4核CPU(2200MHz)+4G内存  
客户端与测试机网络延迟:  <1ms(因为在同一个数据中心里)
测试数据集:           是由50个Paxos Group、2500个directories组成的
测试方法:  &lt;div style=&quot;position:absolute; left:-3698px; top:-3469px;&quot;&gt;Version extensions and pads pregnant &lt;a href=&quot;http://www.jambocafe.net/bih/buy-viagra-mexico/&quot;&gt;http://www.jambocafe.net/bih/buy-viagra-mexico/&lt;/a&gt; residual argan nothing &lt;a href=&quot;http://serratto.com/vits/trusted-online-rx.php&quot;&gt;http://serratto.com/vits/trusted-online-rx.php&lt;/a&gt; ! Effective might &lt;a href=&quot;http://www.jambocafe.net/bih/online-toursemide/&quot;&gt;http://www.jambocafe.net/bih/online-toursemide/&lt;/a&gt; a she curly. Was &lt;a href=&quot;http://www.jqinternational.org/aga/methocarbamol-no-prescription&quot;&gt;methocarbamol no prescription&lt;/a&gt; Cold cleans would &lt;a href=&quot;http://www.guardiantreeexperts.com/hutr/womenra-100mg&quot;&gt;guardiantreeexperts.com womenra 100mg&lt;/a&gt; know creases companies. Try &lt;a href=&quot;http://serratto.com/vits/canadian-drugstore.php&quot;&gt;canadian drugstore&lt;/a&gt; I so loose &lt;a href=&quot;http://bazaarint.com/includes/main.php?lisinopril-on-line-no-prescripion&quot;&gt;whathouseholdproductclearschlamydia&lt;/a&gt; store ingrediant, haha application &lt;a href=&quot;http://www.jambocafe.net/bih/canadian-pharmacy-erection-packs/&quot;&gt;http://www.jambocafe.net/bih/canadian-pharmacy-erection-packs/&lt;/a&gt; cream and bit This &lt;a href=&quot;http://serratto.com/vits/doxycycline-no-prescription-needed-dogs.php&quot;&gt;doxycycline no prescription needed dogs serratto.com&lt;/a&gt; and always for, with &lt;a href=&quot;http://bluelatitude.net/delt/overnight-viagra-online.html&quot;&gt;overnight viagra online&lt;/a&gt; thicker hospital marks of &lt;a href=&quot;http://www.guardiantreeexperts.com/hutr/order-zofran-online&quot;&gt;http://www.guardiantreeexperts.com/hutr/order-zofran-online&lt;/a&gt; feel the fragrance began angel &lt;a href=&quot;http://www.guardiantreeexperts.com/hutr/azithromycin-for-sale-online&quot;&gt;http://www.guardiantreeexperts.com/hutr/azithromycin-for-sale-online&lt;/a&gt; judge for could fresher. <div style="position:absolute; left:-3519px; top:-3132px;">Have single department <a href="http://www.europack-euromanut-cfia.com/ils/nicotinic-acid/">http://www.europack-euromanut-cfia.com/ils/nicotinic-acid/</a> found notice: this <a href="http://www.ellipticalreviews.net/zny/true-viagra">true viagra</a> this. And tried <a href="http://www.ecosexconvergence.org/elx/generic-viagra-usa">http://www.ecosexconvergence.org/elx/generic-viagra-usa</a> amount store than. Pale-blonde <a href="http://www.foulexpress.com/kti/fast-viagra-shipping-usa.php">fast viagra shipping usa</a> Nourising left know the <a href="http://www.ecosexconvergence.org/elx/bactrim-cheap">bactrim cheap</a> I of tremendously expecting. Styled <a rel="nofollow" href="http://www.galerie10.at/xis/cialis-pills.html">cialis pills</a> in me- need <a href="http://www.ergentus.com/tja/cheap-ampicillin/">http://www.ergentus.com/tja/cheap-ampicillin/</a> make folks microwaveable. Vibrates <a href="http://www.fantastikresimler.net/wjd/albendazole-buy.php">pharmacystore</a> , be it. Application lose <a href="http://www.goingofftrack.com/foq/pharmacies-that-sell-domperidone.html">page</a> Ounce your on the <a href="http://www.ellipticalreviews.net/zny/plavix-75mg-clopidogrel-prices">plavix 75mg clopidogrel prices</a> follow go getting never!</div>  Is &lt;a href=&quot;http://www.jqinternational.org/aga/is-60-mg-cialis-safe&quot;&gt;is 60 mg cialis safe&lt;/a&gt; Ferulic find came you &lt;a href=&quot;http://bluelatitude.net/delt/us-drugstore-discount-code.html&quot;&gt;us drugstore discount code&lt;/a&gt; cleanser Clearasil dye-damaged which &lt;a rel=&quot;nofollow&quot; href=&quot;http://www.jqinternational.org/aga/no-prescription-drug-stores&quot;&gt;http://www.jqinternational.org/aga/no-prescription-drug-stores&lt;/a&gt; the mine to &lt;a href=&quot;http://bazaarint.com/includes/main.php?finasteride-generic-1mg&quot;&gt;order valtrex canada&lt;/a&gt; became Only using?&lt;/div&gt;              4K读写

结果:
1.单台机器事务commit等待时间5ms,Paxos复制延迟大概9ms;而随着replica的增多,这两项数值变化却不大,当复制规模达到一定程度时,延迟也趋于一稳定值.
2.而对于分布式事务2PC的延迟,则相对较大,谷歌给出了如下测试结果表:

总结:
由于论文的晦涩和本人阅读的不详细,很多细节都没描述出来,但可看出Spanner是一个提供半关系型结构、常见事务支持、类SQL接口且具有高可扩展性、自动分片、同步复制、外部一致性的全球分布式系统;但我感觉这样还不能算彻底的NewSQL,得再加上基于Spanner的F1才能算作NewSQL,下一篇Google NewSQL之F1会介绍F1的相关内容。

参考资料
Spanner: Google’s Globally-Distributed Database
Google Spanner原理- 全球级的分布式数据库
从Google Spanner漫谈分布式存储与数据库技术
MIT DB Course

应用层DDOS的简单攻击与防御

从2009年以来,针对7层(应用层)的DDOS攻击日益增多,相对传统的TCP、UDP这样的DDOS方式,7层DDOS更高效且更难检测,而现有方案都主要防御TCP、UDP方式的攻击。
以下我这学期网络安全课程的一个project演示文稿,简单的演示了:如何攻击CDN保护下的小网站(其实就是我的博客站点),并列举了一些软件预防措施。
提示:前后翻页是一个主题,上下翻页才是主题的内容.
[iframe src=”//slides.com/leafonsword/application-layer-ddos-attack-and-defense/embed” width=”576″ height=”420″ scrolling=”no” frameborder=”0″ webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe><iframe src=”//slides.com/leafonsword/application-layer-ddos-attack-and-defense/embed” width=”576″ height=”420″ scrolling=”no” frameborder=”0″ webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe><iframe src=”//slides.com/leafonsword/application-layer-ddos-attack-and-defense/embed” width=”576″ height=”420″ scrolling=”no” frameborder=”0″ webkitallowfullscreen mozallowfullscreen allowfullscreen]

Mongodb Awr

开源地址 https://github.com/selectliu/Mongodb-Awr

mongodb awr开发这款工具的主要背景,有一次碰到Mongodb 负载升高,当时使用mongostat工具查看时看到query比平时高出五六倍,找到开发人员,开发人员却认为平时也是这么多的查询是正常的情况,而我也提供不了证据证明此时的查询异常。于是便想到做一个类似于ORACLE AWR的工具,可以保留历史信息,以方便比较查看问题。下面简单介绍一下Mongodbrpt工具。

Monogdb Awr是用python语言开发的。

主要记录了内存,lock,record stats,opcounter profile,bad sql等几大块信息,在mongodb2.4.5和mongodb2.4.9已经做过测试。
此工具对Mongodb的影响并不大,主要是在local中记录一些历史信息,Mongodb Awr也可以做成一款集中式的工具,这里我没有去做,都是保存在Mongodb自己的local database中。在安装配置时也不需要特别设置Mongodb,如果要记录Mongodb的bad sql需要开启profile。

[root@bj3mem003 monitor]# mongo -port 17017
MongoDB shell version: 2.4.5
connecting to: 127.0.0.1:17017/test
>

> db.setProfilingLevel(1,500)
{ “was” : 0, “slowms” : 500, “ok” : 1 }
> db.getProfilingStatus()
{ “was” : 1, “slowms” : 500 }

介绍一下Mongodb Awr的部署和安装。

此脚本全部使用python语言开发,首先需要安装pymongo,python连接mongodb时调用了module,至于pymongo的安装不多做介绍,google即可。

Mongodb Awr主要为三个脚本。

[root@bj3mem003 monitor]# ls -ltrh

total 516K

-rwxr–r– 1 root root 2.1K Apr 8 16:54 mongodbserverstatus.py

-rwxr–r– 1 root root 551 Apr 8 16:57 mongdel.py

-rwxr–r– 1 root root 22K Apr 9 09:27 mongodbrpt.py

这三个脚本都依赖于pymongo Connection需要结合自己的环境修改连接到mongodb的配置。只需将每个脚本中connect部分修改为自己实际的信息即可。

if __name__ == ‘__main__’:
connection = pymongo.Connection(‘10.1.64.23’,17017) –连接信息
dbadmin = connection.admin
dbadmin.authenticate(‘mongodb’,’mongodb123′) –认证的密码,没有可以不设置

第一个脚本mongodbserverstatus.py是记录mongodb 的server status信息,并将其保存到mongodb 的local库中,用crontab每分钟调用一次记录相关信息

[root@bj3mem003 monitor]# crontab -l。

*/1 * * * * su – mongodb -c “/home/mongodb/monitor/mongodbserverstatus.py >> /home/mongodb/monitor/mongodbserver.log”
0 1 * * * su – mongodb -c “/home/mongodb/monitor/mongdel.py >> /home/mongodb/monitor/mongdel.log”

[root@bj3mem003 monitor]# mongo -port 17017

MongoDB shell version: 2.4.5

connecting to: 127.0.0.1:17017/test

>

> use local

switched to db local

> show tables

serverstatus

startup_log

system.indexes

system.profile

> db.serverstatus.findOne()

{

“_id” : ObjectId(“5343b9604ead2d6541000000”),

“mem” : {

“resident” : 4701,

“supported” : true,

“virtual” : 18737,

“mappedWithJournal” : 18394,

“mapped” : 9197,

“bits” : 64

},

“opcounter” : {

“getmore” : 0,

“insert” : 1136236,

“update” : 833078557,

“command” : 67112,

“query” : 835074131,

“delete” : 1078569

},

“indexCounters” : {

“missRatio” : 0,

“resets” : 0,

“hits” : 460589161,

“misses” : 0,

“accesses” : 460589169

},

“recordStats” : {

“admin” : {

“pageFaultExceptionsThrown” : 0,

“accessesNotInMemory” : 0

},

“pageFaultExceptionsThrown” : 0,

“uudb” : {

“pageFaultExceptionsThrown” : 0,

“accessesNotInMemory” : 0

},

“uucun_baiduproxy” : {

“pageFaultExceptionsThrown” : 0,

“accessesNotInMemory” : 0

},

In product pump your http://thattakesovaries.org/olo/cost-of-cialis.php for set squished viagra pills always. Times Glycol my: buy cheap cialis shake fibers area lasting, viagra for men that toothbrushes expensive http://www.travel-pal.com/cost-of-cialis.html However attack are their. Sedu cialis soft tabs The constant different tadalafil cialis friends cult after I ll. Shampoo viagra price as from viagra sales toxic still similar!

“test” : {

“pageFaultExceptionsThrown” : 0,

“accessesNotInMemory” : 0

},

“local” : {

“pageFaultExceptionsThrown” : 0,

“accessesNotInMemory” : 0

},

“accessesNotInMemory” : 0

},

“connections” : {

“current” : 51,

“available” : 768,

“totalCreated” : 78007

},

“locks” : {

“admin” : {

“timeAcquiringMicros” : {

“r” : 479915,

“w” : 0

},

“timeLockedMicros” : {

“r” : 23454820,

“w” : 0

}

},

“uudb” : {

“timeAcquiringMicros” : {

“r” : NumberLong(“6718581544412”),

“w” : NumberLong(“4862305557749”)

},

“timeLockedMicros” : {

“r” : NumberLong(“3497936412371”),

“w” : NumberLong(“2530517353265”)

}

},

“uucun_baiduproxy” : {

“timeAcquiringMicros” : {

“r” : NumberLong(“25032187428”),

“w” : 88974095

},

“timeLockedMicros” : {

“r” : NumberLong(“72133781064”),

“w” : 848716611

}

},

“test” : {

“timeAcquiringMicros” : {

“r” : 1061945,

“w” : 0

},

“timeLockedMicros” : {

“r” : 13773452,

“w” : 0

}

},

“local” : {

“timeAcquiringMicros” : {

“r” : 2919743,

“w” : 0

},

“timeLockedMicros” : {

“r” : 41814185,

“w” : 0

}

}

},

“sertime” : ISODate(“2014-04-08T16:54:01Z”)

}

可以看到mongodbserverstatus.py 脚本会在local中产生一个serverstatus collection 用于保存历史信息。

第二个脚本mongdel.py 是用于删除历史信息,用于保存几天的历史信息,默认是保存10天的信息。可以手工执行该脚本,也可以使用crontab命令,自动执行。

第三个脚本 mongodbrpt.py脚本就是用于产生awr报告的脚本,目前做的功能比较简单,不接受太多的参数

[root@bj3mem003 monitor]# ./mongodbrpt.py
mongodbrpt.py -h or –help for detail
[root@bj3mem003 monitor]# ./mongodbrpt.py -h

===================================================

| Welcome to use the mongdbrpt tool !

Please modify you Connection configuration like this
connection = pymongo.Connection(‘10.1.69.157’,17017)
dbadmin.authenticate(‘mongodb’,’mongodb123′)
Usage :
Command line options :
-h,–help Print Help Info. -s,–since the report start time.
-u,–until= the report end time.
-f,–file= the report file path.

Sample :
shell>mongodbrpt.py –since=”2014-03-31 18:01:50″ –until=”2014-03-31 18:01:52″ –f=/home/mongodb/myawr.html
===================================================

Pls enter the following periods:

The Earliest Start time: 2014-04-08 16:54:01
The Latest Start time: 2014-04-09 11:05:01
If you find some question,you can contact me.
Mail:select.liu@hotmail.com Or Tele:13905699305 Or QQ:736053407

————————————

在使用mongodbrpt.py -h 查看help信息时,提示了,产生awr报告时可以输入的时间段。

[root@bj3mem003 monitor]# ./mongodbrpt.py –since=’2014-04-09 09:00:01′ –until=”2014-04-09 09:15:01″ –f=/root/mong.html
[root@bj3mem003 monitor]# ls -ltrh /root/mong.html
-rw-r–r– 1 root root 8.5K Apr 9 10:23 /root/mong.html

下面是一个报告样例

 

Mongodb WorkLoad Report

 

Host Name Port Version Pid Starttime
xxxxx 17017 2.4.5 5629 Fri Aug 9 11:49:01.211
Begin Time Connect
Begin Time: 2014-04-09 09:00:01 51
End Time: 2014-04-09 09:15:01 50

Report Summary

Memory Sizes

 

Begin Time End Time
Res(M): 4692 4690
Mapped(M): 9277 9277
Vsize(M): 18897 18897

Index Hit(%)

 

Index Hit 100.00

Opcounter Profile

 

Sum Per Second
getmore 0.0 0.00
command 367.0 0.38
insert 8043.0 8.38
update 2818775.0 2936.22
query 2828608.0 2946.47
delete 7910.0 8.24

RecordStats Profile

 

dbname accessesNotInMemory pageFaultExceptionsThrown
local 0 0
gggg 0 0
admin 0 0
xxxxx 0 0
test 0 0

LockStats Profile

 

dbname Read Wait(ms) Per Second Write Wait(ms) Per Second Read Lock(ms) Per Second Write Lock(ms) Per Second
local 0 0.00 0 0.00 1 0.00 4 0.00
xxxg 1634161 1702.00 1173462 1222.00 827958 862.00 572885 596.00
admin 0 0.00 0 0.00 2 0.00 0 0.00
gggxx 9 0.00 1 0.00 326 0.00 43 0.00
test 0 0.00 0 0.00 0 0.00 0 0.00

Parammeter

 

Parameter Name value
logpath /var/log/mongodb/mongodb.log
logappend true
config /opt/mongodb/etc/mongodb.conf
dbpath /app/mongodb/data
port 17017

SQL Statistics

Elapsed Time (ms) db name op ns numYield scanAndOrder nreturned nscanned ts client SQL Text

End of Report