精华内容
下载资源
问答
  • 全局唯一ID--UUID介绍、JAVA中UUID的使用
    万次阅读
    2017-09-15 19:50:46

    UUID是如何保证唯一性的?

    为了保证UUID的唯一性,规范定义了包括网卡MAC地址、时间戳、名字空间(Namespace)、随机或伪随机数、时序等元素。当然,你要说UUID是不是绝对的不会出现重复的,这个也不能这样说的(我下面会提到)。
    UUID具有以下涵义:
    经由一定的算法机器生成为了保证UUID的唯一性,规范定义了包括网卡MAC地址时间戳名字空间(Namespace)随机或伪随机数时序等元素,以及从这些元素生成UUID的算法。UUID的复杂特性在保证了其唯一性的同时,意味着只能由计算机生成。
    非人工指定,非人工识别UUID是不能人工指定的,除非你冒着UUID重复的风险。UUID的复杂性决定了“一般人“不能直接从一个UUID知道哪个对象和它关联。
    在特定的范围内重复的可能性极小UUID的生成规范定义的算法主要目的就是要保证其唯一性。但这个唯一性是有限的,只在特定的范围内才能得到保证,这和UUID的类型有关(参见UUID的版本)。
    UUID的版本UUID具有多个版本,每个版本的算法不同,应用范围也不同。首先是一个特例--Nil UUID--通常我们不会用到它,它是由全为0的数字组成,如下:00000000-0000-0000-0000-000000000000
    UUID Version 1:基于时间的UUID基于时间的UUID通过计算当前时间戳、随机数和机器MAC地址得到。由于在算法中使用了MAC地址,这个版本的UUID可以保证在全球范围的唯一性。但与此同时,使用MAC地址会带来安全性问题,这就是这个版本UUID受到批评的地方。如果应用只是在局域网中使用,也可以使用退化的算法,以IP地址来代替MAC地址--Java的UUID往往是这样实现的(当然也考虑了获取MAC的难度)。
    UUID Version 2:DCE安全的UUIDDCE(Distributed Computing Environment)安全的UUID和基于时间的UUID算法相同,但会把时间戳的前4位置换为POSIX的UID或GID。这个版本的UUID在实际中较少用到。
    UUID Version 3:基于名字的UUID(MD5)基于名字的UUID通过计算名字和名字空间的MD5散列值得到。这个版本的UUID保证了:相同名字空间中不同名字生成的UUID的唯一性;不同名字空间中的UUID的唯一性;相同名字空间中相同名字的UUID重复生成是相同的。
    UUID Version 4:随机UUID根据随机数,或者伪随机数生成UUID。这种UUID产生重复的概率是可以计算出来的,但随机的东西就像是买彩票:你指望它发财是不可能的,但狗屎运通常会在不经意中到来。
    UUID Version 5:基于名字的UUID(SHA1)和版本3的UUID算法类似,只是散列值计算使用SHA1(Secure Hash Algorithm 1)算法。
    UUID的应用从UUID的不同版本可以看出,Version 1/2适合应用于分布式计算环境下,具有高度的唯一性;Version 3/5适合于一定范围内名字唯一,且需要或可能会重复生成UUID的环境下;至于Version 4,个人的建议是最好不用(虽然它是最简单最方便的)。通常我们建议使用UUID来标识对象或持久化数据,但以下情况最好不使用UUID: 映射类型的对象。比如只有代码及名称的代码表。 人工维护的非系统生成对象。比如系统中的部分基础数据。对于具有名称不可重复的自然特性的对象,最好使用Version 3/5的UUID。比如系统中的用户。如果用户的UUID是Version 1的,如果你不小心删除了再重建用户,你会发现人还是那个人,用户已经不是那个用户了。(虽然标记为删除状态也是一种解决方案,但会带来实现上的复杂性。)

    上面这段解析文是知乎一位朋友的理解(https://www.zhihu.com/question/34876910#answer-31004674),个人感觉从UUID的概念、特征描述比较透彻。

    JAVA中UUID的使用

    我们来看看在JAVA中UUID的使用方式:

    查看jdk提供的uuid的api发现。

    uuid 提供了两个方法:randomUUID() 和nameUUIDFromBytes()两个方法。

    其中:randomUUID()是随机(适用于唯一订单号)的。

    nameUUIDFromBytes(byte[] n)会根据n产生唯一的uuid。只要有用户的唯一性信息。就能保证此用户的uuid的唯一性。例如(身份证号等)

    我们更愿意使用自定义唯一编号,再使用该编号生成唯一的UUID。

    我们通过一个非常简单的例子来展示UUID的使用:

    package byron4j.dlzd;
    
    import java.util.UUID;
    public class UuidDemo {
        public static void main(String[] args) {
    
    
            System.out.println(UUID.randomUUID().toString().replace("-", ""));
            System.out.println(UUID.randomUUID().version());
    
                    System.out.println(UUID.nameUUIDFromBytes("890110866094329856".getBytes()).toString().replace("-", ""));
    
    
            System.out.println(UUID.nameUUIDFromBytes("890110866094329856".getBytes()).version());
    
        }
    }
    

    用例输出结果如下:

    d9613ff9975b47e3a8bb1ef3766f7a86
    4
    873473466cf23b5fb988827f8dffbe7d
    3

    我们比较 randomUUID() 和 nameUUIDFromBytes(byte[])方法, 可以得知 其内部使用的是算法版本分别是4、3; 因为我们更趋向于使用版本3、5的算法实现, 所以在实际生产中,推荐使用 nameUUIDFromBytes方法将自身的唯一id转换为UUID形式。

    更多相关内容
  • 弹性域概念概览.doc

    2010-08-03 13:06:55
    多数组织使用由具有意义的段(智能关键字是由一些段组成的代码,这些段中的一个或多...由于智能关键字比唯一编号更利于用户记忆和使用,所以它们在应用产品中非常有用。例如,部件编号 PAD-YEL-11 × 14 比唯一的部……
  • Oracle数据库中,约束具体包括非空(NOT NULL)约束、唯一键(UNIQUE)约束、主键(PRIMARY KEY)约束、外键(FOREIGN KEY)约束和检查(CHECK)约束五种。 1:主键(PRIMARY KEY)约束 什么是主键?在一张表中,...

    Oracle数据库中,约束具体包括非空(NOT NULL)约束、唯一键(UNIQUE)约束、主键(PRIMARY KEY)约束、外键(FOREIGN KEY)约束和检查(CHECK)约束五种。

    1:主键(PRIMARY KEY)约束

    什么是主键?在一张表中,用来唯一标识一条记录的字段集,叫做主关键字或者主关键码,简称主键(或主码),这里说"字段集"是因为主键可能用一个字段或者多个字段来表示。主键唯一确定每一条记录的完整性,其值不能重复,不能空值。可以由一列或者多列构成。举例来看:学生表(学号, 姓名, 性别,邮箱,专业编号),这里学号是主键,一个学号id就可以唯一标识一个学生的信息。另一个表:学生选课表(学号, 课程号, 成绩),这里(学号, 课程号)是主键,因为一个学号(即一个学生)可以选择多门课程,一个课程号(即一个课程)可以被多个学生选择,无法用一个字段来标识一条学生选课的信息记录,而使用(学号, 课程号)这两个字段作为关键字就可以唯一标识学生的选课信息。

    2:外键(FOREIGN KEY)约束

    什么是外键?一张表的非主属性是另一个表的主属性就是这个表的外键。这里有两个分别为: 学生表(学号, 姓名, 性别,邮箱,专业编号),专业信息表(专业编号,专业名称,专业备注信息)。学生表中主键是学号,专业信息表中主键是专业编号。学生表中的非主属性专业编号恰好是专业信息表中的主键。我们就称这个专业编号是学生表的外键。像这样,一个表的非主属性是另一个表的主属性,该非主属性就是外键

    拓展概念:父表和子表

    什么是父表和子表?有两张表A表和B表,表A中的一个字段id是外键,表B中的一个字段id是主键,那么称B为父表,A为子表。就是说一个表中外键字段(相当于这里的A表)是另一个表中(相当于这里的B表)的主键。 还是上面的两个表来举例理解:学生表(学号, 姓名, 性别,专业编号),专业信息表(专业编号,专业名称,专业备注信息)。这里学生表是子表,专业信息表是父表。

      设置表的外键的作用在于建立与父表的联系,比如在专业信息表中某个专业编号的id为'1001',删除这个id后,则学生表中的专业编号id为'1001'的记录也随着删除,这样做的目的在于保证表的完整性。

    3、非空约束(not null):

    什么是非空约束?就是约束的字段,不能为NULL值,必须给定具体的数据,以保证该字段不为空。我们在创建表,给字段添加非空约束,设置后就不能给该字段定义为空值,此约束为列级约束(在建表说明约束时,只能跟在列级定义后)比如:创建学生表,可以设置姓名为非空约束,则姓名都是非空值,不能为空值。

    4、唯一约束(unique):防止输入重复信息,约束的字段具有唯一性,不可重复【列级约束】 字段后加unique。比如我们创建学生表,则邮箱是唯一的,可以添加唯一性约束。

    5、检查约束,对输入的值进行检查,限制输入的值。对该列数据的范围、格式的限制(如:年龄需要比0大、性别只能有两种等),【目前MYSQL不支持,oracle数据库支持】

    表、字段、记录、属性、列、元组定义(自己看论坛学习的,可能有不对的地方,请大家指教)

    一、字段:某一个事物的一个特征,或者说是属性,学生表中,的学号,姓名,性别等就是一个个属性。

    二、记录(元组):事物特征的组合,可以描述一个具体的事物。比如学生表中,学号为1的那一整行,这一整行可以描述张三这个人的特征这样的一个具体事物。元组是记录的另个一称呼。

    三、表:记录的组合 表示同一类事物的组合,表,相当于具有相似特征事物的一个集合。比如学生表,这就是一个表格,还可以由公司员工表,学校的教师表等。

    四、列:字段的另一种称谓,比如学生表中的学号,姓名,性别等等。

    五、元组:记录的另一种称谓,详见上面的记录。
     

     

    参考:

    https://www.cnblogs.com/myseries/p/5222659.html

    https://www.cnblogs.com/seven7seven/p/3730825.html

    https://blog.csdn.net/njyr21/article/details/79351818

    https://blog.csdn.net/qq_40329222/article/details/79513301

    https://blog.csdn.net/aiming66/article/details/51426263

    展开全文
  •  在生产环境中的osd最少可能都有上百个,所以每个osd都有一个全局的编号,类似osd0,osd1,osd2……..序号根据osd诞生的顺序排列,并且是全局唯一的。存储了相同PG的osd节点除了向mon节点发送心跳外,还会互相发送...

    我们在上篇文章已经对比了不同的存储系统之间的区别,本章开始逐步深入记录Ceph的学习和运用。

    开源分布式存储系统的对比

    Ceph简介

    Ceph是一个分布式存储系统,提供对象,块和文件存储,是一个免费开源软件的存储解决方案,可以部署于普通的x86兼容服务器上,可用于解决统一存储的io问题。Ceph诞生于2004年,最早是SageWeil一项关于存储系统的PhD研究项目,致力于开发下一代高性能分布式文件系统的项目。随着云计算的发展,ceph乘上了OpenStack的春风,进而成为了开源社区受关注较高的项目之一。
    该系统被设计成自动修复和智能管理,希望减低管理员和预算开销。
    想达到的目标:没有单点故障的完全分布式存储系统,使数据能容错和无缝的复制,可扩展EB水平(EB,PB,TB,GB)

    Ceph同时支持块、文件、对象接口,支持PB级别扩展,规格上可部署到上千台通用服务器。对象S3和Swift写入的数据是相互可读取的。

    官网
    https://ceph.com/
    文档
    http://docs.ceph.com/docs/master/#how-ceph-clients-stripe-data
    ceph线下会议
    https://ceph.com/cephdays/

    Ceph的优点

    CRUSH算法
    Crush算法是ceph的两大创新之一,简单来说,ceph摒弃了传统的集中式存储元数据寻址的方案,转而使用CRUSH算法完成数据的寻址操作。CRUSH在一致性哈希基础上很好的考虑了容灾域的隔离,能够实现各类负载的副本放置规则,例如跨机房、机架感知等。Crush算法有相当强大的扩展性,理论上支持数千个存储节点。

    高可用
    Ceph中的数据副本数量可以由管理员自行定义,并可以通过CRUSH算法指定副本的物理存储位置以分隔故障域,支持数据强一致性; ceph可以忍受多种故障场景并自动尝试并行修复。

    高扩展性
    Ceph不同于swift,客户端所有的读写操作都要经过代理节点。一旦集群并发量增大时,代理节点很容易成为单点瓶颈。Ceph本身并没有主控节点,扩展起来比较容易,并且理论上,它的性能会随着磁盘数量的增加而线性增长。

    特性丰富
    Ceph支持三种调用接口:对象存储,块存储,文件系统挂载。三种方式可以一同使用。在国内一些公司的云环境中,通常会采用ceph作为openstack的唯一后端存储来提升数据转发效率。

    Ceph的存储实现架构

    Ceph系统可以大致划分为两大部分,客户端和服务端,客户端包含了四种接口,服务端包含了元数据服务器,对象存储集群和集群监视器:

    客户端

    面向用户的使用提供接口,目前有三种存储方式接口提供,对象存储 RGW(rados gateway)、块存储 RBD(rados block device) 和文件存储 CephFS。
    块存储和文件存储都是基于对象存储来进行封装实现的,块存储和文件存储的底层还是对象存储。

    对象存储(RGW:RADOS gateway)

    Ceph 对象存储服务提供了 REST 风格的 API ,它有与 Amazon S3 和 OpenStack Swift 兼容的接口。也就是通常意义的键值存储,其接口就是简单的GET、PUT、DEL和其他扩展;
    RADOSGW是一套基于当前流行的RESTFUL协议的网关,并且兼容S3和Swift。

    块存储(RBD:RADOS block device)

    RBD通过Linux内核客户端和QEMU/KVM驱动来提供一个分布式的块设备。
    RBD 是通过librbd库对应用提供块存储,主要面向云平台的虚拟机提供虚拟磁盘;RBD类似传统的SAN存储,提供数据块级别的访问;
    目前 RBD 提供了两个接口,一种是直接在用户态实现, 通过 QEMU Driver 供 KVM 虚拟机使用。 另一种是在操作系统内核态实现了一个内核模块。通过该模块可以把块设备映射给物理主机,由物理主机直接访问。

    文件存储 (CEPH FS)

    CEPH FS通过Linux内核客户端和FUSE来提供一个兼容POSIX的文件系统。
    Ceph 文件系统服务提供了兼容 POSIX 的文件系统,可以直接挂载为用户空间文件系统。它跟传统的文件系统如Ext4是一个类型,区别在于分布式存储提供了并行化的能力;

    原生接口

    除了以上3种存储接口, 还可以直接使用 librados 的原生接口,直接和RADOS通信;
    原生接口的优点是是它直接和和应用代码集成,操作文件很方便;但它的问题是它不会主动为上传的数据分片;一个1G的大对象上传,落到 Ceph 的存储磁盘上就是1G的文件;
    而以上三个接口是具有分片功能(即:条带化 file-striping)

    服务端

    元数据服务器

    主要是实现集群元数据的分布式管理

    对象存储集群

    因为ceph的三种存储接口都是通过对象存储实现的,对象存储集群将数据和元数据作为对象存储,执行其他关键职能。
    对象存储集群的核心组件是RADOS (Reliable, AutonomicDistributed Object Store)。

    集群监视器

    执行监视功能,保证集群的健康运行和告警

    客户端和服务端交互

    它们之间的结构和交互如图:


    从架构图中可以看到最底层的是RADOS,RADOS自身是一个完整的分布式对象存储系统,它具有可靠、智能、分布式等特性,Ceph所有的存储功能都是基于RADOS实现,所以Ceph的高可靠、高可拓展、高性能、高自动化都是由这一层来提供的,用户数据的存储最终也都是通过这一层来进行存储的,RADOS可以说就是Ceph的核心。

    RADOS系统主要由两部分组成,分别是OSD和Monitor。

    RADOS采用C++开发,所提供的原生Librados API包括C和C++两种。Ceph的上层应用调用本机上的librados API,再由后者通过socket与RADOS集群中的其他节点通信并完成各种操作。

    基于RADOS层的上一层是LIBRADOS,LIBRADOS是一个库,它允许应用程序通过访问该库来与RADOS系统进行交互,支持多种编程语言,比如C、C++、Python等。

    基于LIBRADOS层开发的又可以看到有三层,分别是RADOSGW、RBD和CEPH FS。

    RADOS GateWay、RBD其作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。
    其中,RADOS GW是一个提供与Amazon S3和Swift兼容的RESTful API的gateway,以供相应的对象存储应用开发使用。RBD则提供了一个标准的块设备接口,常用于在虚拟化的场景下为虚拟机创建volume。
    目前,Red Hat已经将RBD驱动集成在KVM/QEMU中,以提高虚拟机访问性能。
    这两种方式目前在云计算中应用的比较多。
    CEPHFS则提供了POSIX接口,用户可直接通过客户端挂载使用。它是内核态的程序,所以无需调用用户空间的librados库。它通过内核中的net模块来与Rados进行交互。通过FUSE挂载到客户端的存储系统使用起来跟本地硬盘的使用方式一致,使用挂载路径即可访问。

    Ceph的物理部署

    服务端 RADOS 集群主要由两种节点组成:一种是为数众多的、负责完成数据存储和维护功能的OSD(Object Storage Device),另一种则是若干个负责完成系统状态检测和维护的monitor。

    Monitor

    Monitor 集群提供了整个存储系统的节点信息等全局的配置信息,通过 Paxos 算法保持数据的一致性。

    OSD

    Pool是存储对象的逻辑分区,它规定了数据冗余的类型和对应的副本分布策略;支持两种类型:副本(replicated)和 纠删码( Erasure Code);目前我们公司内部使用的Pool都是副本类型(3副本);

    PG( placement group)是一个放置策略组,它是对象的集合,该集合里的所有对象都具有相同的放置策略;简单点说就是相同PG内的对象都会放到相同的硬盘上; PG是 ceph的核心概念, 服务端数据均衡和恢复的最小粒度就是PG;

    OSD是负责物理存储的进程,一般配置成和磁盘一一对应,一块磁盘启动一个OSD进程;

    下面这张图形象的描绘了它们之间的关系:

    一个Pool里有很多PG,
    一个PG里包含一堆对象;一个对象只能属于一个PG;
    PG有主从之分,一个PG分布在不同的OSD上(针对三副本类型)

    Ceph的组件详解

    Ceph的核心组件包括Ceph OSD、Ceph Monitor和Ceph MDS。

    Ceph OSD

    OSD的英文全称是Object Storage Device,它的主要功能是存储数据、复制数据、平衡数据、恢复数据等,与其它OSD间进行心跳检查等,并将一些变化情况上报给Ceph Monitor。一般情况下一块硬盘对应一个OSD,由OSD来对硬盘存储进行管理,当然一个分区也可以成为一个OSD。

    Ceph OSD的架构实现由物理磁盘驱动器、Linux文件系统和Ceph OSD服务组成,对于Ceph OSD Deamon而言,Linux文件系统显性的支持了其拓展性,一般Linux文件系统有好几种,比如有BTRFS、XFS、Ext4等,BTRFS虽然有很多优点特性,但现在还没达到生产环境所需的稳定性,一般比较推荐使用XFS。

    OSD是强一致性的分布式存储,它的读写流程如下图

     Ceph的读写操作采用主从模型,客户端要读写数据时,只能向对象所对应的主osd节点发起请求。主节点在接受到写请求时,会同步的向从OSD中写入数据。当所有的OSD节点都写入完成后,主节点才会向客户端报告写入完成的信息。因此保证了主从节点数据的高度一致性。而读取的时候,客户端也只会向主osd节点发起读请求,并不会有类似于数据库中的读写分离的情况出现,这也是出于强一致性的考虑。由于所有写操作都要交给主osd节点来处理,所以在数据量很大时,性能可能会比较慢,为了克服这个问题以及让ceph能支持事物,每个osd节点都包含了一个journal文件。

    伴随OSD的还有一个概念叫做Journal盘,一般写数据到Ceph集群时,都是先将数据写入到Journal盘中,然后每隔一段时间比如5秒再将Journal盘中的数据刷新到文件系统中。一般为了使读写时延更小,Journal盘都是采用SSD,一般分配10G以上,当然分配多点那是更好,Ceph中引入Journal盘的概念是因为Journal允许Ceph OSD功能很快做小的写操作;一个随机写入首先写入在上一个连续类型的journal,然后刷新到文件系统,这给了文件系统足够的时间来合并写入磁盘,一般情况下使用SSD作为OSD的journal可以有效缓冲突发负载。

    在ceph中,每一个osd进程都可称作是一个osd节点,也就是说,每台存储服务器上可能包含了众多的osd节点,每个osd节点监听不同的端口,类似于在同一台服务器上跑多个mysql或redis。每个osd节点可以设置一个目录作为实际存储区域,也可以是一个分区,一整块硬盘。如下图,当前这台机器上跑了两个osd进程,每个osd监听4个端口,分别用于接收客户请求、传输数据、发送心跳、同步数据等操作。

    如上图所示,osd节点默认监听tcp的6800到6803端口,如果同一台服务器上有多个osd节点,则依次往后排序。

      在生产环境中的osd最少可能都有上百个,所以每个osd都有一个全局的编号,类似osd0,osd1,osd2……..序号根据osd诞生的顺序排列,并且是全局唯一的。存储了相同PG的osd节点除了向mon节点发送心跳外,还会互相发送心跳信息以检测pg数据副本是否正常。

    之前在介绍数据流向时说过,每个osd节点都包含一个journal文件,如下图:

    默认大小为5G,也就说每创建一个osd节点,还没使用就要被journal占走5G的空间。这个值是可以调整的,具体大小要依osd的总大小而定。

      Journal的作用类似于mysql innodb引擎中的事物日志系统。当有突发的大量写入操作时,ceph可以先把一些零散的,随机的IO请求保存到缓存中进行合并,然后再统一向内核发起IO请求。这样做效率会比较高,但是一旦osd节点崩溃,缓存中的数据就会丢失,所以数据在还未写进硬盘中时,都会记录到journal中,当osd崩溃后重新启动时,会自动尝试从journal恢复因崩溃丢失的缓存数据。因此journal的io是非常密集的,而且由于一个数据要io两次,很大程度上也损耗了硬件的io性能,所以通常在生产环境中,使用ssd来单独存储journal文件以提高ceph读写性能。

    Ceph Monitor

    由该英文名字我们可以知道它是一个监视器,负责监视Ceph集群,维护Ceph集群的健康状态,同时维护着Ceph集群中的各种Map图,比如OSD Map、Monitor Map、PG Map和CRUSH Map,这些Map统称为Cluster Map,Cluster Map是RADOS的关键数据结构,管理集群中的所有成员、关系、属性等信息以及数据的分发,比如当用户需要存储数据到Ceph集群时,OSD需要先通过Monitor获取最新的Map图,然后根据Map图和object id等计算出数据最终存储的位置。

    Mon节点监控着整个ceph集群的状态信息,监听于tcp的6789端口。每一个ceph集群中至少要有一个Mon节点,官方推荐每个集群至少部署三台。Mon节点中保存了最新的版本集群数据分布图(cluster map)的主副本。客户端在使用时,需要挂载mon节点的6789端口,下载最新的cluster map,通过crush算法获得集群中各osd的IP地址,然后再与osd节点直接建立连接来传输数据。所以对于ceph来说,并不需要有集中式的主节点用于计算与寻址,客户端分摊了这部分工作。而且客户端也可以直接和osd通信,省去了中间代理服务器的额外开销。

      Mon节点之间使用Paxos算法来保持各节点cluster map的一致性;各mon节点的功能总体上是一样的,相互间的关系可以被简单理解为主备关系。如果主mon节点损坏,其他mon存活节点超过半数时,集群还可以正常运行。当故障mon节点恢复时,会主动向其他mon节点拉取最新的cluster map。

      Mon节点并不会主动轮询各个osd的当前状态,相反,osd只有在一些特殊情况才会上报自己的信息,平常只会简单的发送心跳。特殊情况包括:1、新的OSD被加入集群;2、某个OSD发现自身或其他OSD发生异常。Mon节点在收到这些上报信息时,则会更新cluster map信息并加以扩散。

      cluster map信息是以异步且lazy的形式扩散的。monitor并不会在每一次cluster map版本更新后都将新版本广播至全体OSD,而是在有OSD向自己上报信息时,将更新回复给对方。类似的,各个OSD也是在和其他OSD通信时,如果发现对方的osd中持有的cluster map版本较低,则把自己更新的版本发送给对方。

    推荐使用以下的架构

    这里的ceph除了管理网段外,设了两个网段,一个用于客户端读写传输数据。另一个用于各OSD节点之间同步数据和发送心跳信息等。这样做的好处是可以分担网卡的IO压力。否则在数据清洗时,客户端的读写速度会变得极为缓慢。

    Ceph MDS

    全称是Ceph MetaData Server,Mds是ceph集群中的元数据服务器,而通常它都不是必须的,因为只有在使用cephfs的时候才需要它,对象存储和块存储设备是不需要使用该服务的,而目前云计算中用的更广泛的是另外两种存储方式。

    Mds虽然是元数据服务器,但是它不负责存储元数据,元数据也是被切成对象存在各个osd节点中的,如下图:

    在创建CEPHFS时,要至少创建两个POOL,一个用于存放数据,另一个用于存放元数据。Mds只是负责接受用户的元数据查询请求,然后从osd中把数据取出来映射进自己的内存中供客户访问。所以mds其实类似一个代理缓存服务器,替osd分担了用户的访问压力,如下图:

    Ceph与云平台的关系

    Ceph已经成为OpenStack后端存储标配,OpenStack作为IaaS系统,涉及到存储的部分主要是块存储服务模块、对象存储服务模块、镜像管理模块和计算服务模块,对应为其中的Cinder、Swift、Glance和Nova四个项目。

    Ceph RBD块存储是以独立卷的方式挂接到OpenStcak Cinder模块,主要用作数据盘,这种方式主要通过Cinder Driver实现,删除虚拟机时卷依然存在。Nova对接Ceph时,Ceph RBD块存储卷需要与虚拟机绑定,所以删除虚拟机时卷也删除,一般用作启动盘。Ceph也可以和Glance对接用于镜像卷。Keystone作为OpenStack对象Swift的认证模块,支持Ceph通过RADOSGW网关认证,给OpenStcak提供Swift存储服务。

    Ceph社区已经把Ceph 的RBD块存储镜像支持功能扩展到Docker中。在Docker中Ceph的RBD镜像功能主要是负责把RBD镜像通过异步通信的方式从一个Ceph集群复制到另一个Ceph集群,用于对Docker镜像容灾保护和恢复。

    Ceph内部数据存储视图

    在Ceph存储系统中,Cehp的基础服务架构主要包括了Object Storage Device(OSD),Monitor和MDS。
    提供了Librados原生对象基础库、Librbd块存储库、基于S3 和Swift兼容的Librgw对象库和Libceph文件系统库。
    搭建一台Ceph系统至少需要1个Ceph Monitor和2个Ceph OSD。
    一个Cluster可逻辑上划分为多个Pool。
    一个 Pool由若干个逻辑 PG( Placement Group)组成,Pool内的副本数量也是可以设置的。

    Ceph底层是对象系统,所以一个文件会被切分为多个Object,每个Object会被映射到一个PG,每个 PG 会映射到一组 OSD(Object Storage Device),其中第一个OSD 是主,其余的是备,OSD间通过心跳来相互监控存活状态。引入PG概念后,OSD只和PG相关,不但简化了OSD的数据存储,而且实现了Object到OSD的动态映射,OSD的添加和故障不影响Object的映射。

    Ceph数据如何存储

    在Ceph存储系统中,数据存储分三个映射过程
    首先要将用户要操作的file,映射为RADOS能够处理的object。就是简单的按照object的size对file进行切分,相当于RAID中的条带化过程。
    接着把Object映射到PG,在file被映射为一个或多个object之后,就需要将每个object独立地映射到一个PG中去。
    第三次映射就是将作为object的逻辑组织单元的PG映射到数据的实际存储单元OSD。

    文件存入时,首先把File切分为RADOS层面的Object,每个Object一般为2MB或4MB(大小可设置)。每个Object通过哈希算法映射到唯一的PG。每个PG通过Crush算法映射到实际存储单元OSD,PG和OSD间是多对多的映射关系。OSD在物理上可划分到多个故障域中,故障域可以跨机柜和服务器,通过策略配置使PG的不同副本位于不同的故障域中。

    Ceph数据分布算法

    在分布式存储系统中比较关注的一点是如何使得数据能够分布得更加均衡,常见的数据分布算法有一致性Hash和Ceph的Crush算法。Crush是一种伪随机的控制数据分布、复制的算法,Ceph是为大规模分布式存储而设计的,数据分布算法必须能够满足在大规模的集群下数据依然能够快速的准确的计算存放位置,同时能够在硬件故障或扩展硬件设备时做到尽可能小的数据迁移,Ceph的CRUSH算法就是精心为这些特性设计的,可以说CRUSH算法也是Ceph的核心之一。

    Ceph以私有Client方式对外提供服务,支持Linux用户态(Fuse)和内核态(VFS)方式,Clinet还实现数据切片,通过Crush算法定位对象位置,并进行数据的读写。但在测试中,通常在Ceph服务器端将Ceph配置成NFS服务的ExportFS,通过标准NFS接口导出目录。 CephFS 支持POSIX、HDFS、NFS、CIFS服务接口,其中NFS和CIFS通过外置网关实现(通过Clinet导出)。

    在PG通过Crush算法映射到数据的实际存储单元OSD时,需求通过Crush Map、Crush Rules和Crush算法配合才能完成。

    Cluster Map用来记录全局系统状态记数据结构,由Crush Map和OSD Map两部分组成。 Crush Map包含当前磁盘、服务器、机架的层级结构,OSD Map包含当前所有Pool的状态和所有OSD的状态。

    Crush Rules就是数据映射的策略,决定了每个数据对象有多少个副本,这些副本如何存储。

    Crush算法是一种伪随机算法,通过权重决定数据存放(如跨机房、机架感知等),通常采用基于容量的权重。Crush算法支持副本和EC两种数据冗余方式,还提供了四种不同类型的Bucket(Uniform、List、Tree、Straw),大多数情况下的都采用Straw。

    在说明CRUSH算法的基本原理之前,先介绍几个概念和它们之间的关系。

    存储数据与object的关系:当用户要将数据存储到Ceph集群时,存储数据都会被分割成多个object,每个object都有一个object id,每个object的大小是可以设置的,默认是4MB,object可以看成是Ceph存储的最小存储单元。

    object与pg的关系:由于object的数量很多,所以Ceph引入了pg的概念用于管理object,每个object最后都会通过CRUSH计算映射到某个pg中,一个pg可以包含多个object。

    pg与osd的关系:pg也需要通过CRUSH计算映射到osd中去存储,如果是二副本的,则每个pg都会映射到二个osd,比如[osd.1,osd.2],那么osd.1是存放该pg的主副本,osd.2是存放该pg的从副本,保证了数据的冗余。

    pg和pgp的关系:pg是用来存放object的,pgp相当于是pg存放osd的一种排列组合,我举个例子,比如有3个osd,osd.1、osd.2和osd.3,副本数是2,如果pgp的数目为1,那么pg存放的osd组合就只有一种,可能是[osd.1,osd.2],那么所有的pg主从副本分别存放到osd.1和osd.2,如果pgp设为2,那么其osd组合可以两种,可能是[osd.1,osd.2]和[osd.1,osd.3],是不是很像我们高中数学学过的排列组合,pgp就是代表这个意思。一般来说应该将pg和pgp的数量设置为相等。这样说可能不够明显,我们通过一组实验来体会下:

    先创建一个名为testpool包含6个PG和6个PGP的存储池
    ceph osd pool create testpool 6 6
    通过写数据后我们查看下pg的分布情况,使用以下命令:

    ceph pg dump pgs | grep ^1 | awk ‘{print 1, 1 , 2,$15}’
    dumped pgs in format plain
    1.1 75 [3,6,0]
    1.0 83 [7,0,6]
    1.3 144 [4,1,2]
    1.2 146 [7,4,1]
    1.5 86 [4,6,3]
    1.4 80 [3,0,4]
    第1列为pg的id,第2列为该pg所存储的对象数目,第3列为该pg所在的osd

    我们扩大PG再看看
    ceph osd pool set testpool pg_num 12
    再次用上面的命令查询分布情况:
    1.1 37 [3,6,0]
    1.9 38 [3,6,0]
    1.0 41 [7,0,6]
    1.8 42 [7,0,6]
    1.3 48 [4,1,2]
    1.b 48 [4,1,2]
    1.7 48 [4,1,2]
    1.2 48 [7,4,1]
    1.6 49 [7,4,1]
    1.a 49 [7,4,1]
    1.5 86 [4,6,3]
    1.4 80 [3,0,4]
    我们可以看到pg的数量增加到12个了,pg1.1的对象数量本来是75的,现在是37个,可以看到它把对象数分给新增的pg1.9了,刚好是38,加起来是75,而且可以看到pg1.1和pg1.9的osd盘是一样的。
    而且可以看到osd盘的组合还是那6种。

    我们增加pgp的数量来看下,使用命令:
    ceph osd pool set testpool pgp_num 12
    再看下
    1.a 49 [1,2,6]
    1.b 48 [1,6,2]
    1.1 37 [3,6,0]
    1.0 41 [7,0,6]
    1.3 48 [4,1,2]
    1.2 48 [7,4,1]
    1.5 86 [4,6,3]
    1.4 80 [3,0,4]
    1.7 48 [1,6,0]
    1.6 49 [3,6,7]
    1.9 38 [1,4,2]
    1.8 42 [1,2,3]
    再看pg1.1和pg1.9,可以看到pg1.9不在[3,6,0]上,而在[1,4,2]上了,该组合是新加的,可以知道增加pgp_num其实是增加了osd盘的组合。

    通过实验总结:
    (1)PG是指定存储池存储对象的目录有多少个,PGP是存储池PG的OSD分布组合个数
    (2)PG的增加会引起PG内的数据进行分裂,分裂相同的OSD上新生成的PG当中
    (3)PGP的增加会引起部分PG的分布进行变化,但是不会引起PG内对象的变动

    pg和pool的关系:pool也是一个逻辑存储概念,我们创建存储池pool的时候,都需要指定pg和pgp的数量,逻辑上来说pg是属于某个存储池的,就有点像object是属于某个pg的。

    以下这个图表明了存储数据,object、pg、pool、osd、存储磁盘的关系

    本质上CRUSH算法是根据存储设备的权重来计算数据对象的分布的,权重的设计可以根据该磁盘的容量和读写速度来设置,比如根据容量大小可以将1T的硬盘设备权重设为1,2T的就设为2,在计算过程中,CRUSH是根据Cluster Map、数据分布策略和一个随机数共同决定数组最终的存储位置的。

    Cluster Map里的内容信息包括存储集群中可用的存储资源及其相互之间的空间层次关系,比如集群中有多少个支架,每个支架中有多少个服务器,每个服务器有多少块磁盘用以OSD等。

    数据分布策略是指可以通过Ceph管理者通过配置信息指定数据分布的一些特点,比如管理者配置的故障域是Host,也就意味着当有一台Host起不来时,数据能够不丢失,CRUSH可以通过将每个pg的主从副本分别存放在不同Host的OSD上即可达到,不单单可以指定Host,还可以指定机架等故障域,除了故障域,还有选择数据冗余的方式,比如副本数或纠删码。

    下面这个式子简单的表明CRUSH的计算表达式:

    CRUSH(X) -> (osd.1,osd.2…..osd.n)

    式子中的X就是一个随机数。

    下面通过一个计算PG ID的示例来看CRUSH的一个计算过程:

    (1)Client输入Pool ID和对象ID;

    (2)CRUSH获得对象ID并对其进行Hash运算;

    (3)CRUSH计算OSD的个数,Hash取模获得PG的ID,比如0x48;

    (4)CRUSH取得该Pool的ID,比如是1;

    (5)CRUSH预先考虑到Pool ID相同的PG ID,比如1.48。

    对象的寻址过程

    查找对象在集群中的存储的位置,具体分为两步:
    第一步,对象到PG的映射;将对象的id 通过hash映射,然后用PG总数对hash值取模得到pg id:

    pg_ id = hash( object_ id ) % pg_num

    第二步,PG到osd列表映射; 通过crush算法计算PG上的对象分布到哪些OSD硬盘上;

    CRUSH(PG_ID) =⇒ OSD

    CRUSH算法是 ceph的精华所在;

    crush的目标

    先看看crush算法的希望达成的目标:
    数据均匀的分布到集群中;
    需要考虑各个OSD权重的不同(根据读写性能的差异,磁盘的容量的大小差异等设置不同的权重)
    当有OSD损坏需要数据迁移时,数据的迁移量尽可能的少;

    crush算法过程

    简单说下crush算法的过程:
    第一步输入PG id、可供选择的OSD id 列表,和一个常量,通过一个伪随机算法,得到一个随机数,伪随机算法保证了同一个key总是得到相同的随机数,从而保证每次计算的存储位置不会改变;

    CRUSH_HASH( PG_ID, OSD_ID, r ) = draw

    第二步将上面得到的随机数和每个OSD的权重相乘,然后挑出乘积最大的那个OSD;

     ( draw &0xffff ) * osd_weight = osd_straw

    在样本容量足够大之后,这个随机数对挑中的结果不再有影响,起决定性影响的是OSD的权重,也就是说,OSD的权重越大,被挑中的概率越大。
    到这里了我们再看看crush算法如何达成的目标:
    通过随机算法让数据均衡分布,乘以权重让挑选的结果考虑了权重;而如果出现故障OSD,只需要恢复这个OSD上的数据,不在这个节点上的数据不需移动;

    crush优缺点

    聊到这里,crush算法的优缺点就明显了:
    优点:
    输入元数据( cluster map、 placement rule) 较少, 可以应对大规模集群。
    可以应对集群的扩容和缩容。
    采用以概率为基础的统计上的均衡,在大规模集群中可以实现数据均衡

    缺点
    在小规模集群中, 会有一定的数据不均衡现象(权重的影响低,主要起作用的是伪随机算法)。
    看清楚了寻址的过程,就明白为啥PG不能轻易变更了;PG是寻址第一步中的取模参数,变更PG会导致对象的PG id 都发生变化,从而导致整个集群的数据迁移;

    Ceph 是Sega本人的博士论文作品, 其博士论文被整理成三篇短论文,其中一篇就是 CRUSH
    CRUSH论文标题为《CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data》,介绍了CRUSH的设计与实现细节。

    (PS:另外两篇是 RADOS和 CephFS, 分别讲 Ceph 的服务器实现和 Ceph 文件系统的细节实现)

    错误检测和恢复

    错误检测
    利用心跳
    上报monitor
    更新map

    错误恢复
    主osd主持恢复工作
    若主osd挂掉,二级osd选择一个顶上

    数据条带化

    由于存储设备吞吐量的限制,影响性能和可伸缩性。
    跨多个存储设备的连续块条带化存储信息,以提高吞吐量和性能
    Ceph条带化相似于RAID0
    注意:ceph条带化属于client端,不在RADOS范畴

    注意:条带化是独立于对象副本的。由于CRUSH副本对象跨越OSDs,所以条带自动的被复制。

    条带化参数

    Object Size:
    足够大可以容纳条带单元,必须容纳一个或者多个条带单元。(如2MB,4MB)
    Stripe Width:
    一个条带单元的大小,除了最后一个,其他必须一样大(如64K)
    Stripe Count:
    连续写入一系列的对象的个数(如4个)
    注意:
    参数一旦设置不可改变,提前做好性能测试

    Ceph的高级功能

    Ceph支持丰富的存储功能,从分布式系统最基本的横向扩展、动态伸缩、冗余容灾、负载平衡等,到生产环境滚动升级、多存储池、延迟删除等,再到高大上的Ceph集群、快照、EC纠删码、跨存储池缓存等,下面我们简单介绍几个关键特性。

    Ceph基于统一存储系统设计,支持三种接口。File文件系统支持POSIX、HDFS、NFS、CIFS服务接口,Block块服务支持精简配置、COW快照、克隆,对象服务支持原生的Object API、也兼容Swift和S3的API。

    在Ceph storage 2中,提供全球对象存储集群,支持单个命名空间,并支持在多Region地区运行的集群之间提供了数据同步,包含Region内主Zone到从Zone数据同步(可同步数据和元数据)和不同Region间数据同步(只能同步元数据,包含网关用户和桶信息、但不包含桶内的对象)。

    哪些公司在使用Ceph

    红帽
    美国预测分析公司FICO
    澳大利亚的莫纳什大学 500PB
    乐视,一点资讯,今日头条,滴滴,青云等

    Ceph仅仅是OpenStack后端存储标配,目前很多存储厂商、大企业都基于Ceph技术开发或搭建存储系统,我们首先看看几家存储厂商的产品,如HopeBay和SanDisk。

    Hope Bay科技是一家专注于云平台的科技公司,拥有ArkEase Pro存储服务平台、ArkFlex数据存储平台、Ark Express存储网关和ArkVoice企业云端语音录制平台。在ArkFlex数据存储平台中,Hope Bay对Ceph文件系统进行改良,将CIFS、NFS、iSCSI建构在Ceph RBD之上。

    SanDisk收购Fusion-io之后相继推出ioControl混合式存储阵列和InfiniFlash系列闪存。剥离相关业务到新成立新NextGen公司,SanDisk通过InfiniFlash系列闪存主攻闪存市场,其中就有一款机型InfiniFlash System IF500采用Ceph技术(IF100硬件和InfiniFlash OS Ceph横向扩展软件),同时提供对象存储与块存储服务。SanDisk的存储策略是比较开放,低端存储IF100(纯硬件形态)整合了Nexenta的基于ZFS文件系统开源NexentaStor软件(支持NAS和iSCSI),而高端的IF700则使用了Fusion-io时期的 ION Accelerator数据库加速软件。

    此外,很多大型企业也采用Ceph构建构建云平台和分布式存储解决方案,也正是因为Ceph和OpenStack的深度集成,使得Ceph和OpenStack配合被互联网公司用来搭建云平台。

    乐视基于OpenStack 和Ceph(RBD块存储和RADOSGW对象)搭建乐视云平台;宝德云也基于OpenStack、Ceph(RBD块存储和CephFS) 和Docker构建。电商eBay也采用Ceph和 OpenStack 建设私有云,每个Ceph集群容量都高达数 PB 级别,这些集群主要为 OpenStack 服务。同时,eBay 团队在NAS云化投入逐渐加大,CephFS有可能作为NAS 云化的不二之选。

    携程基于Ceph搭建PB级云对象存储,浪潮AS13000系列存储也是基于Ceph开发,思科UCS流媒体服务存储也是基于Ceph对象存储,雅虎基于Ceph搭建云对象存储。联通研究院、CERN实验室、United Stack等也基于Ceph搭建了开发环境。

    Ceph已经支持云Ready: 随着云计算的发展,首先Ceph搭上了OpenStack这只大船,预示着Ceph已经完全云Ready。接着Ceph受到Intel、SanDisk、思科、Yahoo等公司支持,尤其是RedHat以重金收购Inktank公司,将其作为发展的主方向。通过多年发展,RadHat也明确了Ceph和Gluster侧重点和发展方向,Gluster更专注于文件,Ceph更专注于块和对象。

    Ceph社区力量支持:Ceph社区现在已经有很多厂商参入进来,从Intel、思科、SanDisk等这样的巨头,到United Stack这样的Startup公司,再到电信、大学、研究所这类非存储领域的公司或单位,Ceph的参与队伍越来越庞大。

    Ceph功能的不断完善: Ceph的性能不断得到提升,存储特性也不断丰富,甚至可以与传统专业存储媲美,完备的存储服务和低廉的投资成本,使得越来越多的企业和单位选用Ceph提供存储服务。

    SDS和分布式架构: Ceph软件与硬件平台之间完全解耦,对企业来说搭建Ceph存储系统的门槛是逐渐变低,部署简单基于Linux Ubuntu和标准X86平台。Ceph与存储Sandisk、宝德,云计算United Stack、携程和乐视等公司的成功实践,也为Ceph的广泛应用打下参考基础。

    更多详细方案可参考:
    其他公司应用Ceph的具体方案

    相关使用经验

    预先设置PG不更改

    一个Pool里设置的PG数量是预先设置的,PG的数量不是随意设置,需要根据OSD的个数及副本策略来确定:

    Total PGs = ((Total_number_of_OSD * 100) / max_replication_count) / pool_count

    线上尽量不要更改PG的数量,PG的数量的变更将导致整个集群动起来(各个OSD之间copy数据),大量数据均衡期间读写性能下降严重;

    良好的工程实践建议(掉坑后的教训):
    预先规划Pool的规模,设置PG数量;一旦设置之后就不再变更;后续需要扩容就以 Pool 为维度为扩容,通过新增Pool来实现(Pool通过 crushmap实现故障域隔离);

    故障域的划分

    刚开始接触 Ceph,通常会忽略 crushmap,因为即使对它不做任何设置,也不影响我们的正常使用;
    一旦集群大了,没有它集群就处于一个危险的运行状态中;
    没有故障域的划分,整个集群就处于一个未隔离的资源池中;
    一个对象存过去,可能落在 500个OSD硬盘的任意三个上;
    如果一块硬盘坏了,可能带来的是全局影响(副本copy,这个硬盘上丢失的PG副本可能分布在全局各个硬盘上);

    使用crushmap 将整个集群的OSD 划分为一个个故障域,类似将一个集群按业务划分成为了多个小集群;每个Pool 只会用到特定的 OSD,这样,一旦某个OSD 损坏,影响的只是某个业务的某个Pool,将故障的范围控制在一个很小的范围内。

    良好的工程实践建议:
    使用crushmap 划分故障域,将pool限制在特定的osd list上,osd的损坏只会引起这个pool内的数据均衡,不会造成全局影响;

    服务端对象的存储

    对象是数据存储的基本单元, 一般默认 4MB 大小(这里指的是RADOS的底层存储的对象,非RGW接口的对象)。

    对象的组成分为3部分:key 、value、元数据;

    元数据可直接存在文件的扩展属性中(必须是标准的文件属性),也可存到levelDb中;
    value 就是对象数据,在本地文件系统中用一个文件存储;
    对于大文件的存储,Ceph 提供的客户端接口会对大文件分片(条带化)后存储到服务端;这个条带化操作是在客户端接口程序完成的,在 Ceph 存储集群内存储的那些对象是没条带化的。客户端通过 librados 直接写入 Ceph 存储的数据不会分片。

    良好的工程实践建议:
    对于对象存储,只使用 Ceph 提供的 RGW 接口, 不使用 librados原生接口;不仅有分片功能,扩展也更容易(RGW是无状态的,可水平扩展);大量大对象直接存放到 Ceph中会影响 Ceph 稳定性(存储容量达到60%后);

    Ceph二次开发可优化的地方

    内网传输的加密安全问题
    优化Ceph对levelDB迭代器的使用

    参考链接:
    https://www.cnblogs.com/me115/p/6366374.html
    https://www.cnblogs.com/luohaixian/p/8087591.html
    https://blog.csdn.net/i_chips/article/details/53487719

    展开全文
  • 信息检索(Information Retrieval)相关概念

    千次阅读 2021-03-04 15:54:39
    信息检索(Information Retrieval)相关概念 0 引言         好久没更新了,期末那段时间在突击期末考试,然后寒假又懒惰了一些,疏于学习。这篇算是新年开篇了,在这里笔者...

    信息检索(Information Retrieval)相关概念

    0 引言

            好久没更新了,期末那段时间在突击期末考试,然后寒假又懒惰了一些,疏于学习。这篇算是新年开篇了,在这里笔者先来个迟到的新年祝福,祝大家2021一帆风顺、学业有成、事业有成!
            开篇就不整技术性太强的文章了,寒假开始接触一些自然语言处理(NLP)的技术了,所以简单了解了一下相关概念,今天就给大家介绍。

    1 检索

            搜索结果的排序是搜索引擎最核心的部分,极大程度上决定了搜索引擎的质量好坏以及用户接受与否。搜索引擎最关键的两个因素是用户查询与网页内容的相关性、网页链接情况。这节来探讨一下——给定用户查询,如何从内容相关性角度对网页进行排序。判断网页内容是否与用户查询相关,依赖于搜索引擎所采用的检索模型,我也会在后面的博客中介绍几个常用的检索模型: 布尔模型、向量空间模型、概率模型、语言模型以及机器学习排序模型。

            当用户发起查询后,搜索引擎会根据用户查询判断哪些网页文档与用户需求相关,并按照相关程度将网页排序输出,所以相关度计算是将用户查询和文档内容进行匹配的过程,而检索模型就是用来计算内容相关度的理论基础即检索模型就是为网页排序提供依据的!

            什么样的检索模型是个Good model呢?当用户发出查询后,我们首先把要搜索的文档分为两个维度和四个象限:两个维度——“是否相关”、“是否包含关键词”,四个象限——“包含关键词且相关”、“不包含关键词但相关”、“包含关键词但不相关”、“不包含关键词且不相关”。一个好的检索模型应该尽量提升一二象限文档的排名,抑制三四象限文档的排名。

    在这里插入图片描述

            目前大多数检索模型考虑的对象大多集中于出现关键词的文档,并且检索模型理论研究都存在理想化的隐含假设,即假设用户的需求可以通过查询被非常清晰明确地表达,但这往往与真实场景相差甚远,在真实场景中,很有可能出现语义分歧的现象,即同一个词,用户们想表达的意思也不同。但是对于这种情况,检索模型也无能为力。所以我们在使用检索模型的时候,往往是假设在理想状态下的即:用户查询能够清晰明确地表达用于需求的情况下,如何找出内容相关的文档。但是如果用户查询无法精确地表达用户需求,那么现阶段再优秀的检索模型也无济于事,所以后期研究重点会转向填补用户真实需求与查询词之间的鸿沟。接下来,本文将较为详细地介绍几个常用的检索模型!

    2 相关概念

    • 信息检索(Information Retrieval,简称IR): 从大规模非结构化数据(通常是文本)的集合(通常保存在计算机上)中找出满足用户信息需求的资料(通常是文档)的过程。
    • 非结构化数据(unstructured data): 没有清晰和明显语义结构的数据。有时也把网页这种具有格式标记的数据称为“半结构化数据(semistructured data)”。
    • 查询(Query): 用户提交给系统以代表其信息需求的文本。
    • 信息需求(information need): 用户想查找的信息主题。
    • 文档(document): 检索系统的检索对象,代表以文本形式存在的存储对象,比如Word,PDF,html,XML等不同格式的文件都可以称之为文档,再比如一封邮件,一条短信,一条微博也可以称之为文档。一般搜索引擎的处理对象是互联网网页。
    • 文档集(collection): 所有文档的集合,有时也称语料库(corpus)。比如海量的互联网网页或者说大量的电子邮件都是文档集合的具体例子。
    • 文档编号(Document ID):在搜索引擎内部,会将文档集合内每个文档赋予一个唯一的内部编号,以此编号来作为这个文档的唯一标识,这样方便内部处理,每个文档的内部编号即称之为“文档编号”,后文有时会用DocID来便捷地代表文档编号。
    • 单词编号(Word ID):与文档编号类似,搜索引擎内部以唯一的编号来表征某个单词,单词编号可以作为某个单词的唯一表征。
    • 词条化(tokenization): 将文档转换成一个个词条(token)的列表。

    信息检索可以按照其所处理数据的规模进行区分:

    级别规模大小例子
    第一级别大规模Web搜索(web search)
    第二级别小规模苹果的MacOS X操作系统中的Spotlight搜索
    第三级别介于第一种大规模和第二种小规模之间公司内部文档、专利库、生物医学文献的搜索

            信息检索就介绍到这里,再聊聊题外话吧。
            因为种种因素,我开始创业了。其实,我之前没有想过创业这件事,国为我知道自己有几斤几两,我总结自己是“守成有余,创新不足”,我清楚自己不能当个优秀的leader ,但如果给我个伍务或者带几个人做做事,我自认为还是有能力的。但是,机会来了,就不能让它溜走,年轻不就得拼一拼,所心我也把自己赶鸭子上架,大胆尝试了一下,无论最后结果如何,我觉得至少拼过一把(可能听起来有点中二)。

    展开全文
  • EBS Form关键弹性域中的其它的概念

    千次阅读 2014-02-07 13:43:09
    EBS Form关键弹性域中的其它的概念(版权声明,本人原创或者翻译的文章如需转载,如转载用于个人学习,请注明出处;否则请与本人联系,违者必究)你已经了解了下面这些基本弹性域的术语和概念:l 弹性域(Flexfield...
  • 《计算机网络》_考研复试_概念&面试篇

    万次阅读 多人点赞 2020-04-23 21:01:27
    具体介绍CDM中的码分多址(CDMA): 原理: 每比特时间被分成m个更短的时间槽,称为码片,每个站点被指定一个唯一的m位码片序列。发送1时,站点发送码片序列,发送0时,站点发送码片序列的反码。当两个或多个站点...
  • 《操作系统》_考研复试_概念

    千次阅读 多人点赞 2020-04-25 17:55:12
    前言: 本文作为本人的考研复试收尾笔记,先梳理全面精炼的基本知识,文末会附加我自己整理加搜集的重点面试概念题,大家可以用来自测,看是否真正掌握,如果对大家有帮助,希望大家点赞哦~(^▽ ^)
  • 外键 主键 概念

    2020-11-04 09:09:17
    其中课程编号唯一的,课程编号就是一个主键 成绩表(学号,课程号,成绩) 成绩表中单一一个属性无法唯一标识一条记录, 学号和课程号的组合才可以唯一标识一条记录, 所以 学号和课程号的属性组是一个主键 成绩表中的...
  • SQLite 表达式索引的概念和作用

    千次阅读 2020-11-29 21:23:40
    例如,用户注册时的电子邮箱地址通常不区分大小写,同时要求每个邮箱只能注册一次,也是就存在唯一性约束。我们创建以下示例表: CREATE TABLE users(id integer PRIMARY KEY, email varchar(100) not null, ...
  • 2、两种方法实现唯一性约束 3、CHECK约束 4、主键约束 5、外键约束 6、查询约束 案例应用 1、给表niutable的学号—添加主键约束、给表niutable的课程编号—添加主键约束、给表niutable的性别—添加check约.
  • UUID - 通用唯一识别码

    千次阅读 2019-02-28 20:45:58
    UUID - 通用唯一识别码 ...根据标准方法生成,不依赖中央机构的注册和分配,UUID 具有唯一性,这与其他大多数编号方案不同。重复 UUID 码概率接近零,可以忽略不计。 其目的,是让分布式系统中的所有...
  • 逻辑独立的实现:如果数据库的概念模式要修改,则只要对外模式/模式映像作相应修改,就可以使外模式和应用程序保持不变。 记法:影响都是向上影响的。 一个是内模式要修改,我们就只改模式/内模式映像。让它的...
  • Paxos算法是莱斯利·兰伯特(英语:Leslie Lamport,LaTeX中的“La”)于1990年提出的一种基于消息传递且具有高度容错特性的一致算法。 问题和假设 分布式系统中的节点通信存在两种模型:共享内存(Shared ...
  • 由于不必须按顺序存储,链表在插入的时候可以达到O(1)的复杂度,比另一种线性表顺序表快得多,但是查找一个节点或者访问特定编号的节点则需要O(n)的时间,而线性表和顺序表相应的时间复杂度分别是O(logn)和O(1)。...
  • 这些操作系统的概念,保你没听过!

    千次阅读 多人点赞 2020-02-10 12:40:45
    操作系统概念 大部分操作系统提供了特定的基础概念和抽象,例如进程、地址空间、文件等,它们是需要理解的核心内容。下面我们会简要介绍一些基本概念,为了说明这些概念,我们会不时的从 UNIX 中提出示例,相同的...
  • mysql的约束

    千次阅读 2021-01-28 00:24:07
    在mysql设计表中,有个概念叫做约束什么是约束约束英文:constraint约束实际上就是表中数据的限制条件约束种类mysql的约束大概分为以下几种:非空约束(not null)唯一性约束(unique)主键约束(primary key) PK外键约束...
  • 03-关系模型之基础概念测试题

    千次阅读 2019-10-05 18:55:07
    数据库中有了空值会影响许多方面,如影响聚集函数运算的正确等 用户自定义完整是指用户针对具体的数据库应用所定义的完整约束条件 实体完整和参照完整一般由DBMS系统自动支持 外键如果取空值,则违反了...
  • 操作系统基本概念汇总

    千次阅读 2020-06-08 00:23:53
    并发执行的特征:间断、失去封闭、不可再现 在单处理机系统实现并发后,各进程在某一时间段并行运行,CPU与外部设备之间并行工作 文件系统的主要目的是实现对文件的按名存取 通道控制设备控制器,设备在设备...
  • 数据结构基础概念

    万次阅读 多人点赞 2017-11-14 13:44:24
    数据结构一些概念 数据结构就是研究数据的逻辑结构和物理结构以及它们之间相互关系,并对这种结构定义相应的运算,而且确保经过这些运算后所得到的新结构仍然是原来的结构类型。数据:所有能被输入到计算机中,且能...
  • 幂等解决方案

    千次阅读 2019-01-31 16:39:21
    分布式锁——还是拿插入数据的例子,如果是分布是系统,构建全局唯一索引比较困难,例如唯一性的字段没法确定,这时候可以引入分布式锁,通过第三方的系统(redis或zookeeper),在业务系统插入数据或者更新数据,获取...
  • 磁盘扇区如何编号?

    千次阅读 2019-08-13 22:29:13
    由前面介绍可知,我们可以用柱面/磁头/扇区来唯一定位磁盘上每一个区域,或是说柱面/磁头/扇区与磁盘上每一个扇区有一一对应关系,通常DOS将“柱 面/磁头/扇区”这样表示法称为“绝对扇区”表示法。但DOS不能直接...
  • 实验二 概念模型ER图

    千次阅读 2020-10-20 21:06:51
    现约定:任何人可借多种书,任何一种书可为多人所借阅,借书证号具有唯一性。 (3)、当需要时,可通过数据库中保存的出版社的名称、电话、邮编及地址等信息联系相应出版社增购有关书籍。同时..
  • 超硬核!数据结构学霸笔记,考试面试吹牛就靠它

    万次阅读 多人点赞 2021-03-26 11:11:21
    算法五个特性: 有穷:有穷的时间内完成,或者可以说是可接受的时间完成 确定:对于相同的输入只能得到相同的输出 可行:描述的操作都可以执行基本操作有限次来实现 输入:零个或多个输入。取自于某个特定...
  • 分布式系统基本概念 异常类型 1 服务器down机(随时发生、内存数据丢失(因此需要考虑数据持久化)、down机重启之后要恢复内存信息) 2 网络异常(消息丢失、消息乱序(UDP)或者网络包数据错误、区域内可通信...
  • 分布式一致算法基本阐述

    万次阅读 2018-11-28 20:33:38
     如果让leader选举算法能够保证新选举出来的leader服务器拥有集群中所有机器最高编号(ZXID)的事务proposal,那么就可以保证这个新选举出来的leader一定具有所有已经提交的提案。  ZAB两种基本的模式:崩溃...
  • 数据结构基础概念知识点_保研/考研/面试复习

    千次阅读 多人点赞 2019-09-17 20:21:22
    为准备推免保研面试,对数据结构基础概念知识点作了如下总结。 参考书籍:《数据结构(C语言版)》 严蔚敏等 清华大学出版社 参考网页:https://blog.csdn.net/qq_31196849/article/details/78529724 以上引用侵删。 ...
  • 一个出版社可以出版多种书籍,同一本书仅为一个出版社所出版,出版社名具有唯一性。 根据以上情况,完成如下设计。 (1)设计该系统的E-R图。 (2)将E-R图转换为关系模式。 (3)指出转换后的每个关系模式的主码。 ...
  • 关于分布式计算的一些概念

    万次阅读 2018-06-03 14:56:53
    Carl Hewitt于1970年发明Actor模型,当时Actor模型的概念远远领先于那个时代,知道Erlang这样基于Actor模型设计的面向并发编程的新语言横空出世之后,Actor模型才真真火了起来。 1.2 Actor模型是什么? ...
  • rbac 概念

    千次阅读 2016-05-21 20:24:36
    )进行身份认证的标识,标识必须具有唯一性,如用户名、手机号、邮箱地址等,一个主体可以有多个身份,但是必须有一个主身份( Primary Principal )。   n  credential :凭证信息 是只有主体自己知道的安全...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 60,424
精华内容 24,169
关键字:

唯一性编号的概念