A. 不同的存储策略的运用需要注意什么
总的来说首先要注意属性，然后是索引。
互联网时代各种存储框架层出不穷，眼花缭乱，比如传统的关系型数据库：Oracle、Mysql，新兴的NoSQL：HBase、Cassandra、Redis，全文检索框架：ES、Solr等。如何为自己的业务选取合适的存储方案，相信弊枣桥大家都思考过这个问题，本文简单聊聊我对Mysql、HBase、ES的理解，希望能和大家一起探讨进步，有不对的地方还请指出。
MySQL：关系型数据库，主要面向OLTP，支持事务，支持二级索引，支持sql，支持主从、GroupReplication架构模型（本文全部以Innodb为例，不涉及别的存储引擎）。
HBase：基于HDFS，支持海量数据读写（尤其是写），支持上亿行、上百万列的，面向列的分布式NoSql数据库。天然分布式，主从架构，不支岩大持事务，不支持二级索引，不支持sql。
ElasticSearch：ES是一款分布式的全文检索框架，底层基于Lucene实现，虽然ES也提供存储，检索功能，但我一直不认为ES是一款租猛数据库，但是随着ES功能越来越强大，与数据库的界限也越来越模糊。天然分布式，p2p架构，不支持事务，采用倒排索引提供全文检索。
B. 什么是对象存储
什么是对象存储？
存储局域网(SAN)和网络附加存储(NAS)是我们比较熟悉的两种主流网络存储架构，而对象存储(Object-based Storage)是一种新的网络存储架构，基于对象存储技术的设备就是对象存储设备(Object-based Storage Device)简称OSD。
对象存储的发展历史：
1999年成立的全球网络存储工业协会(SNIA)的对象存储设备(Object Storage Device)工作组发布了ANSI的X3T10标准。
对象存储的优点：
总体上来讲，对象存储同兼具SAN高速直接访问磁盘特点及NAS的分布式共享特点。
SAN(Storage Area Network)结构
采用SCSI 块I/O的命令集，通过在磁盘或FC(Fiber Channel)级的数据访问提供高性能的随机I/O和数据吞吐率，它具有高带宽、低延迟的优势，在高性能计算中占有一席之地，如SGI的CXFS文件系统就是基于SAN实现高性能文件存储的，但是由于SAN系统的价格较高，且可扩展性较差，已不能满足成千上万个CPU规模的系统。
C. Druid 简介
Druid是一款开源的，为实时和离线数据的亚秒级查询设计的数据存储引擎。它主要用于对事实数据（event data）进行商业智能OLAP分析。Druid提供低延时（实时）数据导入，灵活的数据探索（data exploration）和快速的数据聚合。目前Druid可以适用于万亿条和PB级的数据量，Druid最常用于面向用户的数据分析应用枝哗哪中。
这部分提供了Druid适合满足的猛码需求。如果我们要开发的应用正好有相同的需求，那么Druid是一个很好的选择。
这里将Druid和其他常见的数据存储和查询引擎进行对比，以便于更好的理解Druid使用场景。
Druid最适合的场景是，对海量实时数据，从Kafka导入到Druid中，并进行OLAP查询。当然，Druid同时也支持离线数据的导入和查询，也芦答可以达到很高的查询性能。
D. HBASE之创建表、插入值、表结构查看
hbase中的一些语句其实都很熟悉了，但是真正要用到的时候，发现其中的一些语培早句就不知道怎么下手了。写的很好地一篇文章，值得用的时候在回来看看。
http://www.itcast.cn/news/20201117/14100430162.shtml
HBASE基于HDFS作为默认推荐的存储引擎，海量级别存储时使用，HBASE中核心的组件就是RegionServer，由WAL和Region组成WAL，日志备份Region：数据存储。
HBASE适合海量数据、基于列的存储，流式（实时）计算框架。
HBASE是否指模运行，可以通过在hbase shell进入执行命令：list ，正常运行即表示正常。
语法：当列族中只有一个列时，'列族名:列名 使用'列族名'
put 'table name','row1','column family: column name', 'value' 即
put '表名','行键','列族名', '列值' 或者
put '表名','行键','列族名: 列名', '列值'
其中 row1 为行键(即Row Key); column family：column name 为列族名和列名; value 为插入列的值。
示例
1.插入数据，插入表名为 LIB:IDL_I_ALL_DAY_UID_FEATURE_HBASE ，插入值为1的数据：
put 'LIB:IDL_I_ALL','0000030000000DIU', 'FEATURE:F_DYNAMIC_2','1'
put 'LIB:IDL_I_ALL','0000030000000DIU' ,'FEATURE:F_DYNAMIC_2_1','1'
put 'LIB:IDL_I_ALL','0000030000000DIU' ,'FEATURE:F_DYNAMIC_2_2','1'
2.插入数据，插入表名为 t_cuishou_visualize_label ，插入用户为 90011112323232 这条数据列名为FEATURE,值为1的数据：
put 't_cuishou_visualize_label','90011112323232','data:age','28'
put 't_cuishou_visualize_label','90011112323232','data:name','张三'
put 't_cuishou_visualize_label','90011112323232','data:id','1'
表失效： disable 'ext_label_uid'
修改表压缩方式： alter 'ext_label_uid'NAME=>'label_info',COMPRESSION=>'snappy'
表生效： enable 'ext_label_uid'
scan：获取表的所有数据，
1、全表扫描语法： scan '表名'
例子： scan 'tbl_user'
2、扫描整个列族-语法： scan '表名',{COLUMN => '列族名'}
例子： scan 'tbl_user'，{COLUMN=>'info'}
3、扫描整个列族的某个列-语法： scan '表名',{COLUMN => '列族名:列名'}
例子： scan 'tbl_user'，{COLUMN=>'info：age'}
1、获取数据，get语唯中缓法：get '表名','行键'
例子： get 'tbl_user','mengday'
2、根据某一行某列族的数据，语法：get '表名','行键','列族名'
例子： get 'tbl_user','mengday','info'
3、从创建到获取数据的全实例
格式： create 'table name','column family'
其中 table name 为表名，创建表必须指定;
column family 为列族名，创建表也必须指定。
比如：
创建列族名为 label_info 的表： create 'ext_label_uid', 'label_info'
查看表： scan 'ext_label_uid'
格式：describe 'table name'
NAME：表示列族名。
BLOOMFILTER：表示为列族级别的类型(读者只作了解即可)。
VERIONS：表示版本数。
N_MEMORY：设置是否存入内存。
KEEP_DELETED_CELLS：设置被删除的数据，在基于时间的历史数据查询中是否依然可见。
DATA_BLOCK_ENCODING：表示数据块的算法(读者只作了解即可)。
TTL：表示版本存活的时间。
COMPRESSION：表示设置压缩算法。
MIN_VERSIONS：表示最小版本数。
BLOCKCACHE：表示是否设置读缓存。
REPLICATION：表示设置备份。
E. 赵弘扬：阿里云Elasticsearch技术演进之路
导读： 全文将围绕以下三方面内容介绍睁键罩阿里云Elasticsearch技术。
01
阿里云Elasticsearch业务
1. 业务规模
阿里云Elasticsearch业务（简称ES），从2017年至今已经服务了几千个客户，数据规模达20PB，在公共云上拥有10000+集群，10W+节点规模，是一个成熟的云原生服务。
2. Elasticsearch在日志场景通常会遇到的问题
在企业的数字化转型过程中会生成大量日志数据，企业通过Elasticsearch满足日志检索、存储、归档审计的需求，而这些需求归根结底都会落到成亮凳本的增加，体现在以下三个方面：
3. 风险解读
在正常情况下，流量到ES协调节点，然后将数据写入Data Node；当流量变成正常情况的10倍时，对ES集群的压力就变得很大，一系列问题会接踵而来。
这种情况可以通过集群扩容的方式进行缓解，但扩容的同时又会产生新的问题：
① 稳定性风险
② 运维复杂度风险
③ 成本风险
--
02
阿里云Elasticsearch日志Serverless服务
1. 日志Serverless服务能力解读
基于上述问题和风险，阿里云引入了 两个新功能 ：
① Indexing Service
Indexing Service是一个超大的ES集群阵列，专做Indexing Build，每个客户可灵活使用， 它具有以下特性：
图中灰色虚线内是用户的ES集群，当流量洪峰到来时，用户可以将流量转发至Indexing Service的SLB中进行build index，然后通过segment merge的方式，回到用户ES集群的Data Node。这样通过外部的云上弹性服务，减轻了用户ES集群压力，实现秒级弹性扩缩容的需求。
② 智能海量存储引擎
2. 日志Serverless服务价值解读
① Serverless日志写入服务：Indexing Service
通过读写分离架构，ES集群的数据写入在云端服务进行托管加速，为用户实例和云端服务搭建桥梁，依托云端弹性计算能力，突破本地集群的物理资源限制。
对比开源ELK生态：
② Serverless日志存储服务：智能海量存储引擎
基于计算存储分离架构及多层存储介质混合，提供可靠的海量弹性低成本存储并保证查询性能，无须提前预留集群存储容量，根据实际数据的存储量按量计费。
3. Elasticsearch日志Serverless服务发布
全球范围内首个在云上提供Serverless能力的云原生Elasticsearch服务， 其核心价值体现在三个方面：
4. 真实案例收益
①客户场景描述
汽车 行业的IT系统，大多是分批建设，技术架构及系统复杂有 历史 包袱，IDC、多云架构比较普遍。新兴的业务部门，一方面需要满足政策合规要求，一方面希望对整体日志数据进行价值挖掘，通常会遇到如下悉闹问题：
②方案构架及价值点
--
03
阿里云Elasticsearch技术演进之路
阿里云Elasticsearch技术演进图
Elasticsearch未来的发展会继续在云原生Serverless上进行演进和迭代，在日志场景下优化成本，通过服务化的能力提升日志场景中的ES产品的易用性，帮助客户解决日志场景下前置日志链路上的问题。
同时，与ES社区就Elasticsearch TSDB时序引擎进行共建，相信很快可以在未来的ES新版本中推出TSDB能力。
今天的分享就到这里，谢谢大家。
分享嘉宾：赵弘扬 阿里云 高级产品专家
出品平台：DataFunTalk
01/ 分享嘉宾
02/ 报名看直播 免费领PPT
04/ 关于我们
欢迎转载分享评论，转载请私信。
F. 海量数据存储
存储技术经历了单个磁盘、磁带、RAID到网络存储系统的发展历程。网络存储技术就是将网络技术和I/O技术集成起来，利用网络的寻址能力、即插即用的连接性、灵活性，存储的高性能和高效率，提供基于网络的数据存储和共享服务。在超大数据量的存储管理、扩展性方面具有明显的优势。
典型的网络存储技术有网络附加存储NAS（Network Attached Storage）和存储区域网SAN（Storage Area Networks）两种。
1）NAS技术是网络技术在存储领域的延伸和发展。它直接将存储设备挂在网上，有良好的共享性、开放性。缺点是与LAN共同用物理网络，易形成拥塞，而影响性能。特别是在数据备份时，性能较低，影响在企业存储应用中的地位。
2）SAN技术是以数据存储为中心，使用光纤通道连接高速网络存储的体系结构。即将数据存储作为网络上的一个区域独立出来。在高度的设备和数据共享基础上，减轻网络和服务器的负担。因光纤通道的存储网和LAN分开，使性能得到很大的提高，而且还提供了很高的可靠性和强大的连续业务处理能力。在SAN中系统的扩展、数据迁移、数据本地备份、远程数据容灾数据备份和数据管理等都比较方便，整个SAN成为一个统一管理的存储池（Storage Pool）。SAN存储设备之间通过专用通道进行通信，不占用服务器的资源。因此非常适合超大量数据的存储，成为网络存储的主流。
3）存储虚拟化技术是将系统中各种异构的存储设备映射为一个单一的存储资源，对用户完全透明，达到互操作性的目的和利用已有的硬件资源，把SAN内部的各种异构的存储资源统一成一个单一视图的存储池，可根据用户的需要方便地切割、分配。从而保持已有的投资，减少总体成本，提高存储效率。
存储虚拟化包括3个层次结构：基于服务器的虚拟化存储、基于存储设备的虚拟化存储和基于网络的虚拟化存储。
1）基于服务器的虚拟化存储由逻辑管理软件在主机/服务器上完成。经过虚拟化的存储空间可跨越多个异构的磁盘阵列，具有高度的稳定性和开放性，实现容易、简便。但对异构环境和分散管理不太适应。
2）基于存储设备的虚拟化存储，因一些高端磁盘阵列本身具有智能化管理，可以实现同一阵列，供不同主机分享。其结构性能可达到最优。但实现起来价格昂贵，可操作性差。
3）基于网络的虚拟化存储，通过使用专用的存储管理服务器和相应的虚拟化软件，实现多个主机/服务器对多个异构存储设备之间进行访问，达到不同主机和存储之间真正的互连和共享，成为虚拟存储的主要形式。根据不同结构可分为基于专用服务器和基于存储路由器两种方式。①基于专用服务器的虚拟化，是用一台服务器专用于提供系统的虚拟化功能。根据网络拓扑结构和专用服务器的具体功能，其虚拟化结构有对称和非对称两种方式。在对称结构中数据的传输与元数据访问使用同一通路。实现简单，对服务器和存储设备的影响小，对异构环境的适应性强。缺点是专用服务器可能成为系统性能的瓶颈，影响SAN的扩展。在非对称结构中，数据的传输与元数据访问使用不同通路。应用服务器的I/O命令先通过命令通路传送到专用服务器，获取元数据和传输数据视图后，再通过数据通路得到所需的数据。与对称结构相比，提高了存储系统的性能，增加了扩展能力。②基于存储路由器的SAN虚拟化，存储路由器是一种智能化设备，既具有路由器的功能，又针对I/O进行专门优化。它部署在存储路由器上，多个存储路由器保存着整个存储系统中的元数据多个副本，并通过一定的更新策略保持一致性。这种结构中，因存储路由器具有强大的协议功能，所以具有更多的优势。能充分利用存储资源，保护投资。能实现软硬件隔离，并辅有大量的自动化工具，提高了虚拟服务器的安全性，降低对技术人员的需求和成本。
G. 大数据的核心技术有哪些
大数据技术的体系庞大且复杂，基础的技术包含数据的采集、数据预处理、分布式存储、数据库、数据仓库、机器学习、并行计算、可视化等。
1、数据采集与预处理：
Flume NG实时日志收集系统，支持在日志系统中定制各类数据发送方，用于收集数据；
Zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，提供数据同步服务。
2、数据存储：
Hadoop作为一个开源的框架，专为离线和大规模数据分析而设计，HDFS作为其核心的存储引擎，已被广泛用于数据存储。
HBase，是一个分布式的、面向列的开源数据库，可以认为是hdfs的封装，本质是数据存储、NoSQL数据库。
3、数据清洗：MapRece作为Hadoop的查询引擎，用于大规模数据集的并行计算
4、数据查询分析：
Hive的核心工作就是把SQL语句翻译成MR程序，可以将结构化的数据映射为一张数据库表，并提供 HQL(Hive SQL)查询功能。
Spark 启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。
5、数据可视化：对接一些BI平台，将分析得到的数据进行可视化，用于指导决策服务。
H. 曲靖java培训学校告诉你大规模数据库的性能和伸缩性的优化
在需要支持移动/平板电脑应用及普通桌面浏览器访问的时代，网站的普及率和有效性很大丛猜程度上取决于其可用性和性能。一个访问缓慢的网站会使得访问者或潜在的客户流失，并导致商业的失败。IT培训http://www.kmbdqn.cn/认为一个访问速度相当快的网站将会决定访客是否会使用网站提供的产品或服务。
拥有大规模数据库的网站始终需要适当的关注、配置、优化、调整和维护，以确保网站的快速加载。这篇文章将讨论如何优化有海量数据的MySQL数据库。
选择InnoDB作为存储引擎
大型产品的数据库对于可靠性和并发性的要求较高，InnoDB作为默认的MySQL存储引擎，相对于MyISAM来说是个更佳的选择。
优化数据库结构
组织数据库的schema、表和字段以降低I/O的开销，将相关项保存在一起，并提前规划，以便随着数据量的增长，性能可以保持较高的水平。
设计数据表应尽量使其占用的空间最小化，表的主键应尽吵清可能短。
对于InnoDB表，主键所在的列在每个辅助索引条目中都是可复制的，因此如果有很多辅助索引，那么一个短的主键可以节省大量空间。
仅创建你需要改进查询性能的索引。索引有助于检索，但是会增加插入和更新操作的执行时升郑前间。
InnoDB的ChangeBuffering特性
InnoDB提供了changebuffering的配置，可减少维护辅助索引所需的磁盘I/O。大规模的数据库可能会遇到大量的表操作和大量的I/O，以保证辅助索引保持最新。当相关页面不在缓冲池里面时，InnoDB的changebuffer将会更改缓存到辅助索引条目，从而避免因不能立即从磁盘读取页面而导致耗时的I/O操作。当页面被加载到缓冲池时，缓冲的更改将被合并，更新的页面之后会刷新到磁盘。这样做可提高性能，适用于MySQL5.5及更高版本。
I. SQL Server 和 Oracle 以及 MySQL 有哪些区别
三者是目前市场占有率最高（依安装量而非收入）的关系数据库，而且很有代表性。排行第四的DB2（属IBM公司），与Oracle的定位和架构非常相似，就不赘述了。
如果要说明三者的区别，首先就要从历史入手。
Oracle：中文译作甲骨文，这是一家传奇的公司，有一个传奇的大老板Larry Ellision。 Ellision 32岁还一事无成，读了三个大学，没得到一个学位文凭，换了十几家公司，老婆也离他而去。开始创业时只有1200美元，却使得Oracle公司连续12年销售额每年翻一番。
Oracle成立于1977年，早期的理论基础，反而来自于一篇IBM的论文《A Relational Model of Data for Large Shared Data Banks》【1】。作者CODD选取了关系代数的五种运算，并基于运算，架构了一种新型的数据存储模型。基于这种模型，Oracle成为了一个非常典型的关系历拿数据库。因此也变的严谨、安全、高速、稳定，并且变的越来越庞大。
由于其诞生早、结构严谨、高可用、高性能等特点，使其在传统数据库应用中大杀四方，金融、通信、能源、运输、零售、制造等各个行业的大型公司基本都是用了Oracle，早些年的时候，世界500强几乎100%都是Oracle的用户。
MySQL ：MySQL的最初的核心思想，主要是开源、简便易用。其开发可追溯至1985年，而第一个内部发行版本诞生，已经是1995年。到1998年，MySQL已经可以支持10中操作系统了，其中就包括win平台。但依然问题多多，如不支持事务操作、子查询 、辩册外键、存储过程和视图等功能。下图是一个截止至2006年的数据库市场占有率【2】：
图中可以看出，MySQL的爆发实际是在01、02年，尤其是02年发布的4.0 Beta版，正式选定InnoDB作为默认引擎，对事务处理能力及数据缓存能力有了极大的提高。同年4.1版开始支持子查询，至此MySQL终于蜕变成一个成熟的关系型数据库系统。05年的5.0版本又添加了存储过程、服务端游标、触发器、查询优化以及分布式事务功能，但同年被Oracle抄了后路，InnoDB被Oracle收编。08年，MySQL被Sun收购，09年，Oracle收购了Sun和MySQL。
由于MySQL的早期定位，其主要应用场景就是互联网开发。基本上，互联网的爆发成就了MySQL，LAMP架构风靡天下。而由于MySQL更多的的追求轻量、易用，以及早期的事物操作及复杂查询优化的缺失，在传统的数据库应用场景中，份额极少。
SQL Server：一提到SQL Server，大家一般都只想到Microsoft SQL Server，而非Sybase SQL Server。SQL Server最初是由Microsoft, Sybase and Ashton-Tate三家公司拦下的生意，是为IBM（又出现了）公司的OS/2操作系统开发的。随着OS/2项目的失败，大家也分道扬镳。 Microsoft自然转向自己的win操作系统，作为windows NT软件方案的一部分。而Sybase则专注于Linux/Unix方向的数据库开发。
MS SQL Server主要面向中小企业。其最大的优势就是在于集成了MS公司的各类产品及资源，提供了强大的可视化界面、高度集成的管理开发工具，在快速构建商业智能（BI）方面颇有建树。 MS SQL Server是MS公司在软件集成方案中的重要一环，也为WIN系统在企业级应用中的普及做出了很大贡献。
典型应用场景
关于“大型数据库”，并没有严格的界定，有说以数据量为准，有说以恢复时间为准。如果综合数据库应用场景来说，大型数据库应肢灶搭用有以下特点：海量数据、高吞吐量；复杂逻辑、高计算量，以及高可用性。从这点上来说，Oracle，DB2就是比较典型的大型数据库，Sybase SQL Server也算是吧。下面分别说明之前三种数据库的应用场景。
Oracle。Oracle的应用，主要在传统行业的数据化业务中，比如：银行、金融这样的对可用性、健壮性、安全性、实时性要求极高的业务；零售、物流这样对海量数据存储分析要求很高的业务。此外，高新制造业如芯片厂也基本都离不开Oracle；电商也有很多使用者，如京东（正在投奔Oracle）、阿里巴巴（计划去Oracle化）。而且由于Oracle对复杂计算、统计分析的强大支持，在互联网数据分析、数据挖掘方面的应用也越来越多。一个典型场景是这样的：
某电信公司（非国内）下属某分公司的数据中心，有4台Oracle Sun的大型服务器用来安装Solaris操作系统和Oracle并提供计算服务，3台Sun Storage磁盘阵列来提供Oracle数据存储，12台IBM小型机，一台Oracle Exadata服务器，一台500T的磁带机用来存储历史数据，San连接内网，使用Tuxedo中间件来保证扩展性和无损迁移。建立支持高并发的Oracle数据库，通过OLTP系统用来对海量数据实时处理、操作，建立高运算量的Oracle数据仓库，用OLAP系统用来分析营收数据及提供自动报表。总预算约750万美金。
MySQL。MySQL基本是生于互联网，长于互联网。其应用实例也大都集中于互联网方向，MySQL的高并发存取能力并不比大型数据库差，同时价格便宜，安装使用简便快捷，深受广大互联网公司的喜爱。并且由于MySQL的开源特性，针对一些对数据库有特别要求的应用，可以通过修改代码来实现定向优化，例如SNS、LBS等互联网业务。一个典型的应用场景是：
某互联网公司，成立之初，仅有PC数台，通过LAMP架构迅速搭起网站框架。随着业务扩张、市场扩大，迅速发展成为6台Dell小型机的中型网站。现在花了三年，终于成为垂直领域的最大网站，计划中的数据中心，拥有Dell机架式服务器40台，总预算20万美金。
MS SQL Server。windows生态系统的产品，好处坏处都很分明。好处就是，高度集成化，微软也提供了整套的软件方案，基本上一套win系统装下来就齐活了。因此，不那么缺钱，但很缺IT人才的中小企业，会偏爱 MS SQL Server 。例如，自建ERP系统、商业智能、垂直领域零售商、餐饮、事业单位等等。
1996年，Bill Gates亲自出手，从Borland挖来了大牛Anders，搞定了C#语言。微软02年搞定了http://ASP.NET。成熟的.NET、Silverlight技术，为 MS SQL Server赢得了部分互联网市场，其中就有曾经的全球最大社交网站MySpace，其发展历程很有代表性，可作为一个比较特别的例子【3】。其巅峰时有超过1.5亿的注册用户及每月400亿的访问量。应该算是MS SQL Server支撑的最大的数据应用了。
架构。其实要说执行的区别，主要还是架构的区别。正是架构导致了相同SQL在执行过程中的解释、优化、效率的差异。这里只做粗略说明，就不细说了：
Oracle： 数据文件包括：控制文件、数据文件、重做日志文件、参数文件、归档文件、密码文件。这是根据文件功能行进行划分，并且所有文件都是二进制编码后的文件，对数据库算法效率有极大的提高。由于Oracle文件管理的统一性，就可以对SQL执行过程中的解析和优化，指定统一的标准：
RBO（基于规则的优化器）、CBO（基于成本的优化器）
通过优化器的选择，以及无敌的HINT规则，给与了SQL优化极大的自由，对CPU、内存、IO资源进行方方面面的优化。
MySQL：最大的一个特色，就是自由选择存储引擎。每个表都是一个文件，都可以选择合适的存储引擎。常见的引擎有 InnoDB、 MyISAM、 NDBCluster等。但由于这种开放插件式的存储引擎，比如要求数据库与引擎之间的松耦合关系。从而导致文件的一致性大大降低。在SQL执行优化方面，也就有着一些不可避免的瓶颈。在多表关联、子查询优化、统计函数等方面是软肋，而且只支持极简单的HINT。
SQL Server ：数据架构基本是纵向划分，分为：Protocol Layer（协议层）， Relational Engine（关系引擎）， Storage Engine（存储引擎）， SQLOS。SQL执行过程就是逐层解析的过程，其中Relational Engine中的优化器，是基于成本的（CBO），其工作过程跟Oracle是非常相似的。在成本之上也是支持很丰富的HINT，包括：连接提示、查询提示、表提示。
J. nuclear(一种网路数据存储系统)详细资料大全
Nuclear存储系统，是中国最大的SNS网站人人网下属UGC团队在遇到海量的UGC数据存储需求情况下，开发的在高性能、高可靠、可扩展方面有着优良表现的海量数据存储系统。
它参考了dynamo设计文档，并且分析了现存开源no-sql系统的优劣，完整分析了Cassandra、Voldemort代码的基础之上，在UGC小组的努力下，加入了自动平衡机器负载，简单切换底层引擎等特色而适用的功能，还有相关的附属功能，可以使一个系统从普通的DB轻易将数据移到nuclear集群中来。
基本介绍
- 中文名 ：Nuclear存储系统拦友
- 外文名 ：Nuclear
- 所属机构 ：人人网下属UGC团队
- 参考 ：dynamo设计文档，开源no-sql系统
分区
Nuclear是一个分散式的Key-Value存储系统，那么key对应的数据分布在简枣槐什么节点上，需要遵守一定的规则。熟悉MemecachedClient的同学一定清楚一致性Hash的套用，没错，HashRing就是我们的不二选择。在Nuclear中，数据分布在0~2的HashRing上，Nuclear集群初始化的时候，根据节点数均分整个Hash Ring。 在N=3时，A,B,C三个节点的配置就是系统需要的最少节点了。Nuclear中，顺时针的开始值和结束值确定一个分区管理的数据范围，同时规定分区的范围左开右闭。因此，如上图，我们记录A,B,C分别管理的分区范围是： A {[c,a],[b, c],[a,b]} B {[a,b],[c,a],[b,c]} C {[b,c],[a,b],[c,a]} 可以看出，A处理管理自己的分区数据外，还会把自己管理的数据顺时针往前复制到2(N-1)个节点中。节点变更
Nuclear增加节点时需要制定目标节点的名称，即增加的节点是用来分担目标节点的负载的。这点不同于Dynamo的分区策略，节点增加的时候会均衡的从现有的节点窃取分区，Nuclear中增加的节点只会影响到邻近的三个节点。 记录N,A,B,C管理的分区如下： N {[c,n],[b,c],[a,b]} A {[n,a],[c,n],[b,c]} B {[a,b],[n,a],[c,n]} C {[b,c],[a,b],[n,a]} Nuclear的分区管理模组将自动的计算出需要同步到N上的数据: A [a,b] => N B [b,c] => N C [c,n] => N 不难明白，其实就是把A,B,C不再需要的数据挪给新的节点了。删、替换节点原理大同小异，不再冗述。路由
Nuclear提供服务器端路由策略，Client的请求随机落在Node节点上，由接收到请求的节点处理后续的逻辑。相对于Client端路由来说，优点是Client无需知道Nuclear集群元数据，易于维护；缺点是会造成一定程度的延时，不过我们的测试结果显示延时在可接受范围之内。 两个设计上的Tips贡献给大家: 1. 万事皆异步 我们在编码的过程中走了一些弯路，同步的操作在高并发的情况下带来的性能下降是非常恐怖的，于是乎，Nuclear系统中任何的高并发操作都岩含消除了Block。no waiting, no delay。 2. 根据系统负载控制后台执行绪的资源占用 Nuclear系统中有不少的后台执行绪默默无闻的做着各种辛苦的工作，但是它们同样会占用系统资源，我们的解决方案是根据系统负载动态调整执行绪的运行和停止，并达到平衡。特性
高可拓展
一个Nuclear集群支持1到n(n<2的64平方)个节点(Node)的规模，每台服务器(Server)支持部署多个节点。当集群资源达到瓶颈时，可以通过增加新的节点来扩展。增加新节点的过程，系统服务无需停止，无需人工干预迁移数据。Nuclear理论上可以无限Scale-Out。高可靠性
单个节点的crash永远对系统的运行造成影响，不存在单点风险。数据的写入参考Dynamo的W+R>N理论，简释之，例如设定系统每一份数据都存储在3个节点上(N=3)，那么读的话必须成功读到两个节点上的数据才认为读成功 (R=2)，写的话必须成功写到两个节点上才认为写成功( W=2)。系统永远可写入(Hinted HandOff)。高性能
在Xeon E5405 CPU的服务器上，单节点每秒最高2.5w req/s。整个集群的性能取决于一致性级别、N、W、R数及底层存储引擎的选择。