• 关于

    多段查询不可用

    的搜索结果

回答

开放搜索服务里查询不到预期的数据,可用以下方法排查: 先在管理控制台里核对一下文档数 1) 如果文档数字不对,根据文档的来源,是SDK/API还是通过RDS、ODPS等方式传入来排查。可以在控制台点击【应用详情】->【错误日志】查看文档上传的时间段内是否有错误日志。同时检查如果是通过其他云产品自动同步的话,需要核实一下连接方式、是否勾选自动同步选项。 2) 如果文档数对上了,需要核对查询的字段的分词方式。可以参考http://bbs.aliyun.com/read/180083.html?spm=5176.7189909.0.0.NxTr0p 3) 如果query后得到的结果太多(目前的限制是1000万),会丢弃一部分的查询结果,可能导致这些结果查询不到。调整的方法是优化查询语句。这样也可以提高查询的性能。具体可以参考http://bbs.aliyun.com/read/186346.html

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

回答

生命周期管理 API 描述 CreateInstance 调用CreateInstance创建一个Redis实例。 DeleteInstance 调用DeleteInstance释放Redis实例。 ModifyInstanceSpec 调用ModifyInstanceSpec变更Redis实例的规格。 TransformToPrePaid 调用TransformToPrePaid将按量付费的Redis实例转换为包年包月(预付费)实例。 DescribeAvailableResource 调用DescribeAvailableResource查询指定可用区内可创建的实例。 实例管理 API 描述 DescribeDBInstanceNetInfo 调用DescribeDBInstanceNetInfo查看Redis实例的网络信息。 DescribeInstanceAttribute 调用DescribeInstanceAttribute查询Redis实例的详细信息。 DescribeInstances 调用DescribeInstances查询一个或多个Redis实例的信息。 FlushInstance 调用FlushInstance清空Redis实例中的数据,不可恢复。 ModifyInstanceAttribute 调用ModifyInstanceAttribute修改Redis实例的属性,包括名称和密码。 ModifyInstanceMaintainTime 调用ModifyInstanceMaintainTime修改Redis实例的可维护时间段,阿里云将在您设定的可维护时间段内对Redis实例进行例行维护。 ModifyInstanceNetExpireTime 若Redis实例之前执行过由经典网络向VPC网络切换,并保留了经典网络连接地址,则可调用ModifyInstanceNetExpireTime延长经典网络连接地址的保存时间。 SwitchNetwork 调用SwitchNetwork切换Redis实例的网络类型,支持从经典网络切换为VPC网络。 ModifyDBInstanceConnectionString 调用ModifyDBInstanceConnectionString修改Redis实例的连接地址。 DescribeLogicInstanceTopology 调用DescribeLogicInstanceTopology查询Redis实例的逻辑拓扑结构。 ModifyInstanceMajorVersion 调用ModifyInstanceMajorVersion升级Redis实例的大版本。 RestartInstance 调用RestartInstance重启运行中的Redis实例。 ModifyInstanceMinorVersion 调用ModifyInstanceMinorVersion升级Redis实例的小版本。 FlushExpireKeys 调用FlushExpireKeys清除Redis实例中的过期Key。 备份恢复 API 描述 CreateBackup 调用CreateBackup为Redis实例创建数据备份。 ModifyBackupPolicy 调用ModifyBackupPolicy修改Redis实例的自动备份策略。 DescribeBackupPolicy 调用DescribeBackupPolicy查询Redis实例的备份策略,包括备份周期、备份时间等。 DescribeBackups 调用DescribeBackups查询Redis实例的备份文件信息。 RestoreInstance 调用RestoreInstance将备份文件中的数据恢复到指定的Redis实例中。 监控管理 API 描述 DescribeMonitorItems 调用DescribeMonitorItems查询Redis监控项列表。 DescribeHistoryMonitorValues 调用DescribeHistoryMonitorValues查看Redis实例的历史监控信息。 参数管理 API 描述 ModifyInstanceConfig 调用ModifyInstanceConfig修改Redis实例的配置参数。 DescribeParameters 调用DescribeParameters查询Redis实例的配置参数和运行参数。 区域管理 API 描述 DescribeRegions 调用DescribeRegions查询可创建Redis实例的地域。 DescribeZones 调用DescribeZones查询支持Redis的可用区。 MigrateToOtherZone 调用MigrateToOtherZone将Redis实例迁移到同地域内的其它可用区。 续费管理 API 描述 RenewInstance 调用RenewInstance为Redis实例续费。 ModifyInstanceAutoRenewalAttribute 调用ModifyInstanceAutoRenewalAttribute开启或者关闭Redis实例的到期前自动续费功能。 DescribeInstanceAutoRenewalAttribute 调用DescribeInstanceAutoRenewalAttribute查看Redis实例的自动续费情况。 账号管理 API 描述 DescribeAccounts 调用DescribeAccounts查找指定Redis实例的帐户列表信息或实例中某个账号的信息。 ModifyAccountDescription 调用ModifyAccountDescription修改Redis账号的描述。 ResetAccountPassword 调用ResetAccountPassword重置Redis账号的密码。 CreateAccount 调用CreateAccount可以在Redis实例中创建有特定权限的账号。 DeleteAccount 调用DeleteAccount删除一个Redis账号。 GrantAccountPrivilege 调用GrantAccountPrivilege修改Redis账号的权限。 网络安全 API 描述 DescribeSecurityIps 调用DescribeSecurityIps查询允许访问Redis实例的IP名单。 ModifySecurityIps 调用ModifySecurityIps设置Redis实例的IP白名单。 ModifyInstanceSSL 调用ModifyInstanceSSL设置Redis实例的SSL加密模式。 ModifyInstanceVpcAuthMode 调用ModifyInstanceVpcAuthMode开启或关闭免密访问。开启免密访问后,同一VPC内的云服务器不使用密码就可以访问Redis,同时仍然支持通过用户名及密码的方式连接Redis。 DescribeInstanceSSL 调用DescribeInstanceSSL查看Redis实例是否开启了SSL加密认证。 DescribeSecurityGroupConfiguration 调用DescribeSecurityGroupConfiguration查看Redis白名单中设置的安全组。 ModifySecurityGroupConfiguration 调用ModifySecurityGroupConfiguration重新设置Redis实例白名单中的安全组。 日志管理 API 描述 DescribeAuditRecords 调用DescribeAuditRecords查看Redis实例的审计日志。 DescribeRunningLogRecords 调用DescribeRunningLogRecords查询Redis实例的运行日志列表。 DescribeSlowLogRecords 调用DescribeSlowLogRecords查询Redis实例在指定时间内产生的慢日志。 ModifyAuditLogConfig 调用ModifyAuditLogConfig设置审计日志的保留天数。 连接管理 API 描述 AllocateInstancePublicConnection 调用AllocateInstancePublicConnection为Redis实例申请外网连接地址。 ReleaseInstancePublicConnection 调用ReleaseInstancePublicConnection释放Redis实例的外网连接地址。 ModifyIntranetAttribute 调用ModifyIntranetAttribute临时调整Redis实例的内网带宽。 DescribeIntranetAttribute 调用DescribeIntranetAttribute查询Redis实例当前的内网带宽。如果使用了临时调整带宽功能,还可查询临时带宽的过期时间。 性能优化 API 描述 CreateCacheAnalysisTask 调用CreateCacheAnalysisTask手动发起缓存分析任务。 DescribeCacheAnalysisReportList 调用DescribeCacheAnalysisReportList查看Redis实例的缓存分析报告列表。 DescribeCacheAnalysisReport 调用DescribeCacheAnalysisReport查看Redis实例在指定日期中的缓存分析报告。 标签管理 API 描述 TagResources 调用TagResources为一个或多个Redis实例绑定标签。 ListTagResources 调用ListTagResources查询绑定了指定标签的Redis实例或者查询指定实例绑定的标签。 UntagResources 调用UntagResources将标签从Redis实例解绑。

保持可爱mmm 2020-03-29 12:29:45 0 浏览量 回答数 0

回答

RunCommand 调用RunCommand在一台或多台ECS实例中执行一段Shell、PowerShell或者Bat类型的脚本。 CreateCommand 调用CreateCommand新建一条云助手命令。 InstallCloudAssistant 调用InstallCloudAssistant为一台或多台ECS实例安装云助手客户端。您需要重启实例来完成安装云助手客户端的操作。 InvokeCommand 调用InvokeCommand为一台或多台ECS实例触发一条云助手命令。 StopInvocation 调用StopInvocation停止一台或多台ECS实例中一条正在进行中(Running)的云助手命令进程DeleteCommand。 DeleteCommand 调用DeleteCommand删除一条云助手命令。 DescribeCloudAssistantStatus 调用DescribeCloudAssistantStatus查询一台或者多台实例是否安装了云助手客户端。 DescribeCommands 调用DescribeCommands查询您已经创建的云助手命令。只输入参数Action和RegionId,不输入其他任何请求参数,则默认查询您所有可用的命令(CommandId)。 DescribeInvocations 调用DescribeInvocations查询云助手脚本的执行列表和状态。 DescribeInvocationResults 调用DescribeInvocationResults查看一条或多条云助手命令的执行结果,即在ECS实例中的实际执行结果。

1934890530796658 2020-03-25 21:57:30 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

参考:https://www.iteblog.com/archives/2530.html分布式和去中心化(Distributed and Decentralized)Cassandra 是分布式的,这意味着它可以运行在多台机器上,并呈现给用户一个一致的整体。事实上,在一个节点上运行 Cassandra 是没啥用的,虽然我们可以这么做,并且这可以帮助我们了解它的工作机制,但是你很快就会意识到,需要多个节点才能真正了解 Cassandra 的强大之处。它的很多设计和实现让系统不仅可以在多个节点上运行,更为多机架部署进行了优化,甚至一个 Cassandra 集群可以运行在分散于世界各地的数据中心上。你可以放心地将数据写到集群的任意一台机器上,Cassandra 都会收到数据。对于很多存储系统(比如 MySQL, Bigtable),一旦你开始扩展它,就需要把某些节点设为主节点,其他则作为从节点。但 Cassandra 是无中心的,也就是说每个节点都是一样的。与主从结构相反,Cassandra 的协议是 P2P 的,并使用 gossip 来维护存活或死亡节点的列表。关于 gossip 可以参见《分布式原理:一文了解 Gossip 协议》。去中心化这一事实意味着 Cassandra 不会存在单点失效。Cassandra 集群中的所有节点的功能都完全一样, 所以不存在一个特殊的主机作为主节点来承担协调任务。有时这被叫做服务器对称(server symmetry)。综上所述,Cassandra 是分布式、无中心的,它不会有单点失效,所以支持高可用性。弹性可扩展(Elastic Scalability)可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。仅仅通过给现有的机器增加硬件的容量、内存进行垂直扩展,是最简单的达到可扩展性的手段。而水平扩展则需要增加更多机器,每台机器提供全部或部分数据,这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。弹性可扩展是指水平扩展的特性,意即你的集群可以不间断的情况下,方便扩展或缩减服务的规模。这样,你就不需要重新启动进程,不必修改应用的查询,也无需自己手工重新均衡数据分布。在 Cassandra 里,你只要加入新的计算机,Cassandra 就会自动地发现它并让它开始工作。高可用和容错(High Availability and Fault Tolerance)从一般架构的角度来看,系统的可用性是由满足请求的能力来量度的。但计算机可能会有各种各样的故障,从硬件器件故障到网络中断都有可能。如何计算机都可能发生这些情况,所以它们一般都有硬件冗余,并在发生故障事件的情况下会自动响应并进行热切换。对一个需要高可用的系统,它必须由多台联网的计算机构成,并且运行于其上的软件也必须能够在集群条件下工作,有设备能够识别节点故障,并将发生故障的中端的功能在剩余系统上进行恢复。Cassandra 就是高可用的。你可以在不中断系统的情况下替换故障节点,还可以把数据分布到多个数据中心里,从而提供更好的本地访问性能,并且在某一数据中心发生火灾、洪水等不可抗灾难的时候防止系统彻底瘫痪。可调节的一致性(Tuneable Consistency)2000年,加州大学伯克利分校的 Eric Brewer 在 ACM 分布式计算原理会议提出了著名的 CAP 定律。CAP 定律表明,对于任意给定的系统,只能在一致性(Consistency)、可用性(Availability)以及分区容错性(Partition Tolerance)之间选择两个。关于 CAP 定律的详细介绍可参见《分布式系统一致性问题、CAP定律以及 BASE 理论》以及《一篇文章搞清楚什么是分布式系统 CAP 定理》。所以 Cassandra 在设计的时候也不得不考虑这些问题,因为分区容错性这个是每个分布式系统必须考虑的,所以只能在一致性和可用性之间做选择,而 Cassandra 的应用场景更多的是为了满足可用性,所以我们只能牺牲一致性了。但是根据 BASE 理论,我们其实可以通过牺牲强一致性获得可用性。Cassandra 提供了可调节的一致性,允许我们选定需要的一致性水平与可用性水平,在二者间找到平衡点。因为客户端可以控制在更新到达多少个副本之前,必须阻塞系统。这是通过设置副本因子(replication factor)来调节与之相对的一致性级别。通过副本因子(replication factor),你可以决定准备牺牲多少性能来换取一致性。 副本因子是你要求更新在集群中传播到的节点数(注意,更新包括所有增加、删除和更新操作)。客户端每次操作还必须设置一个一致性级别(consistency level)参数,这个参数决定了多少个副本写入成功才可以认定写操作是成功的,或者读取过程中读到多少个副本正确就可以认定是读成功的。这里 Cassandra 把决定一致性程度的权利留给了客户自己。所以,如果需要的话,你可以设定一致性级别和副本因子相等,从而达到一个较高的一致性水平,不过这样就必须付出同步阻塞操作的代价,只有所有节点都被更新完成才能成功返回一次更新。而实际上,Cassandra 一般都不会这么来用,原因显而易见(这样就丧失了可用性目标,影响性能,而且这不是你选择 Cassandra 的初衷)。而如果一个客户端设置一致性级别低于副本因子的话,即使有节点宕机了,仍然可以写成功。总体来说,Cassandra 更倾向于 CP,虽然它也可以通过调节一致性水平达到 AP;但是不推荐你这么设置。面向行(Row-Oriented)Cassandra 经常被看做是一种面向列(Column-Oriented)的数据库,这也并不算错。它的数据结构不是关系型的,而是一个多维稀疏哈希表。稀疏(Sparse)意味着任何一行都可能会有一列或者几列,但每行都不一定(像关系模型那样)和其他行有一样的列。每行都有一个唯一的键值,用于进行数据访问。所以,更确切地说,应该把 Cassandra 看做是一个有索引的、面向行的存储系统。Cassandra 的数据存储结构基本可以看做是一个多维哈希表。这意味着你不必事先精确地决定你的具体数据结构或是你的记录应该包含哪些具体字段。这特别适合处于草创阶段,还在不断增加或修改服务特性的应用。而且也特别适合应用在敏捷开发项目中,不必进行长达数月的预先分析。对于使用 Cassandra 的应用,如果业务发生变化了,只需要在运行中增加或删除某些字段就行了,不会造成服务中断。当然, 这不是说你不需要考虑数据。相反,Cassandra 需要你换个角度看数据。在 RDBMS 里, 你得首先设计一个完整的数据模型, 然后考虑查询方式, 而在 Cassandra 里,你可以首先思考如何查询数据,然后提供这些数据就可以了。灵活的模式(Flexible Schema)Cassandra 的早期版本支持无模式(schema-free)数据模型,可以动态定义新的列。 无模式数据库(如 Bigtable 和 MongoDB)在访问大量数据时具有高度可扩展性和高性能的优势。 无模式数据库的主要缺点是难以确定数据的含义和格式,这限制了执行复杂查询的能力。为了解决这些问题,Cassandra 引入了 Cassandra Query Language(CQL),它提供了一种通过类似于结构化查询语言(SQL)的语法来定义模式。 最初,CQL 是作为 Cassandra 的另一个接口,并且基于 Apache Thrift 项目提供无模式的接口。 在这个过渡阶段,术语“模式可选”(Schema-optional)用于描述数据模型,我们可以使用 CQL 的模式来定义。并且可以通过 Thrift API 实现动态扩展以此添加新的列。 在此期间,基础数据存储模型是基于 Bigtable 的。从 3.0 版本开始,不推荐使用基于 Thrift API 的动态列创建的 API,并且 Cassandra 底层存储已经重新实现了,以更紧密地与 CQL 保持一致。 Cassandra 并没有完全限制动态扩展架构的能力,但它的工作方式却截然不同。 CQL 集合(比如 list、set、尤其是 map)提供了在无结构化的格式里面添加内容的能力,从而能扩展现有的模式。CQL 还提供了改变列的类型的能力,以支持 JSON 格式的文本的存储。因此,描述 Cassandra 当前状态的最佳方式可能是它支持灵活的模式。高性能(High Performance)Cassandra 在设计之初就特别考虑了要充分利用多处理器和多核计算机的性能,并考虑在分布于多个数据中心的大量这类服务器上运行。它可以一致而且无缝地扩展到数百台机器,存储数 TB 的数据。Cassandra 已经显示出了高负载下的良好表现,在一个非常普通的工作站上,Cassandra 也可以提供非常高的写吞吐量。而如果你增加更多的服务器,你还可以继续保持 Cassandra 所有的特性而无需牺牲性能。

封神 2019-12-02 02:00:50 0 浏览量 回答数 0

回答

在primary-secondary 类型的协议中,副本被分为两大类,其中有且仅有一个副本作为primary 副本, 除primary 以外的副本都作为secondary 副本。维护primary 副本的节点作为中心节点,中心节点负 责维护数据的更新、并发控制、协调副本的一致性。 Primary-secondary 类型的协议一般要解决四大类问题:数据更新流程、数据读取方式、Primary 副本的确定和切换、数据同步(reconcile)。 数据更新基本流程 1. 数据更新都由primary 节点协调完成。 2. 外部节点将更新操作发给primary 节点 3. primary 节点进行并发控制即确定并发更新操作的先后顺序 4. primary 节点将更新操作发送给secondary 节点 5. primary 根据secondary 节点的完成情况决定更新是否成功并将结果返回外部节点 在工程实践中,如果由primary 直接同时发送给其他N 个副本发送数据,则每个 secondary 的更新吞吐受限于primary 总的出口网络带宽,最大为primary 网络出口带宽的1/N。为了 解决这个问题,有些系统(例如,GFS),使用接力的方式同步数据,即primary 将更新发送给第一 个secondary 副本,第一个secondary 副本发送给第二secondary 副本,依次类推。 数据读取方式 数据读取方式也与一致性高度相关。如果只需要最终一致性,则读取任何副本都可以满足需求。如果需要会 话一致性,则可以为副本设置版本号,每次更新后递增版本号,用户读取副本时验证版本号,从而 保证用户读到的数据在会话范围内单调递增。使用primary-secondary 比较困难的是实现强一致性。 由于数据的更新流程都是由primary 控制的,primary 副本上的数据一定是最新的,所以 如果始终只读primary 副本的数据,可以实现强一致性。如果只读primary 副本,则secondary 副本 将不提供读服务。实践中,如果副本不与机器绑定,而是按照数据段为单位维护副本,仅有primary 副本提供读服务在很多场景下并不会造出机器资源浪费。 将副本分散到集群中个,假设primary 也是随机的确定的,那么每台机器 上都有一些数据的primary 副本,也有另一些数据段的secondary 副本。从而某台服务器实际都提供 读写服务。 - 由primary 控制节点secondary 节点的可用性。当primary 更新某个secondary 副本不成功 时,primary 将该secondary 副本标记为不可用,从而用户不再读取该不可用的副本。不可用的 secondary 副本可以继续尝试与primary 同步数据,当与primary 完成数据同步后,primary 可以副本 标记为可用。这种方式使得所有的可用的副本,无论是primary 还是secondary 都是可读的,且在一 个确定的时间内,某secondary 副本要么更新到与primary 一致的最新状态,要么被标记为不可用, 从而符合较高的一致性要求。这种方式依赖于一个中心元数据管理系统,用于记录哪些副本可用, 哪些副本不可用。某种意义上,该方式通过降低系统的可用性来提高系统的一致性。 primary 副本的确定与切换 在primary-secondary 类型的协议中,另一个核心的问题是如何确定primary 副本,尤其是在原 primary 副本所在机器出现宕机等异常时,需要有某种机制切换primary 副本,使得某个secondary 副本成为新的primary 副本。 通常的,在primary-secondary 类型的分布式系统中,哪个副本是primary 这一信息都属于元信 息,由专门的元数据服务器维护。执行更新操作时,首先查询元数据服务器获取副本的primary 信 息,从而进一步执行数据更新流程。 由于分布式系统中可靠的发现节点异常是需要一定的探测时间的,这样的探测时间通常是10 秒级别,这也意味着一旦primary 异常,最多需要10 秒级别的 发现时间,系统才能开始primary 的切换,在这10 秒时间内,由于没有primary,系统不能提供更 新服务,如果系统只能读primary 副本,则这段时间内甚至不能提供读服务。从这里可以看到, primary-backup 类副本协议的最大缺点就是由于primary 切换带来的一定的停服务时间。 数据同步 不一致的secondary 副本需要与primary 进行同步(reconcile)。 通常不一致的形式有三种:一、由于网络分化等异常,secondary 上的数据落后于primary 上的 数据。二、在某些协议下,secondary 上的数据有可能是脏数据,需要被丢弃。所谓脏数据是由于 primary 副本没有进行某一更新操作,而secondary 副本上反而进行的多余的修改操作,从而造成 secondary 副本数据错误。三、secondary 是一个新增加的副本,完全没有数据,需要从其他副本上 拷贝数据。 对于第一种secondary 数据落后的情况,常见的同步方式是回放primary 上的操作日志(通常是 redo 日志),从而追上primary 的更新进度。对于脏数据的情况, 较好的做法是设计的分布式协议不产生脏数据。如果协议一定有产生脏数据的可能,则也应该使得 产生脏数据的概率降到非常低得情况,从而一旦发生脏数据的情况可以简单的直接丢弃有脏数据的 副本,这样相当于副本没有数据。另外,也可以设计一些基于undo 日志的方式从而可以删除脏数据。 如果secondary 副本完全没有数据,则常见的做法是直接拷贝primary 副本的数据,这种方法往往比 回放日志追更新进度的方法快很多。但拷贝数据时primary 副本需要能够继续提供更新服务,这就 要求primary 副本支持快照(snapshot)功能。即对某一刻的副本数据形成快照,然后拷贝快照,拷贝 完成后使用回放日志的方式追快照形成后的更新操作。

kun坤 2020-04-24 15:30:53 0 浏览量 回答数 0

问题

【7月11日更新】阿里中间件性能挑战赛 - 第二赛季答疑汇总

中间件那珂 2019-12-01 21:37:29 5767 浏览量 回答数 11

问题

加密的数据库查询

保持可爱mmm 2019-12-01 22:00:09 10 浏览量 回答数 1

问题

咨询阿里云服务器的IP地址归属问题,望论坛的大侠指教

sim卡卡 2019-12-01 19:36:25 1612 浏览量 回答数 5

回答

索引,索引!!!为经常查询的字段建索引!! 但也不能过多地建索引。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

问题

Java SDK下载

云栖大讲堂 2019-12-01 21:10:43 1660 浏览量 回答数 0

回答

druid什么版本?只出错一次还是一直出错?我也遇到同样的问题。druid-1.0.5.jar有这个问题,升级到最新druid-1.0.29.jar仍然有这个问题。 @ wenshao 这是我的数据源信息,您看哪里需要调整? BasicInfoForDataSource-16171097 ViewJSONAPI * 用户名dqbxuser指定建立连接时使用的用户名* 连接地址jdbc:oracle:thin:@192.168.128.201:1521:dqsitestdbjdbc连接字符串* 数据库类型oracle数据库类型* 驱动类名oracle.jdbc.OracleDriverjdbc驱动的类名* filter类名com.alibaba.druid.wall.WallFilter,com.alibaba.druid.filter.stat.StatFilterfilter的类名* 获取连接时检测false是否在获得连接后检测其可用性* 空闲时检测true是否在连接空闲一段时间后检测其可用性* 连接放回连接池时检测false是否在连接放回连接池后检测其可用性* 初始化连接大小10连接池建立时创建的初始化连接数* 最小空闲连接数10连接池中最小的活跃连接数* 最大连接数100连接池中最大的活跃连接数* 查询超时时间0查询超时时间* 事务查询超时时间0事务查询超时时间* 登录超时时间0 * 连接有效性检查类名com.alibaba.druid.pool.vendor.OracleValidConnectionChecker * ExceptionSorter类名com.alibaba.druid.pool.vendor.OracleExceptionSorter * 默认autocommit设置true * 默认只读设置null * 默认事务隔离null * MinEvictableIdleTimeMillis1800000 * MaxEvictableIdleTimeMillis25200000 * KeepAlivefalse * FailFastfalse * PoolPreparedStatementsfalse *MaxPoolPreparedStatementPerConnectionSize-1 * MaxWait-1 * MaxWaitThreadCount-1 * LogDifferentThreadtrue * UseUnfairLockfalse * InitGlobalVariantsfalse * InitVariantsfalse 等待次数0获取连接时最多等待多少次等待最大时长0获取连接时最多等待多长时间等待线程数量0当前等待获取连接的线程数事务启动数0事务开始的个数事务时间分布0,0,0,0,0,0,0事务运行时间分布,分布区间为[0-10ms,10-100ms,100-1s,1-10s,10-100s,>100s]池中连接数10当前连接池中的数目池中连接数峰值10连接池中数目的峰值池中连接数峰值时间2017-04-1306:24:15连接池数目峰值出现的时间活跃连接数0当前连接池中活跃连接数活跃连接数峰值1连接池中活跃连接数峰值活跃连接数峰值时间2017-04-1306:24:15活跃连接池峰值出现的时间逻辑连接打开次数1产生的逻辑连接建立总数逻辑连接关闭次数1产生的逻辑连接关闭总数逻辑连接错误次数0产生的逻辑连接出错总数逻辑连接回收重用次数0逻辑连接回收重用次数物理连接打开次数10产生的物理连接建立总数物理关闭数量0产生的物理关闭总数物理连接错误次数0产生的物理连接失败总数执行数0 错误数0 提交数0事务提交次数回滚数0事务回滚次数真实PreparedStatement打开次数0真实PreparedStatement打开次数真实PreparedStatement关闭次数0真实PreparedStatement关闭次数PSCache访问次数0PSCache访问总数PSCache命中次数0PSCache命中次数PSCache不命中次数0PSCache不命中次数连接持有时间分布1,0,0,0,0,0,0,0连接持有时间分布,分布区间为[0-1ms,1-10ms,10-100ms,100ms-1s,1-10s,10-100s,100-1000s,>1000s]Clob打开次数0Clob打开数Blob打开次数0Blob打开数KeepAlive检测次数0KeepAlive检测次数活跃连接堆栈查看 View StackTraceforactiveConnection. [ViewJSONAPI] 连接池中连接信息 View Infoforpollingconnection.  [ViewJSONAPI] sql列表 View InfoforSQL. [ViewJSONAPI] 请问这个问题如何解决

爱吃鱼的程序员 2020-06-08 15:44:04 0 浏览量 回答数 0

问题

阿里云归档存储简介

云栖大讲堂 2019-12-01 21:07:35 1328 浏览量 回答数 0

问题

谁说阿里云不能跑Oracle,让驻云架构师告诉你怎么办!

驻云科技 2019-12-01 21:37:32 14181 浏览量 回答数 4

回答

提交注册表单到后端处理时,调用第三方短信服务(手机号码,后端生成验证码),限制多少时间内重发。验证码可以保存数据库中有效时间,或者session中设置过期时间问题有些太开放,宽松制约。重新考虑一下需求;如你所说的确实是个问题。或者其他人解答一下手机号码注册,短信只作验证功能(省事,用户群体比较有质量,手机号码唯一性,防止恶意刷注册用户数)/邮箱验证也可以,用户体验上手机较好(后期还可以通过手机号码去分析用户) 如果每次登陆都用短信验证码(短信服务还是要钱的...这个一天登陆一多就懂) ######首先 非常感谢你这么认真的回答。 我看完后 再回复你。先谢谢你###### 1. 你们服务端生成 短信 内容 提交到他们那,验证码可以放到缓存里,用户确定的时候检查缓存.写一个公共的服务组件, Linux可用crontab Win可用定时任务,在指定时间段内 每分钟查询下数据库,提交到短信提供商.最好不要使用短信登陆. ######关于问题1 ,一般都是用户前台输入手机号,点击获取验证码按钮后先在自己服务器根据短信服务商的接口规范生成url(包括验证码的生成,生成之后保存在session或者数据库中),然后用curl发请求,收到一个唯一的短信id就表示发送成功了(但是有可能是对方服务器出了问题,收到了id用户还没收到短信,我遇到过这个问题,最后他们换了一个线路解决了)###### 引用来自“p2ng”的评论 提交注册表单到后端处理时,调用第三方短信服务(手机号码,后端生成验证码),限制多少时间内重发。验证码可以保存数据库中有效时间,或者session中设置过期时间问题有些太开放,宽松制约。重新考虑一下需求;如你所说的确实是个问题。或者其他人解答一下手机号码注册,短信只作验证功能(省事,用户群体比较有质量,手机号码唯一性,防止恶意刷注册用户数)/邮箱验证也可以,用户体验上手机较好(后期还可以通过手机号码去分析用户) 如果每次登陆都用短信验证码(短信服务还是要钱的...这个一天登陆一多就懂) 回复1: 一般大家的普通做法是 保持数据库中还是SESSION中 还是内存中啊。  验证码好像就是临时的吧。 这个手机验证码 是需要我自定义生成吗? 我做过登陆图形验证码。用户输入后判断下。就行。提交一次重新生成。 但这个貌似可以提交多次,直到你输入正确的短信验证码是吧? 回复2: 举个简单例子吧: 我加入要做个提醒的功能。  我在web网站上 设置好时间,设置后内容。然后我当天那个时间收到这个短信内容。 我就是提供给会员这个事情。  比如我做一个比赛预告的WEB页面,用户点击比赛前1小时短信提醒我。  回复3: 每次短信登陆的确很麻烦也很费钱。 但类似微博就是这种的啊。 可以提供手机短信登陆的啊。 短信登陆唯一好处就是 用户注册/登陆都一样的,这样用户注册的时候就没有密码设置这一项,用户第一次实用的体验度会很好。。。。 ###### 引用来自“金马超”的评论 你们服务端生成 短信 内容 提交到他们那,验证码可以放到缓存里,用户确定的时候检查缓存.写一个公共的服务组件, Linux可用crontab Win可用定时任务,在指定时间段内 每分钟查询下数据库,提交到短信提供商.最好不要使用短信登陆. 回复1: 大体思路我明白了,只是之前没做过短信注册这个模块。 我看看第三方1069通道的 应该不难。 或者网上搜搜下 回复2: linux的crontab定时任务和win我都会,但我的意思是 一个用户 写周四下午3点 那我这边就执行一个定时任务会不会太浪费了?也太多了? 或者你说,每分钟查下数据库 也就是每隔一分钟执行一个php脚本文件,遍历循环下? 有的话就发 没有的 就不发。 就等于轮询? 这样是不是很耗费服务器资源? 有没有其他解解方法 回复3: 你的意思是 短信注册可以,然后引导用户设置密码。 但手机短信登陆不建议ma? 但我的意思,像weibo就是手机短信验证码直接登陆 携程也是这样 还有一种是你说的只能手机+密码来登陆 那我的意思是,如果二者并行,怎么设计这个表。。。 ###### 引用来自“西南茂”的评论关于问题1 ,一般都是用户前台输入手机号,点击获取验证码按钮后先在自己服务器根据短信服务商的接口规范生成url(包括验证码的生成,生成之后保存在session或者数据库中),然后用curl发请求,收到一个唯一的短信id就表示发送成功了(但是有可能是对方服务器出了问题,收到了id用户还没收到短信,我遇到过这个问题,最后他们换了一个线路解决了) 回复1: 你的流程是   用户填手机号---》用户点击提交获取验证码--》服务器生成一个验证码---》这个验证码通过sdk 用curl发送到短信运营商---》短信运营商服务器收到后发到用户手机号上---》 用户收到输入这个验证码--》我们后台核对  OK? ######对,差不多就是这个流程###### 引用来自“金马超”的评论 你们服务端生成 短信 内容 提交到他们那,验证码可以放到缓存里,用户确定的时候检查缓存.写一个公共的服务组件, Linux可用crontab Win可用定时任务,在指定时间段内 每分钟查询下数据库,提交到短信提供商.最好不要使用短信登陆. 引用来自“kacc850”的评论 回复1: 大体思路我明白了,只是之前没做过短信注册这个模块。 我看看第三方1069通道的 应该不难。 或者网上搜搜下 回复2: linux的crontab定时任务和win我都会,但我的意思是 一个用户 写周四下午3点 那我这边就执行一个定时任务会不会太浪费了?也太多了? 或者你说,每分钟查下数据库 也就是每隔一分钟执行一个php脚本文件,遍历循环下? 有的话就发 没有的 就不发。 就等于轮询? 这样是不是很耗费服务器资源? 有没有其他解解方法 回复3: 你的意思是 短信注册可以,然后引导用户设置密码。 但手机短信登陆不建议ma? 但我的意思,像weibo就是手机短信验证码直接登陆 携程也是这样 还有一种是你说的只能手机+密码来登陆 那我的意思是,如果二者并行,怎么设计这个表。。。 写成一个公共的组件...   这个服务从指定的一张表里查询数据 eg  ID 内容 下发时间 手机号 ... 只要代码没问题的话  对服务器来说不会是什么太大的问题.嗯   是这样的,不建议短信登陆,可以用短信找回密码. 你们公司不是微博/携程,没人家那种财力,最好不要这么做, 而且短信这个行业也不是你想的那么简单,提交就能发的. 如果要并行的话,单独建立一张表用来记录短信登陆比较好. 用户表只放基本信息,短信登陆表 带上用户名,手机号,登陆时间,IP可有可无. 和用户表稍微关联下就行. ######硕达通短信平台,发验证码5秒到,发通知5秒到,速度快,到达率98%以上,成功计费(失败不计费)实时状态报告(成功失败一目了然)支持上下行 北京硕达通  www.shdat.com  买短信有红包!######凌凯短信:快/3秒响应 ·12年品牌塑造,三网(移动、联通、电信)通道,覆盖所有手机号码 ·3秒快速响应,行业领先(www.028lk.com)######雨林木风短信平台,三网合一,五秒达到,到达率99%,欢迎站内信哟~~~~

kun坤 2020-06-11 10:43:41 0 浏览量 回答数 0

回答

设计微服务五个建议:1.它不会与其他服务共享数据库表2.它拥有最少量的数据库表3.它设计为有状态的或无状态的4.其数据可用性需求5.这是真相的唯一来源避免任意规则在设计和创建微服务时,不要陷入使用任意规则的陷阱。如果你阅读了足够多的建议,你会遇到下面的一些规则。虽然吸引人,但这些并不都是划分微服务边界的正确方法。如下:1.“微服务应该有X行代码”让我们弄清楚一件事。对于微服务中有多少行代码没有限制。微服务不会因为你写了几行额外的代码而突然变成单体巨石。关键是确保服务中的代码具有很高的凝聚力(稍后会详细介绍)。2.“将每个函数变成微服务”如果一个函数是根据三个输入值计算出某些东西,并返回一个结果,那么这个函数就是一个微服务吗?这个函数是否是一个可单独部署的应用程序吗?其实真的取决于函数是什么以及它如何服务于整个系统。其他任意规则包括那些不考虑整个上下文的规则,例如团队的经验,DevOps容量,服务在做什么以及数据的可用性需求等。精心设计的服务的特点如果您已阅读过有关微服务的文章,毫无疑问,您会发现有关设计良好的服务的建议。简而言之:高凝聚力和松散耦合。如果你不熟悉这些概念,有很多关于这些概念的文章。虽然合理的建议,但这些概念是相当抽象的。 我已经和数十位CTO就这个话题进行了交流,向他们学习他们如何划分微服务界限,下面为你们提供了一些潜在的特性。特性#1:它不会与其他服务共享数据库表当设计一个微服务时,如果你有多个引用同一个表的服务,这是一个红色警告,因为它可能意味着你的数据库是耦合的来源。“每个服务都应该有自己的表[并且]不应共享数据库表。” - Darby Frey,Lead Honestly共同创始人这实际上是关于服务与数据的关系,这正是Elastic Swiftype SRE的负责人Oleksiy Kovrin告诉我的:“我们在开发新服务时使用的主要基本原则之一是它们不应该跨越数据库边界。每项服务都应该依靠自己的一套底层数据存储。这使我们能够集中访问控制,审计日志记录,缓存逻辑等等,“他说。Kovyrin继续解释说,如果数据库表的一部分“与数据集的其余部分没有或很少有关系,这是一个强烈的信号,即组件可能可以被隔离到一个单独的API或单独的服务中。”特性#2:它具有最少量的数据库表正如第1章所提到的,微服务的理想尺寸应该足够小,但不能过小一点。每个服务的数据库表的数量也是一样。Scaylr工程负责人Steven Czerwinski在接受采访时向我解释说,Scaylr的甜蜜点是“一个服务 + 一个或两个数据库表”。特点#3:它有设计为有状态或无状态在设计微服务时,您需要问自己是否需要访问数据库,或者它是否将成为处理TB数据(如电子邮件或日志)的无状态服务。“我们通过定义服务的输入和输出来定义服务的边界。有时服务是网络API,但它也可能是一个处理输入文件并在数据库中生成记录的过程(这是我们的日志处理服务的情况)“ - Julien Lemoine要清楚这个前沿,它会导致更好的设计服务。特点#4:它的数据可用性需求被考虑在内在设计微服务时,您需要记住哪些服务将依赖于这项新服务,以及如果数据不可用,对系统的影响是什么。考虑到这一点,您可以为此服务正确设计数据备份和恢复系统。 当与Steven Czerwinski谈话时,他提到他们的关键客户行空间映射数据由于其重要性而以不同方式复制和分离到不同分区。“而每个分片信息,都是在自己的小分区中。 如果所在分区宕机,那么就没有备份可用,但它只影响5%的客户,而不是100%的客户,“Czerwinski解释说。特点#5:这是一个真理的单一来源要牢记的最后一个特点是设计一个服务,使其成为系统中某件事情的唯一真理来源。举例来说,当您从电子商务网站订购某物品时,会生成订单ID。此订单ID可供其他服务用于查询订单服务以获取有关订单的完整信息。使用pub / sub概念,在服务之间传递的数据应该是订单ID,而不是订单本身的属性/信息。只有订单服务具有完整的信息,并且是给定订单的唯一真实来源。考虑更大的团队对于大型系统而言,在确定服务边界时,组织架构考虑将发挥作用。有两点需要注意:独立发布时间表和不同的上线时间的重要性。Cloud66首席执行官Khash Sajadi表示:“我们所见过的最成功的微服务实施要么基于软件设计原则,例如基于领域驱动设计、面向服务架构SOA或反映组织方式的架构。“所以对于支付团队来说,”Sajadi继续说道,“他们有支付服务或信用卡验证服务,这是他们向外界提供的服务。这主要是关于向外界提供更多服务的业务部门。““[亚马逊CEO:杰夫贝佐斯]提出了'两个比萨饼'的规则 - 一个团队不能多到两个披萨饼还不够他们吃的地步。” - Iron.io首席技术官Travis Reeder亚马逊是拥有多个团队的大型组织的完美典范。正如在API推荐人发表的一篇文章中提到的,杰夫贝佐斯向所有员工发布了一份授权通知他们,公司内的每个团队都必须通过API进行沟通。任何不会的人将被解雇。这样,所有的数据和功能都通过接口暴露出来。贝佐斯还设法让每个团队解耦,定义他们的资源,并通过API使其可用。亚马逊总是自底而上从头开始建立一个系统。这可以让公司内的每个团队成为彼此的合作伙伴。我与Iron.io的首席技术官Travis Reeder谈到了贝佐斯的内部计划。“杰夫贝佐斯强制所有team都必须建立API来与其他team进行沟通,他也提出了'两个披萨'规则,一个团队不能多到两个披萨饼还不够他们吃的地步。”他说。“我认为这同样适用于这样情况:当一个小团队在开发、管理和生产方面开始变得笨拙或开始变慢,这说明这个团队可能已经太大了,“Reeder告诉我。如何判断服务是否太小,或许没有正确定义在微服务系统的测试和实施阶段,需要牢记下面两条出现现象。要注意的第一个现象是服务之间的任何过度依赖。如果两个服务不断地互相调用,那么这已经是一个强烈的耦合信号,他们如果并成一个服务可能更好。第二个现象:建立服务的开销超过了让其独立的好处。在这种情况下不如合并成一个服务。Darby Frey解释说:“每个应用程序需要将其日志汇总到某处并需要进行监控。您需要设置报警。然后需要有标准的响应操作程序,并在事情中断时运行。你必须管理SSH的访问权限。为了让应用程序正常运行,必须准备大量基础设施支持。“

wangccsy 2019-12-02 01:46:40 0 浏览量 回答数 0

回答

应该说是缓存吧?###### 那位大哥用过内存数据库,或者搞过的指导一下。###### 来的好快。###### 一些内存数据库并不适合做大负载的应用。我觉得你说的应该是缓存系统或者是 NoSQL###### 汉了,缓存系统,没听过。 NoSQL听过一点。 学习一下,再来发言。###### 有开源的,我整过H2,你搜搜 另外,貌似我们这边有人自己开发了内存数据库。###### 工业上有实时数据库 ,做大节点大数据量采集###### 你打算缓存多长时间段的数据(1个小时,1天)? 在此时间内能产生多少数据(10G,100G)? 查询是否会查询超出缓存时间段内的数据? 缓存的数据是否要持久化存储? 先分析分析,再根据实际情况去做折衷###### 建议你使用著名的开发memcached的公司新发布的membase. http://www.membase.org/ embase 是 NoSQL 家族的一个新的重量级的成员。 Membase是开源项目,源代码采用了Apache2.0的使用许可。该项目托管在GitHub.Source tarballs上,目前可以 下载beta版本的Linux二进制包。 Membase容易安装、操作,可以从单节点方便的扩展到集群,而且为memcached(有线协议的兼容性)实现了即插即用功能,在应用方面为开 发者和经营者提供了一个比较低的门槛。做为缓存解决方案,Memcached已经在不同类型的领域(特别是大容量的Web应用)有了广泛的使用,其中 Memcached的部分基础代码被直接应用到了Membase服务器的前端。 通过兼容多种编程语言和框架,Membase具备了很好的复用性。在安装和配置方面,Membase提供了有效的图形化界面和编程接口,包括可配置 的告警信息。 Membase的目标是提供对外的线性扩展能力,包括为了增加集群容量,可以针对统一的节点进行复制。 另外,对存储的数据进行再分配仍然是必要的。 这方面的一个有趣的特性是NoSQL解决方案所承诺的可预测的性能,类准确性的延迟和吞吐量。通过如下方式可以获得上面提到的特性: 自动将在线数据迁移到低延迟的存储介质的技术(内存,固态硬盘,磁盘) 可选的写操作一一异步,同步(基于复制,持久化) 反向通道再平衡[未来考虑支持] 多线程低锁争用 尽可能使用异步处理 自动实现重复数据删除 动态再平衡现有集群 通过把数据复制到多个集群单元和支持快速失败转移来提供系统的高可用性。 ###### 我以前很多项目都是用memcached,现在都已换成membase了,membase是著名的函数式编程语言Erlang编写的,经过实践,membase确实很好很强大.

kun坤 2020-06-07 20:13:38 0 浏览量 回答数 0

回答

大数据系统部署方法 大数据的部署是个复杂的过程,涉及内容众多,但无论如何都离不开以客户需求为导向。所以我们首先需要从客户的角度去考虑对方的需求,抽取出影响点,如实际运行时大概的数据量,客户的实时性要求怎样,高可用方面的要求如何,如此等等。 进而我们依据上述的要求来考虑硬件的选型、平台软件的版本选择、部署时组件的配合以及组件自身针对业务形态进行的优化配置。 一般来说,对于硬件往往是配置越高越好,但客户往往也关注效费比等经济性方面的问题,因此我们进行大数据部署时也需要寻找一个经济上的均衡点,让硬件能最大效率的发挥出功能和性能。 大数据项目的实施,一般从概念阶段到部署上线主要分为以下几个步骤: 需求分析 首先就需要和使用大数据平台的用户进行充分的沟通,通过沟通了解用户将来运行的上层业务的业务特点以及重点。一般来说,大数据的业务类型基本可分为离线业务和在线业务,离线业务主要为MapReduce,进行数据的分析计算处理;在线业务主要为HBase,HBase对外提供实时的数据查询业务。当然上层业务也可能基于Hive来处理,但Hive实质上还是基于MapReduce。 了解用户业务运行时的数据量,分析数据模型,包括已有的数据量、后续单位时间内增加的数据量,以及用户期望的数据保存时间等要求。 模型设计 基于用户的数据量等信息设计存储和计算模型。 考虑数据的存储方式是通过HDFS进行存储还是通过HBase进行存储,或者两者兼而有之。如果用户的数据较为离散,并且只有存储的简单要求,一般单纯采用HDFS即可满足要求。如果用户数据存在外部查询用途,且实时性要求较高,则可以考虑采用HBase进行存储,通过HBase对外提供在线查询业务。 硬件规划 主要基于用户的需求进行硬件规划、部署设计、以及IP地址的规划。需要考虑每台服务器的单节点的性能要求。如计算要求高,则CPU和内存的配置要求也较高,同时在部署设计上需要把计算节点独立出来,避免存储节点占用过多CPU,导致计算延迟。如存储要求高,则需要加大磁盘的容量,在部署设计上可以多DataNode节点分担文件读写压力,同时将计算节点和DataNode节点合设,以减少服务器数量。 市场上有各种类型的磁盘,性能上存在差异,所以还要考虑磁盘类型的选择,一般来说选用sas盘较多,性能要求较低可考虑sata盘,性能要求较高可考虑采用ssd盘。 另外还可以通过raid来辅助实现磁盘性能的提升以及高可靠性的提升。 同时平台的整体部署离不开高性能网络的支撑,所以网络建议采用万兆网,既可以降低网络部署的复杂性,也可以提高可维护性。特殊情况下,也可以采用多网口绑定的方式,但是往往会大幅提高网络部署的复杂性。 对于实现高可用,我们一般都会对网络采用双网双平面的部署方式,如下图所示(图中略去防火墙等设备,主要保留平台所需的设备)。 干货丨大数据系统部署4大步骤5大原则 软件规划 根据用户的业务,规划采用哪些组件来满足用户的功能要求,并且通过部署来实现业务的高可用,高可扩展。 在各个节点部署服务时,还要注意服务间的依赖关系。如HDFS的QJM方式的HA实现对Zookeeper有依赖。 硬件部署 即完成机架的部署和网络的部署,以及服务器在机架上的部署。如果有raid卡的话还要完成raid卡的设置。 软件部署 当硬件完成部署后,接下来就是部署软件了,包括操作系统的安装配置,以及大数据平台的安装配置。 操作系统安装完后,如果是多网口绑定,那就还需要作网口绑定设置。 然后就是最关键的大数据平台的部署了,中兴通讯自研了一套功能强大的管理系统,可完成大规模的平台部署,同时完成大量节点的部署,自动高效。 为保证大数据系统的稳定可靠运行,在整体部署上应遵循如下隔离原则: 生产环境和测试环境的隔离 系统环境分为生产环境和测试环境。其中生产环境用于实际运营,承载真实业务数据和业务应用;测试环境用于各种功能验证和性能测试等,包括应用在上线前的功能验证。如把两个环境合用,将带来很多不确定性,测试环境容易对生产环境造成干扰,影响生产环境正常业务的提供,甚至测试环境中不成熟的应用和业务运行时可能对环境造成破坏性的影响。因此对两个环境进行物理隔离,两者独立运行,互不干扰,防止因硬件资源的占用或者抢夺对运行造成不必要的影响。 不同集群的隔离 为避免可能存在的机架断电导致集群数据丢失或者停止服务,需要将属于同一个集群的不同节点分别部署到不同的机架上,通过多个机架的方式提供对服务器的承载。每个集群都基于一套独立的HDFS运行,这样从物理上和逻辑上与其他集群都进行了隔离。 在线应用和离线应用的隔离 在大数据平台上运行的应用分为在线应用和离线应用两大类。为保证重点在线应用的正常运行,需要单独规划HBase集群,且该集群基于一套独立的HDFS运行,从物理上和逻辑上和其他集群都进行隔离。 不同在线应用的隔离 对于在线应用,分为一般在线应用和重点在线应用,重点在线应用基于一套独立的HDFS运行,实现物理隔离,用于存储重要的在线数据,保证实时查询服务的持续提供。一般在线应用用于提供普通的HBase查询,对实时性的要求低于重点在线应用,所以可和离线应用部署在一个集群中。 不同应用数据的隔离 集群中的数据都是基于HDFS进行存放的,因此对于属于同一个集群内的应用的数据隔离,可通过设置不同的HDFS目录存放的方式实现不同应用数据的隔离,参见下图: 干货丨大数据系统部署4大步骤5大原则 不同应用属于不同的用户,不同的应用使用不同的目录,然后通过对目录进行权限配置的方式进行隔离和共享。

1748847708358317 2019-12-02 03:11:09 0 浏览量 回答数 0

问题

【阿里云产品公测】简单日志服务SLS使用评测含教程

mr_wid 2019-12-01 21:08:11 36639 浏览量 回答数 20

问题

你们有没有做 MySQL 读写分离?如何实现 MySQL 的读写分离?【Java问答】44期

剑曼红尘 2020-06-24 08:34:06 8 浏览量 回答数 1

问题

日志采集器相关问题该怎么解决?

猫饭先生 2019-12-01 21:06:37 930 浏览量 回答数 0

回答

"主题前提 多语言站点包含三个不同方面: 界面翻译 内容 网址路由 尽管它们都以不同的方式互连,但是从CMS的角度来看,它们是使用不同的UI元素进行管理的,并且存储方式也不同。您似乎对自己的实现和对前两个的理解充满信心。问题是关于后一个方面的问题:“ URL转换?我们应该这样做吗?应该以什么方式进行?” URL可以由什么组成? 一个非常重要的事情是,不要对IDN感兴趣。取而代之的是支持音译(也:转录和罗马化)。乍一看,IDN似乎是国际URL的可行选择,但实际上,它不能按广告宣传工作,原因有两个: 某些浏览器会将非ASCII字符(例如'ч'或)'ž'转换为'%D1%87'和'%C5%BE' 如果用户具有自定义主题,则主题的字体很可能没有这些字母的符号 实际上,几年前,我在一个基于Yii的项目(可怕的框架,恕我直言)中尝试了IDN方法。在抓取该解决方案之前,我遇到了上述两个问题。另外,我怀疑这可能是攻击媒介。 可用选项...如我所见。 基本上,您有两个选择,可以抽象为: http://site.tld/[:query]:[:query]决定语言和内容选择的地方 http://site.tld/[:language]/[:query]:[:language]URL的一部分定义语言的选择,[:query]仅用于标识内容 查询是Α和Ω.. 假设您选择http://site.tld/[:query]。 在这种情况下,您有一种主要的语言来源:[:query]段的内容;以及另外两个来源: $_COOKIE['lang']该特定浏览器的价值 HTTP Accept-Language (1),(2)标头中的语言列表 首先,您需要将查询与定义的路由模式之一进行匹配(如果您选择的是Laravel,请在此处阅读)。成功匹配模式后,您需要查找语言。 您将必须遍历模式的所有部分。找到所有这些片段的潜在翻译,并确定使用哪种语言。当(不是“如果”)发生冲突时,将使用两个其他来源(cookie和标头)来解决路由冲突。 例如:http://site.tld/blog/novinka。 那是音译""блог, новинка"",在英语中大约是""blog"", ""latest""。 您已经注意到,俄语中的“блог”将译为“博客”。这意味着对于您的第一部分[:query](在最佳情况下),最终会['en', 'ru']列出可能的语言。然后您进入下一个片段-“ novinka”。可能的列表中可能只有一种语言:['ru']。 当列表中有一项时,您已经成功找到该语言。 但是,如果最终得到2种(例如:俄语和乌克兰语)或更多种可能性..或0种可能性(视情况而定)。您将必须使用Cookie和/或标题才能找到正确的选项。 如果其他所有方法均失败,则选择站点的默认语言。 语言作为参数 替代方法是使用URL,可以将其定义为http://site.tld/[:language]/[:query]。在这种情况下,翻译查询时,您无需猜测语言,因为此时您已经知道要使用哪种语言。 还有另一种语言来源:cookie值。但是,这里没有必要弄乱Accept-Language标头,因为在“冷启动”的情况下(当用户第一次使用自定义查询打开网站时),您不会处理未知数量的可能的语言。 相反,您有3个简单的优先选项: 如果[:language]设置了细分,请使用它 如果$_COOKIE['lang']设置,使用它 使用默认语言 使用该语言时,您只需尝试翻译查询,如果翻译失败,请对该特定段使用“默认值”(基于路由结果)。 这不是第三种选择吗? 是的,从技术上讲,您可以将两种方法结合使用,但这会使过程复杂化,并且只适合那些想要手动更改URL http://site.tld/en/news到http://site.tld/de/news并希望新闻页面更改为德语的人员。 但是即使是这种情况,也可以使用cookie值(其中包含有关先前选择语言的信息)缓解,以减少魔术和希望。 使用哪种方法? 您可能已经猜到了,我建议您将其http://site.tld/[:language]/[:query]作为更明智的选择。 同样在真实的单词情况下,URL中将包含第三大部分:“标题”。如在线商店中的产品名称或新闻站点中的文章标题。 例: http://site.tld/en/news/article/121415/EU-as-global-reserve-currency 在这种情况下'/news/article/121415'将是查询,而'EU-as-global-reserve-currency'标题是。纯粹用于SEO。 可以在Laravel中完成吗? Kinda,但默认情况下不是。 我不太熟悉它,但是据我所知,Laravel使用简单的基于模式的路由机制。要实现多语言URL,您可能必须扩展核心类,因为多语言路由需要访问不同形式的存储(数据库,缓存和/或配置文件)。 已路由。现在怎么办? 结果,您最终将获得两条有价值的信息:当前语言和查询的翻译段。然后,这些值可用于调度将产生结果的类。 基本上,以下网址:(http://site.tld/ru/blog/novinka或不含的版本'/ru')变成了类似 $parameters = [ 'language' => 'ru', 'classname' => 'blog', 'method' => 'latest', ]; 您仅用于调度的对象: $instance = new {$parameter['classname']}; $instance->{'get'.$parameters['method']}( $parameters ); ..或它的某些变体,具体取决于特定的实现。"来源:stack overflow

保持可爱mmm 2020-05-18 10:09:50 0 浏览量 回答数 0

回答

止,请稍后重试。 400 AccountHasArrearage Account has some arrearage. 账户存在欠款。 404 InvalidRuleId.NotFound Rule does not exist. 规则不存在。 400 OverQuota Instance num exceeded Quota. 实例数量超过配额。 400 NoNameAuthentication Account should be Name Authenticated. 帐户未进行实名认证。 400 InvalidOwnerAccount The input parameter OwnerAccount is invalid. 输入的参数OwnerAccount无效。 400 InvalidResourceOwnerAccount The input parameter ResourceOwnerAccount is invalid. 参数ResourceOwnerAccount无效。 400 InvalidOwnerId The specified OwnerId or OwnerAccount is invalid. 输入的账户和账户ID有误,请您检查确认。 400 InvalidOwnerId The input parameter OwnerId or OwnerAccount is invalid. 指定的OwnerId或OwnerAccount无效。请检查该参数是否正确。 400 OverQuota The Total is over the quota. 总数超过了限额,请您减少数量后再重试。 400 ServiceUnavailable The vpc subnet is not exist. VPC子网不存在的或者Vswitch下网段没有可用ip。请检查该参数是否正确。 400 RegionNotSupport The specified region not supported. 该区域不支持。 400 ListenerNumberOverLimit The maximum number of listeners is exceeded. 创建监听的数量超过了限制,请您修改监听数量在30个以内。 400 KeyFormatError The specified ServerCertificate is incorrectly formatted. 参数ServerCertificate的格式不正确,请修改格式后重试。 400 InvalidParameter The Lb Name is Not supported. 参数非法。 400 InvalidParameter The Instance is Not Available. 该实例不可用。 449 SystemBusy The system is busy. 系统繁忙,请您稍后再试。 400 ActionNotAllowed The action is not allowed. 该操作不允许。 400 UserNotAllowed The user is not allowed, please submit the application. 用户无该操作权限,请提交工单。 400 SourceItemsQuotaOverLimit The maximum number of SourceItems is exceeded. 超过了SourceItems的最大数量,请您修改SourceItems的数量在300以内。 400 ActionNotAllowed The load balancer instance does not allow to be upgrade. 负载均衡实例不允许升级。 400 ActionNotAllowed Locked for any Business Reason. 实例因业务原因被锁定。 400 ActionNotAllowed Locked for any Operate Reason. 实例触发了预约变配被锁定,第二天凌晨锁定解除。 400 ActionNotAllowed Listener AccessControl Status is Incorrect. 监听未打开访问控制功能。 400 InvalidParameter The Protocol is not Support 该协议不支持。 400 InvalidParameter The listen bandwidth is not Support 监听的带宽值无效。 400 ActionNotAllowed The Intranet LB's InternetChargeType is not allowed change to paybybandwidth. 该负载均衡的计费方式不允许变更为按带宽计费。 403 Forbbiden.SubUser illegal bid 账号存在问题。 400 InvalidParameter The specified resource does not exist. 该资源不存在,请您检查该参数是否正确。 409 BackendServer.configuring A previous configuration of the load balancer is pending; please try again later. 负载均衡的前一个配置项正在配置中,请稍后再试。 400 ObtainIpFail The specified BackendServers is invalid; some of the specified backend servers do not exist or are not running. 指定的BackendServers无效;指定的后端服务器不存在或不运行。请检查该参数是否正确。 503 ServiceUnavailable The specified region not support VPC. 该地域不支持VPC。 400 InvalidParameter the special internet EIP donot support the VPC network type. VPC网络类型与公网地址EIP冲突。 400 InvalidParameter The specified load balancer does not support the network type of the ECS instance. 负载均衡实例不支持此种网络类型的ECS实例,请您换一种网络类型的ECS后再重试。 400 InvalidParameter The specified RegionId does not exist. 指定的RegionId不存在。请检查该参数是否正确。 400 InvalidParameter The specified vpc cloud instance has deleted 该VPC实例已删除。 400 InvalidParameter The specified vpc cloud instance is deleteing. 该VPC实例正在删除中。 400 PARAMETER_FIELD_ERROR The specified param is invalid. 该参数无效。 400 InvalidParameter The vpc info of LB is empty. 该实例关联的 VPC 信息为空,请您检查该 VPC 信息是否正常。 400 InvalidParameter The vpc Ip is exist. VPC IP 已被使用,请您更换其他 IP 后再试。 400 InvalidParameter The Ip is not Supported. 不支持该IP。 400 InvalidParameter The RsList is illegal. 参数非法。 400 InvalidParameter The Tunnel id is invalid. 指定的 Tunnel id 无效,请您检查该参数是否正确。 400 InvalidParameter The Rs IP is empty. 获取后端服务器的IP失败。 400 InvalidParameter The VmName is emtpy. ServerId 参数不能为空,请您检查 ServerId 参数是否正常。 400 InvalidParameter The App id is invalid. APP ID无效。 400 InvalidParameter The Vgw ip is empty. Vgw ip 为空,请您补充 Vgw ip 参数。 400 InvalidParameter The vm address is not Support. 后端服务器的地址不支持该操作,请您更换后端服务器的地址。 400 InvalidParameter The site is not exist. 主备可用区信息错误 400 InvalidParameter The serviceUnit and eip is not match. serviceUnit 和 eip 不匹配。 400 InvalidParameter The vgw ip is not support. Vgw ip不支持该操作。 503 ServiceUnavailable Illegal Service. 非法服务。 503 ServiceUnavailable Vpc Service error. VPC服务错误,请您检查参数是否正确。 503 ServiceUnavailable System exception. 系统异常,请重试。 500 InternalError Illegal sign. 系统服务忙,请重试。 500 InternalError Query ecs info fail. 查询ECS信息失败。 500 InternalError Illegal timestamp. 非法的时间戳。 500 InternalError Illegal format. 非法的格式。 500 InternalError Illegal user. 非法的用户。 500 InternalError Illegal sign type. 非法的签名类型。 500 InternalError Illegal aliyun idkp. 非法的账号信息。 503 ServiceUnavailable The cloud instance id is invaild. 该实例ID无效。 400 InvalidParameter The type is invalid. 该类型无效,请您检查该类型是否符合当前的操作。 400 InvalidParameter The lvsgw vip is same. lvsgw VIP是相同的。 400 InvalidParameter The resource already exists. 资源已经存在。 400 InvalidParameter The resource status is invalid. 资源状态无效。 400 UnsupportedOperationonfixedprotocalport The operation is not supported by the protocol of the specified port. 指定端口协议不支持该操作。请检查该端口协议是否正确。 500 InternalError The request processing has failed due to backend service exception. 由于后端服务异常,请求处理失败。 400 PrivateKeyEncryption Key has Encrypted . 私钥无需加密。 400 CertificateNotMatchPrivateKey Certificate and key does not match. 证书和密钥不匹配。请检查证书与密钥是否正确。 400 InvalidParameter The specified parameter ServerCertificate format is error. 参数ServerCertificate格式错误,请修改格式后重试。 400 CertificateAndPrivateKeyIsRefered Certificate and PrivateKey Is Refered. 证书被监听使用中。 400 InvalidParameter The specified parameter ServerCertificateId is empty. 参数ServerCertificateId为空。 400 InvalidParameter The specified parameter ServerCertificateId is not Support. 不支持指定的ServerCertificateId。 400 InvalidParameter The specified parameter ServerCertificate or Key is empty. 参数ServerCertificate或Key为空。 400 InvalidParameter The specified parameter key format is error. 参数key格式错误。 400 InvalidParameter The specified port is not valid. 该端口无效。 400 InvalidParameter The specified bandwidth is not valid. 该带宽值无效。 400 VipNotMatchRspool The vip protocol is not match with Rspool. 后端服务器组与监听不匹配,请您检查服务器组与监听的设置。 400 InvalidParameter The specified Bandwidth is invalid. It exceeds the maximum bandwidth available to the instance. 参数Bandwidth无效,实例下所有监听的带宽和超过了实例可用的最大带宽。 400 InvalidParameter The specified Bandwidth is invalid. 指定的带宽无效。请检查带宽参数是否正确。 400 InvalidParameter The specified SourceItems is invalid. 参数SourceItems无效。请检查该参数是否正确。 400 VipTooManyListeners The total number of input listeners exceeds max supported number: 10 实例下监听的总数超限,最多为10个。 400 InvalidParameter The specified protocol is not valid. 该协议无效。 404 InvalidParameter The specified VServerGroupId does not exist. 指定的VServerGroupId不存在。请检查该参数是否正确。 400 InvalidParameter Illegal user ID. 非法用户ID。 400 InvalidParameter User ID is null 用户ID为空,请您填写ID后重试。 400 InvalidParameter The specified parameter: lb_type is not valid. 参数lb_type无效。 400 InvalidParameter The specified parameter: mode is not valid.. 参数mode无效。 503 ServiceUnavailable The specified loadbalancer name has been used. 该负载平衡器名称已经被使用。 400 TcpNotSupportForHybridLb Hybrid type loadbalancer doesn't support TCP type listener 混合型负载平衡不支持TCP类型监听。 400 InvalidParameter The specified BackendServers is invalid. 参数BackendServers无效。请检查该参数是否正确。 400 InvalidParameter The specified BackendServers is invalid, as the Port value should be in [1, 65535]. 参数(backendservers)无效,请确认端口值在[ 1, 65535 ]范围内。 400 UnsupportedOperation The Loadbalancer doesn't support this function. 负载均衡不支持此功能。 400 TooManyBackendServers The total number of input real servers exceeds max supported number: 20 单次请求中服务器的总数超限,最多为20个。 400 InvalidParameter The specified parameter is not valid. 指定的参数无效。请检查该参数是否正确。 400 InvalidParameterLength The specified parameter length is not valid. 参数内容长度非法。 400 InvalidAuthorization The Request is not authorization. 该请求未授权。 500 InternalInvokeError The internal invoking has failed due to unknow error. 由于某些未知错误,请求处理失败。 400 OssInstanceDataNotFound The oss instance of the demand is not exist 日志下载的OSS实例不存在。 400 InvalidAuthorizationStatus The authorization status is not valid. 授权状态无效。 500 InternalInvokeError The internal invoking has failed. 内部错误。 400 InsufficientCapacity There is insufficient capacity available for the requested 用户能够购买的实例个数的配额超了,请走工单申请更高配额。 400 ProcessingSameRequest The same request is being processed. Please try later. 正在处理相同的请求。请稍后再试。 404 InvalidRegionId.NotFound The specified RegionId does not exist. 指定的 RegionId 不存在,请您检查此产品在该地域是否可用。 404 InvalidServerId.NotFound The specified ServerId does not exist. 指定的ServerId不存在。请检查该参数是否正确。 503 InvalidParameter The request has failed due to a temporary failure of the server. 由于服务器故障,请求失败。 400 InvalidParameter Specified parameter is not valid. 该参数无效。 503 ServiceUnavailable The request has failed due to a temporary failure of the server now. 由于服务器故障,请求失败。 400 UnsupportedOperation The specified action is not supported. 不支持该操作。 400 ListenerAlreadyExists A listener with the specified port already exists 绑定在该端口监听已经存在,请您不要重复绑定。 404 ListenerNotFound You have not created a listener for the specified port of the load balancer. 您还没有为负载均衡器的指定端口创建监听。 404 CheckedListenerNotFound No health-checked Listener to the specified port of the Load Balancer. 未对负载均衡器的健康检查进行配置。 400 IpNotAvailable The specified network type load balancer load balancer . 指定的负载均衡实例的网络类型无效。请检查该参数是否正确。 400 InvalidWeight.Malformed A specified weight is not valid. 参数Weight无效。 500 IncorrectListenerAccessControlStatusStatus Current listener access control status does not support this operation. 当前监听访问控制状态不支持此操作。 400 MissingParameter The combination of some parameters violates the spec. 请求参数中存在冲突。 400 UnsupportedParameter The specified parameter is not unsupported. 存在不支持的参数。 403 Forbidden User not authorized to operate on the specified resource. 用户无权限操作该资源。请先申请RAM权限,再进行此操作。 400 TooManyBackendServers The backend server parameter has too many entries. 后端服务参数单次请求中服务器的数量超过限制。 403 Forbbiden.SubUser TUser not authorized to operate on the specified resource as your account is created by another user. 该用户操作另一个账号创建的资源时未被授权,请先授权再进行操作。 400 InvalidBackendServers.Inconsistent All BackendServers on one Specified LoadBalancer have to be in the same vpc or all classic 所有后端服务器在一个负载平衡中必须属于同一个VPC网络或经典网络。 400 InvalidServerId.NotFound The specified server is not found. 后端服务器不存在。 400 InvalidIdentity The request identity was not allowed operated. 请求的认证失败。 400 DomainAlreadyExists Protected DomainName already exists. 该域名已经存在。 400 DomainNotExisted Don't delete or update not existed protected DomainName. 该域名不存在。 400 IpListItemFormatError please check the ip list item format error. IP列表格式错误。 400 SecurityNotSupport security function not support on this listener. 在该监听上不支持安全功能。 400 DomainExist rule with same domain and url already exists in specified vip 监听中已经存在了相同的域名和URL的规则。 400 TooManyRules the number of rules under specified vip is beyond maximum limit. 该监听拥有的规则数已达上限,请您修改规则数量后重试。 400 RspoolVipExist there are vips associating with this vServer group. 已有监听绑定了该虚拟服务器组,请您先解除绑定。 400 RspoolRuleExist there are rules associating with this vServer group. 虚拟服务器组和转发规则有关联,请解绑后再操作。 400 BackendServersMalformed the specified parameter BackendServers is unavailable. 参数BackendServers无效。 400 RuleListMalformed the specified parameter RuleList is unavailable. 参数RuleList无效。 400 DomainMalformed the specified domain in RuleList parameter is unavailable. 该域名格式错误。 400 UrlMalformed the specified url in RuleList parameter is unavailable. 在转发规则列表参数中的URL无效。 400 NetworkConflict there are network conflicts in specified parameter. 在指定的参数中存在网络冲突,请您检查该参数是否正确后再试。 400 VServerGroupEmpty The specified VServerGroupId is invalid; it does not contain vServers. 指定的VServerGroupId无效,没有包含vServers。 400 VpcZoneNotSupportCreate The specified zone dont not supported . 该可用区不支持创建VPC。 400 VpcStatusError the specified vpc status is creating. 该VPC正在创建中。 400 TagCreateCountLimit tags create count limit exceeded. 创建标签超出了配额。 400 TagCountLimit Tags count limit exceeded. 超出了标签数配额。 访问错误中心查看更多错误码。 访问错误中心查看更多错误码。

保持可爱mmm 2020-03-29 12:16:25 0 浏览量 回答数 0

问题

ES 在数据量很大的情况下(数十亿级别)如何提高查询效率啊?【Java问答学堂】28期

剑曼红尘 2020-05-28 09:45:28 15 浏览量 回答数 1

问题

围绕着内存数据库的4个流言

sunny夏筱 2019-12-01 21:46:19 7513 浏览量 回答数 3

回答

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

问题

围绕着内存数据库的4个流言

doudou1 2019-12-01 21:17:05 9279 浏览量 回答数 0

问题

Redis 集群模式的工作原理能说一下么?【Java问答】36期

剑曼红尘 2020-06-12 15:07:18 2 浏览量 回答数 1

问题

仪表板基本操作

反向一觉 2019-12-01 21:03:51 1323 浏览量 回答数 0

问题

学术界关于HBase在物联网/车联网/互联网/金融/高能物理等八大场景的理论研究

pandacats 2019-12-18 16:06:18 1 浏览量 回答数 0

问题

集群部署时的分布式 Session 如何实现?【Java问答学堂】59期

剑曼红尘 2020-07-16 15:14:21 5 浏览量 回答数 1
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站