Doris( https://github.com/itisaid/Doris )是一个海量分布式 KV 存储系统,其设计目 标是支持中等规模高可用可伸缩的 KV 存储集群。
Doris可以实现海量存储,线性伸缩、平滑扩容,自动容错、故障转移,高并发,且运维成本低。部署规模,建议部署4-100+台服务器。
Doris采用两层架构,Client 和 DataServer+Store。
有四个核心组件,Client、DataServer、Store、Administration。
应用程序通过Client SDK进行Doris的访问,
每台服务器上部署一个Data Sever做服务器的管理,每台服务器上有自己的存储Store,整个集群的数据存储,每台机器独立部署。数据通过路由选择写入到不同的机器中。
Administration为管理中心,提供配置、管理和监控。
config指,应用程序启动一个Data Server,在启动时要配置管理中心的ip地址,通关管理中心。管理中心会修改配置项感知到集群中加了新机器,对新机器管理,扩容等。待机器处于可用状态,将该机器的配置项通知给KV Client。从而KV Client进行新的路由选择。
扩容、下线机器等的控制台界面通过Management管理。
Monitor监控机器是否正常。
client写数据,绑定产品的namespace(逻辑隔离),构成新key,路由到具体机器上读写。
路由解析算法是设计的一个关键点,决定集群的管理方式,也决定了集群扩容的复杂性和难度。
Doris的算法类似redis,有桶的概念,key映射到1w个虚拟节点,虚拟节点在映射到物理节点。
由于Doris设计时,用于4-100+规模的集群。因此,Doris分了1w个虚拟节点,当服务器超过100会导致负载不均衡,1000会更差,相当于每一个集群上有10个虚拟节点,虚拟节点会有10%的影响。
扩容时,需要调节虚拟节点指向新的位置。具体过程为,暴利轮询新节点添加后,一个服务器上应该承载的虚拟节点个数,将超出的虚拟节点迁移到新机器即可。如上图左图有2个物理节点,扩容后,有3个物理节点,变为右图。
为了保证高可用。doris所有服务分成2个组,两组服务器对等。两个group是可以有不同数量的服务器。
写操作时,client的路由算法在两个group分别选2个服务器,分别(同时)写入,两个服务器全部返回后,再继续向下进行。读操作时,从两个服务器随机选一个读。这样,提高可用性,数据持久性,不会丢失。
集群管理的重要角色Config Server,有一个功能是负责发现故障服务器。
发现故障的方式有2种:
节点失效分为:瞬间失效、临时失效、永久失效
应用服务器向服务器写,如果写失败,为 瞬间失效 。接着应用服务器进行3次重试。3次都失败,通知管理服务器,进行服务的失效判断。
管理服务器再写一次,如果写成功,认为是客户端自己通信通信问题。如果写入失败,判断为 临时失效 ,通知所有client,服务器失效,不要写,也不读。
如果2小时恢复,则节点为临时失效。如果2小时没有恢复,认为是 永久失效 。
如图,如果节点2失效,进入临时失效阶段。
如图,节点2临时失效2个小时还未恢复,判定为永久失效。进入永久失效的恢复。
设计中,有临时日志节点(备份节点),有空白节点。实际使用中没有节点3空白节点。原因:1 自动迁移有风险,还是需要手动迁移。2 几年宕机1台,一直有一个空白节点standby浪费。一般晚上报警失效也没有事情,第二天,找机器扩容即可。认为24小时之内,同样编号的2台机器连续down掉,概率很低。
物理节点分成2个group,写的时候,向2个group同时写。当其中一个group扩容机器时,该group上的所有节点进入临时失效状态。停止读写,将数据迁移到新的服务器上。
由于是虚拟节点的映射在调整,所以迁移是按照虚拟节点调整。为了迁移方便,虚拟节点物理化,一个虚拟节点对应一个文件。迁移时其实就是拷贝文件。这时,如果group1有节点失效也会出现不一致,但是,通常扩容的过程很快,因为,是scp拷贝文件,瓶颈为网络带宽,通常几十T数据,几分钟迁移完成,十来分钟进行数据恢复。
(一)空间数据存储技术
随着地理信息系统的发展,空间数据库技术也得到了很大的发展,并出现了很多新的空间数据库技术(黄钊等,2003),其中应用最广的就是用关系数据库管理系统(RDBMS)来管理空间数据。
用关系数据库管理系统来管理空间数据,主要解决存储在关系数据库中的空间数据与应用程序之间的数据接口问题,即空间数据库引擎(SpatialDatabase Engine)(熊丽华等,2004)。更确切地说,空间数据库技术是解决空间数据对象中几何属性在关系数据库中的存取问题,其主要任务是:
(1)用关系数据库存储管理空间数据
(2)从数据库中读取空间数据,并转换为GIS应用程序能够接收和使用的格式
(3)将GIS应用程序中的空间数据导入数据库,交给关系数据库管理。
空间数据库中数据存储主要有三种模式:拓扑关系数据存储模式、Oracle Spatial模式和ArcSDE模式。拓扑关系数据存储模式将空间数据存在文件中,而将属性数据存在数据库系统中,二者以一个关键字相连。这样分离存储的方式由于存在数据的管理和维护困难、数据访问速度慢、多用户数据并发共享冲突等问题而不适用于大型空间数据库的建设。而OracleSpatial实际上只是在原来的数据库模型上进行了空间数据模型的扩展,实现的是“点、线、面”等简单要素的存储和检索,所以它并不能存储数据之间复杂的拓扑关系,也不能建立一个空间几何网络。ArcSDE解决了这些问题,并利用空间索引机制来提高查询速度,利用长事务和版本机制来实现多用户同时操纵同一类型数据,利用特殊的表结构来实现空间数据和属性数据的无缝集成等(熊丽华等,2004)。
ArcSDE是ESRI公司开发的一个中间件产品,所谓中间件是一个软件,它允许应用元素通过网络连接进行互操作,屏蔽其下的通讯协议、系统结构、操作系统、数据库和其他应用服务。中间件位于客户机/服务器的操作系统之上,管理计算资源和网络通讯,并营造出一个相对稳定的高层应用环境,使开发人员可以集中精力于系统的上层开发,而不用过多考虑系统分布式环境下的移植性和通讯能力。因此,中间件能无缝地连入应用开发环境中,应用程序可以很容易地定位和共享中间件提供的应用逻辑和数据,易于系统集成。在分布式的网络环境下,客户端的应用程序如果要访问网络上某个服务器的信息,而服务器可能运行在不同于客户端的操作系统和数据库系统中。此时,客户机的应用程序中负责寻找数据的部分只需要访问一个数据访问中间件,由该中间件完成网络中数据或服务的查找,然后将查找的信息返回给客户端(万定生等,2003)。因此,本系统实现空间数据库存储的基本思想就是利用ArcSDE实现各类空间数据的存储。
目前,空间数据存储技术已比较成熟,出现了许多类似ArcSDE功能的中间件产品,这些软件基本上都能实现空间数据的数据库存储与管理,但对于海量空间数据的存储,各种软件性能差别较大。随着数据量的增长,计算机在分析处理上会产生很多问题,比如数据不可能一次完全被读入计算机的内存中进行处理。单纯依赖于硬件技术,并不能满足持续增长的数据的处理要求。因此需要在软件上找到处理海量数据的策略,并最终通过软硬件的结合完成对海量数据的处理。在海量数据存储问题上,许多专家从不同侧面进行过研究,Lindstrom在地形简化中使用了外存模型(Out-of-core)技术钟正采用了基于数据分块、动态调用的策略汪国平等人在研究使用高速网络进行三维海量地形数据的实时交互浏览中,采用了分块、多分辨率模板建立模型等方法。这些技术、方法已经在各自系统上进行了研究和实现。本系统采用的ArcSDE软件基本上也是采用分块模型的方法,具体存储和操作不需要用户过多了解,已经由ArcSDE软件实现。因此,对海量数据的存储管理,更需要从数据的组织方式等方面进行设计。塔里木河流域生态环境动态监测系统采集了大量的遥感影像、正射影像等栅格结构的数据,这些数据具有很大的数据量,为适应流域空间基础设施的管理需要,采取一种新的方式来管理、分发这些海量数据以适应各部门的快速浏览和管理需要。
(二)影像金字塔结构
影像数据库的组织是影像数据库效率的关键,为了获得高效率的存取速度,在数据的组织上使用了金字塔数据结构和网格分块数据结构。该技术主导思想如下:
(1)将数据库中使用到的纹理处理成为大小一致的纹理块
(2)为每块纹理生成5个细节等级的纹理,分别为0、1、2、3、4,其中1级纹理通过0级纹理1/4压缩得到,2级纹理通过1级纹理1/4压缩得到,…,以此类推
(3)在显示每个块数据之前,根据显示比例的大小,并以此决定该使用那一级的纹理
(4)在内存中建立纹理缓冲池,使用LRU算法进行纹理块的调度,确保使用频率高的纹理调度次数尽可能少。
(三)影像数据压缩
影像数据压缩有无损压缩和有损压缩两个方法,具体采取哪种压缩方法需根据具体情况确定。对于像元值很重要的数据,如分类数据、分析数据等采用无损压缩(即LZ77算法),否则采用有损压缩(即JPEG算法)。通过对影像数据的压缩,一方面可以节约存储空间,另一方面可以加快影像的读取和显示速度。影像数据的压缩一般与构建金字塔同时进行,在构建影像金字塔过程中自动完成数据的压缩。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)