首页 文章 精选 留言 我的

精选列表

搜索[学习],共10000篇文章
优秀的个人博客,低调大师

Ceph分布式存储学习指南1.14 Ceph

1.14 Ceph 如果我们比较Ceph和现存的其他存储解决方案,由于Ceph特性丰富,它明显与众不同。它克服了现有存储系统的局限性,并已经被证明是昂贵的老存储系统的理想替代品。它是运行于任何商用硬件上的开源软件定义存储解决方案,这使得它也是一个经济的存储解决方案。Ceph提供了各种接口让客户端连接Ceph集群,这为客户端增加了灵活性。对于数据保护,Ceph并不依赖于RAID技术,因为它存在本章前面提到的各种限制。而是采用了已经被证明比RAID更好的副本和纠删码方案。 Ceph的每一个组件都是可靠的并支持高可用性。如果你在配置Ceph组件的过程中牢记冗余,我们可以自信地说Ceph不存在任何单点故障。而单点故障是当今其他存储解决方案的一大挑战。Ceph最大的优点是它的统一特性,它同时提供了现成的块、文件和对象存储解决方案,而其他的存储系

优秀的个人博客,低调大师

Ceph分布式存储学习指南1.11 HDFS

1.11 HDFS HDFS是一个用Java写的并且为Hadoop框架而生的分布式可扩展文件系统。HDFS不是一个完全兼容POSIX的文件系统,并且不支持块存储,这使得它的适用范围不如Ceph。HDFS的可靠性不需要讨论,因为它不是一个高度可用的文件系统。HDFS中的单点故障以及性能瓶颈主要源于它单一的NameNode节点。它更适合于存储少量大文件,而不是同时存储小文件和大文件。

优秀的个人博客,低调大师

众说纷纭,机器学习究竟是什么

所谓数据科学家,是指那些能够利用最合适的工具与方法完成自身工作的专业人士。最出色的数据科学家能够将自己完整的知识集与模式发现方案充分利用于统计分析工作当中。 我们应该如何对科学技术数据的积累总和进行查阅?通常来讲,这要用到所谓“高级分析”机制。这句话在表述上故意显得比较模糊,其核心在于将一切技术手段纳入其中——包括统计分析、数据挖掘、可预测模型、自然语言处理以及支持向量机等等。 在一般人的印象中,“数据挖掘”的涵盖范围很广、大部分相关工作似乎都能划归其下,包括对于隐私侵犯的关注以及应用程序监控等等。不过在我看来,这相当于所有能在空中飞翔的鸟类都称为“秃鹫”——明显并不准确。究其原因,数据挖掘的指向对象为结构化数据,这类方案通常会涉及到具体的技术机制,例如回归分析、决策树等等,而且一般不会被用于对非结构化数据进行内容分析。 与之类似“机器

优秀的个人博客,低调大师

从猫说起——深度学习的过去、现在和未来

过去:从猫到狗 翻阅1982年第1期的《世界科学》杂志,看到这样一则消息:“1981年10月17日,在瑞典的斯德哥摩尔城举行的诺贝尔奖授奖大会上,美国加州理工学院的罗杰•握尔考特•斯佩里(RogerWolcottSperry)博士和加拿大出生的美国人戴维•哈贝尔教授以及瑞典的托尔斯滕•韦塞尔分享了1981年诺贝尔生理学、医学奖。斯佩里因证明大脑两半球的高度专门化以及许多较高级的功能集中在右半球而获奖;哈贝尔和韦塞尔因研究视觉系统的信息处理方面有所发现而获奖。” 哈贝尔和韦塞尔的获奖要归功于“猫星人”,据说这个研究从1958年开始,在猫的后脑头骨上,开了一个小洞,向洞里插入电极,测量神经元的活跃程度,从而发现了一种神经元细胞——“方向选择性细胞”,即后脑皮层的不同视觉神经元与瞳孔所受刺激之间确实存在某种对应关系。这一重要发现,激活了

优秀的个人博客,低调大师

iOS深入学习之Weak关键字介绍

前言 从大二的开始接触OC就用到了weak属性修饰词,但是当时只是知道如何去用这个关键字:防止循环引用。根本没有深入地去了解它。 在刚来北京的时候面试过程中也常常考到该知识点。大点的公司可能会问它如何使用?如何在对象销毁后将对象置nil,小点的公司可能只问一下它的使用。 Now,如果你对它产生恐惧或者曾经对它产生过恐惧(+1),如果你被该关键字弄得整天吃不下饭,睡不着觉,那么可以继续往下阅读,希望读过该博客之后能够帮到你。 废话不多说,开始介绍。 由浅入深 先来看看最简单的一个例子: #import "ViewController.h" @interface ViewController () @property (nonatomic,strong)id strongPoint; @property (nonatomic,weak)id weakPoint; @end @implementation ViewController - (void)viewDidLoad { [super viewDidLoad]; // self.strongPoint = [NSDate date]; self.strongPoint = [[UILabel alloc] init]; self.weakPoint = self.strongPoint; self.strongPoint = nil; NSLog(@"result is :%@", self.weakPoint); } @end 我们可以看到此时输出的结果为: 2017-02-07 13:20:41.119278 Test[7341:2187477] result is :(null) 如果我们使用的strong来修饰weakPoint,此时输出的结果为: 2017-02-07 13:23:13.211164 Test[7344:2187993] result is :<UILabel: 0x100206070; frame = (0 0; 0 0); userInteractionEnabled = NO; layer = <_UILabelLayer: 0x17009a590>> 如果我们使用assign来修饰weakPoint,此时运行程序可能会崩溃(因为如果引用操作发生时内存还没有改变内容,依旧可以输出正确结果,如果引用的时候内存内容发生改变了,就会crash),因为当assign指针所指向的内存被释放之后,不会自动赋值为nil,这样再次引用该指针的时候就会导致野指针操作。 对上述代码运行结果进行分析: 当使用weak关键字的时候,不会增加对象的计数,而且当所指对象置nil的时候,使用weak修饰的指针将被赋值为nil; 当使用strong关键字的时候,会增加对象的计数,也就是说会保持对象值的存在,所以当使用strong的时候weakPoint还会有值。 因此,我们从这里可以得出一个结果: strong是强引用,它会保持对象值的存在; weak是弱引用,当weak指针指向的对象摧毁之后,属性值也会清空(nil out)。 (注意:使用 _ _ weak修饰 和在@ property里面设置weak是一样的) 但是当我们执行如下代码的时候: __strong NSString *yourString = @"Your String"; __weak NSString *myString = yourString; yourString = nil; __unsafe_unretained NSString *theirString = myString; NSLog(@"%p %@", yourString, yourString); NSLog(@"%p %@", myString, myString); NSLog(@"%p %@", theirString, theirString); 你会发现只有yourString为空,其他两个都不为空,这个是为什么呢?原因如下 这里是因为字符字面值永远不会被释放,所以你的weak指针还是指向它。当你使用@""创建一个string对象的时候,它就是一个字面值,永远不会被改变。如果你在程序中很多地方都用到了一样的字符串,那么你可以测试一下,它们都是同一个对象(地址一样),String字面值不会销毁。使用[[NSString alloc] initWithString:@"literal string"]也是一样的效果。因为它指向了一个字面值的string。 那么请问weak指针指向对象被回收的时候该指针是如何被自动置为nil的呢?? 首先,大家可以看一下博客最后面的附录,里面有两个文档,严格来说是Apple的opensouce。里面有一个objc-weak的类。这里是一个objc-weak.h类和一个objc-weak.mm类。 扩展常识 .m和.mm的区别 .m:源代码文件,这个典型的源代码文件扩展名,可以包含OC和C代码。 .mm:源代码文件,带有这种扩展名的源代码文件,除了可以包含OC和C代码之外,还可以包含C++代码。仅在你的OC代码中确实需要使用C++类或者特性的时候才用这种扩展名。 从.h中可以看到以下几个关键的两个结构体:weak_entry_t和weak_table_t,以及一些方法。接下来简单介绍一下weak如何自动置为nil。 weak的实现其实是一个weak表,该表是一个由自旋锁管理的哈希表。 以下是从NSObject.mm里面摘出的一些方法: id objc_initWeak(id *location, id newObj) { if (!newObj) { *location = nil; return nil; } return storeWeak<false/*old*/, true/*new*/, true/*crash*/> (location, (objc_object*)newObj); } 该function的作用是初始化一个新的weak指针指向对象的地址。其中的参数介绍如下: location段:_ _ weak指针的地址 newObj:对象的指针地址 这里调用的storeWeak方法,storeWeak方法里面通过template模板的参数进行更新weak操作,看源码可以知道里面会调用weak_register_no_lock/weak_unregister_no_lock等objc-weak.mm里面的方法进行相应的操作。objc-weak.h里面有句话: For ARR, we also keep track of whether an arbitrary object is being deallocated by briefly placing it in the table just prior to invoking dealloc, and removing it via objc_clear_deallocating just prior to memory reclamation. 对象被废弃时最后调用objc_clear_deallocating。该函数实现如下: void objc_clear_deallocating(id obj) { assert(obj); assert(!UseGC); if (obj->isTaggedPointer()) return; obj->clearDeallocating(); } 也就是调用了clearDeallocating,继续追踪可以发现,它最终是使用了迭代器来取weak表的value,然后调用weak_clear_no_lock,然后查找对应的value,将该weak指针置空: /** * Called by dealloc; nils out all weak pointers that point to the * provided object so that they can no longer be used. * * @param weak_table * @param referent The object being deallocated. */ void weak_clear_no_lock(weak_table_t *weak_table, id referent_id) { objc_object *referent = (objc_object *)referent_id; weak_entry_t *entry = weak_entry_for_referent(weak_table, referent); if (entry == nil) { /// XXX shouldn't happen, but does with mismatched CF/objc //printf("XXX no entry for clear deallocating %p\n", referent); return; } // zero out references weak_referrer_t *referrers; size_t count; if (entry->out_of_line) { referrers = entry->referrers; count = TABLE_SIZE(entry); } else { referrers = entry->inline_referrers; count = WEAK_INLINE_COUNT; } for (size_t i = 0; i < count; ++i) { objc_object **referrer = referrers[i]; if (referrer) { if (*referrer == referent) { *referrer = nil; } else if (*referrer) { _objc_inform("__weak variable at %p holds %p instead of %p. " "This is probably incorrect use of " "objc_storeWeak() and objc_loadWeak(). " "Break on objc_weak_error to debug.\n", referrer, (void*)*referrer, (void*)referent); objc_weak_error(); } } } weak_entry_remove(weak_table, entry); } objc_clear_deallocating该函数的动作如下: 从weak表中获取废弃对象的地址为键值的记录 将包含在记录中的所有附有 _ _ weak修饰符变量的地址,赋值为nil 将weak表中删除该记录 从引用计数表中删除废弃对象的地址为键值的记录 看了objc-weak.mm的源码大概了解了:其实Weak表示一个hash表,然后里面的key是指向对象的地址,Value是Weak指针的地址的数组。 结束 以上便是我个人对weak的理解,查看objc4的源码,发现里面更多的都是结构体、结构体套结构体等等。 附录 Apple的opensource。 Apple的github。 stackoverflow。 原文链接 点此。

优秀的个人博客,低调大师

hbase 学习(十四)Facebook针对hbase的优化方案分析

使用hbase的目的是为了海量数据的随机读写,但是在实际使用中却发现针对随机读的优化和gc是一个很大的问题,而且hbase的数据是存储在Hdfs,而Hdfs是面向流失数据访问进行设计的,就难免带来效率的下降。下面介绍一下Facebook Message系统在HBase online storage场景下的一个案例(《Apache Hadoop Goes Realtime at Facebook》, SIGMOD 2011),最近他们在存储领域顶级会议FAST2014上发表了一篇论文《Analysis of HDFS Under HBase: A Facebook Messages Case Study》分析了他们在使用HBase中遇到的一些问题和解决方案。该论文首先讲了Facebook的分析方法包括tracing/analysis/simulation,FM系统的架构和文件与数据构成等,接下来开始分析FM系统在性能方面的一些问题,并提出了解决方案。 FM系统的主要读写I/O负载 Figure 2描述了每一层的I/O构成,解释了在FM系统对外请求中读占主导,但是由于logging/compaction/replication/caching导致写被严重放大。 HBase的设计是分层结构的,依次是DB逻辑层、FS逻辑层、底层系统逻辑层。DB逻辑层提供的对外使用的接口主要操作是put()和get()请求,这两个操作的数据都要写到HDFS上,其中读写比99/1(Figure 2中第一条)。 由于DB逻辑层内部为了保证数据的持久性会做logging,为了读取的高效率会做compaction,而且这两个操作都是写占主导的,所以把这两个操作(overheads)加上之后读写比为79/21(Figure 2中第二条)。 相当于调用put()操作向HBase写入的数据都是写入了两份:一份写入内存Memstore然后flush到HFile/HDFS,另一份通过logging直接写HLog/HDFS。Memstore中积累一定量的数据才会写HFile,这使得压缩比会比较高,而写HLog要求实时append record导致压缩比(HBASE-8155)相对较低,导致写被放大4倍以上。 Compaction操作就是读取小的HFile到内存merge-sorting成大的HFile然后输出,加速HBase读操作。Compaction操作导致写被放大17倍以上,说明每部分数据平均被重复读写了17次,所以对于内容不变的大附件是不适合存储在HBase中的。由于读操作在FM业务中占主要比例,所以加速读操作对业务非常有帮助,所以compaction策略会比较激进。 HBase的数据reliable是靠HDFS层保证的,即HDFS的三备份策略。那么也就是上述对HDFS的写操作都会被转化成三倍的local file I/O和两倍的网络I/O。这样使得在本地磁盘I/O中衡量读写比变成了55/45。 然而由于对本地磁盘的读操作请求的数据会被本地OS的cache缓存,那么真正的读操作是由于cache miss引起的读操作的I/O量,这样使得读写比变成了36/64,写被进一步放大。 另外Figure 3从I/O数据传输中真正业务需求的数据大小来看各个层次、各个操作引起的I/O变化。除了上面说的,还发现了整个系统最终存储在磁盘上有大量的cold data(占2/3),所以需要支持hot/cold数据分开存储。 总的来说,HBase stack的logging/compaction/replication/caching会放大写I/O,导致业务逻辑上读为主导的HBase系统在地层实际磁盘I/O中写占据了主导。 FM系统的主要文件类型和大小 FM系统的几种文件类型如Table 2所示,这个是纯业务的逻辑描述。在HBase的每个RegionServer上的每个column family对应一个或者多个HFile文件。FM系统中有8个column family,由于每个column family存储的数据的类型和大小不一样,使得每个column family的读写比是不一样的。而且很少数据是读写都会请求的,所以cache all writes可能作用不大(Figure 4)。 对于每个column family的文件,90%是小于15M的。但是少量的特别大的文件会拉高column family的平均文件大小。例如MessageMeta这个column family的平均文件大小是293M。从这些文件的生命周期来看,大部分FM的数据存储在large,long-lived files,然而大部分文件却是small, short-lived。这对HDFS的NameNode提出了很大的挑战,因为HDFS设计的初衷是为了存储少量、大文件准备的,所有的文件的元数据是存储在NameNode的内存中的,还有有NameNode federation。 FM系统的主要I/O访问类型 下面从temporal locality, spatial locality, sequentiality的角度来看。 73.7%的数据只被读取了一次,但是1.1%的数据被读取了至少64次。也就是说只有少部分的数据被重复读取了。但是从触发I/O的角度,只有19%的读操作读取的是只被读取一次的数据,而大部分I/O是读取那些热数据。 在HDFS这一层,FM读取数据没有表现出sequentiality,也就是说明high-bandwidth, high-latency的机械磁盘不是服务读请求的理想存储介质。而且对数据的读取也没有表现出spatial locality,也就是说I/O预读取也没啥作用。 解决方案1. Flash/SSD作为cache使用 下面就考虑怎么架构能够加速这个系统了。目前Facebook的HBase系统每个Node挂15块100MB/s带宽、10ms寻址时间的磁盘。Figure 9表明:a)增加磁盘块数有点用;b)增加磁盘带宽没啥大用;c)降低寻址时间非常有用。 由于少部分同样的数据会被经常读取,所以一个大的cache能够把80%左右的读取操作拦截而不用触发磁盘I/O,而且只有这少部分的hot data需要被cache。那么拿什么样的存储介质做cache呢?Figure 11说明如果拿足够大的Flash做二级缓存,cache命中率会明显提高,同时cache命中率跟内存大小关系并不大。 注:关于拿Flash/SSD做cache,可以参考HBase BucketBlockCache( HBASE-7404) 我们知道大家比较关心Flash/SSD寿命的问题,在内存和Flash中shuffling数据能够使得最热的数据被交换到内存中,从而提升读性能,但是会降低Flash的寿命,但是随着技术的发展这个问题带来的影响可能越来越小。 说完加速读的cache,接着讨论了Flash作为写buffer是否会带来性能上的提升。由于HDFS写操作只要数据被DataNode成功接收到内存中就保证了持久性(因为三台DataNode同时存储,所以认为从DataNode的内存flush到磁盘的操作不会三个DataNode都失败),所以拿Flash做写buffer不会提高性能。虽然加写buffer会使后台的compaction操作降低他与前台服务的I/O争用,但是会增加很大复杂度,所以还是不用了。最后他们给出了结论就是拿Flash做写buffer没用。 然后他们还计算了,在这个存储栈中加入Flash做二级缓存不但能提升性能达3倍之多,而且只需要增加5%的成本,比加内存性价比高很多。 2.分层架构的缺点和改进方案 如Figure 16所示,一般分布式数据库系统分为三个层次:db layer/replication layer/local layer。这种分层架构的最大优点是简洁清晰,每层各司其职。例如db layer只需要处理DB相关的逻辑,底层的存储认为是available和reliable的。 HBase是图中a)的架构,数据的冗余replication由HDFS来负责。但是这个带来一个问题就是例如compaction操作会读取多个三备份的小文件到内存merge-sorting成一个三备份的大文件,这个操作只能在其中的一个RS/DN上完成,那么从其他RS/DN上的数据读写都会带来网络传输I/O。 图中b)的架构就是把replication层放到了DB层的上面,Facebook举的例子是Salus,不过我对这个东西不太熟悉。我认为Cassandra就是这个架构的。这个架构的缺点就是DB层需要处理底层文件系统的问题,还要保证和其他节点的DB层协调一致,太复杂了。 图中c)的架构是在a的基础上的一种改进,Spark使用的就是这个架构。HBase的compaction操作就可以简化成join和sort这样两个RDD变换。 Figure 17展示了local compaction的原理,原来的网络I/O的一半转化成了本地磁盘读I/O,而且可以利用读cache加速。我们都知道在数据密集型计算系统中网络交换机的I/O瓶颈非常大,例如MapReduce Job中Data Shuffle操作就是最耗时的操作,需要强大的网络I/O带宽。 加州大学圣迭戈分校(UCSD)和 微软亚洲研究院(MSRA)都曾经设计专门的数据中心网络拓扑来优化网络I/O负载,相关研究成果在计算机网络顶级会议SIGCOMM上发表了多篇论文,但是由于其对网络路由器的改动伤筋动骨,最后都没有成功推广开来。 Figure 19展示了combined logging的原理。现在HBase的多个RS会向同一个DataNode发送写log请求,而目前DataNode端会把来自这三个RS的log分别写到不同的文件/块中,会导致该DataNode磁盘seek操作较多(不再是磁盘顺序I/O,而是随机I/O)。Combined logging就是把来自不同RS的log写到同一个文件中,这样就把DataNode的随机I/O转化成了顺序I/O。

资源下载

更多资源
优质分享App

优质分享App

近一个月的开发和优化,本站点的第一个app全新上线。该app采用极致压缩,本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册