• 关于

    内排序不可用

    的搜索结果

回答

本人学习数据结构时看到的不错的总结,共享一下了 文件有一组记录组成,记录有若干数据项组成,唯一标识记录的数据项称关键字; 排序是将文件按关键字的递增(减)顺序排列; 排序文件中有相同的关键字时,若排序后相对次序保持不变的称稳定排序,否则称不稳定排序; 在排序过程中,文件放在内存中处理不涉及数据的内、外存交换的称内部排序,反之称外部排序; 排序算法的基本操作:1)比较关键字的大小;2)改变指向记录的指针或移动记录本身。 评价排序方法的标准:1)执行时间;2)所需辅助空间,辅助空间为O(1)称就地排序;另要注意算法的复杂程度。 若关键字类型没有比较运算符,可事先定义宏或函数表示比较运算。 8.2插入排序 8.2.1直接插入排序 实现过程: void insertsort(seqlist R) { int i, j; for(i=2;i<=n;i++) if(R[i].key< R[i-1].key{ R[0]=R[i];j=i-1; do{R[j+1]=R[j];j--;} while(R[0].key R[j+1]=R[0]; } } 复制代码 算法中引入监视哨R[0]的作用是:1)保存 R[i] 复制代码 的副本;2)简化边界条件,防止循环下标越界。 关键字比较次数最大为(n+2)(n-1)/2;记录移动次数最大为(n+4)(n-1)/2; 算法的最好时间是O(n);最坏时间是O(n^2);平均时间是O(n^2);是一种就地的稳定的排序; 8.2.2希尔排序 实现过程:是将直接插入排序的间隔变为d。d的取值要注意:1)最后一次必为1;2)避免d值互为倍数; 关键字比较次数最大为n^1.25;记录移动次数最大为1.6n^1.25; 算法的平均时间是O(n^1.25);是一种就地的不稳定的排序; 8.3交换排序 8.3.1冒泡排序 实现过程:从下到上相邻两个比较,按小在上原则扫描一次,确定最小值,重复n-1次。 关键字比较次数最小为n-1、最大为n(n-1)/2;记录移动次数最小为0,最大为3n(n-1)/2; 算法的最好时间是O(n);最坏时间是O(n^2);平均时间是O(n^2);是一种就地的稳定的排序; 8.3.2快速排序 实现过程:将第一个值作为基准,设置i,j指针交替从两头与基准比较,有交换后,交换j,i。i=j时确定基准,并以其为界限将序列分为两段。重复以上步骤。 关键字比较次数最好为nlog2n+nC(1)、最坏为n(n-1)/2; 算法的最好时间是O(nlog2n);最坏时间是O(n^2);平均时间是O(nlog2n);辅助空间为O(log2n);是一种不稳定排序; 8.4选择排序 8.4.1直接选择排序 实现过程:选择序列中最小的插入第一位,在剩余的序列中重复上一步,共重复n-1次。 关键字比较次数为n(n-1)/2;记录移动次数最小为0,最大为3(n-1); 算法的最好时间是O(n^2);最坏时间是O(n^2);平均时间是O(n^2);是一种就地的不稳定的排序; 8.4.2堆排序 实现过程:把序列按层次填入完全二叉树,调整位置使双亲大于或小于孩子,建立初始大根或小根堆,调整树根与最后一个叶子的位置,排除该叶子重新调整位置。 算法的最好时间是O(nlog2n);最坏时间是O(nlog2n);平均时间是O(nlog2n);是一种就地的不稳定排序; 8.5归并排序 实现过程:将初始序列分为2个一组,最后单数轮空,对每一组排序后作为一个单元,对2个单元排序,直到结束。 算法的最好时间是O(nlog2n);最坏时间是O(nlog2n);平均时间是O(nlog2n);辅助空间为O(n);是一种稳定排序; 8.6分配排序 8.6.1箱排序 实现过程:按关键字的取值范围确定箱子的个数,将序列按关键字放入箱中,输出非空箱的关键字。 在桶内分配和收集,及对各桶进行插入排序的时间为O(n),算法的期望时间是O(n),最坏时间是O(n^2)。 8.6.2基数排序 实现过程:按基数设置箱子,对关键字从低位到高位依次进行箱排序。 算法的最好时间是O(d*n+d*rd);最坏时间是O(d*n+d*rd);平均时间是O(d*n+d*rd);辅助空间O(n+rd);是一种稳定排序; 8.7各种内部排序方法的比较和选择 按平均时间复杂度分为: 1) 平方阶排序:直接插入、直接选择、冒泡排序; 2) 线性对数阶:快速排序、堆排序、归并排序; 3) 指数阶:希尔排序; 4) 线性阶:箱排序、基数排序。 选择合适排序方法的因素:1)待排序的记录数;2)记录的大小;3)关键字的结构和初始状态;4)对稳定性的要求;5)语言工具的条件;6)存储结构;7)时间和辅助空间复杂度。 结论: 1) 若规模较小可采用直接插入或直接选择排序; 2) 若文件初始状态基本有序可采用直接插入、冒泡或随机快速排序; 3) 若规模较大可采用快速排序、堆排序或归并排序; 4) 任何借助于比较的排序,至少需要O(nlog2n)的时间,箱排序和基数排序只适用于有明显结构特征的关键字; 5) 有的语言没有提供指针及递归,使归并、快速、基数排序算法复杂; 6) 记录规模较大时为避免大量移动记录可用链表作为存储结构,如插入、归并、基数排序,但快速、堆排序在链表上难以实现,可提取关键字建立索引表,然后对索引表排序。 附二: 第八章排序 ************************************************************************************* 记录中可用某一项来标识一个记录,则称为关键字项,该数据项的值称为关键字。 排序是使文件中的记录按关键字递增(或递减)次序排列起来。·基本操作:比较关键字大小;改变指向记录的指针或移动记录。 ·存储结构:顺序结构、链表结构、索引结构。 经过排序后这些具有相同关键字的记录之间的相对次序保持不变,则称这种排序方法是稳定的,否则排序算法是不稳定的。 排序过程中不涉及数据的内、外存交换则称之为"内部排序"(内排序),反之,若存在数据的内外存交换,则称之为外排序。 内部排序方法可分五类:插入排序、选择排序、交换排序、归并排序和分配排序。 评价排序算法好坏的标准主要有两条:执行时间和所需的辅助空间,另外算法的复杂程序也是要考虑的一个因素。 ************************************************************************************* 插入排序:·直接插入排序: ·逐个向前插入到合适位置。 ·哨兵(监视哨)有两个作用: ·作为临变量存放 R[i] 复制代码 ·是在查找循环中用来监视下标变量j是否越界。 ·直接插入排序是就地的稳定排序。时间复杂度为O(n^2),比较次数为(n+2)(n-1)/2;移动次数为(n+4)(n-1)/2; ·希尔排序: ·等间隔的数据比较并按要求顺序排列,最后间隔为1。 ·希尔排序是就地的不稳定排序。时间复杂度为O(n^1.25),比较次数为(n^1.25);移动次数为(1.6n^1.25); 交换排序:·冒泡排序:·自下向上确定最轻的一个。·自上向下确定最重的一个。·自下向上确定最轻的一个,后自上向下确定最重的一个。 ·冒泡排序是就地的稳定排序。时间复杂度为O(n^2),比较次数为n(n-1)/2;移动次数为3n(n-1)/2; ·快速排序:·以第一个元素为参考基准,设定、动两个指针,发生交换后指针交换位置,直到指针重合。重复直到排序完成。 ·快速排序是非就地的不稳定排序。时间复杂度为O(nlog2n),比较次数为n(n-1)/2; 选择排序:·直接选择排序: ·选择最小的放在比较区前。 ·直接选择排序就地的不稳定排序。时间复杂度为O(n^2)。比较次数为n(n-1)/2; ·堆排序 ·建堆:按层次将数据填入完全二叉树,从int(n/2)处向前逐个调整位置。 ·然后将树根与最后一个叶子交换值并断开与树的连接并重建堆,直到全断开。 ·堆排序是就地不稳定的排序,时间复杂度为O(nlog2n),不适宜于记录数较少的文件。。 归并排序: ·先两个一组排序,形成(n+1)/2组,再将两组并一组,直到剩下一组为止。 ·归并排序是非就地稳定排序,时间复杂度是O(nlog2n), 分配排序:·箱排序: ·按关键字的取值范围确定箱子数,按关键字投入箱子,链接所有非空箱。 ·箱排序的平均时间复杂度是线性的O(n). ·基数排序:·从低位到高位依次对关键字进行箱排序。 ·基数排序是非就稳定的排序,时间复杂度是O(d*n+d*rd)。 各种排序方法的比较和选择: ·.待排序的记录数目n;n较大的要用时间复杂度为O(nlog2n)的排序方法; ·记录的大小(规模);记录大最好用链表作为存储结构,而快速排序和堆排序在链表上难于实现; ·关键字的结构及其初始状态; ·对稳定性的要求; ·语言工具的条件; ·存储结构; ·时间和辅助空间复杂度。 排序(sort)或分类 所谓排序,就是要整理文件中的记录,使之按关键字递增(或递减)次序排列起来。其确切定义如下: 输入:n个记录R1,R2,…,Rn,其相应的关键字分别为K1,K2,…,Kn。 输出:Ril,Ri2,…,Rin,使得Ki1≤Ki2≤…≤Kin。(或Ki1≥Ki2≥…≥Kin)。 1.被排序对象--文件 被排序的对象--文件由一组记录组成。 记录则由若干个数据项(或域)组成。其中有一项可用来标识一个记录,称为关键字项。该数据项的值称为关键字(Key)。 注意: 在不易产生混淆时,将关键字项简称为关键字。 2.排序运算的依据--关键字 用来作排序运算依据的关键字,可以是数字类型,也可以是字符类型。 关键字的选取应根据问题的要求而定。 【例】在高考成绩统计中将每个考生作为一个记录。每条记录包含准考证号、姓名、各科的分数和总分数等项内容。若要惟一地标识一个考生的记录,则必须用"准考证号"作为关键字。若要按照考生的总分数排名次,则需用"总分数"作为关键字。 排序的稳定性 当待排序记录的关键字均不相同时,排序结果是惟一的,否则排序结果不唯一。 在待排序的文件中,若存在多个关键字相同的记录,经过排序后这些具有相同关键字的记录之间的相对次序保持不变,该排序方法是稳定的;若具有相同关键字的记录之间的相对次序发生变化,则称这种排序方法是不稳定的。 注意: 排序算法的稳定性是针对所有输入实例而言的。即在所有可能的输入实例中,只要有一个实例使得算法不满足稳定性要求,则该排序算法就是不稳定的。 排序方法的分类 1.按是否涉及数据的内、外存交换分 在排序过程中,若整个文件都是放在内存中处理,排序时不涉及数据的内、外存交换,则称之为内部排序(简称内排序);反之,若排序过程中要进行数据的内、外存交换,则称之为外部排序。 注意: ① 内排序适用于记录个数不很多的小文件 ② 外排序则适用于记录个数太多,不能一次将其全部记录放人内存的大文件。 2.按策略划分内部排序方法 可以分为五类:插入排序、选择排序、交换排序、归并排序和分配排序。 排序算法分析 1.排序算法的基本操作 大多数排序算法都有两个基本的操作: (1) 比较两个关键字的大小; (2) 改变指向记录的指针或移动记录本身。 注意: 第(2)种基本操作的实现依赖于待排序记录的存储方式。 2.待排文件的常用存储方式 (1) 以顺序表(或直接用向量)作为存储结构 排序过程:对记录本身进行物理重排(即通过关键字之间的比较判定,将记录移到合适的位置) (2) 以链表作为存储结构 排序过程:无须移动记录,仅需修改指针。通常将这类排序称为链表(或链式)排序; (3) 用顺序的方式存储待排序的记录,但同时建立一个辅助表(如包括关键字和指向记录位置的指针组成的索引表) 排序过程:只需对辅助表的表目进行物理重排(即只移动辅助表的表目,而不移动记录本身)。适用于难于在链表上实现,仍需避免排序过程中移动记录的排序方法。 3.排序算法性能评价 (1) 评价排序算法好坏的标准 评价排序算法好坏的标准主要有两条: ① 执行时间和所需的辅助空间 ② 算法本身的复杂程度 (2) 排序算法的空间复杂度 若排序算法所需的辅助空间并不依赖于问题的规模n,即辅助空间是O(1),则称之为就地排序(In-PlaceSou)。 非就地排序一般要求的辅助空间为O(n)。 (3) 排序算法的时间开销 大多数排序算法的时间开销主要是关键字之间的比较和记录的移动。有的排序算法其执行时间不仅依赖于问题的规模,还取决于输入实例中数据的状态。

马铭芳 2019-12-02 01:19:07 0 浏览量 回答数 0

问题

八大排序算法

琴瑟 2019-12-01 20:54:01 14297 浏览量 回答数 5

回答

目前支持指定公式(formula)排序,支持基本运算(算术运算、关系运算、逻辑运算、位运算、条件运算)、数学函数和排序特征(feature)等。目前的排序效果对于大多数应用都够用了,比如淘点点,来往,神马小说搜索等。后续会支持script方式。 目前阿里内部的不少应用都在使用,包括淘点点、来往,神马,淘宝搜索部分应用等,官方保证的可用性是99.99%。实质上2014年整年都没出现过搜索不可用的情况。 价格已经出来了,价格是国外同类应用的10%~30%。 目前OpenSearch支持数据源为多表,暂不支持父子文档等多层文档结构。对于收据推送,如果你的数据在阿里云的OSS,RDS,ODPS中,只需要简单配置,数据就可以自动同步到OpenSearch,还可以通过API,ADK自助推送数据。 “答案来源于网络,供您参考”

牧明 2019-12-02 02:15:13 0 浏览量 回答数 0

问题

云数据库Redis 标准版-单副本简介

云栖大讲堂 2019-12-01 21:19:13 1106 浏览量 回答数 0

回答

本教程介绍了如何利用弹性伸缩均衡分布ECS实例,并组合使用按量付费ECS实例和抢占式实例,以更低的成本部署高可用计算集群。 前提条件 使用本教程进行操作前,请确保您已经注册了阿里云账号。如还未注册,请先完成账号注册。 为应用的ECS实例创建了自定义镜像,具体操作请参见使用实例创建自定义镜像。 业务场景 某在线广告提供商应用机器学习精准投放广告,在业务高峰期会临时需要大量计算资源,成本较高,也可能存在ECS实例库存不足、手动创建ECS实例操作仓促、ECS实例临时停止服务等问题,存在一定的业务受损风险。 假设您的应用面向以下场景,也可以采用类似解决方案: 分布式大数据计算。 人工智能训练。 解决方案 弹性伸缩可以快速交付一个计算集群,同时利用均衡分布策略自动将计算节点分散在多个可用区,并实时检测ECS实例的运行状况,确保计算集群的高可用性。 您可以采用以下方案: 通过弹性伸缩将计算节点分散在多个可用区,同时指定多种实例规格。 组合使用按量实例和抢占式实例,以低成本购买ECS实例。伸缩组会按照单位vCPU的价格从低到高排序,优先选择单位vCPU价格更低的实例规格。 示意图如下: 业务收益 利用弹性伸缩部署高可用计算集群,您可以获得以下收益: 零运维成本 您只需提前配置扩缩容策略。负载增加时,伸缩组自动创建ECS实例,并将ECS实例添加到RDS实例的白名单;负载降低时,伸缩组自动将ECS实例从RDS实例的白名单中移除,然后释放ECS实例。整个过程自动触发和完成,无需人工干预。 超高性价比 弹性伸缩支持组合使用按量实例和抢占式实例,抢占式实例最低能以一折的价格购得ECS实例,性价比超高。如果抢占式实例库存不足,也会以按量实例的方式交付,保证交付结果。 天然高可用 均衡分布策略实现自动分散部署计算节点,避免因单可用区中库存不足等原因导致服务不可用,而且默认开启的健康检查功能可以确保伸缩组内ECS实例都处于可用状态。 操作步骤 请根据您的业务架构评估业务模块,为需要部署高可用集群的业务模块创建伸缩组,并为伸缩配置选择应用实例的自定义镜像,确保自动创建出的ECS实例符合应用的要求。 登录弹性伸缩控制台。 单击创建伸缩组。 配置伸缩组信息并完成伸缩组创建。 伸缩组内最小实例数设置为100。 组内实例配置信息来源设置为自定义伸缩配置。 选择多个可用区下的虚拟交换机。 多可用区扩容模式设置为均衡分布策略。 绑定当前业务模块所使用的RDS实例。 请根据需要配置其它信息,详细信息请参见创建伸缩组。 单击创建伸缩配置。 配置伸缩配置信息并完成伸缩配置创建。 计费方式设置为抢占式实例。 镜像设置为您的自定义镜像。 请根据需要配置其它信息,详细信息请参见创建伸缩配置。 确定启用伸缩配置。 确定启用伸缩组。 执行结果 启用伸缩组后,伸缩组自动在所选可用区中均衡部署满100台ECS实例,单可用区中因库存不足等原因引发问题时,对整个应用的影响有限。伸缩组在抢占式实例被回收后自动创建新的抢占式实例,并自动移除进入不健康状态的ECS实例并创建新的ECS实例。保证集群高可用性的同时,也降低了成本。

1934890530796658 2020-03-22 13:27:57 0 浏览量 回答数 0

回答

约翰逊法是作业排序中的一种排序方法。这种方法适用的条件是:n个工件经过二、三台设备(有限台设备)加工,所有工件在有限设备上加工的次序相同。为了便于阐述这种方法的具体做法,下面结合一个例子来进行说明: 例:有五个工件在二台设备上加工,加工顺序相同,现在设备1上加工,再在设备2上加工,工时列于下表1中,用约翰逊法排序。 表1 加工工时表 具体步骤为: 第一步,取出最小工时t12=2。如该工时为第一工序的,则最先加工;反之,则放在最后加工。此例是A工件第二工序时间,按规则排在最后加工。 第二步,将该已排序工作划去。 第三步,对余下的工作重复上述排序步骤,直至完毕。此时t21=t42=3,B工件第一工序时间最短,最先加工;D工件第二工序时间最短,排在余下的工件中最后加工。最后得到的排序为:B-C-E-D-A。整批工件的停留时间为27分钟。 更一般的情况是工件加工顺序不同,称为随机性排序。由杰克逊对约翰逊法稍加改进后得到求解方法,称为杰克逊算法。 [周期性生产类型作业计划编制] 周期性生产类型由于是多产品轮番生产,零件数量又十分大,作业计划的难度比较大。作业计划分厂部计划和车间计划。在车间计划中的作业排序问题是一件十分困难的工作。 一、 厂部作业计划 厂部作业计划一般只以产品作为计划单位,如产品结构比较简单,厂部计划的能力又很强,也可做部件计划。在确定了周期性生产类型的期量标准的基础上,根据其量标准下达产品的生产批量,以及投入出产的时间,就是厂部计划的主要内容。实际上,采用这种生产方式的企业由于产品大结构复杂,产品生产周期比较长,往往都超过一个月。厂部都是根据订单安排月度计划,当品种数量比较多时,很难做批量计划,这时的厂部计划主要下达月度的生产总量和具体的产品品种规格。由于产品周期垮了数个月,还要下达产品的出产日期、毛坯的投入出产期和机加工的投入出产期,计划单位为产品。部件和零件的生产计划由车间考虑。 二、 车间作业计划 车间接到的生产任务是一个计划期的总生产量,车间要进一步细分任务,分批生产。主要考虑的问题是生产能力的平衡、零部件数量上的配套、提高设备利用率、缩短生产周期、减少在制品资金占用量,所以计划难度很高。大多数企业都是凭经验安排计划。作车间作业计划时,有一些定量模型和方法可供适用,如多品种轮番生产的最小生产费用计划方法就是其中常用的一种。。 三、 作业排序 周期性生产类型的生产组织形式是工艺专业化,车间往往就是生产过程中的某个工艺阶段,每个零件在车间内要经过某几个工序的加工。因此车间的作业计划中工件加工的排序问题是一个难点。其难处在于零件种类多,加工的工艺流程和加工工时差别较大。一般采取重点管住关键零件和关键设备的方法。 零件加工排序问题一般可作如下描述:n种零件在有m台设备的车间内加工,每种零件加工所需要的设备数可以是不同的,加工的顺序也可以不同,要求排出效果尽可能好的工件加工次序。目前对这个问题的研究所取得的成果只能解决少数几种特殊条件下的排序问题,其思路是先确定一个优化目标,再寻求解题模型。通常取一批加工任务在车间内停留的时间最短为优化目标。 下面做简要介绍。 1、 n个工件在一台设备上加工 这是一种最简单的排序问题,只要按如下规则排序既可以了。 式中,ti为第i个工件的加工工时,该式的排序规律是加工工时短的工件先加工。 2、 n个工件需经过二台设备加工 比较简单的一种情况是所有工件在二台设备上加工的次序相同,此时用约翰逊法可以求解。更一般的情况是工件加工顺序不同,称为随机排序。由杰克逊对约翰逊法稍加改进后得到求解方法,称为杰克逊算法。 3、 n个工件在三台设备上加工 随着设备数量的增加,优化难度加大。在三台设备上加工,当满足一定条件时有优化方法。如果n个工件的加工顺序相同,且满足以下两条件中的任何一条,可用约翰逊法求解。 算法如下: 第一步,令 Ti1=ti1+ti2 Ti2=ti2+ti3 得到两台虚拟设备的工序工时; 第二步,对二台虚拟设备,按约翰逊法排序。 对于三台设备的随机性问题还没有简便的优化方法。 4、 二个工件在m台设备上加工 这种情况下可用分枝定界法求解,如设备数量较大,则工作量很大,通常采用图解法。但图解法不能保证是最优解。 上述四种情况在实际生产中只是少数情况,可见多数情况下还没有好的解法,一般可根据排队理论采用计算机模拟方法。 [最小批量法] 最小批量法是确定批量和生产间隔期时常用的一种以量定期法。此方法从设备利用和生产率方面考虑批量的选择,要时的选定的批量能够保证一次准备结束时间对批量加工时间的比值不大于给定的数值。可用下式表示: 损失系数由经验确定,可参考下表1: 表1 准备结束时间损失系数 [经济批量法] 经济批量法是确定批量和生产间隔期时常用的一种以量定期方法。生产费用与批量之间存在着函数关系,批量主要通过两方面因素影响生产费用:一是生产准备费用,这部分费用随生产批次增减而变化;二是保管费用,即在制品在存储保管期间所发生的费用,如仓库管理费用、资金呆滞损失、存货的损耗费用等。这些费用与批量大小和存储时间长短有关。 [周期性生产类型作业计划的期量标准] 周期性生产类型的作业计划的期量标准主要包括批量和生产间隔期、生产周期和生产提前期,合理制定期量标准可以使生产资源得到较好的利用。下面分别阐述这些期量标准。 一、 批量和生产间隔期 采用周期性生产类型的企业,由于产品体积大、结构复杂,再加上品种多等因素,不能采取月度计划一次投料生产的方法。否则不但使在制品充满生产现场,使现场一片混乱,甚至发生生产场地不够用的现象,还会占用大量的流动资金。但又不能像流水生产那样每天小批量的投料生产,所以需要确定一个合理的生产批量。 批量是指一次性投入生产的同种制品的数量。每投一次需要消耗一次准备结束时间,,用于熟悉图纸、领取工卡量居、调整设备工装等等作业。生产间隔期是相邻两批同种工件投入(或产出)的时间间隔。在周期性重复生产条件下批量和生产间隔期有如下关系: 批量=平均日产量*生产间隔期 在生产任务稳定条件下,日产量不变,则批量与生产间隔期成正比。批量大,则间隔期长,相应的在制品数量也大,生产周期较长,这样对使用流动资金是不利的。反之,如批量小,会导致频繁变动产品,增加准备结束作业次数,多消耗准备结束时间,降低设备利用率,也是不利的。因此确定批量和生产间隔期,需要在这些因素之间进行平衡,达到既有利于流动资金的有效使用,又提高设备的利用率。 确定批量和生产间隔期通常有两种方式。 (一) 以量定期法 当平均日产量不变时,批量与生产间隔期互为因果关系,此方法的思路为,先根据综合经济效果确定批量,然后推算生产间隔期,对间隔期做适当的修正后,再对批量做调整。这种方式又有几种具体的方法:最小批量法、经济批量法等。 (二) 以期定量法 此方法的思路为先确定生产间隔期,在推算出批量。按照零件复杂程度、体积大小、价值高低确定各个零件的生产间隔期,然后根据生产数量推算出批量。为了管理上的方便企业都事先制定好标准生产间隔期,数值通常取月工作日(20天)的约数,如1天、2天、4天、5天(一周)、10天、20天(1月)等等。采用这种方法使生产间隔期和相应的批量规范化了,便于管理。标准生产间隔期表如下表1所示: 表1 标准生产间隔期表 生产间隔期与批量的总数不宜太多,一般不超过六种为宜。 二、 生产周期 生产周期是指从加工对象投产起,到它完工时止所经历的日历时间。生产周期这一期量标准是编制生产作业计划和确定产品及其零件在各工艺阶段投入和产出日期的主要依据,是成批生产作业计划的一项重要期量标准。 对产品来说,它的生产周期包括毛坯准备、零件加工、部件装配、成品总装、油漆,直到入库为止的全部时间,如下图2所示: 图2 产品生产周期结构示意图 生产周期可以按零件工序、零件加工过程和产品进行计算。其中零件工序生产周期是计算产品生产周期的基础。这里分别介绍它们的计算方法: 1、 零件工序生产周期 指一批零件在某道工序上的作业时间。计算公式如下: 式中:Tp--修正后的零件加工生产周期; a--为平行系数。 上述公式也适用于计算装配阶段的生产周期。 2、 产品生产周期 产品生产周期是各工艺阶段的生产周期与所有保险期之和。 [多品种轮番生产的最小生产费用计划方法] 多品种轮番生产的最小生产费用计划方法是车间制定生产作业计划时常可用到的一种很有用的定量方法。这种方法的思路是将计划期划分为几个长度相等的循环流程,在每个循环流程中实行多品种轮番生产;以循环流程长度作为因变量,列出生产费用函数,求出最小费用循环流程;最后从该流程长度推算出各品种的批量。 设: Di--第i种产品计划期需求量; Pi--第i种产品计划期生产能力; tmi--第i种产品单件加工时间,tmi=1/Pi; ti--第i种产品批量生产时间,ti=Qi·tmi; tsi--第i种产品准备与结束时间; Si--第i种产品一次准备、结束单位时间的费用; Ci--第i种产品单位产品计划期储存费用; Qi--第i种产品生产批量; Ii--第i种产品在制品数量; L--循环流程长度,

云篆 2019-12-02 01:19:19 0 浏览量 回答数 0

问题

十大经典排序算法大梳理 7月6日 【今日算法】

游客ih62co2qqq5ww 2020-07-07 02:04:48 1002 浏览量 回答数 1

回答

首先遵循sql规范,然后可以提高你的并行度,最后,聚合的sql肯定会遇到shuffle,这就需要你解决好shuffle的问题,下面是我这你的一些技巧,希望对你有帮助 /** * @author BlueCat丶懒猫 * @title: SparkShuffleSolutions * @date 2019/11/18 12:37 * @desc: * 2.1 数据倾斜原理 *    在进行shuffle的时候,必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理,此时如果某个key对应的数据量特别大的话,就会发生数据倾斜 * 2.2 数据倾斜问题发现与定位 *    通过Spark Web UI来查看当前运行的stage各个task分配的数据量,从而进一步确定是不是task分配的数据不均匀导致了数据倾斜。 * 知道数据倾斜发生在哪一个stage之后,接着我们就需要根据stage划分原理,推算出来发生倾斜的那个stage对应代码中的哪一部分, * 这部分代码中肯定会有一个shuffle类算子。通过countByKey查看各个key的分布。 * 2.3 数据倾斜解决方案 *     2.3.1 过滤少数导致倾斜的key *     2.3.2 提高shuffle操作的并行度 *     2.3.3 局部聚合和全局聚合 => solution1 * 2.3.4 将reduce join转为map join((小表几百M或者一两G))  => solution2 * 2.3.5 采样倾斜key并分拆join操作(join的两表都很大,但仅一个RDD的几个key的数据量过大) => solution3 * 2.3.6 使用随机前缀和扩容RDD进行join(RDD中有大量的key导致数据倾斜) => solution4 * 4 spark shuffle参数调优 * spark.shuffle.file.buffer * 默认值:32k * 参数说明:该参数用于设置shuffle write task的BufferedOutputStream的buffer缓冲大小。将数据写到磁盘文件之前,会先写入buffer缓冲中,待缓冲写满之后,才会溢写到磁盘。 * 调优建议:如果作业可用的内存资源较为充足的话,可以适当增加这个参数的大小(比如64k),从而减少shuffle write过程中溢写磁盘文件的次数,也就可以减少磁盘IO次数,进而提升性能。在实践中发现,合理调节该参数,性能会有1%~5%的提升。 * spark.reducer.maxSizeInFlight * 默认值:48m * 参数说明:该参数用于设置shuffle read task的buffer缓冲大小,而这个buffer缓冲决定了每次能够拉取多少数据。 * 调优建议:如果作业可用的内存资源较为充足的话,可以适当增加这个参数的大小(比如96m),从而减少拉取数据的次数,也就可以减少网络传输的次数,进而提升性能。在实践中发现,合理调节该参数,性能会有1%~5%的提升。 * spark.shuffle.io.maxRetries * 默认值:3 * 参数说明:shuffle read task从shuffle write task所在节点拉取属于自己的数据时,如果因为网络异常导致拉取失败,是会自动进行重试的。该参数就代表了可以重试的最大次数。如果在指定次数之内拉取还是没有成功,就可能会导致作业执行失败。 * 调优建议:对于那些包含了特别耗时的shuffle操作的作业,建议增加重试最大次数(比如60次),以避免由于JVM的full gc或者网络不稳定等因素导致的数据拉取失败。在实践中发现,对于针对超大数据量(数十亿~上百亿)的shuffle过程,调节该参数可以大幅度提升稳定性。 * spark.shuffle.io.retryWait * 默认值:5s * 参数说明:具体解释同上,该参数代表了每次重试拉取数据的等待间隔,默认是5s。 * 调优建议:建议加大间隔时长(比如60s),以增加shuffle操作的稳定性。 * spark.shuffle.memoryFraction * 默认值:0.2 * 参数说明:该参数代表了Executor内存中,分配给shuffle read task进行聚合操作的内存比例,默认是20%。 * 调优建议:在资源参数调优中讲解过这个参数。如果内存充足,而且很少使用持久化操作,建议调高这个比例,给shuffle read的聚合操作更多内存,以避免由于内存不足导致聚合过程中频繁读写磁盘。在实践中发现,合理调节该参数可以将性能提升10%左右。 * spark.shuffle.manager * 默认值:sort * 参数说明:该参数用于设置ShuffleManager的类型。Spark 1.5以后,有三个可选项:hash、sort和tungsten-sort。HashShuffleManager是Spark 1.2以前的默认选项,但是Spark 1.2以及之后的版本默认都是SortShuffleManager了。tungsten-sort与sort类似,但是使用了tungsten计划中的堆外内存管理机制,内存使用效率更高。 * 调优建议:由于SortShuffleManager默认会对数据进行排序,因此如果你的业务逻辑中需要该排序机制的话,则使用默认的SortShuffleManager就可以;而如果你的业务逻辑不需要对数据进行排序,那么建议参考后面的几个参数调优,通过bypass机制或优化的HashShuffleManager来避免排序操作,同时提供较好的磁盘读写性能。这里要注意的是,tungsten-sort要慎用,因为之前发现了一些相应的bug。 * spark.shuffle.sort.bypassMergeThreshold * 默认值:200 * 参数说明:当ShuffleManager为SortShuffleManager时,如果shuffle read task的数量小于这个阈值(默认是200),则shuffle write过程中不会进行排序操作,而是直接按照未经优化的HashShuffleManager的方式去写数据,但是最后会将每个task产生的所有临时磁盘文件都合并成一个文件,并会创建单独的索引文件。 * 调优建议:当你使用SortShuffleManager时,如果的确不需要排序操作,那么建议将这个参数调大一些,大于shuffle read task的数量。那么此时就会自动启用bypass机制,map-side就不会进行排序了,减少了排序的性能开销。但是这种方式下,依然会产生大量的磁盘文件,因此shuffle write性能有待提高。 * spark.shuffle.consolidateFiles * 默认值:false * 参数说明:如果使用HashShuffleManager,该参数有效。如果设置为true,那么就会开启consolidate机制,会大幅度合并shuffle write的输出文件,对于shuffle read task数量特别多的情况下,这种方法可以极大地减少磁盘IO开销,提升性能。 * 调优建议:如果的确不需要SortShuffleManager的排序机制,那么除了使用bypass机制,还可以尝试将spark.shffle.manager参数手动指定为hash,使用HashShuffleManager,同时开启consolidate机制。在实践中尝试过,发现其性能比开启了bypass机制的SortShuffleManager要高出10%~30%。 */

BlueCat丶懒猫 2020-01-09 19:27:54 0 浏览量 回答数 0

问题

伸缩组:创建伸缩组

青蛙跳 2019-12-01 21:31:57 546 浏览量 回答数 0

回答

拿下代码,放入eclipse,{@fix:由于个人jdk配置,仅在jre1.6下运行},什么输出都没有。下面来说说原因:1、对于非volatile修饰的变量,尽管jvm的优化,会导致变量的可见性问题,但这种可见性的问题也只是在短时间内高并发的情况下发生,CPU执行时会很快刷新Cache,一般的情况下很难出现,而且出现这种问题是不可预测的,与jvm, 机器配置环境等都有关。所以在未修改flag1之前,i会一直自增。一旦flag1修改后,sleep了1s,在flag2为修改之前,while循环就退出了,所以基本不会看到输出。2、说说volatile的语义。volatile能保证可见性。其保证每次对volatile变量的读取会重新从主存中获取,以使得最新修改的值对其可见。(其大概的实现方式:每次写volatile变量时,会锁定系统总线,这样会导致其他CPU的Cache失效,这样下次读取时,CPU检测到Cache失效,会重新从主存中加载)。在jdk1.5之前,volatile只能保证可见性,但会re-order的问题,这也是著名的double-check-lock的问题(对此,可google出一大堆的文章)。在jdk1.5中,对volatile语义进行了增强,其保证jvm内存模型不会对volatile修饰的变量进行重排序(写volatile变量操作不会与其之前的读写操作重排,读volatile操作不会与其后的读写操作重排)[1], 之后double-check-lock才算实际的可用。3、volatile提供的可见性和禁止指令重排的语义可以满足一定程度的同步性需求。对于volatile变量的使用,文献[2]中给出最佳实践:1.写入变量时并不依赖变量的当前值,或者可以确保只有单一线程修改该变量值;2.变量不需要和其他成员变量一起参与类的状态不变性约束;3.访问变量时,没有其他额外的原因需要加锁。

蛮大人123 2019-12-02 01:58:18 0 浏览量 回答数 0

回答

1.使用key值前缀来作命名空间虽然说Redis支持多个数据库(默认32个,可以配置更多),但是除了默认的0号库以外,其它的都需要通过一个额外请求才能使用。所以用前缀作为命名空间可能会更明智一点。另外,在使用前缀作为命名空间区隔不同key的时候,最好在程序中使用全局配置来实现,直接在代码里写前缀的做法要严格避免,这样可维护性实在太差了。2.创建一个类似 ”registry” 的key用于标记key使用情况为了更好的管理你的key值的使用,比如哪一类key值是属于哪个业务的,你通常会在内部wiki或者什么地方创建一个文档,通过查询这个文档,我们能够知道Redis中的key都是什么作用。与之结合,一个推荐的做法是,在Redis里面保存一个registry值,这个值的名字可以类似于 key_registry 这样的,这个key对应的value就是你文档的位置,这样我们在使用Redis的时候,就能通过直接查询这个值获取到当前Redis的使用情况了。3.注意垃圾回收Redis是一个提供持久化功能的内存数据库,如果你不指定上面值的过期时间,并且也不进行定期的清理工作,那么你的Redis内存占用会越来越大,当有一天它超过了系统可用内存,那么swap上场,离性能陡降的时间就不远了。所以在Redis中保存数据时,一定要预先考虑好数据的生命周期,这有很多方法可以实现。比如你可以采用Redis自带的过期时间为你的数据设定过期时间。但是自动过期有一个问题,很有可能导致你还有大量内存可用时,就让key过期去释放内存,或者是内存已经不足了key还没有过期。如果你想更精准的控制你的数据过期,你可以用一个ZSET来维护你的数据更新程度,你可以用时间戳作为score值,每次更新操作时更新一下score,这样你就得到了一个按更新时间排序序列串,你可以轻松地找到最老的数据,并且从最老的数据开始进行删除,一直删除到你的空间足够为止。4.设计好你的Sharding机制Redis目前并不支持Sharding,但是当你的数据量超过单机内存时,你不得不考虑Sharding的事(注意:Slave不是用来做Sharding操作的,只是数据的一个备份和读写分离而已)。所以你可能需要考虑好数据量大了后的分片问题,比如你可以在只有一台机器的时候就在程序上设定一致性hash机制,虽然刚开始所有数据都hash到一台机器,但是当你机器越加越多的时候,你就只需要迁移少量的数据就能完成了。5.不要有个锤子看哪都是钉子当你使用Redis构建你的服务的时候,一定要记住,你只是找了一个合适的工具来实现你需要的功能。而不是说你在用Redis构建一个服务,这是很不同的,你把Redis当作你很多工具中的一个,只在合适使用的时候再使用它,在不合适的时候选择其它的方法。

落地花开啦 2019-12-02 01:48:56 0 浏览量 回答数 0

回答

索引,索引!!!为经常查询的字段建索引!! 但也不能过多地建索引。insert和delete等改变表记录的操作会导致索引重排,增加数据库负担。优化目标1.减少 IO 次数 IO永远是数据库最容易瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是 IO 操作所占用的,减少 IO 次数是 SQL 优化中需要第一优先考虑,当然,也是收效最明显的优化手段。2.降低 CPU 计算 除了 IO 瓶颈之外,SQL优化中需要考虑的就是 CPU 运算量的优化了。order by, group by,distinct … 都是消耗 CPU 的大户(这些操作基本上都是 CPU 处理内存中的数据比较运算)。当我们的 IO 优化做到一定阶段之后,降低 CPU 计算也就成为了我们 SQL 优化的重要目标优化方法改变 SQL 执行计划 明确了优化目标之后,我们需要确定达到我们目标的方法。对于 SQL 语句来说,达到上述2个目标的方法其实只有一个,那就是改变 SQL 的执行计划,让他尽量“少走弯路”,尽量通过各种“捷径”来找到我们需要的数据,以达到 “减少 IO 次数” 和 “降低 CPU 计算” 的目标分析复杂的SQL语句explain 例如: mysql> explain select from (select from ( select * from t3 where id=3952602) a) b; id select_type table type possible_keys key key_len ref rows Extra 1 PRIMARY system NULL NULL NULL NULL 1 2 DERIVED system NULL NULL NULL NULL 1 3 DERIVED t3 const PRIMARY,idx_t3_id PRIMARY 4 1 很显然这条SQL是从里向外的执行,就是从id=3 向上执行.show show tables或show tables from database_name; // 显示当前数据库中所有表的名称 show databases; // 显示mysql中所有数据库的名称 show columns from table_name from database_name; 或MySQL show columns from database_name.table_name; // 显示表中列名称 show grants for user_name@localhost; // 显示一个用户的权限,显示结果类似于grant 命令 show index from table_name; // 显示表的索引 show status; // 显示一些系统特定资源的信息,例如,正在运行的线程数量 show variables; // 显示系统变量的名称和值show processlist; // 显示系统中正在运行的所有进程,也就是当前正在执行的查询。 show table status; // 显示当前使用或者指定的database中的每个表的信息。信息包括表类型和表的最新更新时间 show privileges; // 显示服务器所支持的不同权限 show create database database_name; // 显示create database 语句是否能够创建指定的数据库 show create table table_name; // 显示create database 语句是否能够创建指定的数据库 show engies; // 显示安装以后可用的存储引擎和默认引擎。 show innodb status; // 显示innoDB存储引擎的状态 show logs; // 显示BDB存储引擎的日志 show warnings; // 显示最后一个执行的语句所产生的错误、警告和通知 show errors; // 只显示最后一个执行语句所产生的错误关于enum 存在争议。 对于取值有限且固定的字段,推荐使用enum而非varchar。但是!!其他数据库可能不支持,导致了难于迁移的问题。开启缓存查询 对于完全相同的sql,使用已经存在的执行计划,从而跳过解析和生成执行计划的过程。 应用场景:有一个不经常变更的表,且服务器收到该表的大量相同查询。对于频繁更新的表,查询缓存是不适合的 Mysql 判断是否命中缓存的办法很简单,首先会将要缓存的结果放在引用表中,然后使用查询语句,数据库名称,客户端协议的版本等因素算出一个hash值,这个hash值与引用表中的结果相关联。如果在执行查询时,根据一些相关的条件算出的hash值能与引用表中的数据相关联,则表示查询命中 查询必须是完全相同的(逐字节相同)才能够被认为是相同的。另外,同样的查询字符串由于其它原因可能认为是不同的。使用不同的数据库、不同的协议版本或者不同 默认字符集的查询被认为是不同的查询并且分别进行缓存。 下面sql查询缓存认为是不同的: SELECT * FROM tbl_name Select * from tbl_name 缓存机制失效的场景 如果查询语句中包含一些不确定因素时(例如包含 函数Current()),该查询不会被缓存,不确定因素主要包含以下情况 · 引用了一些返回值不确定的函数 · 引用自定义函数(UDFs)。 · 引用自定义变量。 · 引用mysql系统数据库中的表。 · 下面方式中的任何一种: SELECT ...IN SHARE MODE SELECT ...FOR UPDATE SELECT ...INTO OUTFILE ... SELECT ...INTO DUMPFILE ... SELECT * FROM ...WHERE autoincrement_col IS NULL · 使用TEMPORARY表。 · 不使用任何表。 · 用户有某个表的列级别权限。额外的消耗 如果使用查询缓存,在进行读写操作时会带来额外的资源消耗,消耗主要体现在以下几个方面 · 查询的时候会检查是否命中缓存,这个消耗相对较小 · 如果没有命中查询缓存,MYSQL会判断该查询是否可以被缓存,而且系统中还没有对应的缓存,则会将其结果写入查询缓存 · 如果一个表被更改了,那么使用那个表的所有缓冲查询将不再有效,并且从缓冲区中移出。这包括那些映射到改变了的表的使用MERGE表的查询。一个表可以被许多类型的语句更改,例如INSERT、UPDATE、DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE。 对于InnoDB而言,事物的一些特性还会限制查询缓存的使用。当在事物A中修改了B表时,因为在事物提交之前,对B表的修改对其他的事物而言是不可见的。为了保证缓存结果的正确性,InnoDB采取的措施让所有涉及到该B表的查询在事物A提交之前是不可缓存的。如果A事物长时间运行,会严重影响查询缓存的命中率 查询缓存的空间不要设置的太大。 因为查询缓存是靠一个全局锁操作保护的,如果查询缓存配置的内存比较大且里面存放了大量的查询结果,当查询缓存失效的时候,会长时间的持有这个全局锁。因为查询缓存的命中检测操作以及缓存失效检测也都依赖这个全局锁,所以可能会导致系统僵死的情况静态表速度更快定长类型和变长类型 CHAR(M)定义的列的长度为固定的,M取值可以为0~255之间,当保存CHAR值时,在它们的右边填充空格以达到指定的长度。当检索到CHAR值时,尾部的空格被删除掉。在存储或检索过程中不进行大小写转换。CHAR存储定长数据很方便,CHAR字段上的索引效率级高,比如定义char(10),那么不论你存储的数据是否达到了10个字节,都要占去10个字节的空间,不足的自动用空格填充。 VARCHAR(M)定义的列的长度为可变长字符串,M取值可以为0~65535之间,(VARCHAR的最大有效长度由最大行大小和使用的字符集确定。整体最大长度是65,532字节)。VARCHAR值保存时只保存需要的字符数,另加一个字节来记录长度(如果列声明的长度超过255,则使用两个字节)。VARCHAR值保存时不进行填充。当值保存和检索时尾部的空格仍保留,符合标准SQL。varchar存储变长数据,但存储效率没有CHAR高。 如果一个字段可能的值是不固定长度的,我们只知道它不可能超过10个字符,把它定义为 VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度+1。空间上考虑,用varchar合适;从效率上考虑,用char合适,关键是根据实际情况找到权衡点。VARCHAR和TEXT、BlOB类型 VARCHAR,BLOB和TEXT类型是变长类型,对于其存储需求取决于列值的实际长度(在前面的表格中用L表示),而不是取决于类型的最大可能尺寸。 BLOB和TEXT类型需要1,2,3或4个字节来记录列值的长度,这取决于类型的最大可能长度。VARCHAR需要定义大小,有65535字节的最大限制;TEXT则不需要。如果你把一个超过列类型最大长度的值赋给一个BLOB或TEXT列,值被截断以适合它。 一个BLOB是一个能保存可变数量的数据的二进制的大对象。4个BLOB类型TINYBLOB、BLOB、MEDIUMBLOB和LONGBLOB仅仅在他们能保存值的最大长度方面有所不同。 BLOB 可以储存图片,TEXT不行,TEXT只能储存纯文本文件。 在BLOB和TEXT类型之间的唯一差别是对BLOB值的排序和比较以大小写敏感方式执行,而对TEXT值是大小写不敏感的。换句话说,一个TEXT是一个大小写不敏感的BLOB。 效率来说基本是char>varchar>text,但是如果使用的是Innodb引擎的话,推荐使用varchar代替char char和varchar可以有默认值,text不能指定默认值静态表和动态表 静态表字段长度固定,自动填充,读写速度很快,便于缓存和修复,但比较占硬盘,动态表是字段长度不固定,节省硬盘,但更复杂,容易产生碎片,速度慢,出问题后不容易重建。当只需要一条数据的时候,使用limit 1 表记录中的一行尽量不要超过一个IO单元 区分in和exist select * from 表A where id in (select id from 表B)这句相当于select from 表A where exists(select from 表B where 表B.id=表A.id)对于表A的每一条数据,都执行select * from 表B where 表B.id=表A.id的存在性判断,如果表B中存在表A当前行相同的id,则exists为真,该行显示,否则不显示 区分in和exists主要是造成了驱动顺序的改变(这是性能变化的关键),如果是exists,那么以外层表为驱动表,先被访问,如果是IN,那么先执行子查询。 所以IN适合于外表大而内表小的情况;EXISTS适合于外表小而内表大的情况复杂多表尽量少用join MySQL 的优势在于简单,但这在某些方面其实也是其劣势。MySQL 优化器效率高,但是由于其统计信息的量有限,优化器工作过程出现偏差的可能性也就更多。对于复杂的多表 Join,一方面由于其优化器受限,再者在 Join 这方面所下的功夫还不够,所以性能表现离 Oracle 等关系型数据库前辈还是有一定距离。但如果是简单的单表查询,这一差距就会极小甚至在有些场景下要优于这些数据库前辈。尽量用join代替子查询 虽然 Join 性能并不佳,但是和 MySQL 的子查询比起来还是有非常大的性能优势。 MySQL需要为内层查询语句的查询结果建立一个临时表。然后外层查询语句在临时表中查询记录。查询完毕后,MySQL需要插销这些临时表。所以在MySQL中可以使用连接查询来代替子查询。连接查询不需要建立临时表,其速度比子查询要快。尽量少排序 排序操作会消耗较多的 CPU 资源,所以减少排序可以在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL 的响应时间。 对于MySQL来说,减少排序有多种办法,比如: 上面误区中提到的通过利用索引来排序的方式进行优化 减少参与排序的记录条数 非必要不对数据进行排序尽量避免select * 大多数关系型数据库都是按照行(row)的方式存储,而数据存取操作都是以一个固定大小的IO单元(被称作 block 或者 page)为单位,一般为4KB,8KB… 大多数时候,每个IO单元中存储了多行,每行都是存储了该行的所有字段(lob等特殊类型字段除外)。 所以,我们是取一个字段还是多个字段,实际上数据库在表中需要访问的数据量其实是一样的。 也有例外情况,那就是我们的这个查询在索引中就可以完成,也就是说当只取 a,b两个字段的时候,不需要回表,而c这个字段不在使用的索引中,需要回表取得其数据。在这样的情况下,二者的IO量会有较大差异。尽量少or 当 where 子句中存在多个条件以“或”并存的时候,MySQL 的优化器并没有很好的解决其执行计划优化问题,再加上 MySQL 特有的 SQL 与 Storage 分层架构方式,造成了其性能比较低下,很多时候使用 union all 或者是union(必要的时候)的方式来代替“or”会得到更好的效果。尽量用 union all 代替 union union 和 union all 的差异主要是前者需要将两个(或者多个)结果集合并后再进行唯一性过滤操作,这就会涉及到排序,增加大量的 CPU 运算,加大资源消耗及延迟。所以当我们可以确认不可能出现重复结果集或者不在乎重复结果集的时候,尽量使用 union all 而不是 union。尽量早过滤 在 SQL 编写中同样可以使用这一原则来优化一些 Join 的 SQL。比如我们在多个表进行分页数据查询的时候,我们最好是能够在一个表上先过滤好数据分好页,然后再用分好页的结果集与另外的表 Join,这样可以尽可能多的减少不必要的 IO 操作,大大节省 IO 操作所消耗的时间。避免类型转换 这里所说的“类型转换”是指 where 子句中出现 column 字段的类型和传入的参数类型不一致的时候发生的类型转换: 人为在column_name 上通过转换函数进行转换直接导致 MySQL(实际上其他数据库也会有同样的问题)无法使用索引,如果非要转换,应该在传入的参数上进行转换,由数据库自己进行转换, 如果我们传入的数据类型和字段类型不一致,同时我们又没有做任何类型转换处理,MySQL 可能会自己对我们的数据进行类型转换操作,也可能不进行处理而交由存储引擎去处理,这样一来,就会出现索引无法使用的情况而造成执行计划问题。优先优化高并发的 SQL,而不是执行频率低某些“大”SQL 对于破坏性来说,高并发的 SQL 总是会比低频率的来得大,因为高并发的 SQL 一旦出现问题,甚至不会给我们任何喘息的机会就会将系统压跨。而对于一些虽然需要消耗大量 IO 而且响应很慢的 SQL,由于频率低,即使遇到,最多就是让整个系统响应慢一点,但至少可能撑一会儿,让我们有缓冲的机会。从全局出发优化,而不是片面调整 尤其是在通过调整索引优化 SQL 的执行计划的时候,千万不能顾此失彼,因小失大。尽可能对每一条运行在数据库中的SQL进行 explain 知道 SQL 的执行计划才能判断是否有优化余地,才能判断是否存在执行计划问题。在对数据库中运行的 SQL 进行了一段时间的优化之后,很明显的问题 SQL 可能已经很少了,大多都需要去发掘,这时候就需要进行大量的 explain 操作收集执行计划,并判断是否需要进行优化。尽量避免where子句中对字段进行null值的判断 会导致引擎放弃索引,进而进行全表扫描。 尽量不要给数据库留null值,尽可能地使用not null填充数据库。可以为每个null型的字段设置一个和null对应的实际内容表述。避免在where中使用!=, >, <操作符 否则引擎放弃使用索引,进行全表扫描。常用查询字段建索引避免在where中使用or imagein和not in关键词慎用,容易导致全表扫面 对连续的数值尽量用between通配符查询也容易导致全表扫描避免在where子句中使用局部变量 sql只有在运行时才解析局部变量。而优化程序必须在编译时访问执行计划,这时并不知道变量值,所以无法作为索引的输入项。 image避免在where子句中对字段进行表达式操作 会导致引擎放弃使用索引 image避免在where子句中对字段进行函数操作 image不要where子句的‘=’左边进行函数、算术运算或其他表达式运算 系统可能无法正确使用索引避免update全部字段 只update需要的字段。频繁调用会引起明显的性能消耗,同时带来大量日志。索引不是越多越好 一个表的索引数最好不要超过6个尽量使用数字型字段而非字符型 因为处理查询和连接时会逐个比较字符串的每个字符,而对于数字型而言只需要比较一次就够了。尽可能用varchar/nvarchar代替char/nchar 变长字段存储空间小,对于查询来说,在一个相对较小的字段内搜索效率更高。。。?避免频繁创建和删除临时表,减少系统表资源消耗select into和create table 新建临时表时,如果一次性插入数据量很大,使用select into代替create table,避免造成大量log,以提高速度。 如果数据量不大,为了缓和系统表的资源,先create table,再insert。 拆分大的DELETE和INSERT语句 因为这两个操作是会锁表的,对于高访问量的站点来说,锁表时间内积累的访问数、数据库连接、打开的文件数等等,可能不仅仅让WEB服务崩溃,还会让整台服务器马上挂了。 所以,一定要拆分,使用LIMIT条件休眠一段时间,批量处理。

wangccsy 2019-12-02 01:50:30 0 浏览量 回答数 0

回答

Redis常见的几种主要使用方式: Redis 单副本 Redis 多副本(主从) Redis Sentinel(哨兵) Redis Cluster(集群) Redis 自研 Redis各种使用方式的优缺点: 1 Redis单副本 Redis各种使用方式的优缺点: Redis 多副本,采用主从(replication)部署结构,相较于单副本而言最大的特点就是主从实例间数据实时同步,并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上,根据公司的基础环境配置,可以实现同时对外提供服务和读写分离策略。 优点: 1、高可靠性,一方面,采用双机主备架构,能够在主库出现故障时自动进行主备切换,从库提升为主库提供服务,保证服务平稳运行。另一方面,开启数据持久化功能和配置合理的备份策略,能有效的解决数据误操作和数据异常丢失的问题。 2、读写分离策略,从节点可以扩展主库节点的读能力,有效应对大并发量的读操作。 缺点: 1、故障恢复复杂,如果没有RedisHA系统(需要开发),当主库节点出现故障时,需要手动将一个从节点晋升为主节点,同时需要通知业务方变更配置,并且需要让其他从库节点去复制新主库节点,整个过程需要人为干预,比较繁琐。 2、主库的写能力受到单机的限制,可以考虑分片 3、主库的存储能力受到单机的限制,可以考虑Pika 4、原生复制的弊端在早期的版本也会比较突出,如:Redis复制中断后,Slave会发起psync,此时如果同步不成功,则会进行全量同步,主库执行全量备份的同时可能会造成毫秒或秒级的卡顿;又由于COW机制,导致极端情况下的主库内存溢出,程序异常退出或宕机;主库节点生成备份文件导致服务器磁盘IO和CPU(压缩)资源消耗;发送数GB大小的备份文件导致服务器出口带宽暴增,阻塞请求。建议升级到最新版本。 使用场景 对 Redis 协议兼容性要求较高的业务 标准版完全兼容 Redis 协议,业务可以平滑迁移。 Redis 作为持久化数据存储使用的业务 标准版提供持久化机制及备份恢复机制,极大地保证数据可靠性。 单个 Redis 性能压力可控 由于 Redis 原生采用单线程机制,性能在10万 QPS 以下的业务建议使用。如果需要更高的性能要求,请选用集群版本。 Redis 命令相对简单,排序、计算类命令较少 由于 Redis 的单线程机制,CPU 会成为主要瓶颈。如排序、计算类较多的业务建议选用集群版配置。 2 Redis多副本(主从) Redis 多副本,采用主从(replication)部署结构,相较于单副本而言最大的特点就是主从实例间数据实时同步,并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上,根据公司的基础环境配置,可以实现同时对外提供服务和读写分离策略。 优点: 1、高可靠性,一方面,采用双机主备架构,能够在主库出现故障时自动进行主备切换,从库提升为主库提供服务,保证服务平稳运行。另一方面,开启数据持久化功能和配置合理的备份策略,能有效的解决数据误操作和数据异常丢失的问题。 2、读写分离策略,从节点可以扩展主库节点的读能力,有效应对大并发量的读操作。 缺点: 1、故障恢复复杂,如果没有RedisHA系统(需要开发),当主库节点出现故障时,需要手动将一个从节点晋升为主节点,同时需要通知业务方变更配置,并且需要让其他从库节点去复制新主库节点,整个过程需要人为干预,比较繁琐。 2、主库的写能力受到单机的限制,可以考虑分片 3、主库的存储能力受到单机的限制,可以考虑Pika 4、原生复制的弊端在早期的版本也会比较突出,如:Redis复制中断后,Slave会发起psync,此时如果同步不成功,则会进行全量同步,主库执行全量备份的同时可能会造成毫秒或秒级的卡顿;又由于COW机制,导致极端情况下的主库内存溢出,程序异常退出或宕机;主库节点生成备份文件导致服务器磁盘IO和CPU(压缩)资源消耗;发送数GB大小的备份文件导致服务器出口带宽暴增,阻塞请求。建议升级到最新版本。 使用场景 对 Redis 协议兼容性要求较高的业务 标准版完全兼容 Redis 协议,业务可以平滑迁移。 Redis 作为持久化数据存储使用的业务 标准版提供持久化机制及备份恢复机制,极大地保证数据可靠性。 单个 Redis 性能压力可控 由于 Redis 原生采用单线程机制,性能在10万 QPS 以下的业务建议使用。如果需要更高的性能要求,请选用集群版本。 Redis 命令相对简单,排序、计算类命令较少 由于 Redis 的单线程机制,CPU 会成为主要瓶颈。如排序、计算类较多的业务建议选用集群版配置。 3 Redis Sentinel(哨兵) Redis Sentinel是社区版本推出的原生高可用解决方案,Redis Sentinel部署架构主要包括两部分:Redis Sentinel集群和Redis数据集群,其中Redis Sentinel集群是由若干Sentinel节点组成的分布式集群。可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel的节点数量要满足2n+1(n>=1)的奇数个。 优点: 1、Redis Sentinel集群部署简单 2、能够解决Redis主从模式下的高可用切换问题 3、很方便实现Redis数据节点的线形扩展,轻松突破Redis自身单线程瓶颈,可极大满足对Redis大容量或高性能的业务需求。 4、可以实现一套Sentinel监控一组Redis数据节点或多组数据节点 缺点: 1、部署相对Redis 主从模式要复杂一些,原理理解更繁琐 2、资源浪费,Redis数据节点中slave节点作为备份节点不提供服务 3、Redis Sentinel主要是针对Redis数据节点中的主节点的高可用切换,对Redis的数据节点做失败判定分为主观下线和客观下线两种,对于Redis的从节点有对节点做主观下线操作,并不执行故障转移。 4、不能解决读写分离问题,实现起来相对复杂 建议: 1、如果监控同一业务,可以选择一套Sentinel集群监控多组Redis数据节点的方案,反之选择一套Sentinel监控一组Redis数据节点的方案 2、sentinel monitor 配置中的 建议设置成Sentinel节点的一半加1,当Sentinel部署在多个IDC的时候,单个IDC部署的Sentinel数量不建议超过(Sentinel数量 – quorum)。 3、合理设置参数,防止误切,控制切换灵敏度控制 quorum down-after-milliseconds 30000 failover-timeout 180000 maxclient timeout 4、部署的各个节点服务器时间尽量要同步,否则日志的时序性会混乱 5、Redis建议使用pipeline和multi-keys操作,减少RTT次数,提高请求效率 6、自行搞定配置中心(zookeeper),方便客户端对实例的链接访问 4 Redis Cluster(集群) Redis Cluster是社区版推出的Redis分布式集群解决方案,主要解决Redis分布式方面的需求,比如,当遇到单机内存,并发和流量等瓶颈的时候,Redis Cluster能起到很好的负载均衡的目的。Redis Cluster集群节点最小配置6个节点以上(3主3从),其中主节点提供读写操作,从节点作为备用节点,不提供请求,只作为故障转移使用。Redis Cluster采用虚拟槽分区,所有的键根据哈希函数映射到0~16383个整数槽内,每个节点负责维护一部分槽以及槽所印映射的键值数据。 优点: 1、无中心架构 2、数据按照slot存储分布在多个节点,节点间数据共享,可动态调整数据分布。 3、可扩展性,可线性扩展到1000多个节点,节点可动态添加或删除。 4、高可用性,部分节点不可用时,集群仍可用。通过增加Slave做standby数据副本,能够实现故障自动failover,节点之间通过gossip协议交换状态信息,用投票机制完成Slave到Master的角色提升。 5、降低运维成本,提高系统的扩展性和可用性。 缺点: 1、Client实现复杂,驱动要求实现Smart Client,缓存slots mapping信息并及时更新,提高了开发难度,客户端的不成熟影响业务的稳定性。目前仅JedisCluster相对成熟,异常处理部分还不完善,比如常见的“max redirect exception”。 2、节点会因为某些原因发生阻塞(阻塞时间大于clutser-node-timeout),被判断下线,这种failover是没有必要的。 3、数据通过异步复制,不保证数据的强一致性。 4、多个业务使用同一套集群时,无法根据统计区分冷热数据,资源隔离性较差,容易出现相互影响的情况。 5、Slave在集群中充当“冷备”,不能缓解读压力,当然可以通过SDK的合理设计来提高Slave资源的利用率。 6、key批量操作限制,如使用mset、mget目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于keys 不支持跨slot查询,所以执行mset、mget、sunion等操作支持不友好。 7、key事务操作支持有限,只支持多key在同一节点上的事务操作,当多个key分布于不同的节点上时无法使用事务功能。 8、key作为数据分区的最小粒度,因此不能将一个很大的键值对象如hash、list等映射到不同的节点。 9、不支持多数据库空间,单机下的redis可以支持到16个数据库,集群模式下只能使用1个数据库空间,即db 0。 10、复制结构只支持一层,从节点只能复制主节点,不支持嵌套树状复制结构。 11、避免产生hot-key,导致主库节点成为系统的短板。 12、避免产生big-key,导致网卡撑爆、慢查询等。 13、重试时间应该大于cluster-node-time时间 14、Redis Cluster不建议使用pipeline和multi-keys操作,减少max redirect产生的场景。 使用场景 数据量较大 Redis 集群版可以有效的扩展数据规模,相比标准版支持存储量更大的64、128、256 GB 集群版,可以有效的满足数据扩展需求。 QPS 压力较大 标准版 Redis 无法支撑较大的 QPS,需要采用多节点的部署方式来冲破 Redis 单线程的性能瓶颈。 吞吐密集型应用 相比标准版,Redis 集群版的内网吞吐限制相对较低,针对热点数据读取、大吞吐类型的业务可以友好的支持。 对 Redis 协议不敏感的应用 由于集群版的架构引入了多个组件,在 Redis 协议支持上相比标准版有一定限制。

剑曼红尘 2020-04-27 14:41:57 0 浏览量 回答数 0

问题

OpenSearch有什么优势?

轩墨 2019-12-01 20:55:24 907 浏览量 回答数 0

问题

TableInBatchGetRowRequest

云栖大讲堂 2019-12-01 21:01:41 1444 浏览量 回答数 0

回答

常见错误处理 错误码 处理方式 1000 一般为语法或者超时引起,如果多次刷新不再出现,则是超时引起,如果仍出现,则语法有问题,请对照文档仔细检查,如分隔符、函数字段类型等 2112 排序表达式中的text_relevance(field)、fieldterm_proximity(field)等文本feature中的field必须在查询的索引包含的源字段中,否则会报错,但不影响搜索结果。 3007 对于API推送系统是有频率限制,请控制好频率重试 4003 可以先按照文档样例,试下签名结果是否一致,判断是否是签名算法问题。如果不是,请检查下参数按照字典序排序后应该是公共参数(大写字母)在前,请求参数(小写字母)在后。另外还有空格等一些编码规则,具体参考授权文档介绍 4007 一般Json字段内容中包含双引号或者不可见字符会导致格式解析失败,请转义或者过滤后重试 4010 TimeStamp参数是有过期时间的,请按照要求格式取当前时间来计算 5001 没有找到对应的用户,一般为ACCESSKEY信息不正确,或者使用区域域名错误(API域名请以应用管理-》基本信息-》API入口为准),请检查修改后重试 5008 服务内部是通过Accesskey来进行用户身份校验的,请确保AccessKey已经开启,您可以通过控制台AccessKey管理入口来创建和删除 6013 start+hit不能超过5000,否则会报错无结果。需要超过5000的请求,请查看下API文档中的SCROLL接口,看是否满足需求 6015 请及时到控制台配额管理处进行QPS峰值的调整,否则超过的请求会被丢弃 6127 除了query子句,其他子句出现的字段都必须配置为属性字段才能使用。请修改应用结构后重试 系统级别(1000-1999) 错误码 错误说明 1000 系统内部错误 1001 没有找到模版 1003 不支持的索引类型 1004 服务暂时不可用,请稍后再试 应用相关(2000-2999) 错误码 错误说明 2001 待查应用不存在 2002 应用已经存在 2003 到达创建应用总限制 2004 应用名不可用。应用名由数字、26个英文字母或下划线组成,长度不超过30位 2005 应用名称没有设定 2006 新应用名称没有设定 2007 备注不超300字 2008 摘要配置参数错误 2009 更新状态失败 2010 应用暂停中 2011 应用冻结中 2012 应用未开启 2013 删除失败,没有此应用 2014 文件上传失败 2016 区域信息没有 2017 此应用并不属于当前区域 2099 当前接口暂时不提供服务。 2101 表达式不存在 2102 表达式名称被占用 2103 到达该应用表达式总数限制 2104 表达式名不可用。表达式名由数字、26个英文字母或下划线组成,长度不超过30位 2105 表达式名称没有设定 2106 新表达式名称没有设定 2107 表达式备注不超过300字 2108 表达式备注格式错误 2109 表达式格式错误 2110 表达式长度超过限制 2111 表达式id未指定 2112 表达式错误 2113 表达式不能为空 2114 操作错误 2201 粗排配置名没有设定 2202 粗排配置名已经存在 2203 粗排配置个数超出限制 2204 粗排配置名错误。只能由数字、26个英文字母或下划线组成 2205 粗排配置名长度超出限制 2206 粗排字段必须是数值型 2207 粗排配置不存在 2208 粗排配置错误,必须包含字段 2209 粗排配置权重错误,必须是-100000到100000之间的非0数值,浮点数精度支持6位 2210 与系统默认粗排配置重名 2211 timeliness()的参数必须是INT类型 2112 排序表达式错误 2551 查询指定的下拉提示规则不存在 文档相关(3000-3999) 错误码 错误说明 3001 文档不能为空 3002 文档大小超过限制 3003 已经到最大文档数 3004 保存文档失败 3005 doc格式错误 3006 文档操作cmd不合法 3007 请求过于频繁 3008 文档总长度太长 3009 没有文档id 3011 在配置RDS或MYSQL数据源后,不支持API推送文档 3012 未找到指定资源 3013 文档推送速率超过应用配额 3014 文档推送速率触发系统限制 3015 单次推送文档个数超过系统限制 3016 文档总数超过应用配额 授权相关(4000-4999) 错误码 错误说明 4001 认证失败 4002 需要设置签名 4003 签名验证失败 4004 需要设置SignatureNonce 4005 SignatureNonce不能重复使用 4006 SignatureNonce验证失败 4007 解析JSON格式失败 4008 用户名称不能为空,请检查域名正确性 4009 需要指定用户标识 4010 时间过期 4011 demo帐号禁止执行的操作 4012 数据表不存在 4013 Timestamp格式错误 4014 需要设置Timestamp 4020 RAM子账户鉴权失败 用户相关(5000-5999) 错误码 错误说明 5001 用户不存在 5002 用户名不正确 5003 需要用户登录 5005 用户未开通OpenSearch服务,请前往阿里云官网开通 5008 用户没有启用ACCESSKEY 5100 用户没有此区域的操作权限 5004 用户未缴费 5005 用户未开通OpenSearch服务,请前往阿里云官网开通 5006 欠费冻结中 5008 用户没有启用ACCESSKEY 5009 用户已经删除 5010 ACCESSKEY 已经禁用 5011 通过邮箱获取到多个用户 5012 CODE_USER_ALIYUN_USER_ID_INVALID,错误信息为空 5013 CODE_USER_ALIYUN_BID_INVALID,错误信息为空 5014 CODE_USER_CLIENT_ID_INVALID,错误信息为空 5015 CODE_USER_ID_INVALID,错误信息为空 5100 用户没有此区域的操作权限 搜索相关(6000-6999) 错误码 错误说明 6001 查询query为空 6002 并不被支持的搜索key关键字 6003 并不被支持的搜索field关键字 6004 复杂查询为空 6005 field无效 6006 请求包含太多应用名 6007 超出多索引查询每个模板中索引总数 6008 请求串语法错误,解析失败 6009 查询子句过长 6010 无效的rerank size 6011 SignatureNonce格式错误 6013 start+hit超过系统限制 6014 因系统繁忙,请求被丢弃 6015 因流量超出配额,请求被丢弃 6016 查询hit数超过系统限制 6017 目前scroll只支持search_type为scan,也就是说设置了参数scroll,就必须设置参数search_type=scan 6018 设置了scroll参数,但没有search_type参数 6019 传入的scroll_id参数解析失败 6020 无效的scroll参数值 6021 scroll请求不支持Aggregate/Sort/Distinct,当传入这些clause时,会报错 6022 scroll_id已经过期失效了 6100 查询词为空 6101 查询的索引字段不存在 6102 Query中的数值范围错误 6103 Filter中的表达式返回值必须为bool类型 6104 Sort中的表达式返回值不能为bool类型 6105 Sort中存在相同的表达式 6106 查询query语句非法 6107 统计函数表达式的返回值不能为bool或者string类型 6108 统计中的范围必须为升序 6109 统计中的范围表达式返回值类型错误 6110 统计函数不存在 6111 不支持的统计函数 6112 Query 子句错误 6113 Filter子句错误 6114 Aggregate子句错误 6115 Sort子句错误 6116 Distinct子句错误 6117 查询中包含未知的子句 6118 语法错误 6119 Distinct子句中的dist_count值错误,应该为大于0的整数 6120 Distinct子句中的dist_times值错误,应该为大于0的整数 6121 Distinct子句中的reserved值错误,应为true/false 6122 Distinct子句缺少distinct_key 6123 Distinct子句中的grade值错误,例如为空,或非数值 6124 Distinct子句中包含distinct个数不对,个数应在(0,2] 6125 Distinct子句中的max_item_count值错误,应该为大于0的整数 6126 Distinct子句中的update_total_hit值错误,应为true/false 6127 请求中包含了未定义的attribute字段 6128 表达式中的二元操作符的两边的表达式结果类型不匹配 6129 表达式中的二元操作符的两边表达式不能同时为常量 6130 二元逻辑运算表达式类型错误,应为bool类型 6131 二元表达式中不支持string类型 6132 二元表达式中不支持数组类型 6133 位操作中的类型错误 6134 常量表达式的返回值类型错误 6300 常量表达式类型应是整数或浮点数 6301 位取反操作数类型必须为整数 6302 取负数操作数必须为数值 6303 逻辑非操作数必须为数值 6304 二元运算操作数类型错误 6305 非法的二元运算符 6306 函数参数类型错误 6307 函数未定义 6308 函数参数个数错误 6309 非法的数组操作 6310 可过滤字段不存在 6311 数组字段被错当作单值使用 6312 单值字段被错当作数组使用 6313 数组字段下标越界(小于0) 6314 不支持的字段类型 6315 索引字段参数不存在 6316 Query中没有指定索引 6317 Filter子句中只能使用一次公式 6318 公式语法解析出错 6500 搜索语法中包含不存在的字段 6501 在线系统没有索引数据 6502 用户query语法错误 6601 一个索引字段只能包含在一个规则中 6602 没有查询词,如default:’’的情况 6603 查询中的索引字段没有在查询分析规则中指定 6604 关键词没有使用引号括起来,如default:xxx,正确为default:’xxx’ 6605 双引号查询不能配置查询分析规则 6607 disable参数格式错误 6608 disable指定关闭的索引字段不存在 6609 disable指定关闭的功能列表不存在 6610 查询分析后的query为空(原query为空,或者全部是stopword) 6611 查询中没有指定索引字段 数据处理相关(7000-7999) 错误码 错误说明 7100 没有错误发生 7101 单个文档过长 7102 文档所属应用的元信息错误(clientid 或 accesskey、应用名或表名等不正确) 7103 HA3 文档格式错误: 字段解析失败 7104 JSON文档格式错误:字段解析失败 7105 JSON 文档格式错误: json非法 7106 JSON 文档格式错误: json非法 7107 不支持的编码 7108 编码转换失败 7109 fields中没有id字段 7110 fields中id定义不合法 7111 fields中包含保留字段 7201 HA3 文档格式错误: cmd 非法(cmd 非 ADD/UPDATE/DELETE) 7202 JSON 文档格式错误: cmd 非法(cmd 非 ADD/UPDATE/DELETE) 7301 主键字段不存在 7302 字段数据类型错误 7303 数组字段相关错误 7401 文档总数超出配额 7402 每日更新文档数超出配额 7403 单次导入的数据大小超出配额 7500 系统内部错误 7501 云梯Hive待同步字段的列号超出了当前数据的列数范围 7502 从Mysql中读取到的主键字段为空,请联系数据库管理员 7503 JsonKeyValueExtractor内容转换错误: Json格式非法 7504 JsonKeyValueExtractor内容转换错误: key不存在 7505 TairLDBExtractor内容转换错误: namespace非法(应为int32类型) 7506 TairLDBExtractor内容转换错误: 从Tair中读取数据失败 7507 MySql实时同步过滤条件格式错误 7508 系统内部错误: 内容转换插件初始化失败 7509 TairLDBExtractor内容转换配置错误:Tair连接失败,请检查configId 或 namespace 是否有效 7510 KVExtractor内容解析错误:KV格式无法解析 7511 OSS 数据读取失败 7512 OSS 内容长度超过限度 7513 OSS 内容解析错误 7514 系统内部错误: OSS LOG 格式不兼容 7515 过滤条件执行错误 7516 字段映射过程中源表字段缺失 7517 StringCatenateExtractor内容转换错误: 源字段不存在 7518 StringCatenateExtractor内容转换错误: 不支持多值字段 7601 任务执行错误 7602 更新app失败 7701 数据清理任务错误:指定过滤字段不存在 7801 文档格式错误 文档错误内部通知(8000-8999) 错误码 错误说明 8001 保存错误信息失败 8002 必要参数缺失 8003 应用不存在 8004 参数错误 模板相关(9000-9999) 错误码 错误说明 9001 用户名为空 9002 应用名为空 9003 模板名不可用。模板名只能由数字、26个英文字母或下划线组成 9004 模板名长度不可超过30位 9005 查询模板信息出错 9006 模板名字已存在 9007 插入模板信息出错 9008 无效的数据 9009 定义的字段数目超过系统允许的最大字段数 9010 此字段保留字段名 9011 字段已存在 9012 索引名称必须以字母开头,由数字、26个英文字母或下划线组成,长度不超过30位,多值字段类型不能为SWS_TEXT或TEXT 9013 不支持数组 9014 不支持主键 9015 未设定主键 9016 主键不唯一 9017 更新信息失败 9018 删除信息失败 9019 包含多个索引字段的搜索字段最多4个 9020 同一个STRING/TEXT类型的索引字段不能进入多个只包含一个字段的搜索字段中 9021 索引名称必须以字母开头,由数字、26个英文字母或下划线组成,长度不超过30个 9022 该表已经关联 9023 索引名不能包含多类型的字段 9100 系统内部错误 9101 该字段超过数量限制 9102 该数据源未被用到 9103 无效的外表连接 9104 最多2级关联 9105 待查模板不存在 9501 用户名为空 9502 应用名为空 9519 未指定模板 9600 系统内部错误 9902 插件字段类型错误 9999 此域名不提供本服务 数据同步相关(10000-) 错误码 错误说明 10001 没有指定的tddl group key,tddl信息获取失败 10002 获取字段失败或者表不存在 10011 连接agg失败 10012 应用里存在doc 10013 应用不是自定义结构 10110 该任务已结束 10010 部分数据源有问题,已经忽略有错误的数据 10014 数据源类型错误 10100 创建任务失败,未结束的任务已经存在 10101 没有指定应用ID 10106 没有指定应用ID 10107 没有指定应用ID 10102 ACTION无效 10112 文档数量超过限制 10201 获取配额列表失败 10202 更新配额失败 10301 参数错误:参数未提供或者格式不正确 10302 时间参数错误 10303 数据源未配置 10304 该表配额超限 10305 OSS参数错误 10306 OSS BUCKET名称无效 10307 OSS 记录类型无效 10308 OSS BUCKET日志功能未开启 10309 存在未完成的任务 10310 不是运行中的应用,无法创建任务 10311 时间范围不合法 10312 应用描述长度超过限制,最多600字 10313 OSS 内容格式不合法 10314 OSS BUCKET所在区域ACL网络不通 10315 OSS BUCKET的地址信息不合法 10330 数据源参数不合法 10350 连接ODPS服务失败 10351 ODPS 返回错误 10400 OSS前缀不合法 10450 字段不存在

保持可爱mmm 2020-03-26 22:06:37 0 浏览量 回答数 0

问题

使用表格存储的表的建议有哪些

云栖大讲堂 2019-12-01 20:57:03 1070 浏览量 回答数 0

回答

我一直在做很多关于可用选项的阅读。我还亲自推荐了高性能MySQL第二版。 这是我设法拼凑而成的: 聚类 一般而言,集群是将负载分布在许多服务器上,这些服务器在外部应用程序中似乎是一台服务器。 MySQL NDB集群 MySQL NDB Cluster是一个具有同步复制和自动数据分割功能的分布式,无内存的,无共享的存储引擎(对不起,我从高性能书上借来的字面意思是,但它们放在那儿很好)。对于某些应用程序来说,这可能是一个高性能的解决方案,但是Web应用程序通常无法在其上很好地工作。 主要问题在于,除了非常简单的查询(仅涉及一个表)之外,群集通常还必须在多个节点上搜索数据,从而使网络延迟蔓延,并显着减慢查询的完成时间。由于该应用程序将群集视为一台计算机,因此无法告诉它从哪个节点获取数据。 此外,内存需求对于许多大型数据库而言并不可行。 连续红杉 这是MySQL的另一种群集解决方案,它充当MySQL服务器之上的中间件。它提供同步复制,负载平衡和故障转移。它还可以确保请求始终从最新副本中获取数据,并自动选择具有新数据的节点。 我读了一些不错的东西,总的来说,这听起来很有希望。 联邦 联合类似于集群,因此我也在这里进行了介绍。MySQL通过联合存储引擎提供联合。与NDB群集解决方案类似,它仅适用于简单查询-但对于复杂查询,群集甚至更糟(因为网络延迟要高得多)。 复制和负载平衡 MySQL具有在不同服务器上创建数据库复制的内置功能。这可用于许多用途-在服务器之间分配负载,热备份,创建测试服务器和故障转移。 复制的基本设置涉及一台主服务器主要处理写操作,而一个或多个从服务器仅处理读操作。master-master配置的更高级的变化是,它允许通过同时写入多个服务器来扩展写入。 每种配置都有其优缺点,但是它们共同面临的一个问题是复制滞后-由于MySQL复制是异步的,因此并非所有节点始终都具有最新数据。这要求应用程序了解复制,并结合复制感知查询才能按预期工作。对于某些应用程序来说,这可能不是问题,但是如果您始终需要最新的数据,事情就会变得有些复杂。 复制需要一些负载平衡以在节点之间分配负载。这可以像对应用程序代码进行某些修改一样简单,也可以使用专用的软件和硬件解决方案。 分片和分割 分片是扩展数据库解决方案的常用方法。您将数据拆分为较小的碎片,并将其散布在不同的服务器节点上。这需要应用程序知道对数据存储的修改才能有效地工作,因为它需要知道在哪里可以找到所需的信息。 有可用的抽象框架来帮助处理数据分片,例如Hibernate Shards,它是Hibernate ORM的扩展(不幸的是,它是Java的。我正在使用PHP)。HiveDB是另一个这样的解决方案,它也支持分片重新平衡。 其他 狮身人面像 Sphinx是全文搜索引擎,其功能远不止测试搜索。对于许多查询,它比MySQL快得多(尤其是对于分组和排序),并且可以并行查询远程系统并汇总结果-这使其在分片中非常有用。 通常,狮身人面像应与其他扩展解决方案一起使用,以获取更多可用的硬件和基础架构。不利的一面是,您再次需要应用程序代码来了解sphinx,以便明智地使用它。 摘要 伸缩解决方案因需要它的应用程序的需求而异。对于我们和大多数Web应用程序,我相信复制(可能是多主服务器)是负载平衡器分配负载的一种方式。为了能够水平扩展,还必须对特定问题区域(巨大的表)进行分片。 我还将对Continentant Sequoia进行一下测试,看看它是否能够真正实现它所承诺的目标,因为它将对应用程序代码进行的更改最少。来源:stack overflow

保持可爱mmm 2020-05-17 13:02:45 0 浏览量 回答数 0

回答

选择一门编程语言,例如C之类的。如果不想学编程,就尝试下Excel里面的公式。-------------------------算法的定义 算法(Algorithm)是一系列解决问题的清晰指令,也就是说,能够对一定规范的输入,在有限时间内获得所要求的输出。如果一个算法有缺陷,或不适合于某个问题,执行这个算法将不会解决这个问题。不同的算法可能用不同的时间、空间或效率来完成同样的任务。一个算法的优劣可以用空间复杂度与时间复杂度来衡量。 算法可以理解为有基本运算及规定的运算顺序所构成的完整的解题步骤。或者看成按照要求设计好的有限的确切的计算序列,并且这样的步骤和序列可以解决一类问题。 一个算法应该具有以下五个重要的特征: 1、有穷性: 一个算法必须保证执行有限步之后结束; 2、确切性: 算法的每一步骤必须有确切的定义; 3、输入:一个算法有0个或多个输入,以刻画运算对象的初始情况,所谓0个输入是指算法本身定除了初始条件; 4、输出:一个算法有一个或多个输出,以反映对输入数据加工后的结果。没有输出的算法是毫无意义的; 5、可行性: 算法原则上能够精确地运行,而且人们用笔和纸做有限次运算后即可完成。 计算机科学家尼克劳斯-沃思曾著过一本著名的书《数据结构十算法= 程序》,可见算法在计算机科学界与计算机应用界的地位。 [编辑本段]算法的复杂度 同一问题可用不同算法解决,而一个算法的质量优劣将影响到算法乃至程序的效率。算法分析的目的在于选择合适算法和改进算法。一个算法的评价主要从时间复杂度和空间复杂度来考虑。 时间复杂度 算法的时间复杂度是指算法需要消耗的时间资源。一般来说,计算机算法是问题规模n 的函数f(n),算法的时间复杂度也因此记做 T(n)=Ο(f(n)) 因此,问题的规模n 越大,算法执行的时间的增长率与f(n) 的增长率正相关,称作渐进时间复杂度(Asymptotic Time Complexity)。 空间复杂度 算法的空间复杂度是指算法需要消耗的空间资源。其计算和表示方法与时间复杂度类似,一般都用复杂度的渐近性来表示。同时间复杂度相比,空间复杂度的分析要简单得多。 详见百度百科词条"算法复杂度" [编辑本段]算法设计与分析的基本方法 1.递推法 递推法是利用问题本身所具有的一种递推关系求问题解的一种方法。它把问题分成若干步,找出相邻几步的关系,从而达到目的,此方法称为递推法。 2.递归 递归指的是一个过程:函数不断引用自身,直到引用的对象已知 3.穷举搜索法 穷举搜索法是对可能是解的众多候选解按某种顺序进行逐一枚举和检验,并从众找出那些符合要求的候选解作为问题的解。 4.贪婪法 贪婪法是一种不追求最优解,只希望得到较为满意解的方法。贪婪法一般可以快速得到满意的解,因为它省去了为找最优解要穷尽所有可能而必须耗费的大量时间。贪婪法常以当前情况为基础作最优选择,而不考虑各种可能的整体情况,所以贪婪法不要回溯。 5.分治法 把一个复杂的问题分成两个或更多的相同或相似的子问题,再把子问题分成更小的子问题……直到最后子问题可以简单的直接求解,原问题的解即子问题的解的合并。 6.动态规划法 动态规划是一种在数学和计算机科学中使用的,用于求解包含重叠子问题的最优化问题的方法。其基本思想是,将原问题分解为相似的子问题,在求解的过程中通过子问题的解求出原问题的解。动态规划的思想是多种算法的基础,被广泛应用于计算机科学和工程领域。 7.迭代法 迭代是数值分析中通过从一个初始估计出发寻找一系列近似解来解决问题(一般是解方程或者方程组)的过程,为实现这一过程所使用的方法统称为迭代法。 [编辑本段]算法分类 算法可大致分为基本算法、数据结构的算法、数论与代数算法、计算几何的算法、图论的算法、动态规划以及数值分析、加密算法、排序算法、检索算法、随机化算法、并行算法。 算法可以宏泛的分为三类: 有限的,确定性算法 这类算法在有限的一段时间内终止。他们可能要花很长时间来执行指定的任务,但仍将在一定的时间内终止。这类算法得出的结果常取决于输入值。 有限的,非确定算法 这类算法在有限的时间内终止。然而,对于一个(或一些)给定的数值,算法的结果并不是唯一的或确定的。 无限的算法 是那些由于没有定义终止定义条件,或定义的条件无法由输入的数据满足而不终止运行的算法。通常,无限算法的产生是由于未能确定的定义终止条件。 [编辑本段]举例 经典的算法有很多,如:"欧几里德算法,割圆术,秦九韶算法"。 [编辑本段]算法经典专著 目前市面上有许多论述算法的书籍,其中最著名的便是《计算机程序设计艺术》(The Art Of Computer Programming) 以及《算法导论》(Introduction To Algorithms)。 [编辑本段]算法的历史 “算法”即演算法的大陆中文名称出自《周髀算经》;而英文名称Algorithm 来自于9世纪波斯数学家al-Khwarizmi,因为al-Khwarizmi在数学上提出了算法这个概念。“算法”原为"algorism",意思是阿拉伯数字的运算法则,在18世纪演变为"algorithm"。欧几里得算法被人们认为是史上第一个算法。 第一次编写程序是Ada Byron于1842年为巴贝奇分析机编写求解解伯努利方程的程序,因此Ada Byron被大多数人认为是世界上第一位程序员。因为查尔斯·巴贝奇(Charles Babbage)未能完成他的巴贝奇分析机,这个算法未能在巴贝奇分析机上执行。 因为"well-defined procedure"缺少数学上精确的定义,19世纪和20世纪早期的数学家、逻辑学家在定义算法上出现了困难。20世纪的英国数学家图灵提出了著名的图灵论题,并提出一种假想的计算机的抽象模型,这个模型被称为图灵机。图灵机的出现解决了算法定义的难题,图灵的思想对算法的发展起到了重要作用的。

马铭芳 2019-12-02 01:19:58 0 浏览量 回答数 0

回答

调用CreateScalingConfiguration创建一个伸缩配置。 调试 您可以在OpenAPI Explorer中直接运行该接口,免去您计算签名的困扰。运行成功后,OpenAPI Explorer可以自动生成SDK代码示例。 调试 请求参数 名称 类型 是否必选 示例值 描述 Action String 否 CreateScalingConfiguration 系统规定参数。取值: CreateScalingConfiguration。 ScalingGroupId String 是 asg-bp14wlu85wrpchm0**** 伸缩配置所属的伸缩组的ID。 ImageId String 否 centos6u5_64_20G_aliaegis****.vhd 镜像文件ID,自动创建实例时使用的镜像资源。 ImageName String 否 myimage 镜像文件名称,同一个地域内镜像名称唯一。如果设置了ImageId, ImageName将被忽略。 不支持通过ImageName设置镜像市场镜像。 InstanceType String 否 ecs.t1.xsmall ECS实例的实例规格,更多信息请参见实例规格族。 Cpu Integer 否 2 vCPU个数。 同时指定CPU和Memory可以定义实例规格范围,例如,CPU=2且Memory=16可以定义配置为2 vCPU和16 GiB的所有实例规格。弹性伸缩会结合IO优化、可用区等因素确定可用实例规格集合,并根据价格排序为您创建价格最低的实例。 说明 该区间配置效果仅在成本优化模式下且伸缩配置未设置实例规格时生效。 Memory Integer 否 16 内存大小。 同时指定CPU和Memory可以定义实例规格范围,例如,CPU=2且Memory=16可以定义配置为2 vCPU和16 GiB的所有实例规格。弹性伸缩会结合IO优化、可用区等因素确定可用实例规格集合,并根据价格排序为您创建价格最低的实例。 说明 该区间配置效果仅在成本优化模式下且伸缩配置未设置实例规格时生效。 DeploymentSetId String 否 ds-bp1frxuzdg87zh4pz**** ECS实例所属的部署集的ID。 InstanceTypes.N RepeatList 否 ecs.t1.xsmall.1 多实例规格参数。如果使用了InstanceTypes.N,InstanceType将被忽略,其中N的取值范围:1~10,即一个伸缩配置内最多可以设置10种实例规格。 N代表当前伸缩配置中实例规格的优先级,编号为1的实例规格优先级最高,实例规格优先级随着编号的增大依次降低。当无法根据优先级较高的实例规格创建出实例时,弹性伸缩服务会自动选择下一优先级的实例规格来创建实例。 SecurityGroupId String 否 sg-280ih**** ECS实例所属的安全组的ID,同一个安全组内的ECS实例可以互相访问。 IoOptimized String 否 optimized 是否为I/O优化实例。已停售的实例规格实例默认值是none,其他实例规格默认值是optimized。取值范围: none:非I/O优化实例。 optimized:I/O优化实例。 InternetChargeType String 否 PayByTraffic 网络计费类型,取值范围: PayByBandwidth:按带宽计费。此时InternetMaxBandwidthOut即为所选的固定带宽值。 PayByTraffic:按流量计费。此时InternetMaxBandwidthOut只是一个带宽上限,计费以实际产生的网络流量为依据。 如果未指定该参数,经典网络下默认值为PayByBandwidth,专有网络VPC下默认值为PayByTraffic。 InternetMaxBandwidthIn Integer 否 100 公网入带宽最大值,单位为Mbps (Mega bit per second),取值范围:1~200。 如果您没有指定该参数,则入带宽将自动被设置为200Mbps。实例的入数据流量免费,该参数在任何情况下都不涉及计费。 InternetMaxBandwidthOut Integer 否 50 公网出带宽最大值,单位为Mbps (Mega bit per second),取值范围: 按带宽计费:0~100,如果您没有指定该参数,则出带宽将自动被设置为0Mbps。 按流量计费:0~100,如果您没有指定该参数,则会出现报错。 SystemDisk.Category String 否 cloud_ssd 系统盘的磁盘种类。取值范围: cloud:普通云盘 cloud_efficiency:高效云盘 cloud_ssd:SSD云盘 ephemeral_ssd:本地SSD盘 cloud_essd:ESSD云盘 InstanceType为系列I的实例规格且实例属于非I/O优化实例时,默认值:cloud。否则,默认值:cloud_efficiency。 SystemDisk.Size Integer 否 100 系统盘的大小,单位:GiB。取值范围: cloud:20~500 cloud_efficiency:20~500 cloud_ssd:20~500 cloud_essd:20~500 ephemeral_ssd:20~500 默认值:max{40, ImageSize}。 指定该参数后,系统盘大小必须大于等于max{20, ImageSize}。 SystemDisk.DiskName String 否 cloud_ssdSystem 系统盘的名称。长度为2~128个英文或中文字符。必须以大小字母或中文开头,不能以 http:// 和 https:// 开头。可以包含数字、半角冒号(:)、下划线(_)或者连字符(-)。 默认值:空。 SystemDisk.Description String 否 FinanceDept 系统盘的描述。长度为2~256个英文或中文字符,不能以 http:// 和 https:// 开头。 SystemDisk.AutoSnapshotPolicyId String 否 sp-bp12m37ccmxvbmi5**** 系统盘使用的自动快照策略ID。 ScalingConfigurationName String 否 test-sc 伸缩配置的名称,2~64英文或中文字符,以数字、大小写字母或中文开头,可包含数字、下划线(_)、连字符(-)或点号(.)。 在同一地域下同一伸缩组内伸缩配置名称唯一。如果您没有指定该参数,则默认使用伸缩配置的ID。 DataDisk.N.Size Integer 否 100 数据盘N的磁盘大小,N的取值范围:1~16,内存单位为GiB。取值范围: cloud:5~2000 cloud_efficiency:20~32768 cloud_ssd:20~32768 cloud_essd:20~32768 ephemeral_ssd:5~800 指定该参数后,磁盘大小必须大于等于快照大小(快照通过SnapshotId指定)。 DataDisk.N.SnapshotId String 否 s-280s7**** 创建数据盘时使用的快照,N的取值范围:1~16。指定该参数后,DataDisk.N.Size会被忽略,实际创建的磁盘大小为指定快照的大小。 如果该快照创建于2013年7月15日或之前,调用会被拒绝,返回参数中会提示InvalidSnapshot.TooOld。 DataDisk.N.Category String 否 cloud_ssd 数据盘N的磁盘种类,N的取值范围:1~16。该参数取值范围: cloud:普通云盘。随实例创建的普通云盘的DeleteWithInstance属性为true。 cloud_efficiency:高效云盘 cloud_ssd:SSD云盘 ephemeral_ssd:本地SSD盘 cloud_essd:ESSD云盘 对于I/O优化实例,默认值为cloud_efficiency。对于非I/O优化实例,默认值为cloud。 DataDisk.N.Device String 否 /dev/xvdb 数据盘挂载点,N的取值范围:1~16。如果您没有指定该参数,则默认在自动创建ECS实例时由系统分配,从/dev/xvdb开始,到/dev/xvdz结束。 DataDisk.N.DeleteWithInstance Boolean 否 true 指定数据盘是否随实例释放,N的取值范围:1~16。该参数取值范围: true:释放实例时,该磁盘随实例一起释放。 false:释放实例时,该磁盘保留不释放。 默认值:true。 该参数只可对独立云盘设置(DataDisk.N.Category为cloud、cloud_efficiency、cloud_ssd或cloud_essd),否则会出现报错。 DataDisk.N.Encrypted String 否 false 数据盘N是否加密,N的取值范围:1~16。该参数取值范围: true:加密 false:不加密 默认值:false。 DataDisk.N.KMSKeyId String 否 0e478b7a-4262-4802-b8cb-00d3fb40**** 数据盘对应的KMS密钥的ID,N的取值范围:1~16。 DataDisk.N.DiskName String 否 cloud_ssdData 数据盘的名称,N的取值范围:1~16。长度为2~128个英文或中文字符。必须以大小字母或中文开头,不能以 http:// 和 https:// 开头。可以包含数字、半角冒号(:)、下划线(_)或者连字符(-)。 默认值:空。 DataDisk.N.Description String 否 FinanceDept 数据盘的描述,N的取值范围:1~16。长度为2~256个英文或中文字符,不能以 http:// 和 https:// 开头。 DataDisk.N.AutoSnapshotPolicyId String 否 sp-bp19nq9enxqkomib**** 数据盘使用的自动快照策略ID,N的取值范围:1~16。 LoadBalancerWeight Integer 否 50 后端服务器的权重,取值范围:1~100。 默认值:50。 Tags String 否 {"key1":"value1","key2":"value2", ... "key5":"value5"} ECS实例的标签。标签以键值对方式传入,最多可以使用5组标签。Key和Value的使用要求如下: Key最多支持64个字符,不能以aliyun和acs:开头,不能包含 http:// 或者 https:// 。一旦使用标签,Key不允许为空字符串。 Value最多支持128个字符,不能以aliyun和acs:开头,不能包含 http:// 或者 https:// 。Value可以为空字符串。 UserData String 否 echo hello ecs! ECS实例的自定义数据,需要以Base64方式编码,编码前的原始数据最多为16KB。 KeyPairName String 否 KeyPairTest 登录ECS实例时使用的密钥对的名称。 对Windows实例,该参数将被忽略,默认为空。 对Linux实例,密码登录方式会被初始化成禁止。 RamRoleName String 否 RamRoleTest ECS实例的RAM角色名称。RAM角色名称由RAM提供和维护,您可调用ListRoles查询可用的RAM角色。创建RAM角色的方法请参见CreateRole。 SecurityEnhancementStrategy String 否 Active 是否开启安全加固。取值范围: Active:启用安全加固,只对公共镜像生效。 Deactive:不启用安全加固,对所有镜像类型生效。 InstanceName String 否 Instance**** 使用本伸缩配置自动创建的ECS实例的名称。 HostName String 否 Host**** 云服务器的主机名。点号(.)或连字符(-)不能作为首尾字符,不能连续使用点号(.)或连字符(-)。另外,不同类型实例的命名要求如下: Windows实例:主机名长度为2~15,可以包含大小写字母、数字和连字符(-)。不能包含点号(.),不能全是数字。 其他类型实例(Linux等):主机名长度为2~64,可以包含多个点号(.)。两个点号(.)之间为一段,每段可以包含大小写字母、数字和连字符(-)。 SpotStrategy String 否 NoSpot 后付费实例的抢占策略。取值范围: NoSpot:普通的按量付费实例。 SpotWithPriceLimit:设置上限价格的抢占式实例。 SpotAsPriceGo:系统自动出价,跟随当前市场实际价格。 默认值:NoSpot。 PasswordInherit Boolean 否 false 是否使用镜像预设的密码。使用该参数时,您需要确保使用的镜像已经设置了密码。 SpotPriceLimit.N.InstanceType String 否 ecs.t1.xsmall 抢占式实例的实例规格,N的取值范围:1~10。SpotStrategy取值为SpotWithPriceLimit时生效。 SpotPriceLimit.N.PriceLimit Float 否 0.5 抢占式实例对应的出价,N的取值范围:1~10。SpotStrategy取值为SpotWithPriceLimit时生效。 Password String 否 123-abcABC ECS实例的密码。长度为8至30个字符,必须同时包含大小写英文字母、数字和特殊符号中的三类字符。特殊符号可以是: ()` ~!@#$%^&*-_+=|{}[]:;'<>,.?/ 其中,Windows实例不能以斜线号(/)为密码首字符。 说明 如果传入Password参数,建议您使用HTTPS协议发送请求,避免密码泄露。 ResourceGroupId String 否 rg-resource**** ECS实例所属资源组的ID。 SecurityGroupIds.N RepeatList 否 sg-bp18kz60mefs**** 将ECS实例同时加入多个安全组。N的取值范围与实例能够加入安全组上限有关。更多详情,请参见使用限制下的安全组章节。 说明 不支持同时指定SecurityGroupId和SecurityGroupIds.N。 HpcClusterId String 否 hpc-clusterid ECS实例所属的EHPC集群的ID。 InstanceDescription String 否 FinaceDept ECS实例的描述。长度为2~256个英文或中文字符,不能以 http:// 和 https:// 开头。 ClientToken String 否 123e4567-e89b-12d3-a456-42665544**** 保证请求幂等性。从您的客户端生成一个参数值,确保不同请求间该参数值唯一。只支持ASCII字符,且不能超过64个字符。更多详情,请参见如何保证幂等性。 Ipv6AddressCount Integer 否 1 为弹性网卡指定随机生成的IPv6地址数量。 返回数据 名称 类型 示例值 描述 ScalingConfigurationId String asc-bp1ffogfdauy0nu5**** 伸缩配置ID。 RequestId String 473469C7-AA6F-4DC5-B3DB-A3DC0DE3C83E 请求ID。 示例 请求示例 http(s)://[Endpoint]/?Action=CreateScalingConfiguration &ScalingGroupId=asg-bp14wlu85wrpchm0**** &SecurityGroupId=sg-280ih**** &<公共请求参数> 正常返回示例 XML 格式 asc-bp1ffogfdauy0nu5**** 473469C7-AA6F-4DC5-B3DB-A3DC0DE3C83E JSON 格式 { "RequestId": "473469C7-AA6F-4DC5-B3DB-A3DC0DE3C83E", "ScalingConfigurationId": "asc-bp1ffogfdauy0nu5****" } 错误码 访问错误中心查看更多错误码。 HttpCode 错误码 错误信息 描述 400 InstanceType.Mismatch The specified scaling configuration and existing active scaling configuration have different instance type. 指定的伸缩配置的实例规格与当前的伸缩配置的实例规格不匹配。 404 InvalidDataDiskSnapshotId.NotFound Snapshot “XXX” does not exist. 不存在指定的快照。 400 InvalidDataDiskSnapshotId.SizeNotSupported The capacity of snapshot “XXX” exceeds the size limit of the specified disk category. 指定快照的大小超过了磁盘大小的限制。 403 InvalidDevice.InUse Device “XXX” has been occupied. 数据盘挂载点重复。 400 InvalidImageId.InstanceTypeMismatch The specified image does not support the specified instance type. 不允许在指定的实例规格下使用该镜像。 404 InvalidImageId.NotFound The specified image does not exist. 该账号下不存在指定的镜像。 400 InvalidKeyPairName.NotFound The specified KeyPairName does not exist in our records. 指定的KeyPairName不存在。 400 InvalidNetworkType.ForRAMRole RAMRole can't be used For classic instance. 经典网络实例不支持RamRoleName参数。 400 InvalidParameter The specified value of parameter KeyPairName is not valid. Windows系统不支持KeyPairName参数。 400 InvalidParameter.Conflict The value of parameter SystemDisk.Category and parameter DataDisk.N.Category are conflict. 指定的系统盘类型和数据盘类型冲突。 400 InvalidRamRole.NotFound The specified RamRoleName does not exist. 不存在指定的RamRoleName。 400 InvalidScalingConfigurationName.Duplicate The specified value of parameter ScalingConfigurationName is duplicated. 已存在相同伸缩配置名。 404 InvalidScalingGroupId.NotFound The specified scaling group does not exist. 该账号下不存在指定的伸缩组。 400 InvalidSecurityGroupId.IncorrectNetworkType The network type of specified security Group does not support this action. 指定的安全组与伸缩组指定网络类型不一致。 404 InvalidSecurityGroupId.NotFound The specified security group does not exist. 该账号下不存在指定的安全组。 400 InvalidSecurityGroupId.VPCMismatch The specified security group and the specified virtual switch are not in the same VPC. 指定的安全组和虚拟交换机不属于同一个虚拟专有网络。 403 InvalidSnapshot.TooOld This operation is denied because the specified snapshot is created before 2013-07-15. 该快照创建于2013年7月15日或之前,调用被拒绝。 403 InvalidSystemDiskCategory.ValueUnauthorized The system disk category is not authorized. 没有创建临时磁盘系统盘的权限。 400 InvalidUserData.Base64FormatInvalid The specified parameter UserData must be base64 encoded. UserData不符合Base64编码规范。 400 InvalidUserData.SizeExceeded The specified parameter UserData exceeds the size. 指定的UserData过长。 403 QuotaExceeded.EphemeralDiskSize Ephemeral disk size quota exceeded. 临时磁盘数据盘总容量超过2TiB(2048GiB)。 400 QuotaExceeded.ScalingConfiguration Scaling configuration quota exceeded in the specified scaling group. 您目前拥有的伸缩配置个数已经达到上限。 400 QuotaExceeded.SecurityGroupInstance Instance quota exceeded in the specified security group. 指定的安全组中添加的ECS实例个数已经达到上限。 调用DescribeScalingConfigurations查询现有的伸缩配置。 调试 您可以在OpenAPI Explorer中直接运行该接口,免去您计算签名的困扰。运行成功后,OpenAPI Explorer可以自动生成SDK代码示例。 调试 请求参数 名称 类型 是否必选 示例值 描述 Action String 否 DescribeScalingConfigurations 系统规定参数,取值:DescribeScalingConfigurations。 RegionId String 是 cn-qingdao 伸缩配置所属伸缩组的地域ID。 PageNumber Integer 否 1 伸缩配置列表的页码。起始值:1。 默认值:1 。 PageSize Integer 否 50 分页查询时设置的每页行数。最大值:50。 默认值:10。 ScalingGroupId String 否 asg-bp17pelvl720x3v7**** 伸缩组的ID,您可以查询该伸缩组下所有的伸缩配置。 ScalingConfigurationId.1 String 否 asc-bp17pelvl720x5ub**** ScalingConfigurationId.N为待查询伸缩配置的ID,N的取值范围:1~10。查询结果包括生效和失效的伸缩配置,并通过返回参数LifecycleState进行标识。 ScalingConfigurationName.1 String 否 c1908dd1-690f-4c9b-ab73-350f1f06**** ScalingConfigurationName.N为待查询伸缩配置的名称,N的取值范围:1~10。查询结果会忽略失效的伸缩配置名称,并且不报错。 返回数据 名称 类型 示例值 描述 TotalCount Integer 1 伸缩配置的总数。 PageNumber Integer 1 当前页码。 PageSize Integer 50 每页行数。 RequestId String 473469C7-AA6F-4DC5-B3DB-A3DC0DE3C83E 请求ID。 ScalingConfigurations Array 伸缩配置信息的集合。 示例 请求示例 http(s)://[Endpoint]/?Action=DescribeScalingConfigurations &RegionId=cn-qingdao &<公共请求参数> 正常返回示例 XML 格式 804F240A-8D3E-40A1-BD68-6B333DEA2CA8 1 1 50 2014-08-14T10:58Z centos6u5_64_20G_aliaegis_20140703.vhd ecs.t1.xsmall PayByTraffic 200 0 Active asc-bp1ezrfgoyn5kijl**** c1908dd1-690f-4c9b-ab73-350f1f06**** sg-280ih**** sg-bp18kz60mefs**** cloud 200 cloud s-280s7**** /dev/xvdb JSON 格式 { "RequestId": "804F240A-8D3E-40A1-BD68-6B333DEA2CA8", "TotalCount": "1", "PageNumber": "1", "PageSize": "50", "ScalingConfigurations": { "ScalingConfiguration": { "CreationTime": "2014-08-14T10:58Z", "ImageId": "centos6u5_64_20G_aliaegis_20140703.vhd", "InstanceType": "ecs.t1.xsmall", "InternetChargeType": "PayByTraffic", "InternetMaxBandwidthIn": "200", "InternetMaxBandwidthOut": "0", "LifecycleState": "Active", "ScalingConfigurationId": "asc-bp1ezrfgoyn5kijl****", "ScalingConfigurationName": "c1908dd1-690f-4c9b-ab73-350f1f06****", "ScalingGroupId": "sg-280ih****", "SecurityGroupId": "sg-bp18kz60mefs****", "SystemDiskCategory": "cloud", "DataDisks": { "DataDisk": { "Size": "200", "Category": "cloud", "SnapshotId": "s-280s7****", "Device": "/dev/xvdb" } } } } } 错误码 访问错误中心查看更多错误码。调用DeleteScalingConfiguration删除一个伸缩配置。 接口说明 以下情况不能删除伸缩配置: 伸缩配置在伸缩组中处于生效状态。 伸缩组中仍然存在使用该伸缩配置创建的ECS实例。 调试 您可以在OpenAPI Explorer中直接运行该接口,免去您计算签名的困扰。运行成功后,OpenAPI Explorer可以自动生成SDK代码示例。 调试 请求参数 名称 类型 是否必选 示例值 描述 ScalingConfigurationId String 是 eOs27Kb0oXvQcUYjEGel**** 待删除伸缩配置的ID。 Action String 否 DeleteScalingConfiguration 系统规定参数,取值:DeleteScalingConfiguration。 返回数据 名称 类型 示例值 描述 RequestId String 473469C7-AA6F-4DC5-B3DB-A3DC0DE3C83E 请求 ID。无论调用接口成功与否,我们都会返回请求 ID。 示例 请求示例 http://ess.aliyuncs.com/?Action=DeleteScalingConfiguration &ScalingConfigurationId=eOs27Kb0oXvQcUYjEGel**** &<公共请求参数> 正常返回示例 XML 格式 473469C7-AA6F-4DC5-B3DB-A3DC0DE3C83E JSON 格式 { "RequestId":"473469C7-AA6F-4DC5-B3DB-A3DC0DE3C83E" } 错误码 访问错误中心查看更多错误码。 HttpCode 错误码 错误信息 描述 404 InvalidScalingConfigurationId.NotFound The specified scaling configuration does not exist. 指定的伸缩配置在该用户账号下不存在。 400 IncorrectScalingConfigurationLifecycleState The current lifecycle state of specified scaling configuration does not support this action. 指定的伸缩配置未处于Inactive状态。 400 InstanceInUse You cannot delete a scaling configuration or scaling group while there is an instance associated with it. 指定的伸缩配置还有关联的ECS实例未被删除。调用ModifyScalingConfiguration修改一个伸缩配置。 接口说明 如果修改伸缩配置的名称,请注意同一伸缩组下不能存在名称相同的伸缩配置。 调试 您可以在OpenAPI Explorer中直接运行该接口,免去您计算签名的困扰。运行成功后,OpenAPI Explorer可以自动生成SDK代码示例。 调试 请求参数 名称 类型 是否必选 示例值 描述 ScalingConfigurationId String 是 asc-**** 待修改伸缩配置的ID。 Action String 否 ModifyScalingConfiguration 系统规定参数,取值: ModifyScalingConfiguration。 Cpu Integer 否 2 vCPU个数。 同时指定CPU和Memory可以定义实例规格范围,例如,CPU=2且Memory=16可以定义配置为2 vCPU和16 GiB的所有实例规格。弹性伸缩会结合IO优化、可用区等因素确定可用实例规格集合,并根据价格排序为您创建价格最低的实例。 说明 该区间配置效果仅在成本优化模式下且伸缩配置未设置实例规格时生效。 DataDisk.N.AutoSnapshotPolicyId String 否 sp-bp19nq9enxqkomib**** 数据盘使用的自动快照策略ID,N的取值范围:1~16。 DataDisk.N.Category String 否 cloud_ssd 数据盘N的磁盘种类,N的取值范围:1~16。该参数取值范围: cloud:普通云盘。随实例创建的普通云盘的DeleteWithInstance属性为true。 cloud_efficiency:高效云盘 cloud_ssd:SSD云盘 cloud_essd:ESSD云盘 ephemeral_ssd:本地SSD盘 DataDisk.N.DeleteWithInstance Boolean 否 true 指定数据盘是否随实例释放,N的取值范围:1~16。该参数取值范围: true:释放实例时,该磁盘随实例一起释放。 false:释放实例时,该磁盘保留不释放。 该参数只可对独立云盘设置(DataDisk.N.Category为cloud、cloud_efficiency、cloud_ssd或cloud_essd),否则会出现报错。 DataDisk.N.Description String 否 FinanceDept 数据盘的描述,N的取值范围:1~16。长度为2~256个英文或中文字符,不能以 http:// 和 https:// 开头。 DataDisk.N.Device String 否 /dev/xvdb 数据盘挂载点,N的取值范围:1~16。如果您没有指定该参数,则默认在自动创建ECS实例时由系统分配,从/dev/xvdb开始,到/dev/xvdz结束。 DataDisk.N.DiskName String 否 cloud_ssdData 数据盘的名称,N的取值范围:1~16。长度为2~128个英文或中文字符。必须以大小字母或中文开头,不能以 http:// 和 https:// 开头。可以包含数字、半角冒号(:)、下划线(_)或者连字符(-)。 DataDisk.N.Encrypted String 否 false 数据盘N是否加密,N的取值范围:1~16。该参数取值范围: true:加密 false:不加密 DataDisk.N.KMSKeyId String 否 0e478b7a-4262-4802-b8cb-00d3fb40**** 数据盘对应的KMS密钥的ID,N的取值范围:1~16。 DataDisk.N.Size Integer 否 100 数据盘N的磁盘大小,N的取值范围:1~16,内存单位为GiB。取值范围: cloud:5~2000 cloud_efficiency:20~32768 cloud_ssd:20~32768 cloud_essd:20~32768 ephemeral_ssd:5~800 指定该参数后,磁盘大小必须大于等于快照大小(快照通过SnapshotId指定)。 DataDisk.N.SnapshotId String 否 s-snapshot**** 创建数据盘时使用的快照,N的取值范围:1~16。指定该参数后,DataDisk.N.Size会被忽略,实际创建的磁盘大小为指定快照的大小。 如果该快照创建于2013年7月15日或之前,调用会被拒绝,返回参数中会提示InvalidSnapshot.TooOld。 DeploymentSetId String 否 ds-bp13v7bjnj9gis**** ECS实例所属的部署集的ID。 HostName String 否 Joshu**** 云服务器的主机名。点号(.)或连字符(-)不能作为首尾字符,不能连续使用点号(.)或连字符(-)。另外,不同类型实例的命名要求如下: Windows实例:主机名长度为2~15,可以包含大小写字母、数字和连字符(-)。不能包含点号(.),不能全是数字。 其他类型实例(Linux等):主机名长度为2~64,可以包含多个点号(.)。两个点号(.)之间为一段,每段可以包含大小写字母、数字和连字符(-)。 HpcClusterId String 否 hpc-clusterid ECS实例所属的EHPC集群的ID。 ImageId String 否 centos6u5_64_20G_aliaegis_20140703.vhd 镜像文件ID,自动创建实例时使用的镜像资源。 ImageName String 否 suse11sp3_64_20G_aliaegis_20150428.vhd 镜像文件名称,同一个地域内镜像名称唯一。如果设置了ImageId, ImageName将被忽略。 不支持通过ImageName设置镜像市场镜像。 InstanceDescription String 否 FinaceDept ECS实例的描述。长度为2~256个英文或中文字符,不能以 http:// 和 https:// 开头。 InstanceName String 否 Joshu**** 使用本伸缩配置自动创建的ECS实例的名称。 InstanceTypes.N RepeatList 否 ecs.t1.xsmall 多实例规格参数。如果使用了InstanceTypes.N,InstanceType将被忽略,其中N的取值范围:1~10,即一个伸缩配置内最多可以设置10种实例规格。 N代表当前伸缩配置中实例规格的优先级,编号为1的实例规格优先级最高,实例规格优先级随着编号的增大依次降低。当无法根据优先级较高的实例规格创建出实例时,弹性伸缩服务会自动选择下一优先级的实例规格来创建实例。 InternetChargeType String 否 PayByBandwidth 网络计费类型,取值范围: PayByBandwidth:按带宽计费。此时InternetMaxBandwidthOut即为所选的固定带宽值。 PayByTraffic:按流量计费。此时InternetMaxBandwidthOut只是一个带宽上限,计费以实际产生的网络流量为依据。 InternetMaxBandwidthOut Integer 否 50 公网出带宽最大值,单位为Mbps (Mega bit per second),取值范围: 按带宽计费:0~100,如果您没有指定该参数,则出带宽将自动被设置为0Mbps。 按流量计费:0~100,如果您没有指定该参数,则会出现报错。 IoOptimized String 否 none 是否为I/O优化实例。取值范围: none:非I/O优化实例。 optimized:I/O优化实例。 KeyPairName String 否 null 登录ECS实例时使用的密钥对的名称。 对Windows实例,该参数将被忽略,默认为空。 对Linux实例,密码登录方式会被初始化成禁止。 LoadBalancerWeight Integer 否 50 后端服务器的权重,取值范围:0~100。 Memory Integer 否 16 内存大小。 同时指定CPU和Memory可以定义实例规格范围,例如,CPU=2且Memory=16可以定义配置为2 vCPU和16 GiB的所有实例规格。弹性伸缩会结合IO优化、可用区等因素确定可用实例规格集合,并根据价格排序为您创建价格最低的实例。 说明 该区间配置效果仅在成本优化模式下且伸缩配置未设置实例规格时生效。 Override Boolean 否 true 是否覆盖。取值范围: true false PasswordInherit Boolean 否 false 是否使用镜像预设的密码。使用该参数时,您需要确保使用的镜像已经设置了密码。 RamRoleName String 否 RamRoleTest ECS实例的RAM角色名称。RAM角色名称由RAM提供和维护,您可调用ListRoles查询可用的RAM角色。创建RAM角色的方法请参见CreateRole。 ResourceGroupId String 否 abcd1234abcd**** ECS实例所属资源组的ID。 ScalingConfigurationName String 否 test-modify 伸缩配置的名称,2~64个英文或中文字符,以数字、大小写字母或中文开头,可包含数字、下划线(_)、连字符(-)或点号(.)。 在同一地域下同一伸缩组内伸缩配置名称唯一。如果您没有指定该参数,则默认使用伸缩配置的ID。 SecurityGroupId String 否 sg-F876F**** ECS实例所属的安全组的ID,同一个安全组内的ECS实例可以互相访问。 SecurityGroupIds.N RepeatList 否 sg-bp18kz60mefs**** 将ECS实例同时加入多个安全组。N的取值范围与实例能够加入安全组上限有关。更多详情,请参见使用限制下的安全组章节。 说明 不支持同时指定SecurityGroupId和SecurityGroupIds.N。 SpotPriceLimit.N.InstanceType String 否 ecs.t1.small 抢占式实例的实例规格,N的取值范围:1~10。SpotStrategy取值为SpotWithPriceLimit时生效。 SpotPriceLimit.N.PriceLimit Float 否 0.125 抢占式实例对应的出价,N的取值范围:1~10。SpotStrategy取值为SpotWithPriceLimit时生效。 SpotStrategy String 否 NoSpot 后付费实例的抢占策略。取值范围: NoSpot:普通的按量付费实例。 SpotWithPriceLimit:设置上限价格的抢占式实例。 SpotAsPriceGo:系统自动出价,跟随当前市场实际价格。 SystemDisk.AutoSnapshotPolicyId String 否 sp-bp12m37ccmxvbmi5**** 系统盘使用的自动快照策略ID。 SystemDisk.Category String 否 cloud_efficiency 系统盘的磁盘种类。取值范围: cloud:普通云盘 cloud_efficiency:高效云盘 cloud_ssd:SSD云盘 cloud_essd:ESSD云盘 ephemeral_ssd:本地SSD盘 SystemDisk.Description String 否 FinanceDept 系统盘的描述。长度为2~256个英文或中文字符,不能以 http:// 和 https:// 开头。 SystemDisk.DiskName String 否 cloud_ssdSystem 系统盘的名称。长度为2~128个英文或中文字符。必须以大小字母或中文开头,不能以 http:// 和 https:// 开头。可以包含数字、半角冒号(:)、下划线(_)或者连字符(-)。 SystemDisk.Size Integer 否 50 系统盘的大小,单位:GiB。取值范围: cloud:20~500 cloud_efficiency:20~500 cloud_ssd:20~500 cloud_essd:20~500 ephemeral_ssd:20~500 指定该参数后,系统盘大小必须大于等于max{20, ImageSize}。 Tags String 否 “key1”:”value1” ECS实例的标签。标签以键值对方式传入,最多可以使用5组标签。Key和Value的使用要求如下: Key最多支持64个字符,不能以aliyun和acs:开头,不能包含 http:// 或者 https:// 。一旦使用标签,Key不允许为空字符串。 Value最多支持128个字符,不能以aliyun和acs:开头,不能包含 http:// 或者 https:// 。Value可以为空字符串。 UserData String 否 echo hello ecs! ECS实例的自定义数据,需要以Base64方式编码,编码前的原始数据最多为16KB。 返回数据 名称 类型 示例值 描述 RequestId String 473469C7-AA6F-4DC5-B3DB-A3DC0DE3C83E 请求ID。 示例 请求示例 http(s)://[Endpoint]/?Action=ModifyScalingConfiguration &ScalingConfigurationId=asc-**** &<公共请求参数> 正常返回示例 XML 格式 473469C7-AA6F-4DC5-B3DB-A3DC0DE3C83E JSON 格式 { "requestId":"473469C7-AA6F-4DC5-B3DB-A3DC0DE3C83E" } 错误码 访问错误中心查看更多错误码。 HttpCode 错误码 错误信息 描述 403 Forbidden.Unauthorized A required authorization for the specified action is not supplied. 未授权操作当前Action。 404 InvalidDataDiskSnapshotId.NotFound Snapshot “XXX” does not exist. 不存在指定的快照。 400 InvalidDataDiskSnapshotId.SizeNotSupported The capacity of snapshot “XXX” exceeds the size limit of the specified disk category. 指定快照的大小超过了磁盘大小的限制。 404 InvalidImageId.NotFound The specified image does not exist. 指定的镜像不存在。 400 InvalidKeyPairName.NotFound The specified KeyPairName does not exist in our records. 指定的KeyPairName不存在。 400 InvalidNetworkType.ForRAMRole RAMRole can’t be used For classic instance. 经典网络实例不支持RamRoleName参数。 400 InvalidParamter The specified value of parameter is not valid. 指定的参数值无效。 400 InvalidScalingConfigurationName.Duplicate The specified value of parameter is duplicated. 伸缩配置名已存在。 400 InvalidSecurityGroupId.IncorrectNetworkType The network type of specified Security Group does not support this action. 指定的安全组与伸缩组指定网络类型不一致。 400 InvalidSecurityGroupId.VPCMismatch The specified security group and the specified virtual switch are not in the same VPC. 指定的安全组和虚拟交换机不属于同一个虚拟专有网络。 400 InvalidTags.KeyValue The specified tags key/value cannot be empty. 必须指定Tags参数。 400 InvalidTags.ListSize The specified tags list size cannot be more than “5”. Tags列表长度超过限制长度。 400 InvalidUserData.Base64FormatInvalid The specified parameter UserData must be base64 encoded. UserData不符合Base64编码规范。 400 InvalidUserData.SizeExceeded The specified parameter UserData exceeds the size. 指定的UserData过长。

1934890530796658 2020-03-25 10:04:36 0 浏览量 回答数 0

回答

在向表中添加额外的2000左右行之后,还要验证MySQL是否仍执行全表扫描user_metrics。在小型表中,按索引访问实际上比表扫描更昂贵(在I / O方式上),MySQL的优化程序可能会考虑到这一点。 与我之前的文章相反,事实证明MySQL也在使用基于成本的优化器,这是一个好消息-也就是说,ANALYZE如果您认为数据库中的数据量足以代表数据库运行了至少一次,将来的日常使用。 在处理基于成本的优化器(Oracle,Postgres等)时,您需要确保ANALYZE在其大小增加10-15%以上时,定期在各种表上运行。(默认情况下,Postgres将自动为您执行此操作,而其他RDBMS将把此职责留给DBA(即您)。)通过统计分析,ANALYZE将有助于优化程序更好地了解I / O量(以及其他相关资源)在各种候选执行计划之间进行选择时,将涉及到诸如CPU之类的,例如用于排序的信息。运行失败ANALYZE可能会导致非常糟糕的规划决策,有时甚至是灾难性的决策(例如,由于s 上的嵌套循环不好,毫秒查询有时会花费数小时JOIN)。 如果运行后性能仍然不能令人满意ANALYZE,则通常可以使用提示来解决该问题,例如FORCE INDEX,而在其他情况下,您可能会偶然发现MySQL错误(例如,这个较旧的错误可能会咬住您的本人)。使用Rails的nested_set)。 现在,由于您使用的是Rails应用程序,因此ActiveRecord使用提示来发出自定义查询而不是继续使用ActiveRecord-生成的查询将很麻烦(并且破坏的目的)。 我已经提到过,在我们的Rails应用程序中,所有 SELECT查询在切换到Postgres后都降至100ms以下,而ActiveRecord由于内部表扫描的嵌套循环,即使使用索引,由MySQL 生成的某些复杂联接有时也可能需要15s或更长时间。可用。没有哪个优化器是完美的,您应该注意这些选择。除了查询计划优化之外,还需要注意其他潜在的性能问题。但是,这超出了您的问题范围。来源:stack overflow

保持可爱mmm 2020-05-17 10:11:03 0 浏览量 回答数 0

回答

92题 一般来说,建立INDEX有以下益处:提高查询效率;建立唯一索引以保证数据的唯一性;设计INDEX避免排序。 缺点,INDEX的维护有以下开销:叶节点的‘分裂’消耗;INSERT、DELETE和UPDATE操作在INDEX上的维护开销;有存储要求;其他日常维护的消耗:对恢复的影响,重组的影响。 需要建立索引的情况:为了建立分区数据库的PATITION INDEX必须建立; 为了保证数据约束性需要而建立的INDEX必须建立; 为了提高查询效率,则考虑建立(是否建立要考虑相关性能及维护开销); 考虑在使用UNION,DISTINCT,GROUP BY,ORDER BY等字句的列上加索引。 91题 作用:加快查询速度。原则:(1) 如果某属性或属性组经常出现在查询条件中,考虑为该属性或属性组建立索引;(2) 如果某个属性常作为最大值和最小值等聚集函数的参数,考虑为该属性建立索引;(3) 如果某属性经常出现在连接操作的连接条件中,考虑为该属性或属性组建立索引。 90题 快照Snapshot是一个文件系统在特定时间里的镜像,对于在线实时数据备份非常有用。快照对于拥有不能停止的应用或具有常打开文件的文件系统的备份非常重要。对于只能提供一个非常短的备份时间而言,快照能保证系统的完整性。 89题 游标用于定位结果集的行,通过判断全局变量@@FETCH_STATUS可以判断是否到了最后,通常此变量不等于0表示出错或到了最后。 88题 事前触发器运行于触发事件发生之前,而事后触发器运行于触发事件发生之后。通常事前触发器可以获取事件之前和新的字段值。语句级触发器可以在语句执行前或后执行,而行级触发在触发器所影响的每一行触发一次。 87题 MySQL可以使用多个字段同时建立一个索引,叫做联合索引。在联合索引中,如果想要命中索引,需要按照建立索引时的字段顺序挨个使用,否则无法命中索引。具体原因为:MySQL使用索引时需要索引有序,假设现在建立了"name,age,school"的联合索引,那么索引的排序为: 先按照name排序,如果name相同,则按照age排序,如果age的值也相等,则按照school进行排序。因此在建立联合索引的时候应该注意索引列的顺序,一般情况下,将查询需求频繁或者字段选择性高的列放在前面。此外可以根据特例的查询或者表结构进行单独的调整。 86题 建立索引的时候一般要考虑到字段的使用频率,经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话,还需要考虑联合索引中的顺序。此外也要考虑其他方面,比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 85题 存储过程是一组Transact-SQL语句,在一次编译后可以执行多次。因为不必重新编译Transact-SQL语句,所以执行存储过程可以提高性能。触发器是一种特殊类型的存储过程,不由用户直接调用。创建触发器时会对其进行定义,以便在对特定表或列作特定类型的数据修改时执行。 84题 存储过程是用户定义的一系列SQL语句的集合,涉及特定表或其它对象的任务,用户可以调用存储过程,而函数通常是数据库已定义的方法,它接收参数并返回某种类型的值并且不涉及特定用户表。 83题 减少表连接,减少复杂 SQL,拆分成简单SQL。减少排序:非必要不排序,利用索引排序,减少参与排序的记录数。尽量避免 select *。尽量用 join 代替子查询。尽量少使用 or,使用 in 或者 union(union all) 代替。尽量用 union all 代替 union。尽量早的将无用数据过滤:选择更优的索引,先分页再Join…。避免类型转换:索引失效。优先优化高并发的 SQL,而不是执行频率低某些“大”SQL。从全局出发优化,而不是片面调整。尽可能对每一条SQL进行 explain。 82题 如果条件中有or,即使其中有条件带索引也不会使用(要想使用or,又想让索引生效,只能将or条件中的每个列都加上索引)。对于多列索引,不是使用的第一部分,则不会使用索引。like查询是以%开头。如果列类型是字符串,那一定要在条件中将数据使用引号引用起来,否则不使用索引。如果mysql估计使用全表扫描要比使用索引快,则不使用索引。例如,使用<>、not in 、not exist,对于这三种情况大多数情况下认为结果集很大,MySQL就有可能不使用索引。 81题 主键不能重复,不能为空,唯一键不能重复,可以为空。建立主键的目的是让外键来引用。一个表最多只有一个主键,但可以有很多唯一键。 80题 空值('')是不占用空间的,判断空字符用=''或者<>''来进行处理。NULL值是未知的,且占用空间,不走索引;判断 NULL 用 IS NULL 或者 is not null ,SQL 语句函数中可以使用 ifnull ()函数来进行处理。无法比较 NULL 和 0;它们是不等价的。无法使用比较运算符来测试 NULL 值,比如 =, <, 或者 <>。NULL 值可以使用 <=> 符号进行比较,该符号与等号作用相似,但对NULL有意义。进行 count ()统计某列的记录数的时候,如果采用的 NULL 值,会被系统自动忽略掉,但是空值是统计到其中。 79题 HEAP表是访问数据速度最快的MySQL表,他使用保存在内存中的散列索引。一旦服务器重启,所有heap表数据丢失。BLOB或TEXT字段是不允许的。只能使用比较运算符=,<,>,=>,= <。HEAP表不支持AUTO_INCREMENT。索引不可为NULL。 78题 如果想输入字符为十六进制数字,可以输入带有单引号的十六进制数字和前缀(X),或者只用(Ox)前缀输入十六进制数字。如果表达式上下文是字符串,则十六进制数字串将自动转换为字符串。 77题 Mysql服务器通过权限表来控制用户对数据库的访问,权限表存放在mysql数据库里,由mysql_install_db脚本初始化。这些权限表分别user,db,table_priv,columns_priv和host。 76题 在缺省模式下,MYSQL是autocommit模式的,所有的数据库更新操作都会即时提交,所以在缺省情况下,mysql是不支持事务的。但是如果你的MYSQL表类型是使用InnoDB Tables 或 BDB tables的话,你的MYSQL就可以使用事务处理,使用SET AUTOCOMMIT=0就可以使MYSQL允许在非autocommit模式,在非autocommit模式下,你必须使用COMMIT来提交你的更改,或者用ROLLBACK来回滚你的更改。 75题 它会停止递增,任何进一步的插入都将产生错误,因为密钥已被使用。 74题 创建索引的时候尽量使用唯一性大的列来创建索引,由于使用b+tree做为索引,以innodb为例,一个树节点的大小由“innodb_page_size”,为了减少树的高度,同时让一个节点能存放更多的值,索引列尽量在整数类型上创建,如果必须使用字符类型,也应该使用长度较少的字符类型。 73题 当MySQL单表记录数过大时,数据库的CRUD性能会明显下降,一些常见的优化措施如下: 限定数据的范围: 务必禁止不带任何限制数据范围条件的查询语句。比如:我们当用户在查询订单历史的时候,我们可以控制在一个月的范围内。读/写分离: 经典的数据库拆分方案,主库负责写,从库负责读。垂直分区: 根据数据库里面数据表的相关性进行拆分。简单来说垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表。水平分区: 保持数据表结构不变,通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中,达到了分布式的目的。水平拆分可以支撑非常大的数据量。 72题 乐观锁失败后会抛出ObjectOptimisticLockingFailureException,那么我们就针对这块考虑一下重试,自定义一个注解,用于做切面。针对注解进行切面,设置最大重试次数n,然后超过n次后就不再重试。 71题 一致性非锁定读讲的是一条记录被加了X锁其他事务仍然可以读而不被阻塞,是通过innodb的行多版本实现的,行多版本并不是实际存储多个版本记录而是通过undo实现(undo日志用来记录数据修改前的版本,回滚时会用到,用来保证事务的原子性)。一致性锁定读讲的是我可以通过SELECT语句显式地给一条记录加X锁从而保证特定应用场景下的数据一致性。 70题 数据库引擎:尤其是mysql数据库只有是InnoDB引擎的时候事物才能生效。 show engines 查看数据库默认引擎;SHOW TABLE STATUS from 数据库名字 where Name='表名' 如下;SHOW TABLE STATUS from rrz where Name='rrz_cust';修改表的引擎alter table table_name engine=innodb。 69题 如果是等值查询,那么哈希索引明显有绝对优势,因为只需要经过一次算法即可找到相应的键值;当然了,这个前提是,键值都是唯一的。如果键值不是唯一的,就需要先找到该键所在位置,然后再根据链表往后扫描,直到找到相应的数据;如果是范围查询检索,这时候哈希索引就毫无用武之地了,因为原先是有序的键值,经过哈希算法后,有可能变成不连续的了,就没办法再利用索引完成范围查询检索;同理,哈希索引也没办法利用索引完成排序,以及like ‘xxx%’ 这样的部分模糊查询(这种部分模糊查询,其实本质上也是范围查询);哈希索引也不支持多列联合索引的最左匹配规则;B+树索引的关键字检索效率比较平均,不像B树那样波动幅度大,在有大量重复键值情况下,哈希索引的效率也是极低的,因为存在所谓的哈希碰撞问题。 68题 decimal精度比float高,数据处理比float简单,一般优先考虑,但float存储的数据范围大,所以范围大的数据就只能用它了,但要注意一些处理细节,因为不精确可能会与自己想的不一致,也常有关于float 出错的问题。 67题 datetime、timestamp精确度都是秒,datetime与时区无关,存储的范围广(1001-9999),timestamp与时区有关,存储的范围小(1970-2038)。 66题 Char使用固定长度的空间进行存储,char(4)存储4个字符,根据编码方式的不同占用不同的字节,gbk编码方式,不论是中文还是英文,每个字符占用2个字节的空间,utf8编码方式,每个字符占用3个字节的空间。Varchar保存可变长度的字符串,使用额外的一个或两个字节存储字符串长度,varchar(10),除了需要存储10个字符,还需要1个字节存储长度信息(10),超过255的长度需要2个字节来存储。char和varchar后面如果有空格,char会自动去掉空格后存储,varchar虽然不会去掉空格,但在进行字符串比较时,会去掉空格进行比较。Varbinary保存变长的字符串,后面不会补\0。 65题 首先分析语句,看看是否load了额外的数据,可能是查询了多余的行并且抛弃掉了,可能是加载了许多结果中并不需要的列,对语句进行分析以及重写。分析语句的执行计划,然后获得其使用索引的情况,之后修改语句或者修改索引,使得语句可以尽可能的命中索引。如果对语句的优化已经无法进行,可以考虑表中的数据量是否太大,如果是的话可以进行横向或者纵向的分表。 64题 建立索引的时候一般要考虑到字段的使用频率,经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话,还需要考虑联合索引中的顺序。此外也要考虑其他方面,比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 63题 存储过程是一些预编译的SQL语句。1、更加直白的理解:存储过程可以说是一个记录集,它是由一些T-SQL语句组成的代码块,这些T-SQL语句代码像一个方法一样实现一些功能(对单表或多表的增删改查),然后再给这个代码块取一个名字,在用到这个功能的时候调用他就行了。2、存储过程是一个预编译的代码块,执行效率比较高,一个存储过程替代大量T_SQL语句 ,可以降低网络通信量,提高通信速率,可以一定程度上确保数据安全。 62题 密码散列、盐、用户身份证号等固定长度的字符串应该使用char而不是varchar来存储,这样可以节省空间且提高检索效率。 61题 推荐使用自增ID,不要使用UUID。因为在InnoDB存储引擎中,主键索引是作为聚簇索引存在的,也就是说,主键索引的B+树叶子节点上存储了主键索引以及全部的数据(按照顺序),如果主键索引是自增ID,那么只需要不断向后排列即可,如果是UUID,由于到来的ID与原来的大小不确定,会造成非常多的数据插入,数据移动,然后导致产生很多的内存碎片,进而造成插入性能的下降。总之,在数据量大一些的情况下,用自增主键性能会好一些。 60题 char是一个定长字段,假如申请了char(10)的空间,那么无论实际存储多少内容。该字段都占用10个字符,而varchar是变长的,也就是说申请的只是最大长度,占用的空间为实际字符长度+1,最后一个字符存储使用了多长的空间。在检索效率上来讲,char > varchar,因此在使用中,如果确定某个字段的值的长度,可以使用char,否则应该尽量使用varchar。例如存储用户MD5加密后的密码,则应该使用char。 59题 一. read uncommitted(读取未提交数据) 即便是事务没有commit,但是我们仍然能读到未提交的数据,这是所有隔离级别中最低的一种。 二. read committed(可以读取其他事务提交的数据)---大多数数据库默认的隔离级别 当前会话只能读取到其他事务提交的数据,未提交的数据读不到。 三. repeatable read(可重读)---MySQL默认的隔离级别 当前会话可以重复读,就是每次读取的结果集都相同,而不管其他事务有没有提交。 四. serializable(串行化) 其他会话对该表的写操作将被挂起。可以看到,这是隔离级别中最严格的,但是这样做势必对性能造成影响。所以在实际的选用上,我们要根据当前具体的情况选用合适的。 58题 B+树的高度一般为2-4层,所以查找记录时最多只需要2-4次IO,相对二叉平衡树已经大大降低了。范围查找时,能通过叶子节点的指针获取数据。例如查找大于等于3的数据,当在叶子节点中查到3时,通过3的尾指针便能获取所有数据,而不需要再像二叉树一样再获取到3的父节点。 57题 因为事务在修改页时,要先记 undo,在记 undo 之前要记 undo 的 redo, 然后修改数据页,再记数据页修改的 redo。 Redo(里面包括 undo 的修改) 一定要比数据页先持久化到磁盘。 当事务需要回滚时,因为有 undo,可以把数据页回滚到前镜像的状态,崩溃恢复时,如果 redo log 中事务没有对应的 commit 记录,那么需要用 undo把该事务的修改回滚到事务开始之前。 如果有 commit 记录,就用 redo 前滚到该事务完成时并提交掉。 56题 redo log是物理日志,记录的是"在某个数据页上做了什么修改"。 binlog是逻辑日志,记录的是这个语句的原始逻辑,比如"给ID=2这一行的c字段加1"。 redo log是InnoDB引擎特有的;binlog是MySQL的Server层实现的,所有引擎都可以使用。 redo log是循环写的,空间固定会用完:binlog 是可以追加写入的。"追加写"是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。 最开始 MySQL 里并没有 InnoDB 引擎,MySQL 自带的引擎是 MyISAM,但是 MyISAM 没有 crash-safe 的能力,binlog日志只能用于归档。而InnoDB 是另一个公司以插件形式引入 MySQL 的,既然只依靠 binlog 是没有 crash-safe 能力的,所以 InnoDB 使用另外一套日志系统,也就是 redo log 来实现 crash-safe 能力。 55题 重做日志(redo log)      作用:确保事务的持久性,防止在发生故障,脏页未写入磁盘。重启数据库会进行redo log执行重做,达到事务一致性。 回滚日志(undo log)  作用:保证数据的原子性,保存了事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制下的读(MVCC),也即非锁定读。 二进 制日志(binlog)    作用:用于主从复制,实现主从同步;用于数据库的基于时间点的还原。 错误日志(errorlog) 作用:Mysql本身启动,停止,运行期间发生的错误信息。 慢查询日志(slow query log)  作用:记录执行时间过长的sql,时间阈值可以配置,只记录执行成功。 一般查询日志(general log)    作用:记录数据库的操作明细,默认关闭,开启后会降低数据库性能 。 中继日志(relay log) 作用:用于数据库主从同步,将主库发来的bin log保存在本地,然后从库进行回放。 54题 MySQL有三种锁的级别:页级、表级、行级。 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。 页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。 死锁: 是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。 死锁的关键在于:两个(或以上)的Session加锁的顺序不一致。 那么对应的解决死锁问题的关键就是:让不同的session加锁有次序。死锁的解决办法:1.查出的线程杀死。2.设置锁的超时时间。3.指定获取锁的顺序。 53题 当多个用户并发地存取数据时,在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性(脏读,不可重复读,幻读等),可能产生死锁。 乐观锁:乐观锁不是数据库自带的,需要我们自己去实现。 悲观锁:在进行每次操作时都要通过获取锁才能进行对相同数据的操作。 共享锁:加了共享锁的数据对象可以被其他事务读取,但不能修改。 排他锁:当数据对象被加上排它锁时,一个事务必须得到锁才能对该数据对象进行访问,一直到事务结束锁才被释放。 行锁:就是给某一条记录加上锁。 52题 Mysql是关系型数据库,MongoDB是非关系型数据库,数据存储结构的不同。 51题 关系型数据库优点:1.保持数据的一致性(事务处理)。 2.由于以标准化为前提,数据更新的开销很小。 3. 可以进行Join等复杂查询。 缺点:1、为了维护一致性所付出的巨大代价就是其读写性能比较差。 2、固定的表结构。 3、高并发读写需求。 4、海量数据的高效率读写。 非关系型数据库优点:1、无需经过sql层的解析,读写性能很高。 2、基于键值对,数据没有耦合性,容易扩展。 3、存储数据的格式:nosql的存储格式是key,value形式、文档形式、图片形式等等,文档形式、图片形式等等,而关系型数据库则只支持基础类型。 缺点:1、不提供sql支持,学习和使用成本较高。 2、无事务处理,附加功能bi和报表等支持也不好。 redis与mongoDB的区别: 性能:TPS方面redis要大于mongodb。 可操作性:mongodb支持丰富的数据表达,索引,redis较少的网络IO次数。 可用性:MongoDB优于Redis。 一致性:redis事务支持比较弱,mongoDB不支持事务。 数据分析:mongoDB内置了数据分析的功能(mapreduce)。 应用场景:redis数据量较小的更性能操作和运算上,MongoDB主要解决海量数据的访问效率问题。 50题 如果Redis被当做缓存使用,使用一致性哈希实现动态扩容缩容。如果Redis被当做一个持久化存储使用,必须使用固定的keys-to-nodes映射关系,节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况),必须使用可以在运行时进行数据再平衡的一套系统,而当前只有Redis集群可以做到这样。 49题 分区可以让Redis管理更大的内存,Redis将可以使用所有机器的内存。如果没有分区,你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。 48题 除了缓存服务器自带的缓存失效策略之外(Redis默认的有6种策略可供选择),我们还可以根据具体的业务需求进行自定义的缓存淘汰,常见的策略有两种: 1.定时去清理过期的缓存; 2.当有用户请求过来时,再判断这个请求所用到的缓存是否过期,过期的话就去底层系统得到新数据并更新缓存。 两者各有优劣,第一种的缺点是维护大量缓存的key是比较麻烦的,第二种的缺点就是每次用户请求过来都要判断缓存失效,逻辑相对比较复杂!具体用哪种方案,可以根据应用场景来权衡。 47题 Redis提供了两种方式来作消息队列: 一个是使用生产者消费模式模式:会让一个或者多个客户端监听消息队列,一旦消息到达,消费者马上消费,谁先抢到算谁的,如果队列里没有消息,则消费者继续监听 。另一个就是发布订阅者模式:也是一个或多个客户端订阅消息频道,只要发布者发布消息,所有订阅者都能收到消息,订阅者都是平等的。 46题 Redis的数据结构列表(list)可以实现延时队列,可以通过队列和栈来实现。blpop/brpop来替换lpop/rpop,blpop/brpop阻塞读在队列没有数据的时候,会立即进入休眠状态,一旦数据到来,则立刻醒过来。Redis的有序集合(zset)可以用于实现延时队列,消息作为value,时间作为score。Zrem 命令用于移除有序集中的一个或多个成员,不存在的成员将被忽略。当 key 存在但不是有序集类型时,返回一个错误。 45题 1.热点数据缓存:因为Redis 访问速度块、支持的数据类型比较丰富。 2.限时业务:expire 命令设置 key 的生存时间,到时间后自动删除 key。 3.计数器:incrby 命令可以实现原子性的递增。 4.排行榜:借助 SortedSet 进行热点数据的排序。 5.分布式锁:利用 Redis 的 setnx 命令进行。 6.队列机制:有 list push 和 list pop 这样的命令。 44题 一致哈希 是一种特殊的哈希算法。在使用一致哈希算法后,哈希表槽位数(大小)的改变平均只需要对 K/n 个关键字重新映射,其中K是关键字的数量, n是槽位数量。然而在传统的哈希表中,添加或删除一个槽位的几乎需要对所有关键字进行重新映射。 43题 RDB的优点:适合做冷备份;读写服务影响小,reids可以保持高性能;重启和恢复redis进程,更加快速。RDB的缺点:宕机会丢失最近5分钟的数据;文件特别大时可能会暂停数毫秒,或者甚至数秒。 AOF的优点:每个一秒执行fsync操作,最多丢失1秒钟的数据;以append-only模式写入,没有任何磁盘寻址的开销;文件过大时,不会影响客户端读写;适合做灾难性的误删除的紧急恢复。AOF的缺点:AOF日志文件比RDB数据快照文件更大,支持写QPS比RDB支持的写QPS低;比RDB脆弱,容易有bug。 42题 对于Redis而言,命令的原子性指的是:一个操作的不可以再分,操作要么执行,要么不执行。Redis的操作之所以是原子性的,是因为Redis是单线程的。而在程序中执行多个Redis命令并非是原子性的,这也和普通数据库的表现是一样的,可以用incr或者使用Redis的事务,或者使用Redis+Lua的方式实现。对Redis来说,执行get、set以及eval等API,都是一个一个的任务,这些任务都会由Redis的线程去负责执行,任务要么执行成功,要么执行失败,这就是Redis的命令是原子性的原因。 41题 (1)twemproxy,使用方式简单(相对redis只需修改连接端口),对旧项目扩展的首选。(2)codis,目前用的最多的集群方案,基本和twemproxy一致的效果,但它支持在节点数改变情况下,旧节点数据可恢复到新hash节点。(3)redis cluster3.0自带的集群,特点在于他的分布式算法不是一致性hash,而是hash槽的概念,以及自身支持节点设置从节点。(4)在业务代码层实现,起几个毫无关联的redis实例,在代码层,对key进行hash计算,然后去对应的redis实例操作数据。这种方式对hash层代码要求比较高,考虑部分包括,节点失效后的代替算法方案,数据震荡后的自动脚本恢复,实例的监控,等等。 40题 (1) Master最好不要做任何持久化工作,如RDB内存快照和AOF日志文件 (2) 如果数据比较重要,某个Slave开启AOF备份数据,策略设置为每秒同步一次 (3) 为了主从复制的速度和连接的稳定性,Master和Slave最好在同一个局域网内 (4) 尽量避免在压力很大的主库上增加从库 (5) 主从复制不要用图状结构,用单向链表结构更为稳定,即:Master <- Slave1 <- Slave2 <- Slave3...这样的结构方便解决单点故障问题,实现Slave对Master的替换。如果Master挂了,可以立刻启用Slave1做Master,其他不变。 39题 比如订单管理,热数据:3个月内的订单数据,查询实时性较高;温数据:3个月 ~ 12个月前的订单数据,查询频率不高;冷数据:1年前的订单数据,几乎不会查询,只有偶尔的查询需求。热数据使用mysql进行存储,需要分库分表;温数据可以存储在ES中,利用搜索引擎的特性基本上也可以做到比较快的查询;冷数据可以存放到Hive中。从存储形式来说,一般情况冷数据存储在磁带、光盘,热数据一般存放在SSD中,存取速度快,而温数据可以存放在7200转的硬盘。 38题 当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核心流程的性能时,仍然需要保证服务还是可用的,即使是有损服务。系统可以根据一些关键数据进行自动降级,也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用,即使是有损的。而且有些服务是无法降级的(如加入购物车、结算)。 37题 分层架构设计,有一条准则:站点层、服务层要做到无数据无状态,这样才能任意的加节点水平扩展,数据和状态尽量存储到后端的数据存储服务,例如数据库服务或者缓存服务。显然进程内缓存违背了这一原则。 36题 更新数据的时候,根据数据的唯一标识,将操作路由之后,发送到一个 jvm 内部队列中。读取数据的时候,如果发现数据不在缓存中,那么将重新读取数据+更新缓存的操作,根据唯一标识路由之后,也发送同一个 jvm 内部队列中。一个队列对应一个工作线程,每个工作线程串行拿到对应的操作,然后一条一条的执行。 35题 redis分布式锁加锁过程:通过setnx向特定的key写入一个随机值,并同时设置失效时间,写值成功既加锁成功;redis分布式锁解锁过程:匹配随机值,删除redis上的特点key数据,要保证获取数据、判断一致以及删除数据三个操作是原子的,为保证原子性一般使用lua脚本实现;在此基础上进一步优化的话,考虑使用心跳检测对锁的有效期进行续期,同时基于redis的发布订阅优雅的实现阻塞式加锁。 34题 volatile-lru:当内存不足以容纳写入数据时,从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。 volatile-ttl:当内存不足以容纳写入数据时,从已设置过期时间的数据集中挑选将要过期的数据淘汰。 volatile-random:当内存不足以容纳写入数据时,从已设置过期时间的数据集中任意选择数据淘汰。 allkeys-lru:当内存不足以容纳写入数据时,从数据集中挑选最近最少使用的数据淘汰。 allkeys-random:当内存不足以容纳写入数据时,从数据集中任意选择数据淘汰。 noeviction:禁止驱逐数据,当内存使用达到阈值的时候,所有引起申请内存的命令会报错。 33题 定时过期:每个设置过期时间的key都需要创建一个定时器,到过期时间就会立即清除。该策略可以立即清除过期的数据,对内存很友好;但是会占用大量的CPU资源去处理过期的数据,从而影响缓存的响应时间和吞吐量。 惰性过期:只有当访问一个key时,才会判断该key是否已过期,过期则清除。该策略可以最大化地节省CPU资源,却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问,从而不会被清除,占用大量内存。 定期过期:每隔一定的时间,会扫描一定数量的数据库的expires字典中一定数量的key,并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时,可以在不同情况下使得CPU和内存资源达到最优的平衡效果。 32题 缓存击穿,一个存在的key,在缓存过期的一刻,同时有大量的请求,这些请求都会击穿到DB,造成瞬时DB请求量大、压力骤增。如何避免:在访问key之前,采用SETNX(set if not exists)来设置另一个短期key来锁住当前key的访问,访问结束再删除该短期key。 31题 缓存雪崩,是指在某一个时间段,缓存集中过期失效。大量的key设置了相同的过期时间,导致在缓存在同一时刻全部失效,造成瞬时DB请求量大、压力骤增,引起雪崩。而缓存服务器某个节点宕机或断网,对数据库服务器造成的压力是不可预知的,很有可能瞬间就把数据库压垮。如何避免:1.redis高可用,搭建redis集群。2.限流降级,在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。3.数据预热,在即将发生大并发访问前手动触发加载缓存不同的key,设置不同的过期时间。 30题 缓存穿透,是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是,数据查询先进行缓存查询,如果key不存在或者key已经过期,再对数据库进行查询,并把查询到的对象,放进缓存。如果数据库查询对象为空,则不放进缓存。一些恶意的请求会故意查询不存在的 key,请求量很大,对数据库造成压力,甚至压垮数据库。 如何避免:1:对查询结果为空的情况也进行缓存,缓存时间设置短一点,或者该 key 对应的数据 insert 了之后清理缓存。2:对一定不存在的 key 进行过滤。可以把所有的可能存在的 key 放到一个大的 Bitmap 中,查询时通过该 bitmap 过滤。 29题 1.memcached 所有的值均是简单的字符串,redis 作为其替代者,支持更为丰富的数据类型。 2.redis 的速度比 memcached 快很多。 3.redis 可以持久化其数据。 4.Redis支持数据的备份,即master-slave模式的数据备份。 5.Redis采用VM机制。 6.value大小:redis最大可以达到1GB,而memcache只有1MB。 28题 Spring Boot 推荐使用 Java 配置而非 XML 配置,但是 Spring Boot 中也可以使用 XML 配置,通过spring提供的@ImportResource来加载xml配置。例如:@ImportResource({"classpath:some-context.xml","classpath:another-context.xml"}) 27题 Spring像一个大家族,有众多衍生产品例如Spring Boot,Spring Security等等,但他们的基础都是Spring的IOC和AOP,IOC提供了依赖注入的容器,而AOP解决了面向切面的编程,然后在此两者的基础上实现了其他衍生产品的高级功能。Spring MVC是基于Servlet的一个MVC框架,主要解决WEB开发的问题,因为 Spring的配置非常复杂,各种xml,properties处理起来比较繁琐。Spring Boot遵循约定优于配置,极大降低了Spring使用门槛,又有着Spring原本灵活强大的功能。总结:Spring MVC和Spring Boot都属于Spring,Spring MVC是基于Spring的一个MVC框架,而Spring Boot是基于Spring的一套快速开发整合包。 26题 YAML 是 "YAML Ain't a Markup Language"(YAML 不是一种标记语言)的递归缩写。YAML 的配置文件后缀为 .yml,是一种人类可读的数据序列化语言,可以简单表达清单、散列表,标量等数据形态。它通常用于配置文件,与属性文件相比,YAML文件就更加结构化,而且更少混淆。可以看出YAML具有分层配置数据。 25题 Spring Boot有3种热部署方式: 1.使用springloaded配置pom.xml文件,使用mvn spring-boot:run启动。 2.使用springloaded本地加载启动,配置jvm参数-javaagent:<jar包地址> -noverify。 3.使用devtools工具包,操作简单,但是每次需要重新部署。 用

游客ih62co2qqq5ww 2020-03-27 23:56:48 0 浏览量 回答数 0

回答

redis 是一个高性能的key-value数据库。 redis的出现,很大程度补偿了memcached这类keyvalue存储的不足,在部 分场合可以对关系数据库起到很好的补充作用。它提供了Python,Ruby,Erlang,PHP客户端,使用很方便。问题是这个项目还很新,可能还不足够稳定, redis 是一个高性能的key-value数据库。 redis的出现,很大程度补偿了memcached这类keyvalue存储的不足,在部 分场合可以对关系数据库起到很好的补充作用。它提供了Python,Ruby,Erlang,PHP客户端,使用很方便。问题是这个项目还很新,可能还不足够稳定,而且没有在实际的一些大型系统应用的实例。此外,缺乏mc中批量get也是比较大的问题,始终批量获取跟多次获取的网络开销是不一样的。 性能测试结果: SET操作每秒钟 110000 次,GET操作每秒钟 81000 次,服务器配置如下: Linux 2.6, Xeon X3320 2.5Ghz. stackoverflow 网站使用 Redis 做为缓存服务器。 安装过程: Redis是一种高级key-value数据库。它跟memcached类似,不过数据可以持久化,而且支持的数据类型很丰富。有字符串,链表,集 合和有序集合。支持在服务器端计算集合的并,交和补集(difference)等,还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务 器。 Redis的所有数据都是保存在内存中,然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”);也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。 一、下载最新版 wget http://redis.googlecode.com/files/redis-2.0.0-rc4.tar.gz 二、解压缩 tar redis-2.0.0-rc4.tar.gz 三、安装C/C++的编译组件(非必须) apt-get install build-essential 四、编译 cd redis-2.0.0-rc4 make make命令执行完成后,会在当前目录下生成本个可执行文件,分别是redis-server、redis-cli、redis-benchmark、redis-stat,它们的作用如下: redis-server:Redis服务器的daemon启动程序 redis-cli:Redis命令行操作工具。当然,你也可以用telnet根据其纯文本协议来操作 redis-benchmark:Redis性能测试工具,测试Redis在你的系统及你的配置下的读写性能 redis-stat:Redis状态检测工具,可以检测Redis当前状态参数及延迟状况 在后面会有这几个命令的说明,当然是从网上抄的。。。 五、修改配置文件 /etc/sysctl.conf 添加 vm.overcommit_memory=1 刷新配置使之生效 sysctl vm.overcommit_memory=1 补充介绍: **如果内存情况比较紧张的话,需要设定内核参数: echo 1 > /proc/sys/vm/overcommit_memory 内核参数说明如下: overcommit_memory文件指定了内核针对内存分配的策略,其值可以是0、1、2。 0, 表示内核将检查是否有足够的可用内存供应用进程使用;如果有足够的可用内存,内存申请允许;否则,内存申请失败,并把错误返回给应用进程。 1, 表示内核允许分配所有的物理内存,而不管当前的内存状态如何。 2, 表示内核允许分配超过所有物理内存和交换空间总和的内存 **编辑redis.conf配置文件(/etc/redis.conf),按需求做出适当调整,比如: daemonize yes #转为守护进程,否则启动时会每隔5秒输出一行监控信息 save 60 1000 #减小改变次数,其实这个可以根据情况进行指定 maxmemory 256000000 #分配256M内存 在我们成功安装Redis后,我们直接执行redis-server即可运行Redis,此时它是按照默认配置来运行的(默认配置甚至不是后台运 行)。我们希望Redis按我们的要求运行,则我们需要修改配置文件,Redis的配置文件就是我们上面第二个cp操作的redis.conf文件,目前 它被我们拷贝到了/usr/local/redis/etc/目录下。修改它就可以配置我们的server了。如何修改?下面是redis.conf的主 要配置参数的意义: daemonize:是否以后台daemon方式运行 pidfile:pid文件位置 port:监听的端口号 timeout:请求超时时间 loglevel:log信息级别 logfile:log文件位置 databases:开启数据库的数量 save * :保存快照的频率,第一个表示多长时间,第三个*表示执行多少次写操作。在一定时间内执行一定数量的写操作时,自动保存快照。可设置多个条件。 rdbcompression:是否使用压缩 dbfilename:数据快照文件名(只是文件名,不包括目录) dir:数据快照的保存目录(这个是目录) appendonly:是否开启appendonlylog,开启的话每次写操作会记一条log,这会提高数据抗风险能力,但影响效率。 appendfsync:appendonlylog如何同步到磁盘(三个选项,分别是每次写都强制调用fsync、每秒启用一次fsync、不调用fsync等待系统自己同步) 下面是一个略做修改后的配置文件内容: daemonize yes pidfile /usr/local/redis/var/redis.pid port 6379 timeout 300 loglevel debug logfile /usr/local/redis/var/redis.log databases 16 save 900 1 save 300 10 save 60 10000 rdbcompression yes dbfilename dump.rdb dir /usr/local/redis/var/ appendonly no appendfsync always glueoutputbuf yes shareobjects no shareobjectspoolsize 1024 将上面内容写为redis.conf并保存到/usr/local/redis/etc/目录下 然后在命令行执行: 1 /usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf 即可在后台启动redis服务,这时你通过 1 telnet 127.0.0.1 6379 即可连接到你的redis服务。 六、启动服务并验证 启动服务器 ./redis-server 或 $redis-server /etc/redis.conf 查看是否成功启动 $ ps -ef | grep redis 或 ./redis-cli ping PONG 七、启动命令行客户端赋值取值 redis-cli set mykey somevalue ./redis-cli get mykey 八、关闭服务 $ redis-cli shutdown #关闭指定端口的redis-server $redis-cli -p 6380 shutdown 九、客户端也可以使用telnet形式连接。 [root@dbcache conf]# telnet 127.0.0.1 6379 Trying 127.0.0.1... Connected to dbcache (127.0.0.1). Escape character is '^]'. set foo 3 bar +OK get foo $3 bar ^] telnet> quit Connection closed. 答案来源于网络

养狐狸的猫 2019-12-02 02:17:01 0 浏览量 回答数 0

问题

讨论PostgreSQL 和其他数据库的差异在哪里

云栖技术 2019-12-01 21:56:16 2721 浏览量 回答数 1

问题

spring cloud springboot 框架源码 activiti工作流 前后分离

游客q6uipubrszn5g 2019-12-01 19:56:47 21 浏览量 回答数 0

问题

spring cloud springboot 框架源码 activiti工作流 前后分离

游客ydre72cd7ywew 2019-12-01 19:57:42 15 浏览量 回答数 0

问题

springcloud vue.js 微服务分布式 前后分离 activiti工作流

游客ydre72cd7ywew 2019-12-01 19:59:33 11 浏览量 回答数 0

问题

spring cloud 微服务 分布式 Activiti6 工作流 vue.js html

游客ydre72cd7ywew 2019-12-01 21:49:22 8 浏览量 回答数 0

问题

springcloud 项目源码 Activiti6 工作 微服务 分布式 vue.js html

游客ydre72cd7ywew 2019-12-01 19:54:54 22 浏览量 回答数 0

问题

springcloud 项目源码 微服务 分布式 Activiti6 工作流 vue.js html

游客egqjd4t7mlyom 2019-12-01 19:58:16 35 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 企业建站模板