• 关于

    数据库有较小的

    的搜索结果

问题

移动客户端微博应用的下拉更新和载入更多的业务逻辑是什么?

OSC青岛济南源创会报名开始!>>> » 最近在研究微博应用,对于下拉更新和载入更多的ios或Android技术已经掌握,但苦苦不知道什么样的业务逻辑是最好的,把我的思路写下,请大家帮忙看看。 描述1:初始页面,本地...
杨冬芳 2019-12-01 20:14:44 1283 浏览量 回答数 1

回答

1、常用的方式就是通过环境搭建来自建数据库,一般自建数据库可以满足大部分网站的需要,对于流量较大的网站,很有可能读写速度高时导致数据库的可靠性降低。 2、RDS对于小流量网站来说其实是鸡肋,普通的自建数据库也是可以完全没有问题的,一个网站在流量小于10万的情况下自建数据库是完全可以承受的。 3、日流量在10万以上,或者是百万级别的网站,考虑RDS的话还是可以的。
1252111517567195 2019-12-02 00:23:55 0 浏览量 回答数 0

回答

1、常用的方式就是通过环境搭建来自建数据库,一般自建数据库可以满足大部分网站的需要,对于流量较大的网站,很有可能读写速度高时导致数据库的可靠性降低。 2、RDS对于小流量网站来说其实是鸡肋,普通的自建数据库也是可以完全没有问题的,一个网站在流量小于10万的情况下自建数据库是完全可以承受的。 3、日流量在10万以上,或者是百万级别的网站,考虑RDS的话还是可以的。 一般情况下,磁盘读取量达到15M/s的时候就是异常情况了,要么是有人在采集你的网站,要么是有人在攻击你的数据库,两者情况区别就在于磁盘读取之后数据库会不会挂掉,目前解决这一问题的方法有很多,其中加强网站防护肯定是必要的,其次如果是网站对数据库可靠性要求很高,又不能在技术层面规避这种攻击的话,就可以选择关系型数据库。 答案来源于网络
养狐狸的猫 2019-12-02 03:01:55 0 浏览量 回答数 0

云数据库新人专场

MySQL年付低至19.9,其它热门产品1元起购!

回答

任何时候信息都是一对一的(每个用户都有一个用户名和密码),那么最好在一个表中使用它,因为它减少了数据库检索结果所需的联接数。我认为某些数据库对每个表的列数有限制,但是在正常情况下我不会担心它,如果需要,您可以随时将其拆分。 如果数据是一对多的(每个用户有成千上万的使用信息行),则应将其拆分为单独的表以减少重复的数据(重复的数据会浪费存储空间,缓存空间,并使数据库难以维护)。 您可能会发现有关数据库规范化的Wikipedia文章很有趣,因为它深入讨论了这样做的原因: 数据库规范化是组织关系数据库的字段和表以最小化冗余和依赖性的过程。规范化通常涉及将大表划分为较小(和较少冗余)的表,并定义它们之间的关系。目的是隔离数据,以便可以仅在一个表中进行字段的添加,删除和修改,然后通过定义的关系传播到数据库的其余部分。 还需要注意非规范化,因为在某些情况下重复数据会更好(因为它减少了数据库读取数据时需要做的工作量)。我强烈建议您尽可能使数据规范化,以开始使用,并且只有在您意识到特定查询中的性能问题时才进行规范化。来源:stack overflow
保持可爱mmm 2020-05-18 11:14:48 0 浏览量 回答数 0

回答

1.内存中加载的数据量过于庞大,如一次从数据库取出过多数据;2.集合类中有对对象的引用,使用完后未清空,使得JVM不能回收;3.代码中存在死循环或循环产生过多重复的对象实体;4.使用的第三方软件中的BUG;5.启动参数内存值设定的过小;2.Java代码导致错误的解决: 重点排查以下几点:1)检查代码中是否有死循环或递归调用。2)检查是否有大循环重复产生新对象实体。3)检查对数据库查询中,是否有一次获得全部数据的查询。一般来说,如果一次取十万条记录到内存,就可能引起内存溢出。这个问题比较隐蔽,在上线前,数据库中数据较少,不容易出问题,上线后,数据库中数据多了,一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。4 )检查List、MAP等集合对象是否有使用完后,未清除的问题。List、MAP等集合对象会始终存有对对象的引用,使得这些对象不能被GC回收。查询数据时,一次查询过多的数据,后来调整了该部分的代码,每次只取出指定量的数据,成功的解决该问题。 出现OutOfMemoryError,发现session的资源一直没有被释放产生的,最好通过session的invalidate()方法将session的资源释放。 程序中出现死循环。 4.tomcat部署、运行出现OutOfMemoryError,加大内存参数值,解决此问题。
a123456678 2019-12-02 02:12:50 0 浏览量 回答数 0

回答

首先,我们先来聊聊各类数据模型。下列相关信息参考自Emil Eifrem的博文及NoSQL数据库说明。文档类数据库传承:受Lotus Notes启发而来。数据模型:文档汇总,包括键-值汇总。实例: CouchDB, MongoDB优势: 数据建模自然、程序员易于上手、开发流程短、兼容网页模式、便于达成CRUD(即添加、查询、更新及删除的简称)。图形类数据库传承:来自 Euler 及图形理论。数据模型:节点及关系,二者结合能够保持键-值间的成对状态实例: AllegroGraph, InfoGrid, Neo4j优势:轻松玩转复杂的图形问题、处理速度快关系类数据库传承:源自 E. F. Codd在大型共享数据库中所提出的数据关系模型理论数据模型:以关系组为基础实例: VoltDB, Clustrix, MySQL优势:性能强大、联机事务处理系统扩展性好、支持SQL访问、视图直观、擅长处理交易关系、与程序员间的交互效果优异面向对象类数据库传承:源自图形数据库方面的研究成果数据模型: 对象实例: Objectivity, Gemstone优势:擅长处理复杂的对象模型、快速的键-值访问及键-功能访问并且兼具图形数据库的各类功能键-值存储传承: Amazon Dynamo中的paper概念及分布式hash表数据模型:对成对键-值的全局化汇总实例: Membase, Riak优势:尺寸掌控得当、擅长处理持续的小规模读写需求、速度快、程序员易于上手BigTable Clones传承自:谷歌BigTable中的paper概念数据模型:纵列群,即在某个表格模型中,每行在理论上至少可以有一套单独的纵列配置实例: HBase, Hypertable, Cassandra优势:尺寸掌控得当、擅长应对大规模写入负载、可用性高、支持多数据中心、支持映射简化数据结构类服务传承: 不明实例: Redis数据模型: 执行过程基于索引、列表、集合及字符串值优势:为数据库应用引入前所未有的新鲜血液网格类数据库传承:源自数据网格及元组空间研究数据模型:基于空间的构架实例: GigaSpaces, Coherence优势:优良的性能表现及上佳的交易处理扩展性我们该为自己的应用程序选择哪套方案?选择的关键在于重新思考我们的应用程序如何依据不同数据模型及不同产品进行有针对性的协同工作。即用正确的数据模型处理对应的现实任务、用正确的产品解决对应的现实问题。要探究哪类数据模型能够切实为我们的应用程序提供帮助,可以参考“到底NoSQL能在我们的工作中发挥什么作用?”一文。在这篇文章中,我试着将各种不同特性、不同功能的常用创建系统中的那些非常规的应用实例综合起来。将应用实例中的客观需求与我们的选择联系起来。这样大家就能够逆向分析出我们的基础架构中适合引入哪些产品。至于具体结论是NoSQL还是SQL,这已经不重要了。关注数据模型、产品特性以及自身需要。产品总是将各种不同的功能集中起来,因此我们很难单纯从某一类数据模型构成方式的角度直接找到最合用的那款。对功能及特性的需求存在优先级,只要对这种优先级具备较为清晰的了解,我们就能够做出最佳选择。如果我们的应用程序需要…复杂的交易:因为没人愿意承受数据丢失,或者大家更倾向于一套简单易用的交易编程模式,那么请考虑使用关系类或网格类数据库。例如:一套库存系统可能需要完整的ACID(即数据库事务执行四要素:原子性、一致性、隔离性及持久性)。顾客选中了一件产品却被告知没有库存了,这类情况显然容易引起麻烦。因为大多数时候,我们想要的并不是额外补偿、而只是选中的那件货品。若是以扩展性为优先,那么NoSQL或SQL都能应对自如。这种情况下我们需要关注那些支持向外扩展、分类处理、实时添加及移除设备、负载平衡、自动分类及整理并且容错率较高的系统。要求持续保有数据库写入功能,则需要较高的可用性。在这种情况下不妨关注BigTable类产品,其在一致性方面表现出众。如有大量的小规模持续读写要求,也就是说工作负载处于波动状态,可以关注文档类、键-值类或是那些提供快速内存访问功能的数据库。引入固态硬盘作为存储媒介也是不错的选择。以社交网络为实施重点的话,我们首先想到的就是图形类数据库;其次则是Riak这种关系类数据库。具备简单SQL功能的常驻内存式关系数据库基本上就可以满足小型数据集合的需求。Redis的集合及列表操作也能发挥作用。如果我们的应用程序需要…在访问模式及数据类型多种多样的情况下,文档类数据库比较值得考虑。这类数据库不仅灵活性好,性能表现也可圈可点。需要完备的脱机报告与大型数据集的话,首选产品是Hadoop,其次则是支持映射简化的其它产品。不过仅仅支持映射简化还不足以提供如Hadoop一样上佳的处理能力。如果业务跨越数个数据中心,Bigtable Clone及其它提供分布式选项的产品能够应对由地域距离引起的延迟现象,并具备较好的分区兼容性。要建立CRUD应用程序,首选文档类数据库。这类产品简化了从外部访问复杂数据的过程。需要内置搜索功能的话,推荐Riak。要对数据结构中的诸如列表、集合、队列及发布/订阅信息进行操作,Redis是不二之选。其具备的分布式锁定、覆盖式日志及其它各种功能都会在这类应用状态下大放异彩。将数据以便于处理的形式反馈给程序员(例如以JSON、HTTP、REST、Javascript这类形式),文档类数据库能够满足这类诉求,键-值类数据库效果次之。如果我们的应用程序需要…以直观视图的形式进行同步交易,并且具备实时数据反馈功能,VoltDB算得上一把好手。其数据汇总以及时间窗口化的表现都非常抢眼。若是需要企业级的支持及服务水平协议,我们需要着眼于特殊市场。Membase就是这样一个例子。要记录持续的数据流,却找不到必要的一致性保障?BigTable Clone交出了令人满意的答卷,因为其工作基于分布式文件系统,所以可以应对大量的写入操作。要让操作过程变得尽可能简单,答案一定在托管或平台即服务类方案之中。它们存在的目的正是处理这类要求。要向企业级客户做出推荐?不妨考虑关系类数据库,因为它们的长项就是具备解决繁杂关系问题的技术。如果需要利用动态方式建立对象之间的关系以使其具有动态特性,图形类数据库能帮上大忙。这类产品往往不需要特定的模式及模型,因此可以通过编程逐步建立。S3这类存储服务则是为支持大型媒体信息而生。相比之下NoSQL系统则往往无法处理大型二进制数据块,尽管MongoDB本身具备文件服务功能。如果我们的应用程序需要…有高效批量上传大量数据的需求?我们还是得找点有对应功能的产品。大多数产品都无法胜任,因为它们不支持批量操作。文档类数据库或是键-值类数据库能够利用流畅的模式化系统提供便捷的上传途径,因为这两类产品不仅支持可选区域、添加区域及删除区域,而且无需建立完整的模式迁移框架。要实现完整性限制,就得选择一款支持SQL DLL的产品,并在存储过程或是应用程序代码中加以运行。对于协同工作极为依赖的时候就要选择图形类数据库,因为这类产品支持在不同实体间的迅速切换。数据的移动距离较短且不必经过网络时,可以在预存程序中做出选择。预存程序在关系类、网格类、文档类甚至是键-值类数据库中都能找到。如果我们的应用程序需要…键-值存储体系擅长处理BLOB类数据的缓存及存储问题。缓存可以用于应对网页或复杂对象的存储,这种方案能够降低延迟、并且比起使用关系类数据库来说成本也较低。对于数据安全及工作状态要求较高的话可以尝试使用定制产品,并且在普遍的工作范畴(例如向上扩展、调整、分布式缓存、分区及反规范化等等)之外一定要为扩展性(或其它方面)准备解决方案。多样化的数据类型意味着我们的数据不能简单用表格来管理或是用纵列来划分,其复杂的结构及用户组成(也可能还有其它各种因素)只有文档类、键-值类以及Bigtable Clone这些数据库才能应付。上述各类数据库都具备极为灵活的数据类型处理能力。有时其它业务部门会需要进行快速关系查询,引入这种查询方式可以使我们不必为了偶尔的查看而重建一切信息。任何支持SQL的数据库都能实现这类查询。至于在云平台上运行并自动充分利用云平台的功能——这种美好的愿望目前还只能是愿望。如果我们的应用程序需要…支持辅助索引,以便通过不同的关键词查找数据,这要由关系类数据库及Cassandra推出的新辅助索引系统共同支持才能实现。创建一套处于不断增长中的数据集合(真正天文数量级的数据)然而访问量却并不大,那么Bigtable Clone是最佳选择,因为它会将数据妥善安排在分布式文件系统当中。需要整合其它类型的服务并确保数据库提供延后写入同步功能?那最好的实现方式是捕捉数据库的各种变化并将其反馈到其它系统中以保障运作的一致性。通过容错性检查了解系统对供电中断、隔离及其它故障情况的适应程度。若是当前的某项技术尚无人问津、自己却感觉大有潜力可挖,不妨在这条路上坚持走下去。这种情况有时会带来意料之外的美好前景。尝试在移动平台上工作并关注CouchDB及移动版couchbase。哪种方案更好?25%的状态改善尚不足以让我们下决心选择NoSQL。选择标准是否恰当取决于实际情况。这类标准对你的方案有指导意义吗?如果你的公司尚处于起步阶段,并且需要尽快推出自己的产品,这时不要再犹豫不决了。无论是SQL还是NoSQL都可以作为参考。
a123456678 2019-12-02 03:00:14 0 浏览量 回答数 0

回答

本文介绍如何使用数据传输服务DTS(Data Transmission Service),将自建Oracle数据迁移至RDS MySQL实例。DTS支持结构迁移、全量数据迁移以及增量数据迁移,同时使用这三种迁移类型可以实现在本地应用不停服的情况下,平滑地完成Oracle数据库的数据迁移。 源库支持的实例类型 进行数据迁移操作的Oracle数据库支持以下实例类型: 有公网IP的自建数据库 ECS上的自建数据库 通过专线/VPN网关/智能网关接入的自建数据库 本文以有公网IP的自建数据库为例介绍配置流程,其他实例类型的自建Oracle数据库配置流程与该案例类似。 前提条件 自建Oracle数据库的版本为9i、10g或11g版本。 自建Oracle数据库已开启Supplemental Logging,且要求supplemental_log_data_pk,supplemental_log_data_ui已开启,详情请参见Supplemental Logging。 自建Oracle数据库已开启ARCHIVELOG(归档模式),设置合理的归档日志保持周期且归档日志能够被访问,详情请参见ARCHIVELOG。 自建Oracle数据库的服务端口已开放至公网。 RDS MySQL实例的存储空间须大于自建Oracle数据库占用的存储空间。 注意事项 DTS在执行全量数据迁移时将占用源库和目标库一定的读写资源,可能会导致数据库的负载上升,在数据库性能较差、规格较低或业务量较大的情况下(例如源库有大量慢SQL、存在无主键表或目标库存在死锁等),可能会加重数据库压力,甚至导致数据库服务不可用。因此您需要在执行数据迁移前评估源库和目标库的性能,同时建议您在业务低峰期执行数据迁移(例如源库和目标库的CPU负载在30%以下)。 如果源数据库没有主键或唯一约束,且所有字段没有唯一性,可能会导致目标数据库中出现重复数据。 RDS MySQL实例对表名的英文大小写不敏感,如果使用大写英文建表,RDS MySQL会先把表名转为小写再执行建表操作。 如果源Oracle数据库中存在表名相同仅大小写不同的表,可能会导致迁移对象重名并在结构迁移中提示“对象已经存在”。如果出现这种情况,请在配置迁移对象的时候,使用DTS提供的对象名映射功能对重名的对象进行重命名,详情请参见库表列映射。 如果待迁移的数据库在目标RDS MySQL实例中不存在,DTS会自动创建。但是对于如下两种情况,您需要在配置迁移任务之前在目标RDS MySQL实例中创建数据库。 数据库名称不符合RDS定义规范,详细规范请参见创建数据库。 待迁移数据库在源Oracle数据库与目标RDS MySQL实例中的名称不同。 费用说明 迁移类型 链路配置费用 公网流量费用 结构迁移/全量数据迁移 不收费。 通过公网将数据迁移出阿里云时将收费,详情请参见产品定价。 增量数据迁移 收费,详情请参见产品定价。 迁移类型说明 结构迁移 DTS支持结构迁移的对象为表和索引,暂不支持视图、同义词、触发器、存储过程、存储函数、包、自定义类型等。表和索引的结构迁移存在以下限制: 表:不支持嵌套表;对于聚簇表和索引组织表,会在目标端转换成普通的表。 索引:不支持Function-Based Index、Domain Index、Bitmap Index和ReverseIndex。 全量数据迁移 DTS会将自建Oracle数据库迁移对象的存量数据,全部迁移到目标RDS MySQL实例数据库中 。 说明 为保障数据一致性,全量数据迁移期间请勿在自建Oracle数据库中写入新的数据。 增量数据迁移 在全量迁移的基础上,DTS会轮询并捕获自建Oracle数据库产生的redolog,将自建Oracle数据库的增量更新数据同步到目标RDS MySQL实例数据库中。通过增量数据迁移可以实现在本地应用不停服的情况下,平滑地完成Oracle数据库的数据迁移工作。 增量数据迁移支持同步的SQL操作 INSERT、DELETE、UPDATE CREATE TABLE 说明 表内定义不能包含函数。 ALTER TABLE、ADD COLUMN、DROP COLUMN、RENAME COLUMN、ADD INDEX DROP TABLE RENAME TABLE、TRUNCATE TABLE、CREATE INDEX 数据库账号权限要求 数据库 结构迁移 全量迁移 增量数据迁移 自建Oracle数据库 schema的owner权限 schema的owner权限 SYSDBA RDS MySQL实例 待迁入数据库的写权限 待迁入数据库的写权限 待迁入数据库的写权限 数据库账号创建及授权方法: 自建Oracle数据库请参见CREATE USER和GRANT。 RDS MySQL实例请参见创建账号和修改账号权限。 数据类型映射关系 详情请参见异构数据库间的数据类型映射关系。 操作步骤 登录数据传输控制台。 在左侧导航栏,单击数据迁移。 在迁移任务列表页面顶部,选择迁移的目标实例所属地域。选择地域 单击页面右上角的创建迁移任务。 配置迁移任务的源库及目标库信息。 源库和目标库连接配置 类别 配置 说明 任务名称 - DTS会自动生成一个任务名称,建议配置具有业务意义的名称(无唯一性要求),便于后续识别。 源库信息 实例类型 选择有公网IP的自建数据库。 实例地区 当实例类型选择为有公网IP的自建数据库时,实例地区无需设置。 说明 如果您的自建Oracle数据库进行了白名单安全设置,您需要在实例地区配置项后,单击获取DTS IP段来获取到DTS服务器的IP地址,并将获取到的IP地址加入自建Oracle数据库的白名单安全设置中。 数据库类型 选择Oracle。 主机名或IP地址 填入自建Oracle数据库的访问地址,本案例填入公网地址。 端口 填入自建Oracle数据库的服务端口,默认为1521。 实例类型 非RAC实例:选择该项后,您还需要填写SID信息。 RAC实例:选择该项后,您还需要填写ServiceName信息。 数据库账号 填入自建Oracle的数据库账号,权限要求请参见迁移账号权限要求。 数据库密码 填入该数据库账号对应的密码。 说明 源库信息填写完毕后,您可以单击数据库密码后的测试连接来验证填入的源库信息是否正确。源库信息填写正确则提示测试通过;如果提示测试失败,单击测试失败后的诊断,根据提示调整填写的源库信息。 目标库信息 实例类型 选择RDS实例。 实例地区 选择目标RDS实例所属地域。 RDS实例ID 选择目标RDS实例ID。 数据库账号 填入目标RDS实例的数据库账号,权限要求请参见迁移账号权限要求。 数据库密码 填入该数据库账号对应的密码。 说明 目标库信息填写完毕后,您可以单击数据库密码后的测试连接来验证填入的目标库信息是否正确。目标库信息填写正确则提示测试通过;如果提示测试失败,单击测试失败后的诊断,根据提示调整填写的目标库信息。 配置完成后,单击页面右下角的授权白名单并进入下一步。 说明 此步骤会将DTS服务器的IP地址自动添加到目标RDS实例的白名单中,用于保障DTS服务器能够正常连接目标RDS实例。 选择迁移对象及迁移类型。 选择迁移类型和迁移对象 配置 说明 迁移类型 如果只需要进行全量迁移,同时勾选结构迁移和全量数据迁移。 说明 为保障数据一致性,全量数据迁移期间请勿在自建Oracle数据库中写入新的数据。 如果需要进行不停机迁移,同时勾选结构迁移、全量数据迁移和增量数据迁移。 迁移对象 在迁移对象框中选中待迁移的对象,单击向右小箭头将其移动到已选择对象框。 说明 迁移对象选择的粒度可以为库、表、列三个粒度。 默认情况下,迁移完成后,迁移对象名跟自建Oracle数据库一致。如果您需要迁移对象在目标RDS实例上名称不同,那么需要使用DTS提供的对象名映射功能。使用方法请参见库表列映射。 单击页面右下角的预检查并启动。 说明 在迁移任务正式启动之前,会先进行预检查。只有预检查通过后,才能成功启动迁移任务。 如果预检查失败,单击具体检查项后的提示,查看失败详情。根据提示修复问题后,重新进行预检查。 预检查通过后,单击下一步。 在购买配置确认页面,选择链路规格并勾选数据传输(按量付费)服务条款。 单击购买并启动,迁移任务正式开始。 全量数据迁移 请勿手动结束迁移任务,否则可能导致数据不完整。您只需等待迁移任务完成即可,迁移任务会自动结束。 增量数据迁移 迁移任务不会自动结束,您需要手动结束迁移任务。 说明 请选择合适的时间手动结束迁移任务,例如业务低峰期或准备将业务切换至目标实例时。 观察迁移任务的进度变更为增量迁移,并显示为无延迟状态时,将源库停写几分钟,此时增量迁移的状态可能会显示延迟的时间。 等待迁移任务的增量迁移再次进入无延迟状态后,手动结束迁移任务。无延迟 将业务切换至RDS实例。 后续操作 用于数据迁移的数据库帐号拥有读写权限,为保障数据库安全性,请在数据迁移完成后,删除自建Oracle数据库和RDS MySQL实例中的数据库帐号。 更多信息 DTS支持在自建Oracle数据迁移至RDS MySQL实例时的数据反向回流,您可以使用该功能将RDS MySQL实例中产生的数据变化同步回自建Oracle数据库。如您有相关需求,请提交工单申请开通。
游客yl2rjx5yxwcam 2020-03-08 14:04:46 0 浏览量 回答数 0

问题

什么是数据库/表组/表/分区?

在传统的关系数据库系统中,表隶属于某个数据库。而分析型数据库为了方便的进行数据的关联的管理,以及进行资源分配,引入了表组的概念。 数据库 在分析型数据库中,数据库是用户和系统管理员的...
nicenelly 2019-12-01 21:25:03 1067 浏览量 回答数 0

问题

什么是数据库/表组/表/分区?

在传统的关系数据库系统中,表隶属于某个数据库。而分析型数据库为了方便的进行数据的关联的管理,以及进行资源分配,引入了表组的概念。 数据库 在分析型数据库中,数据库是用户和系统管理员的...
nicenelly 2019-12-01 21:10:08 1371 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 说明 RDS for MyQL的账号管理机制已更新。对于RDS for MySQL实例,请参见创建账号和数据库。 在使用数据库之前,您需要在RDS实例中创建账号。目前,RDS有两种管理模式的账号,即经典模式和高权限模式。经典模式是较早的管理模式,无法通过SQL来管理数据库和账号。高权限模式是较新的管理模式,开放了更多的权限,而且创建高权限账号后您可以通过SQL来管理数据库和账号。从长远来看,若您有个性化和精细化权限管理的需求,我们推荐您使用高权限模式。 本文将介绍在经典模式和高权限模式下的账号特点和功能区别,以及如何创建不同模式的账号。 账号模式简介 在经典模式下,所有账号均通过阿里云的RDS控制台或者API创建,不能通过SQL创建,且账号之间是平等关系。另外,您可以通过RDS控制台创建、管理所有账号和数据库。 在高权限模式下,创建的第一个账号为初始账号,需通过阿里云的RDS控制台或API创建和管理。 初始账号创建成功后,用初始账号登录数据库,通过SQL命令或阿里云的数据管理DMS来创建和管理其它普通账号。 但您不能使用初始账号去修改其它普通账号的密码,如果需要修改普通账号的密码,只能删除后重新创建。例如,使用初始账号root登录数据库后,再创建普通账号jeffrey,如下所示: mysql -hxxxxxxxxx.mysql.rds.aliyuncs.com -uroot -pxxxxxx -e " CREATE USER 'jeffrey'@'%' IDENTIFIED BY 'password'; CREATE DATABASE DB001; " 另外,在高权限模式下,RDS控制台暂不支持数据库管理页面,也不支持通过API CreateDatabase等接口管理数据库的功能,您需要通过SQL命令或DMS来创建和管理数据库。 关于在经典模式和高权限模式下创建和管理数据库/账号的区别,请参见下图: 二者对比 引擎版本支持账号 各版本引擎所支持的账号模式,如下表所示: 数据库引擎 账号模式 MySQL 5.5/5.6 经典模式/高权限模式说明:仅支持经典到高权限模式的单向升级,不支持回滚。 MySQL 5.7 高权限模式 SQL Server 2008 R2 经典模式 SQLServer 2012/2016 高权限模式 PostgreSQL 高权限模式 PPAS 高权限模式 账号和权限区别 下表从账号和权限的角度列出了经典模式和高权限模式的区别: 对比项目 经典模式 高权限模式 账号数量 最多500个。 无限制。 数据库数量 MySQL:最多500个。 SQL Server:最多50个。 无限制。 是否可以通过RDS控制台管理数据库和账号 是 可以在控制台上管理第一个创建的高权限账号,但不能管理其它账号,需要通过SQL命令或DMS来创建和管理其它账号。 不能在控制台上创建和管理数据库,需要通过SQL命令或DMS来创建和管理数据库。 是否可以通过SQL管理数据库和账号 否 是 权限管理 简单,对每个账号只提供读写和只读两种账号权限。 更加丰富、精细。可充分利用数据库引擎的权限管理优势,比如可按用户分配不同表的查询权限。 账号支持的权限(仅适用于MySQL) SELECT、INSERT、UPDATE、DELETE、CREATE、DROP、PROCESS、INDEX、ALTER、CREATE TEMPORARY TABLES、LOCK TABLES、EXECUTE、REPLICATION SLAVE、REPLICATION CLIENT、CREATE VIEW、SHOW VIEW、CREATE ROUTINE、ALTER ROUTINE、EVENT、TRIGGER 除经典模式所支持的20个权限外,还额外支持CREATE USER、RELOAD和REFERENCES。 功能区别 在产品功能上,两种模式没有任何区别,所有功能可以正常使用,包括只读实例、读写分离、变配升级、网络管理、IP白名单、监控报警等。 如何创建账号 注意事项 分配数据库账号权限时,请按最小权限原则和业务角色创建账号,并合理分配只读和读写权限。必要时可以把数据库账号和数据库拆分成更小粒度,使每个数据库账号只能访问其业务之内的数据。如果不需要数据库写入操作,请分配只读权限。 请设置数据库账号的密码为强密码,并定期更换。 操作步骤 关于如何创建经典模式下的账号,请参见下列文档中创建账号的部分: MySQL 5.7高可用版/5.5/5.6创建数据库和账号 创建数据库和账号SQL Server 2008 R2版 关于如何创建高权限模式下的账号,请参见下列文档中创建账号的部分: 创建高权限账号 MySQL 5.7基础版创建数据库和账号 创建数据库和账号 创建数据库和账号
2019-12-01 22:56:51 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 说明 RDS for MyQL的账号管理机制已更新。对于RDS for MySQL实例,请参见创建账号和数据库。 在使用数据库之前,您需要在RDS实例中创建账号。目前,RDS有两种管理模式的账号,即经典模式和高权限模式。经典模式是较早的管理模式,无法通过SQL来管理数据库和账号。高权限模式是较新的管理模式,开放了更多的权限,而且创建高权限账号后您可以通过SQL来管理数据库和账号。从长远来看,若您有个性化和精细化权限管理的需求,我们推荐您使用高权限模式。 本文将介绍在经典模式和高权限模式下的账号特点和功能区别,以及如何创建不同模式的账号。 账号模式简介 在经典模式下,所有账号均通过阿里云的RDS控制台或者API创建,不能通过SQL创建,且账号之间是平等关系。另外,您可以通过RDS控制台创建、管理所有账号和数据库。 在高权限模式下,创建的第一个账号为初始账号,需通过阿里云的RDS控制台或API创建和管理。 初始账号创建成功后,用初始账号登录数据库,通过SQL命令或阿里云的数据管理DMS来创建和管理其它普通账号。 但您不能使用初始账号去修改其它普通账号的密码,如果需要修改普通账号的密码,只能删除后重新创建。例如,使用初始账号root登录数据库后,再创建普通账号jeffrey,如下所示: mysql -hxxxxxxxxx.mysql.rds.aliyuncs.com -uroot -pxxxxxx -e " CREATE USER 'jeffrey'@'%' IDENTIFIED BY 'password'; CREATE DATABASE DB001; " 另外,在高权限模式下,RDS控制台暂不支持数据库管理页面,也不支持通过API CreateDatabase等接口管理数据库的功能,您需要通过SQL命令或DMS来创建和管理数据库。 关于在经典模式和高权限模式下创建和管理数据库/账号的区别,请参见下图: 二者对比 引擎版本支持账号 各版本引擎所支持的账号模式,如下表所示: 数据库引擎 账号模式 MySQL 5.5/5.6 经典模式/高权限模式说明:仅支持经典到高权限模式的单向升级,不支持回滚。 MySQL 5.7 高权限模式 SQL Server 2008 R2 经典模式 SQLServer 2012/2016 高权限模式 PostgreSQL 高权限模式 PPAS 高权限模式 账号和权限区别 下表从账号和权限的角度列出了经典模式和高权限模式的区别: 对比项目 经典模式 高权限模式 账号数量 最多500个。 无限制。 数据库数量 MySQL:最多500个。 SQL Server:最多50个。 无限制。 是否可以通过RDS控制台管理数据库和账号 是 可以在控制台上管理第一个创建的高权限账号,但不能管理其它账号,需要通过SQL命令或DMS来创建和管理其它账号。 不能在控制台上创建和管理数据库,需要通过SQL命令或DMS来创建和管理数据库。 是否可以通过SQL管理数据库和账号 否 是 权限管理 简单,对每个账号只提供读写和只读两种账号权限。 更加丰富、精细。可充分利用数据库引擎的权限管理优势,比如可按用户分配不同表的查询权限。 账号支持的权限(仅适用于MySQL) SELECT、INSERT、UPDATE、DELETE、CREATE、DROP、PROCESS、INDEX、ALTER、CREATE TEMPORARY TABLES、LOCK TABLES、EXECUTE、REPLICATION SLAVE、REPLICATION CLIENT、CREATE VIEW、SHOW VIEW、CREATE ROUTINE、ALTER ROUTINE、EVENT、TRIGGER 除经典模式所支持的20个权限外,还额外支持CREATE USER、RELOAD和REFERENCES。 功能区别 在产品功能上,两种模式没有任何区别,所有功能可以正常使用,包括只读实例、读写分离、变配升级、网络管理、IP白名单、监控报警等。 如何创建账号 注意事项 分配数据库账号权限时,请按最小权限原则和业务角色创建账号,并合理分配只读和读写权限。必要时可以把数据库账号和数据库拆分成更小粒度,使每个数据库账号只能访问其业务之内的数据。如果不需要数据库写入操作,请分配只读权限。 请设置数据库账号的密码为强密码,并定期更换。 操作步骤 关于如何创建经典模式下的账号,请参见下列文档中创建账号的部分: MySQL 5.7高可用版/5.5/5.6创建数据库和账号 创建数据库和账号SQL Server 2008 R2版 关于如何创建高权限模式下的账号,请参见下列文档中创建账号的部分: 创建高权限账号 MySQL 5.7基础版创建数据库和账号 创建数据库和账号 创建数据库和账号
2019-12-01 22:56:51 0 浏览量 回答数 0

回答

不同的数据库连接数据库的方式不同,但是大体分为几种:ODBC(Open Database Connectivity,开放数据库互连)是微软公司开放服务结构(WOSA,Windows Open Services Architecture)中有关数据库的一个组成部分,它建立了一组规范,并提供了一组对数据库访问的标准API(应用程序编程接口)。这些API利用SQL来完成其大部分任务。DAO(Data Access Objects):数据访问对象是用来显露了Microsoft Jet数据库引擎(最早是给Microsoft Access 所使用,现在已经支持其它数据库),并允许开发者通过ODBC直接连接到其他数据库一样,直接连接到 Access 表。DAO 最适用于单系统应用程序或在小范围本地分布使用。其内部已经对Jet数据库的访问进行了加速优化,而且其使用起来也是很方便的。所以如果数据库是Access数据库且是本地使用的话,建议使用这种访问方式---应用的专一性RDO(Remote Data Objects)远程数据对象是一个到ODBC的、面向对象的数据访问接口,它同易于使用的DAO style组合在一起,提供了一个接口,形式上展示出所有ODBC的底层功能和灵活性。尽管RDO在很好地访问Jet或ISAM数据库方面受到限制,而且它只能通过现存的ODBC驱动程序来访问关系数据库。但是,RDO已被证明是许多SQL Server、Oracle 以及其他大型关系数据库开发者经常选用的最佳接口。RDO提供了用来访问存储过程和复杂结果集的更多和更复杂的对象、属性,以及方法。---无疑是在odbc基础上的OLE DB 是 Microsoft 的一个战略性系统级编程接口,用于管理整个组织内的数据。OLE DB 是建立在 ODBC 功能之上的一个开放规范。ODBC 是为访问关系型数据库而专门开发的,OLE DB 则用于访问关系型和非关系型信息源,例如主机 ISAM/VSAM 和层次数据库,电子邮件和文件系统存储,文本、图形和地理数据以及自定义业务对象。 OLE DB 定义了一组 COM 接口,对各种数据库管理系统服务进行封装,并允许创建软件组件,实现这些服务。OLE DB 组件包括数据提供程序(包含和表现数据)、数据使用者(使用数据)和服务组件(处理和传送数据,例如,查询处理器和游标引擎)。OLE DB 接口有助于平滑地集成组件,这样,OLE DB 组件厂商就可以快速地向市场提供高质量 OLE DB 组件。此外,OLE DB 包含了一个连接 ODBC 的“桥梁”,对现用的各种 ODBC 关系型数据库驱动程序提供一贯的支持。---号称取代odbc,但也兼容odbcADO(ActiveX Data Object)是DAO/RDO的后继产物。ADO 2.0在功能上与RDO更相似,而且一般来说,在这两种模型之间有一种相似的映射关系。ADO"扩展"了DAO和 RDO 所使用的对象模型,这意味着它包含较少的对象、更多的属性、方法(和参数),以及事件。 作为最新的数据库访问模式,ADO的使用也是简单易用,所以微软已经明确表示今后把重点放在ADO上,对DAO/RDO不再作升级,所以ADO已经成为了当前数据库开发的主流。 ADO涉及的数据存储有DSN(数据源名称)、ODBC(开放式数据连接)以及OLE DB三种方式。后面的例程将详细讲解这三种方式的具体访问实现。---可以说是对odbc,oledb这些系统级的编程接口的汇接,并对DAO,RDO这些应用级的编程接口的升级吧。
卓刀 2019-12-02 00:38:22 0 浏览量 回答数 0

回答

您好,一般来说,建议是停止相关的应用后再重启,那样数据库之类的写操作会在重启前先停止,对数据来说较安全。通过ECS控制面板来重启ECS,一般会有两个选项:“重启”和“强制重启”。一般选择“重启”是相对较安全,出现数据丢失的可能性较小。
dongshan8 2019-12-02 03:12:20 0 浏览量 回答数 0

回答

本文介绍如何使用数据传输服务DTS(Data Transmission Service),将自建MySQL迁移至RDS MySQL实例。DTS支持结构迁移、全量数据迁移以及增量数据迁移,同时使用这三种迁移类型可以实现在自建应用不停服的情况下,平滑地完成自建MySQL数据库的迁移上云。 前提条件 创建RDS MySQL实例。 自建MySQL数据库版本为5.1、5.5、5.6、5.7、8.0版本。 RDS MySQL实例的存储空间须大于自建MySQL数据库占用的存储空间。 注意事项 DTS在执行全量数据迁移时将占用源库和目标库一定的读写资源,可能会导致数据库的负载上升,在数据库性能较差、规格较低或业务量较大的情况下(例如源库有大量慢SQL、存在无主键表或目标库存在死锁等),可能会加重数据库压力,甚至导致数据库服务不可用。因此您需要在执行数据迁移前评估源库和目标库的性能,同时建议您在业务低峰期执行数据迁移(例如源库和目标库的CPU负载在30%以下)。 如果源数据库没有主键或唯一约束,且所有字段没有唯一性,可能会导致目标数据库中出现重复数据。 对于数据类型为FLOAT或DOUBLE的列,DTS会通过ROUND(COLUMN,PRECISION)来读取该列的值。如果没有明确定义其精度,DTS对FLOAT的迁移精度为38位,对DOUBLE的迁移精度为308位,请确认迁移精度是否符合业务预期。 DTS自动在阿里云RDS MySQL中创建数据库,如果待迁移的数据库名称不符合阿里云RDS的定义规范,将导致创建数据库失败,所以您需要在配置迁移任务之前在阿里云RDS MySQL中创建数据库。 说明 关于阿里云RDS的定义规范和创建数据库的操作方法,请参见创建数据库。 对于迁移失败的任务,DTS会触发自动恢复。在您将业务切换至目标实例前,请务必先结束或释放该任务,避免该任务被自动恢复后,导致源端数据覆盖目标实例的数据。 费用说明 迁移类型 链路配置费用 公网流量费用 结构迁移/全量数据迁移 不收费。 通过公网将数据迁移出阿里云时将收费,详情请参见产品定价。 增量数据迁移 收费,详情请参见产品定价。 迁移类型说明 结构迁移 DTS将迁移对象的结构定义迁移到目标实例,目前DTS支持结构迁移的对象为表、视图、触发器、存储过程、存储函数,不支持event的结构迁移。 说明 在结构迁移时,DTS会将视图、存储过程和函数中的DEFINER转换为INVOKER。 由于DTS不迁移user信息,因此在调用目标库的视图、存储过程和函数时需要对调用者授予读写权限。 全量数据迁移 DTS会将自建MySQL数据库迁移对象的存量数据,全部迁移到目标RDS MySQL实例数据库中。 说明 由于全量数据迁移会并发INSERT导致目标实例的表存在碎片,全量迁移完成后目标实例的表空间会比源实例大。 为保障数据一致性,全量数据迁移期间请勿在自建MySQL数据库中写入新的数据。 增量数据迁移 在全量迁移的基础上,DTS会读取自建MySQL数据库的binlog信息,将自建MySQL数据库的增量更新数据同步到目标RDS MySQL实例中。通过增量数据迁移可以实现在自建应用不停服的情况下,平滑地完成MySQL数据库的迁移上云。 增量数据迁移支持同步的SQL操作 INSERT、UPDATE、DELETE、REPLACE CREATE TABLE、ALTER TABLE、RENAME TABLE、TRUNCATE TABLE、DROP TABLE 数据库账号的权限要求 数据库 结构迁移 全量迁移 增量迁移 自建MySQL数据库 select权限 select权限 select、replication slave和replication client权限 RDS MySQL实例 读写权限 读写权限 读写权限 数据库账号创建及授权方法: 自建MySQL数据库请参见为自建MySQL创建账号并设置binlog。 RDS MySQL实例请参见创建账号和修改账号权限。 准备工作 为自建MySQL创建账号并设置binlog 操作步骤 登录数据传输控制台。 在左侧导航栏,单击数据迁移。 在迁移任务列表页面顶部,选择迁移的目标实例所属地域。选择地域 单击页面右上角的创建迁移任务。 配置迁移任务的源库及目标库信息。 源库和目标库连接配置 类别 配置 说明 任务名称 - DTS会自动生成一个任务名称,建议配置具有业务意义的名称(无唯一性要求),便于后续识别。 源库信息 实例类型 您可以根据源库部署位置,选择有公网IP的自建数据库、ECS上的自建数据库或通过专线/VPN网关/智能网关接入的自建数据库。 本文以有公网IP的自建数据库为例介绍配置流程,当自建MySQL数据库为其他实例类型时,配置流程与该案例类似。 实例地区 当实例类型选择为有公网IP的自建数据库时,实例地区无需设置。 说明 如果您的自建MySQL数据库具备白名单安全设置,您需要在实例地区配置项后,单击获取DTS IP段来获取到DTS服务器的IP地址,并将获取到的IP地址加入自建MySQL数据库的白名单安全设置中。 数据库类型 选择MySQL。 主机名或IP地址 填入自建MySQL数据库的访问地址,本案例中填入公网地址。 端口 填入自建MySQL数据库的服务端口(需开放至公网),默认为3306。 数据库账号 填入自建MySQL的数据库账号,权限要求请参见数据库账号的权限要求。 数据库密码 填入该数据库账号对应的密码。 说明 源库信息填写完毕后,您可以单击数据库密码后的测试连接来验证填入的源库信息是否正确。源库信息填写正确则提示测试通过;如果提示测试失败,单击测试失败后的诊断,根据提示调整填写的源库信息。 目标库信息 实例类型 选择RDS实例。 实例地区 选择目标RDS实例所属地域。 RDS实例ID 选择目标RDS实例ID。 数据库账号 填入目标RDS实例的数据库账号,权限要求请参见数据库账号的权限要求。 数据库密码 填入该数据库账号对应的密码。 说明 目标库信息填写完毕后,您可以单击数据库密码后的测试连接来验证填入的目标库信息是否正确。目标库信息填写正确则提示测试通过;如果提示测试失败,单击测试失败后的诊断,根据提示调整填写的目标库信息。 连接方式 根据需求选择非加密连接或SSL安全连接。如果设置为SSL安全连接,您需要提前开启RDS实例的SSL加密功能,详情请参见设置SSL加密。 配置完成后,单击页面右下角的授权白名单并进入下一步。 说明 此步骤会将DTS服务器的IP地址自动添加到目标RDS实例的白名单中,用于保障DTS服务器能够正常连接目标RDS实例。 选择迁移对象及迁移类型。 选择迁移类型和迁移对象 配置 说明 迁移类型 如果只需要进行全量迁移,则同时勾选结构迁移和全量数据迁移。 说明 为保障数据一致性,全量数据迁移期间请勿在自建MySQL数据库中写入新的数据。 如果需要进行不停机迁移,则同时勾选结构迁移、全量数据迁移和增量数据迁移。 迁移对象 在迁移对象框中单击待迁移的对象,然后单击向右小箭头将其移动至已选择对象框。 说明 迁移对象选择的粒度可以为库、表、列三个粒度。 默认情况下,迁移完成后,迁移对象名跟自建MySQL数据库一致。如果您需要迁移对象在目标RDS实例上名称不同,那么需要使用DTS提供的对象名映射功能。使用方法请参见库表列映射。 如果使用了对象名映射功能,可能会导致依赖这个对象的其他对象迁移失败。 单击页面右下角的预检查并启动。 说明 在迁移任务正式启动之前,会先进行预检查。只有预检查通过后,才能成功启动迁移任务。 如果预检查失败,单击具体检查项后的提示,查看失败详情。根据提示修复问题后,重新进行预检查。 预检查通过后,单击下一步。 在购买配置确认页面,选择链路规格并勾选数据传输(按量付费)服务条款。 单击购买并启动,迁移任务正式开始。 结束迁移任务 警告 为尽可能地减少数据迁移对业务的影响,建议参考业务切换流程文档中介绍的流程执行业务切换并建立回退方案(将目标库的增量数据实时迁移回源库中)。如果无需切换业务,则可按照下述步骤结束迁移任务。 全量数据迁移 请勿手动结束迁移任务,否则可能导致数据不完整。您只需等待迁移任务完成即可,迁移任务会自动结束。 增量数据迁移 迁移任务不会自动结束,您需要手动结束迁移任务。 观察迁移任务的进度变更为增量迁移,并显示为无延迟状态时,将源库停写几分钟,此时增量迁移的状态可能会显示延迟的时间。 等待迁移任务的增量迁移再次进入无延迟状态后,手动结束迁移任务。结束增量迁移任务 后续操作 用于数据迁移的数据库账号拥有读写权限,为保障数据库安全性,请在数据迁移完成后,删除自建MySQL数据库和RDS MySQL实例中的数据库账号。 常见问题 Q:预检查失败如何处理? A:详情请参见源库连接性检查。 Q:迁移失败的任务如何处理? A:详情请参见修复迁移失败的任务。
游客yl2rjx5yxwcam 2020-03-08 14:03:52 0 浏览量 回答数 0

问题

极端情况下的RDS数据导入方案

大多数时候,我们能够通过PHPmyadmin或程序自带的数据库备份功能备份网站数据库。 但是对于一些运行时间较长的网站来说,其数据库大小可能会非常惊人。 比如我之前曾搬迁过几个社区,数据库达到了...
西秦说云 2019-12-01 21:05:46 7899 浏览量 回答数 3

回答

一般情况下,建议采用商品和活动分表记录,然后通过一张关系表来建立联系,这样不管从商品找活动还是从活动找商品都会比较方便。对于近期活动需要快速读取的情况,甚至可以针对活动单独建立缓存数据,以提高读取效率。商品,活动,限购都是需要记录的事实。关键问题是“限购”应该怎样表示。由于限购本身还可能包含其他属性,比如限购日期等等,所以不是单单一个关联表(多对多关系)就能解决的。有两种方法可以记录限购:1)记录不限购的商品、活动2)记录限购的商品活动如果限购的商品活动数量相对较小,方法2)更合适。Product (ProductId, ...)Activity (ActivityId, ...)PurchaseRestriction (ProductId, ActivityId, StartDate, EndDate,...)你的疑问:这张映射表,属于哪个模块去维护商品、活动不是相互独立的,PurchaseRestriction 恰恰表示了它们之间的联系。PurchaseRestriction 既跟Product相关,又跟Activity相关。不是简单的“谁的属性”。很多人设计class时使用循环引用,比如,Product 拥有 RestrictedActivities 集合,Activity 拥有 RestrictedProducts 集合。你心里也有类似的疑问,一方面觉得限购是一个事实,只应该放在一个地方;另一方面,感觉限购既是Product的属性,又是Activity的属性。我觉得,这是面向对象的一个缺点,“对象拥有属性,属性必须属于某个对象”这个思想的根源是认为所有东西都是树状结构的。这跟树形数据库犯了同样的错误,后来出现网络数据库。网络数据库可以表达复杂的结构,但是过于复杂。关系数据库的出现,解决了树形数据库和网络数据库的问题。关系数据库是基于集合论和一阶谓词逻辑的模型,可以完美地表达各种结构。"模块化"当然很好,合理的模块化减少了程序各模块之间的耦合。但是,一个系统最大的耦合往往是程序和数据的耦合。数据的结构变了,程序必须跟着变。因此,规范的数据库设计比应用程序的模块化更重要。你把商品和活动分到不同的模块,一方面提高了抽象级别,模块化,另一方面割裂了它们的联系。虽然模块多了,但模块间的交互更复杂了。你的问题没有完美的答案,有3个解决方案:a) 商品模块去维护b) 活动模块去维护c) 单独的模块去维护。上面提到的(商品是否能参加活动,商品限购属性),我觉得第一个是可以归为商品固有属性,第二个可能通过一张映射表来记录(因为限购商品毕竟是少数)"商品是否能参加活动"可以由PurchaseRestriction推导出,不需要这样的属性。在程序里,也许有某个类,它有一个属性 CanTakePartInActivity. 但是数据库不能这样设计。
蛮大人123 2019-12-02 02:03:45 0 浏览量 回答数 0

回答

这个小一点的可以转,如果文件较大的话,转出来的SQL也是非常巨大的,很难操作。  你可以自己转换。  找台有MS Sql的电脑,附加数据库,把这2个文件附加进去,就还原出来一个新数据库, 进去可以继续操作,也可以导出数据为SQL文件
vesaa 2019-12-02 00:37:42 0 浏览量 回答数 0

问题

用户指南-账号管理-创建账号

[tr=transparent] [/url]说明[tr=transparent]RDS for MyQL的账号管理机制已更新。对于RDS for MySQL实例,请参见[url=https://hel...
李沃晟 2019-12-01 21:38:45 851 浏览量 回答数 0

问题

如何将mysqldump的输出拆分为较小的文件??mysql

我需要将整个表从一个MySQL数据库移动到另一个数据库。我没有完全访问第二个权限,只有phpMyAdmin访问权限。我只能上传(压缩)小于2MB的sql文件。但是,第一个数据库表的my...
保持可爱mmm 2020-05-17 18:57:12 1 浏览量 回答数 1

回答

一个复杂查询还是多个简单查询 MySQL内部每秒能扫描内存中上百万行数据,相比之下,响应数据给客户端就要慢得多 使用尽可能小的查询是好的,但是有时将一个大的查询分解为多个小的查询是很有必要的。 切分查询 将一个大的查询分为多个小的相同的查询 一次性删除1000万的数据要比一次删除1万,暂停一会的方案更加损耗服务器开销。 分解关联查询,让缓存的效率更高。 执行单个查询可以减少锁的竞争。 在应用层做关联更容易对数据库进行拆分。 查询效率会有大幅提升。 较少冗余记录的查询。
剑曼红尘 2020-03-31 11:24:00 0 浏览量 回答数 0

回答

下文将RDS和自建数据库从多个方面进行对比,介绍RDS具有的优势。 特性对比 对比项 云数据库RDS 自购服务器搭建数据库服务 服务可用性 高可用架构提供高可用性。 需自行保障,自行搭建主备复制,自建RAID等。 数据可靠性 自动主备复制、数据备份、日志备份等。 需自行保障,自行搭建主备复制,自建RAID等。 系统安全性 防DDoS攻击,流量清洗;及时修复各种数据库安全漏洞。 自行部署,价格高昂;自行修复数据库安全漏洞。 数据库备份 自动备份。 自行实现,但需要寻找备份存放空间以及定期验证备份是否可恢复。 软硬件投入 无软硬件投入,按需付费。 数据库服务器成本相对较高,对于SQL Server还需支付许可证费用。 系统托管 无托管费用。 每台2U服务器每年超过5000元(如果需要主备,两台服务器需超过10000元/年)。 维护成本 无需运维。 需招聘专职DBA来维护,花费大量人力成本。 部署扩容 即时开通,快速部署,弹性扩容。 需硬件采购、机房托管、机器部署等工作,周期较长。 资源利用率 按实际结算,100%利用率。 由于业务有高峰期和低峰期,资源利用率很低。 价格对比 费用 云数据库RDS 自购服务器搭建数据库服务 硬件费用和备品配件费用 RDS实例的费用。例如,内存1200 MB、存储空间50 GB(IOPS能力可达到600)的实例费用是2040元/年。 至少需要2台数据库服务器。每台IOPS能力达到600的服务器费用大约是6000元。 1台用于连接前端Web服务器的内网交换机(便宜的1U非网管交换机为1000元左右)。 后期硬件损坏和更换至少还要消耗30%费用。 硬件花费:(6000 × 2 + 1000)× 130% = 16900元。 每年费用:16900元/3 = 5633元(硬件按照3年折旧计算)。 机房托管费用 服务商负责,无需付费。 1U机柜空间托管费用为3000元/年,共有2台1U服务器和1台1U内网交换机需要计费,机房托管费用:3000 × 3 = 9000元。 带宽费用 同一地域内,ECS和RDS可以通过内网互通,且不收取费用。 若在不同地域,ECS和RDS可以通过外网互通,需收取外网流量费用,详细收费标准请参见云数据库RDS详细价格信息。 只用于内网,不产生公网费用。 数据库运维工程师费用 数据库维护由服务商负责,无人员成本。 1个初级DBA工程师月薪至少5000/月,假设当前项目占用该工程师30%的工作量,则人员成本为5000 × 12× 30% = 18000元。 每年总费用 2040元/年。 32633元/年。 RDS MySQL与自建数据库对比优势 对比项 RDS MySQL ECS自建 IDC自建 性价比 弹性资源; ALISQL提供各种特性功能,提升用户使用感受; 备份有一半实例空间免费; 公网流量免费; 免费使用自带的域名; 更新速度快,紧跟MySQL最新版本。 弹性资源; 开源版无性能优化; 备份空间独立收费; 公网流量收费。 一次投入的沉没成本大; 开源版无性能优化; 需要独立准备备份资源,成本极高; 公网流量收费,域名费用高。 可用性 基础版约15分钟即可完成故障转移; 高可用版和集群版提供自研高可用系统,实现30秒内故障恢复; 只读实例自动实现负载均衡; 读写分离使用方便; 未来会推出分析节点,满足分析型场景需求。 基础版约30分钟完成故障转移; 需要单独购买高可用系统; 需要单独实现或者购买负载均衡; 分析型场景需要与分析型数据库结合,搭建难度大、成本高。 单机实例,少则两小时,多则等待配货数周; 需要单独购买高可用系统; 需要单独实现或者购买负载均衡设备; 分析型场景需要与分析型数据库结合,搭建难度大、成本高。 可靠性 数据可靠性高,自动主备复制、数据备份、日志备份等; MySQL 5.6三节点企业版,实现RPO(Recovery Point Object)=0; MySQL 5.7三节点企业版(MGR),实现RPO=0、RTO(Recovery Time Objective) < 1分钟。 在好的架构下才能实现高可靠性; 实现RPO=0的成本极高,需要单独购买研发服务。 数据可靠性一般,取决于单块磁盘的损害概率; 实现RPO=0的成本极高,需要单独购买研发服务。 易用性 自动化备份恢复系统,支持按时间点恢复、单库备份恢复等,流式备份对实例性能影响小; 自动化监控告警系统,支持秒级监控,覆盖实例和数据库所有性能指标,支持短信、邮箱、旺旺、钉钉等通道,且根据消费有大额度的免费短信数量; 支持异地容灾; 支持一键版本升级。 无自动备份系统,流式备份能力需要单独实现,实现按时间点恢复功能成本高; 需要单独购买监控系统,在云监控中配置告警系统; 技术实现难度极大; 版本升级成本高。 无自动备份系统,流式备份能力需要单独实现,实现按时间点恢复功能成本高; 需要单独购买或配置监控系统,通道较少,成本较高; 异地数据中心成本极高,技术实现难度也大,很难实现异地容灾; 版本升级成本高。 性能 MySQL的本地SSD盘实例性能极佳; MySQL的ESSD性能较SSD提升显著; 增加只读实例之后性能强劲且负载均衡; CloudDBA提供高级优化能力; SQL洞察满足大部分监控及性能优化数据库场景。 ECS本地盘意味着降低数据可靠性,采用云盘的话需要规划架构,成本支出较大; 基于ESSD的ECS自建MySQL性能低于基于ESSD的RDS MySQL性能; 实现集群版的难度较高,咨询成本较高,维护成本极高; 依赖资深DBA,支出大,受制于人。 比云计算硬件更新速度慢,性能一般都会低于云数据库; 难以实现计算和存储分离,若使用高端存储实现计算和存储分离,动辄需要数千万支出; 实现集群版的难度较高,咨询成本较高,维护成本极高; 依赖资深DBA,支出大,受制于人。 安全 事前防护:白名单、安全组、专有网络隔离; 事中保护:连接链路加密、数据落盘加密(BYOK覆盖多种存储介质); 事后审计:SQL洞察、历史事件。 事前防护:白名单、安全组、专有网络隔离; 事中保护:需要单独实现连接链路加密和数据落盘加密,BYOK密钥轮转难度大,咨询成本较高; 事后审计:审计困难,需要单独保存SQL日志。 事前防护:白名单和专有网络隔离的咨询成本较高; 事中保护:需要单独实现连接链路加密和数据落盘加密,BYOK密钥轮转难度大,咨询成本较高; 事后审计:审计困难,需要单独保存SQL日志。 RDS SQL Server与自建数据库对比优势 对比项 RDS SQL Server ECS自建 IDC自建 性价比 弹性资源; WEB版性价比极高; 备份有一半实例空间免费; 公网流量免费。 弹性资源; 不可使用WEB版; 备份空间独立收费; 公网流量收费。 一次投入的沉没成本大; 不可使用WEB版; 需要独立准备备份资源,成本极高; 公网流量收费,域名费用高。 可用性 基础版约15分钟即可完成故障转移; 高可用版和集群版提供自研高可用系统,实现30秒内故障恢复; 集群版的只读实例自动实现负载均衡; 集群版的读写分离使用方便。 基础版约30分钟完成故障转移; 需要单独购买高可用系统; 需要单独实现或者购买负载均衡。 单机实例,少则两小时,多则等待配货数周; 需要单独购买高可用系统; 需要单独实现或者购买负载均衡设备。 可靠性 数据可靠性高,自动主备复制、数据备份、日志备份等; 集群版可实现RPO(Recovery Point Object)=0。 在好的架构下才能实现高可靠性; 实现RPO=0的成本极高,需要单独购买研发服务。 数据可靠性一般,取决于单块磁盘的损害概率; 实现RPO=0的成本极高,需要单独购买研发服务。 易用性 自动化备份恢复系统,支持按时间点恢复、单库备份恢复等,流式备份对实例性能影响小; 自动化监控告警系统,支持秒级监控,覆盖实例和数据库所有性能指标,支持短信、邮箱、旺旺、钉钉等通道,且根据消费有大额度的免费短信数量; 即将支持异地容灾。 无自动备份系统,流式备份能力需要单独实现,实现按时间点恢复功能成本高; 需要单独购买监控系统,在云监控中配置告警系统; 技术实现难度极大。 无自动备份系统,流式备份能力需要单独实现,实现按时间点恢复功能成本高; 需要单独购买或配置监控系统,通道较少,成本较高; 异地数据中心成本极高,技术实现难度也大,很难实现异地容灾。 性能 SQL Server 2008 R2的本地SSD盘实例性能极佳,SQL Server 201x版本新计算存储分离架构可享受硬件红利 ; SQL Server的ESSD性能较SSD提升显著; 增加只读实例之后性能强劲且负载均衡; CloudDBA提供高级优化能力。 ECS本地盘意味着降低数据可靠性,采用云盘的话需要规划架构,成本支出较大; 基于ESSD的ECS自建SQL Server性能低于基于ESSD的RDS SQL Server性能; 实现集群版的难度较高,咨询成本较高,维护成本极高; 依赖资深DBA,支出大,受制于人。 比云计算硬件更新速度慢,性能一般都会低于云数据库; 难以实现计算和存储分离,若使用高端存储实现计算和存储分离,动辄需要数千万支出; 实现集群版的难度较高,咨询成本较高,维护成本极高; 依赖资深DBA,支出大,受制于人。 安全 事前防护:白名单、专有网络隔离; 事中保护:连接链路加密、数据落盘加密; 事后审计:SQL审计(数据库审计)、历史事件; 微软安全更新,阿里技术兜底。 事前防护:白名单、安全组、专有网络隔离; 事中保护:需要单独实现连接链路加密和数据落盘加密,咨询成本较高; 事后审计:审计困难,需要单独保存SQL日志。 事前防护:白名单和专有网络隔离的咨询成本较高; 事中保护:需要单独实现连接链路加密和数据落盘加密,咨询成本较高; 事后审计:审计困难,需要单独保存SQL日志。 法律 附带License,无法律风险; 即将支持自带License,降低整体成本支出。 只有单独购买License。 只有单独购买License,否则法律风险极大。
游客yl2rjx5yxwcam 2020-03-09 10:46:50 0 浏览量 回答数 0

问题

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

转载自:http://www.hbase.group/article/2 引言 HBase在互联网领域有广泛的应用,比如:互联网的消息系统的存储、订单的存储、搜索原材料的存储、用户画像数据的存储...
pandacats 2019-12-18 16:06:18 1 浏览量 回答数 0

问题

哪种mysql代理可根据表名路由?:报错

大家好 现有一个应用需求,使用的mysql,由于数据量较大,提取了部分数据生成一个小库,也就是现在这个应用有两个数据库,DB1为小库,DB2为大库。举...
kun坤 2020-06-06 15:59:49 0 浏览量 回答数 1

回答

转自:阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问: 谁选型?是负责采购的同学、 DBA 还是业务研发? 如果选型的是采购的同学,他们更注重成本,包括存储方式、网络需求等。 如果选型的是 DBA 同学,他们关心的: ① 运维成本 首先是运维成本,包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等; ② 稳定性 其次,DBA会关注稳定性,包括是否支持数据多副本、服务高可用、多写多活等; ③ 性能 第三是性能,包括延迟、QPS 以及是否支持更高级的分级存储功能等; ④ 拓展性 第四是扩展性,如果业务的需求不确定,是否容易横向扩展和纵向扩容; ⑤ 安全 最后是安全,需要符合审计要求,不容易出现 SQL 注入或拖库情况。 ⑥ 其他 除了采购和 DBA之外,后台应用研发的同学同样会关注稳定性、性能、扩展性等问题,同时也非常关注数据库接口是否便于开发,是否便于修改数据库 schema 等问题。 接下来我们来看一下爱奇艺使用的数据库类型: MySQL,互联网业务必备系统; TiDB,爱奇艺的 TiDB 实践会有另外的具体介绍; Redis,KV 数据库,互联网公司标配; Couchbase,这个在爱奇艺用得比较多,但国内互联网公司用得比较少,接下来的部分会详细说明; 其他,比如 MongoDB、图数据库、自研 KV 数据库 HiKV 等; 大数据分析相关系统,比如 Hive、Impala 等等。 可以看到爱奇艺的数据库种类还是很多的,这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。 那么,我们先对这些数据库按照接口(SQL、NoSQL)和面向的业务场景(OLTP、OLAP)这两位维度进行一个简单非严谨的分类。 下图中,左上角是面向 OLTP、支持 SQL 的这样一类系统,例如 MySQL,一般支持事务不同的隔离级别, QPS 要求比较高,延时比较低,主要用于交易信息和关键数据的存储,比如订单、VIP 信息等。 左下角是 NoSQL 数据库,是一类针对特殊场景做优化的系统,schema 一般比较简单,吞吐量较高、延迟较低,一般用作缓存或者 KV 数据库。 整个右侧都是 OLAP 的大数据分析系统,包括 Clickhouse、Impala等,一般支持SQL、不支持事务,扩展性比较好,可以通过加机器增加数据的存储量,响应延迟较长。 还有一类数据库是比较中立的,在数据量比较小的时候性能比较好,在数据量较大或复杂查询的时候性能也不差,一般通过不同的存储引擎和查询引擎来满足不同的业务需求,我们把它叫做 HTAP,TiDB 就是这样一种数据库。 二、iQIYI对数据库的优化与完善 前面我们提到了很多种的数据库,那么接下来就和大家介绍一下在爱奇艺我们是怎么使用这些数据库的。 1、MySQL在爱奇艺的使用 ① MySQL 首先是 MySQL。MySQL 基本使用方式是 master-slave + 半同步,支持每周全备+每日增量备份。我们做了一些基本功能的增强,首先是增强了数据恢复工具 Xtrabackup 的性能。 之前遇到一个情况,我们有一个全量库是 300G 数据,增量库每天 70G 数据,总数据量 700G 左右。我们当时只需要恢复一个表的数据,但该工具不支持单表恢复,且整库恢复需要 5 个小时。 针对这个情况我们具体排查了原因,发现在数据恢复的过程中需要进行多次写盘的 IO 操作并且有很多串行操作,所以我们做了一些优化。例如删减过程中的一些写盘操作,减少落盘并将数据处理并行化,优化后整库恢复耗时减少到 100 分钟,而且可以直接恢复单表数据。 然后是适配 DDL 和 DML 工具到内部系统,gh-ostt 和 oak-online-alter-table 在数据量大的时候会造成 master-slave 延时,所以我们在使用工具的时候也增加了延时上的考虑,实时探测Master-Slave 库之间延时的情况,如果延时较大会暂停工具的使用,恢复到正常水平再继续。 ② MySQL高可用 第二是 MySQL 高可用。Master-slave 加上半同步这种高可用方式不太完善,所以我们参照了 MHA 并进行了改动,采用 master + agent 的方式。Agent 在每一个物理机上部署,可以监控这个物理机上的所有实例的状态,周期性地向 master 发送心跳,Master 会实时监测各个Agent的状态。 如果 MySQL故障,会启动 Binlog 补偿机制,并切换访问域名完成 failover。考虑到数据库跨机房跨地区部署的情况,MHA 的 master 我们也做了高可用设计,众多 master 会通过 raft 组成一个 raft group,类似 TiDB 的 PD 模块。目前 MySQL failover 策略支持三种方式:同机房、同地域跨机房以及跨地域。 ③ MySQL拓展能力 第三是提高MySQL扩展能力,以提供更大容量的数据存储。扩展方式有 SDK,例如开源的 ShardingSphere,在爱奇艺的使用也比较广泛。另外就是 Proxy,开源的就更多了。但是 SDK 和 Proxy 使用的问题是支持的 SQL 语句简单,扩容难度大,依赖较多且运维复杂,所以部分业务已经迁移至 TiDB。 ④ 审计 第四是审计。我们在 MySQL 上做了一个插件获取全量 SQL 操作,后端打到 Kafka,下游再接入包括 Clickhouse 等目标端进行 SQL 统计分析。除此之外还有安全策略,包括主动探索是否有 SQL 注入及是否存在拖库情况等,并触发对应的告警。 MySQL 审计插件最大的问题是如何降低对 MySQL 性能的影响,对此我们进行了一些测试,发现使用 General Log 对性能损耗较大,有 10%~20% 的降低。 于是我们通过接口来获取 MySQL 插件里的监控项,再把监控项放到 buffer 里边,用两级的 RingBuffer 来保证数据的写入不会有锁资源竞争。在这个插件里再启动一个线程,从 RingBuffer 里读取数据并把数据打包写到 FIFO 管道里。 我们在每台 MySQL 的物理机里再启动一个 Agent,从管道里阻塞地读取数据发至 Kafka。优化后我们再次进行压测,在每台机器上有 15 万的更新、删除或插入操作下不会丢失数据,性能损耗一般情况下小于 2%。 目前已经在公司内部的集群上线了一年时间,运行比较稳定,上线和下线对业务没有影响。 ⑤ 分级存储 第五是分级存储。MySQL 里会存一些过程性的数据,即只需要读写最近一段时间存入的数据,过段时间这些数据就不需要了,需要进行定时清理。 分级存储就是在 MySQL 之上又用了其他存储方式,例如 TiDB 或其他 TokuDB,两者之间可以进行数据自动搬迁和自动归档,同时前端通过 SDK + Proxy 来做统一的访问入口。这样一来,业务的开发同学只需要将数据存入 MySQL 里,读取时可能从后端接入的任意数据库读出。这种方式目前只是过渡使用,之后会根据 TiDB 的特性进行逐步迁移。 Redis在爱奇艺的使用 接下来是 Redis。Redis 也是使用 master - slave 这种方式,由于网络的复杂性我们对 Sentinel 的部署进行了一些特殊配置,在多机房的情况下每个机房配置一定数量 Sentinel 来避免脑裂。 备份恢复方面介绍一个我们的特殊场景,虽然 Redis 是一个缓存,但我们发现不少的业务同学会把它当做一个 KVDB 来使用,在某些情况下会造成数据的丢失。 所以我们做了一个 Redis 实时备份功能,启动一个进程伪装成 Redis 的 Slave 实时获取数据,再放到后端的 KV 存储里,例如 ScyllaDB,如果要恢复就可以从 ScyllaDB 里把数据拉出来。 我们在用 Redis 时最大的痛点就是它对网络的延迟或抖动非常敏感。如有抖动造成 Redis Master 超时,会由 Sentinel 重新选出一个新的节点成为 Master,再把该节点上的数据同步到所有 Slave 上,此过程中数据会放在 Master 节点的 Buffer 里,如果写入的 QPS 很高会造成 Buffer 满溢。如果 Buffer 满后 RDB 文件还没有拷贝过去,重建过程就会失败。 基于这种情况,我们对 Redis 告警做了自动化优化,如有大量 master - slave 重建失败,我们会动态调整一些参数,例如把 Buffer 临时调大等, 此外我们还做了 Redis 集群的自动扩缩容功能。 我们在做 Redis 开发时如果是 Java 语言都会用到 Jedis。用 Jedis 访问客户端分片的 Redis 集群,如果某个分片发生了故障或者 failover,Jedis 就会对所有后端的分片重建连接。如果某一分片发生问题,整个 Redis 的访问性能和 QPS 会大幅降低。针对这个情况我们优化了 Jedis,如果某个分片发生故障,就只针对这个分片进行重建。 在业务访问 Redis 时我们会对 Master 绑定一个读写域名,多个从库绑定读域名。但如果我们进行 Master failover,会将读写域名从某旧 Master 解绑,再绑定到新 Master 节点上。 DNS 本身有一个超时时间,所以数据库做完 failover 后业务程序里没有立刻获取到新的 Master 节点的 IP的话,有可能还会连到原来的机器上,造成访问失败。 我们的解决方法是把 DNS 的 TTL 缩短,但对 DNS 服务又会造成很大的压力,所以我们在 SDK 上提供 Redis 的名字服务 RNS,RNS 从 Sentinel 里获取集群的拓扑和拓扑的变化情况,如果集群 failover,Sentinel 会接到通知,客户端就可以通过 RNS 来获取新的 Master 节点的 IP 地址。我们去掉域名,通过 IP 地址来访问整个集群,屏蔽了 DNS 的超时,缩短了故障的恢复时间。 SDK 上还做了一些功能,例如 Load Balance 以及故障检测,比如某个节点延时较高的话会被临时熔断等。 客户端分片的方式会造成 Redis 的扩容非常痛苦,如果客户端已经进行了一定量的分片,之后再增加就会非常艰难。 Redis 在 3.0 版本后会提供 Redis Cluster,因为功能受限在爱奇艺应用的不是很多,例如不支持显示跨 DC 部署和访问,读写只在主库上等。 我们某些业务场景下会使用 Redis 集群,例如数据库访问只发生在本 DC,我们会在 DC 内部进行 Cluster 部署。 但有些业务在使用的过程中还是想做 failover,如果集群故障可以切换到其他集群。根据这种情况我们做了一个 Proxy,读写都通过它来进行。写入数据时 Proxy 会做一个旁路,把新增的数据写在 Kafka 里,后台启用同步程序再把 Kafka 里的数据同步到其他集群,但存在一些限制,比如我们没有做冲突检测,所以集群间数据需要业务的同学做单元化。线上环境的Redis Cluster 集群间场景跨 DC 同步 需要 50 毫秒左右的时间。 2、Couchbase在爱奇艺的使用 Redis 虽然提供 Cluster 这种部署方式,但存在一些问题。所以数据量较大的时候(经验是 160G),就不推荐 Redis 了,而是采用另一种存储方式 Couchbase。 Couchbase 在国内互联网公司用的比较少,一开始我们是把他当做一个 Memcached 来使用的,即纯粹的缓存系统。 但其实它性能还是比较强大的,是一个分布式高性能的 KV 系统,支持多种存储引擎 (bucket)。第一种是 Memcached bucket,使用方式和 Memcached 一样为 KV 存储,不支持数据持久化也没有数据副本,如果节点故障会丢失数据; 第二种是 Couchbase bucket,支持数据持久化,使用 Json 写入,有副本,我们一般会在线上配置两个副本,如果新加节点会对数据进行 rebalance,爱奇艺使用的一般是 Couchbase bucket 这种配置。 Couchbase 数据的分布如下图,数据写入时在客户端上会先进行一次哈希运算,运算完后会定位 Key 在哪一个 vBucket (相当于数据库里的某个分片)。之后客户端会根据 Cluster Map 发送信息至对应的服务端,客户端的 Cluster Map 保存的是 vBucket 和服务器的映射关系,在服务端数据迁移的过程中客户端的 Cluster Map 映射关系会动态更新,因此客户端对于服务端的 failover 操作不需要做特殊处理,但可能在 rebalance 过程中会有短暂的超时,导致的告警对业务影响不大。 Couchbase 在爱奇艺应用比较早,2012 年还没有 Redis Cluster 的时候就开始使用了。集群管理使用 erlang 语言开发,最大功能是进行集群间的复制,提供多种复制方式:单向、双向、星型、环式、链式等。 爱奇艺从最初的 1.8 版本使用到如今的 5.0 版本,正在调研的 6.0,中间也遇到了很多坑,例如 NTP 时间配置出错会导致崩溃,如果每个集群对外 XDCR 并发过高导致不稳定,同步方向变更会导致数据丢失等等,我们通过运维和一些外部工具来进行规避。 Couchbase 的集群是独立集群,集群间的数据同步通过 XDCR,我们一般配置为双向同步。对于业务来说,如果 Cluster 1 写入, Cluster 2 不写入,正常情况下客户端会写 Cluster 1。如果 Cluster 1 有故障,我们提供了一个 Java SDK,可以在配置中心把写入更改到 Cluster 2,把原来到 Cluster 1 的连接逐步断掉再与Cluster 2 新建连接。这种集群 failover 的过程对于客户端来说是相对透明和无感的。 3、爱奇艺自研数据库HiKV的使用 Couchbase 虽然性能非常高,并且数据的存储可以超过内存。但是,如果数据量超过内存 75% 这个阈值,性能就会下降地特别快。在爱奇艺,我们会把数据量控制在可用内存的范围之内,当做内存数据库使用。但是它的成本非常高,所以我们后面又开发了一个新的数据库—— HiKV。 开发 HiKV 的目的是为了把一些对性能要求没那么高的 Couchbase 应用迁移到 HiKV 上。HiKV 基于开源系统 ScyllaDB,主要使用了其分布式数据库的管理功能,增加了单机存储引擎 HiKV。 ScyllaDB 比较吸引人的是它宣称性能高于 Cassandra 十倍,又完全兼容 Cassandra 接口,设计基本一致,可以视为 C++ 版 Cassandra 系统。 ScyllaDB 性能的提升主要是使用了一些新的技术框架,例如 C++ 异步框架 seastar,主要原理是在j每台物理机的核上会 attach 一个应用线程,每个核上有自己独立的内存、网络、IO 资源,核与核之间没有数据共享但可以通信,其最大的好处是内存访问无锁,没有冲突过程。 当一个数据读或写到达 ScyllaDB 的 server 时,会按照哈希算法来判断请求的 Key 是否是该线程需要处理的,如果是则本线程处理,否则会转发到对应线程上去。 除此之外,它还支持多副本、多数据中心、多写多活,功能比较强大。 在爱奇艺,我们基于 SSD 做了一个 KV 存储引擎。Key 放在内存里,Value 放在盘上的文件里,我们在读和写文件时,只需要在内存索引里定位,再进行一次盘的 IO 开销就可以把数据读出来,相比 ScyllaDB 原本基于 LSM Tree 的存储引擎方式对 IO 的开销较少。 索引数据全部放在内存中,如果索引长度较长会限制单机可存储的数据量,于是我们通过开发定长的内存分布器,对于比较长的 Key 做摘要缩短长度至 20 字节,采用红黑树索引,限制每条记录在内存里的索引长度至为 64 字节。内存数据要定期做 checkpoint,客户端要做限流、熔断等。 HiKV 目前在爱奇艺应用范围比较大,截至目前已经替换了 30% 的 Couchbase,有效地降低了存储成本。 4、爱奇艺的数据库运维管理 爱奇艺数据库种类较多,如何高效地运维和管理这些数据库也是经历了不同的阶段。 最初我们通过 DBA 写脚本的方式管理,如果脚本出问题就找 DBA,导致了 DBA 特别忙碌。 第二个阶段我们考虑让大家自己去查问题的答案,于是在内部构建了一个私有云,通过 Web 的方式展示数据库运行状态,让业务的同学可以自己去申请集群,一些简单的操作也可以通过自服务平台实现,解放了 DBA。一些需要人工处理的大型运维操作经常会造成一些人为故障,敲错参数造成数据丢失等。 于是在第三个阶段我们把运维操作 Web 化,通过网页点击可以进行 90% 的操作。 第四个阶段让经验丰富的 DBA 把自身经验变成一些工具,比如有业务同学说 MySQL master-slave 延时了,DBA 会通过一系列操作排查问题。现在我们把这些操作串起来形成一套工具,出问题时业务的同学可以自己通过网页上的一键诊断工具去排查,自助进行处理。 除此之外我们还会定期做预警检查,对业务集群里潜在的问题进行预警报告;开发智能客服,回答问题;通过监控的数据对实例打标签,进行削峰填谷地智能调度,提高资源利用率。 三、不同场景下数据库选型建议 1、实用数据库选型树 最后来说一些具体数据库选型建议。这是 DBA 和业务一起,通过经验得出来的一些结论。 对于关系型数据库的选型来说,可以从数据量和扩展性两个维度考虑,再根据数据库有没有冷备、要不要使用 Toku 存储引擎,要不要使用 Proxy 等等进行抉择。 NoSQL 也是什么情况下使用 master-slave,什么情况下使用客户端分片、集群、Couchbase、HiKV 等,我们内部自服务平台上都有这个选型树信息。 2、一些思考 ① 需求 我们在选型时先思考需求,判断需求是否真实。 你可以从数据量、QPS、延时等方面考虑需求,但这些都是真实需求吗?是否可以通过其他方式把这个需求消耗掉,例如在数据量大的情况下可以先做数据编码或者压缩,数据量可能就降下来了。 不要把所有需求都推到数据库层面,它其实是一个兜底的系统。 ② 选择 第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么?是因为热门吗?还是因为技术上比较先进?但是不是能真正地解决你的问题?如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。 ③ 放弃 第三是放弃,当你放弃一个系统时真的是因为不好用吗?还是没有用好?放弃一个东西很难,但在放弃时最好有一个充分的理由,包括实测的结果。 ④ 自研 第四是自研,在需要自己开发数据库时可以参考和使用一些成熟的产品,但不要盲目自研。 ⑤ 开源 最后是开源,要有拥抱开源的态度。
茶什i 2019-12-27 14:17:56 0 浏览量 回答数 0

回答

当MySQL单表记录数过大时,数据库的CRUD性能会明显下降,一些常见的优化措施如下: 限定数据的范围: 务必禁止不带任何限制数据范围条件的查询语句。比如:我们当用户在查询订单历史的时候,我们可以控制在一个月的范围内。;读/写分离: 经典的数据库拆分方案,主库负责写,从库负责读;缓存: 使用MySQL的缓存,另外对重量级、更新少的数据可以考虑使用应用级别的缓存; 还有就是通过分库分表的方式进行优化,主要有垂直分表和水平分表 垂直分区: 根据数据库里面数据表的相关性进行拆分。 例如,用户表中既有用户的登录信息又有用户的基本信息,可以将用户表拆分成两个单独的表,甚至放到单独的库做分库。 简单来说垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表。 如下图所示,这样来说大家应该就更容易理解了。 垂直拆分的优点: 可以使得行数据变小,在查询时减少读取的Block数,减少I/O次数。此外,垂直分区可以简化表的结构,易于维护。 垂直拆分的缺点: 主键会出现冗余,需要管理冗余列,并会引起Join操作,可以通过在应用层进行Join来解决。此外,垂直分区会让事务变得更加复杂; 垂直分表 把主键和一些列放在一个表,然后把主键和另外的列放在另一个表中 适用场景 1、如果一个表中某些列常用,另外一些列不常用 2、可以使数据行变小,一个数据页能存储更多数据,查询时减少I/O次数 缺点 有些分表的策略基于应用层的逻辑算法,一旦逻辑算法改变,整个分表逻辑都会改变,扩展性较差 对于应用层来说,逻辑算法增加开发成本 管理冗余列,查询所有数据需要join操作 水平分区: 保持数据表结构不变,通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中,达到了分布式的目的。 水平拆分可以支撑非常大的数据量。 水平拆分是指数据表行的拆分,表的行数超过200万行时,就会变慢,这时可以把一张的表的数据拆成多张表来存放。举个例子:我们可以将用户信息表拆分成多个用户信息表,这样就可以避免单一表数据量过大对性能造成影响。 水品拆分可以支持非常大的数据量。需要注意的一点是:分表仅仅是解决了单一表数据过大的问题,但由于表的数据还是在同一台机器上,其实对于提升MySQL并发能力没有什么意义,所以 水平拆分最好分库 。 水平拆分能够 支持非常大的数据量存储,应用端改造也少,但 分片事务难以解决 ,跨界点Join性能较差,逻辑复杂。 《Java工程师修炼之道》的作者推荐 尽量不要对数据进行分片,因为拆分会带来逻辑、部署、运维的各种复杂度 ,一般的数据表在优化得当的情况下支撑千万以下的数据量是没有太大问题的。如果实在要分片,尽量选择客户端分片架构,这样可以减少一次和中间件的网络I/O。 水平分表: 表很大,分割后可以降低在查询时需要读的数据和索引的页数,同时也降低了索引的层数,提高查询次数 适用场景 1、表中的数据本身就有独立性,例如表中分表记录各个地区的数据或者不同时期的数据,特别是有些数据常用,有些不常用。 2、需要把数据存放在多个介质上。 水平切分的缺点 1、给应用增加复杂度,通常查询时需要多个表名,查询所有数据都需UNION操作 2、在许多数据库应用中,这种复杂度会超过它带来的优点,查询时会增加读一个索引层的磁盘次数 下面补充一下数据库分片的两种常见方案: 客户端代理: 分片逻辑在应用端,封装在jar包中,通过修改或者封装JDBC层来实现。 当当网的 Sharding-JDBC 、阿里的TDDL是两种比较常用的实现。 中间件代理: 在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。 我们现在谈的 Mycat 、360的Atlas、网易的DDB等等都是这种架构的实现。 分库分表后面临的问题 事务支持 分库分表后,就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价; 如果由应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担。 跨库join 只要是进行切分,跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。 分库分表方案产品 跨节点的count,order by,group by以及聚合函数问题 这些是一类问题,因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案:与解决跨节点join问题的类似,分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行,因此很多时候它的速度要比单一大表快很多。但如果结果集很大,对应用程序内存的消耗是一个问题。 数据迁移,容量规划,扩容等问题 来自淘宝综合业务平台团队,它利用对2的倍数取余具有向前兼容的特性(如对4取余得1的数对2取余也是1)来分配数据,避免了行级别的数据迁移,但是依然需要进行表级别的迁移,同时对扩容规模和分表数量都有限制。总得来说,这些方案都不是十分的理想,多多少少都存在一些缺点,这也从一个侧面反映出了Sharding扩容的难度。 ID问题 一旦数据库被切分到多个物理结点上,我们将不能再依赖数据库自身的主键生成机制。一方面,某个分区数据库自生成的ID无法保证在全局上是唯一的;另一方面,应用程序在插入数据之前需要先获得ID,以便进行SQL路由. 一些常见的主键生成策略
剑曼红尘 2020-03-31 11:34:39 0 浏览量 回答数 0

回答

phpMyAdmin导入文件大小是有php.ini配置文件控制的,需要修改upload_max_filesize和post_max_size两个参数。(php.ini会取upload_max_filesize和post_max_size两个配置的较小值项作为导入数据库文件大小限制的有效值,所以两个参数都要修改) 参考: phpMyAdmin数据库导入大小限制修改解决方法
张扯淡 2019-12-02 01:28:07 0 浏览量 回答数 0

回答

虚拟主机在上传导入MySQL数据库过程中,如果需要上传较大的数据库sql文件,可以通过 MySQL-Front 客户端工具方式进行上传解决。 MySQL-Front是一个小巧的免费版管理Mysql的应用程序,可以通过访问 http://www.mysqlfront.de/ 官方网站下载该软件。 以下内容介绍通过MySQL-Front软件对虚拟主机的MySQL数据库进行 删除、创建和导入数据的操作方法。   如果该回答对您有帮助的话,麻烦点击采纳此答案
叶康铭 2019-12-02 00:55:03 0 浏览量 回答数 0

问题

redis 适合做一个小型网站的数据存储么?

小弟对于数据库这方面的知识实在有限,只是相较于mysql觉得redis用得很是顺手与舒服,但是看到诸大牛者都只将redis用于临时存储。我不禁对于自己将redis当做主力数据库的做法感到紧张,虽还不至于遇到什么过不去的难题,但是为了现在做的...
爵霸 2019-12-01 20:11:18 899 浏览量 回答数 1

问题

redis 适合做一个小型网站的数据存储么?

弟对于数据库这方面的知识实在有限,只是相较于mysql觉得redis用得很是顺手与舒服,但是看到诸大牛者都只将redis用于临时存储。我不禁对于自己将redis当做主力数据库的做法感到紧张,虽还不至于遇到什么过不去的难题,但是为了现在做的项...
蛮大人123 2019-12-01 19:51:54 1208 浏览量 回答数 1

问题

redis 适合做一个小型网站的数据存储么?

小弟对于数据库这方面的知识实在有限,只是相较于mysql觉得redis用得很是顺手与舒服,但是看到诸大牛者都只将redis用于临时存储。我不禁对于自己将redis当做主力数据库的做法感到紧张,虽还不至于遇到什么过不去的难题,但是为了现在做的...
a123456678 2019-12-01 20:13:33 803 浏览量 回答数 1

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT 阿里云科技驱动中小企业数字化