• 关于

    mysql数据库大数据更新时间

    的搜索结果

回答

详细解答可以参考官方帮助文档 如果您初次使用阿里云关系型数据库 RDS,请参阅 阿里云关系型数据库 RDS 快速入门 系列文档,帮助您了解 RDS 并快速迁移本地数据库到 RDS 上。 My SQL快速入门 SQL Server快速入门 PostgreSQL快速入门 PPAS快速入门 数据库引擎 以下是对四种数据库引擎的介绍: 阿里云数据库 MySQL 版 MySQL 是全球最受欢迎的开源数据库,作为开源软件组合 LAMP(Linux + Apache + MySQL + Perl/PHP/Python)中的重要一环,广泛应用于各类应用。 Web2.0 时代,风靡全网的社区论坛软件系统 Discuz! 和博客平台 WordPress 均基于 MySQL 实现底层架构。Web3.0 时代,阿里巴巴、Facebook、Google 等大型互联网公司都采用更为灵活的 MySQL 构建了成熟的大规模数据库集群。 阿里云数据库 MySQL 版基于 Alibaba 的 MySQL 源码分支,经过双 11 高并发、大数据量的考验,拥有优良的性能和吞吐量。除此之外,阿里云数据库 MySQL 版还拥有经过优化的读写分离、数据压缩、智能调优等高级功能。 当前 RDS for MySQL 支持 5.5、5.6 和 5.7 版本。 阿里云数据库 SQL Server 版 SQL Server 是发行最早的商用数据库产品之一,作为 Windows 平台(IIS + .NET + SQL Server)中的重要一环,支撑着大量的企业应用。SQL Server 自带的 Management Studio 管理软件内置了大量图形工具和丰富的脚本编辑器。您通过可视化界面即可快速上手各种数据库操作。 阿里云数据库 SQL Server 版不仅拥有高可用架构和任意时间点的数据恢复功能,强力支撑各种企业应用,同时也包含了微软的 License 费用,您无需再额外支出 License 费用。 当前 RDS for SQL Server 支持以下版本: SQL Server 2008 R2 企业版 SQL Server 2012 Web版、标准版、企业版 SQL Server 2016 Web版、标准版、企业版 阿里云数据库 PostgreSQL 版 PostgreSQL 是全球最先进的开源数据库。作为学院派关系型数据库管理系统的鼻祖,它的优点主要集中在对 SQL 规范的完整实现以及丰富多样的数据类型支持,包括JSON 数据、IP 数据和几何数据等,而这些数据类型大部分商业数据库都不支持。 除了完美支持事务、子查询、多版本控制(MVCC)、数据完整性检查等特性外,阿里云数据库 PostgreSQL 版还集成了高可用和备份恢复等重要功能,减轻您的运维压力。 当前 RDS for PostgreSQL 支持 9.4/10 版本。 阿里云数据库 PPAS 版 PPAS(Postgres Plus Advanced Server)是一个稳定、安全且可扩展的企业级关系型数据库,基于全球最先进的开源数据库 PostgreSQL,并在性能、应用方案和兼容性等方面进行了增强,提供直接运行 Oracle 应用的能力。您可以在 PPAS 上稳定地运行各种企业应用,同时得到更高性价比的服务。 阿里云数据库 PPAS 版集成了账号管理、资源监控、备份恢复和安全控制等功能,并将持续地更新完善。 当前 RDS for PPAS 支持 9.3/10 版本。
2019-12-01 22:57:16 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 如果您初次使用阿里云关系型数据库 RDS,请参阅 阿里云关系型数据库 RDS 快速入门 系列文档,帮助您了解 RDS 并快速迁移本地数据库到 RDS 上。 My SQL快速入门 SQL Server快速入门 PostgreSQL快速入门 PPAS快速入门 数据库引擎 以下是对四种数据库引擎的介绍: 阿里云数据库 MySQL 版 MySQL 是全球最受欢迎的开源数据库,作为开源软件组合 LAMP(Linux + Apache + MySQL + Perl/PHP/Python)中的重要一环,广泛应用于各类应用。 Web2.0 时代,风靡全网的社区论坛软件系统 Discuz! 和博客平台 WordPress 均基于 MySQL 实现底层架构。Web3.0 时代,阿里巴巴、Facebook、Google 等大型互联网公司都采用更为灵活的 MySQL 构建了成熟的大规模数据库集群。 阿里云数据库 MySQL 版基于 Alibaba 的 MySQL 源码分支,经过双 11 高并发、大数据量的考验,拥有优良的性能和吞吐量。除此之外,阿里云数据库 MySQL 版还拥有经过优化的读写分离、数据压缩、智能调优等高级功能。 当前 RDS for MySQL 支持 5.5、5.6 和 5.7 版本。 阿里云数据库 SQL Server 版 SQL Server 是发行最早的商用数据库产品之一,作为 Windows 平台(IIS + .NET + SQL Server)中的重要一环,支撑着大量的企业应用。SQL Server 自带的 Management Studio 管理软件内置了大量图形工具和丰富的脚本编辑器。您通过可视化界面即可快速上手各种数据库操作。 阿里云数据库 SQL Server 版不仅拥有高可用架构和任意时间点的数据恢复功能,强力支撑各种企业应用,同时也包含了微软的 License 费用,您无需再额外支出 License 费用。 当前 RDS for SQL Server 支持以下版本: SQL Server 2008 R2 企业版 SQL Server 2012 Web版、标准版、企业版 SQL Server 2016 Web版、标准版、企业版 阿里云数据库 PostgreSQL 版 PostgreSQL 是全球最先进的开源数据库。作为学院派关系型数据库管理系统的鼻祖,它的优点主要集中在对 SQL 规范的完整实现以及丰富多样的数据类型支持,包括JSON 数据、IP 数据和几何数据等,而这些数据类型大部分商业数据库都不支持。 除了完美支持事务、子查询、多版本控制(MVCC)、数据完整性检查等特性外,阿里云数据库 PostgreSQL 版还集成了高可用和备份恢复等重要功能,减轻您的运维压力。 当前 RDS for PostgreSQL 支持 9.4/10 版本。 阿里云数据库 PPAS 版 PPAS(Postgres Plus Advanced Server)是一个稳定、安全且可扩展的企业级关系型数据库,基于全球最先进的开源数据库 PostgreSQL,并在性能、应用方案和兼容性等方面进行了增强,提供直接运行 Oracle 应用的能力。您可以在 PPAS 上稳定地运行各种企业应用,同时得到更高性价比的服务。 阿里云数据库 PPAS 版集成了账号管理、资源监控、备份恢复和安全控制等功能,并将持续地更新完善。 当前 RDS for PPAS 支持 9.3/10 版本。
2019-12-01 22:57:16 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 如果您初次使用阿里云关系型数据库 RDS,请参阅 阿里云关系型数据库 RDS 快速入门 系列文档,帮助您了解 RDS 并快速迁移本地数据库到 RDS 上。 My SQL快速入门 SQL Server快速入门 PostgreSQL快速入门 PPAS快速入门 数据库引擎 以下是对四种数据库引擎的介绍: 阿里云数据库 MySQL 版 MySQL 是全球最受欢迎的开源数据库,作为开源软件组合 LAMP(Linux + Apache + MySQL + Perl/PHP/Python)中的重要一环,广泛应用于各类应用。 Web2.0 时代,风靡全网的社区论坛软件系统 Discuz! 和博客平台 WordPress 均基于 MySQL 实现底层架构。Web3.0 时代,阿里巴巴、Facebook、Google 等大型互联网公司都采用更为灵活的 MySQL 构建了成熟的大规模数据库集群。 阿里云数据库 MySQL 版基于 Alibaba 的 MySQL 源码分支,经过双 11 高并发、大数据量的考验,拥有优良的性能和吞吐量。除此之外,阿里云数据库 MySQL 版还拥有经过优化的读写分离、数据压缩、智能调优等高级功能。 当前 RDS for MySQL 支持 5.5、5.6 和 5.7 版本。 阿里云数据库 SQL Server 版 SQL Server 是发行最早的商用数据库产品之一,作为 Windows 平台(IIS + .NET + SQL Server)中的重要一环,支撑着大量的企业应用。SQL Server 自带的 Management Studio 管理软件内置了大量图形工具和丰富的脚本编辑器。您通过可视化界面即可快速上手各种数据库操作。 阿里云数据库 SQL Server 版不仅拥有高可用架构和任意时间点的数据恢复功能,强力支撑各种企业应用,同时也包含了微软的 License 费用,您无需再额外支出 License 费用。 当前 RDS for SQL Server 支持以下版本: SQL Server 2008 R2 企业版 SQL Server 2012 Web版、标准版、企业版 SQL Server 2016 Web版、标准版、企业版 阿里云数据库 PostgreSQL 版 PostgreSQL 是全球最先进的开源数据库。作为学院派关系型数据库管理系统的鼻祖,它的优点主要集中在对 SQL 规范的完整实现以及丰富多样的数据类型支持,包括JSON 数据、IP 数据和几何数据等,而这些数据类型大部分商业数据库都不支持。 除了完美支持事务、子查询、多版本控制(MVCC)、数据完整性检查等特性外,阿里云数据库 PostgreSQL 版还集成了高可用和备份恢复等重要功能,减轻您的运维压力。 当前 RDS for PostgreSQL 支持 9.4/10 版本。 阿里云数据库 PPAS 版 PPAS(Postgres Plus Advanced Server)是一个稳定、安全且可扩展的企业级关系型数据库,基于全球最先进的开源数据库 PostgreSQL,并在性能、应用方案和兼容性等方面进行了增强,提供直接运行 Oracle 应用的能力。您可以在 PPAS 上稳定地运行各种企业应用,同时得到更高性价比的服务。 阿里云数据库 PPAS 版集成了账号管理、资源监控、备份恢复和安全控制等功能,并将持续地更新完善。 当前 RDS for PPAS 支持 9.3/10 版本。
2019-12-01 22:57:16 0 浏览量 回答数 0

Quick BI 数据可视化分析平台

2020年入选全球Gartner ABI魔力象限,为中国首个且唯一入选BI产品

回答

详细解答可以参考官方帮助文档 如果您初次使用阿里云关系型数据库 RDS,请参阅 阿里云关系型数据库 RDS 快速入门 系列文档,帮助您了解 RDS 并快速迁移本地数据库到 RDS 上。 My SQL快速入门 SQL Server快速入门 PostgreSQL快速入门 PPAS快速入门 数据库引擎 以下是对四种数据库引擎的介绍: 阿里云数据库 MySQL 版 MySQL 是全球最受欢迎的开源数据库,作为开源软件组合 LAMP(Linux + Apache + MySQL + Perl/PHP/Python)中的重要一环,广泛应用于各类应用。 Web2.0 时代,风靡全网的社区论坛软件系统 Discuz! 和博客平台 WordPress 均基于 MySQL 实现底层架构。Web3.0 时代,阿里巴巴、Facebook、Google 等大型互联网公司都采用更为灵活的 MySQL 构建了成熟的大规模数据库集群。 阿里云数据库 MySQL 版基于 Alibaba 的 MySQL 源码分支,经过双 11 高并发、大数据量的考验,拥有优良的性能和吞吐量。除此之外,阿里云数据库 MySQL 版还拥有经过优化的读写分离、数据压缩、智能调优等高级功能。 当前 RDS for MySQL 支持 5.5、5.6 和 5.7 版本。 阿里云数据库 SQL Server 版 SQL Server 是发行最早的商用数据库产品之一,作为 Windows 平台(IIS + .NET + SQL Server)中的重要一环,支撑着大量的企业应用。SQL Server 自带的 Management Studio 管理软件内置了大量图形工具和丰富的脚本编辑器。您通过可视化界面即可快速上手各种数据库操作。 阿里云数据库 SQL Server 版不仅拥有高可用架构和任意时间点的数据恢复功能,强力支撑各种企业应用,同时也包含了微软的 License 费用,您无需再额外支出 License 费用。 当前 RDS for SQL Server 支持以下版本: SQL Server 2008 R2 企业版 SQL Server 2012 Web版、标准版、企业版 SQL Server 2016 Web版、标准版、企业版 阿里云数据库 PostgreSQL 版 PostgreSQL 是全球最先进的开源数据库。作为学院派关系型数据库管理系统的鼻祖,它的优点主要集中在对 SQL 规范的完整实现以及丰富多样的数据类型支持,包括JSON 数据、IP 数据和几何数据等,而这些数据类型大部分商业数据库都不支持。 除了完美支持事务、子查询、多版本控制(MVCC)、数据完整性检查等特性外,阿里云数据库 PostgreSQL 版还集成了高可用和备份恢复等重要功能,减轻您的运维压力。 当前 RDS for PostgreSQL 支持 9.4/10 版本。 阿里云数据库 PPAS 版 PPAS(Postgres Plus Advanced Server)是一个稳定、安全且可扩展的企业级关系型数据库,基于全球最先进的开源数据库 PostgreSQL,并在性能、应用方案和兼容性等方面进行了增强,提供直接运行 Oracle 应用的能力。您可以在 PPAS 上稳定地运行各种企业应用,同时得到更高性价比的服务。 阿里云数据库 PPAS 版集成了账号管理、资源监控、备份恢复和安全控制等功能,并将持续地更新完善。 当前 RDS for PPAS 支持 9.3/10 版本。
2019-12-01 22:57:16 0 浏览量 回答数 0

问题

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

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

问题

用户指南-快速入门

如果您初次使用阿里云关系型数据库RDS,请参阅快速入门系列文档,帮助您快速上手RDS。 My SQL快速入门SQL Server快速入门PostgreSQL快速入门PPAS快速入门 数据库引擎 以下是对四...
李沃晟 2019-12-01 21:38:18 545 浏览量 回答数 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

回答

其实从去年已经隐隐约约感觉到数据库的有变化,只是没有想到变得这么快。今年的一些事情实实在在地给了某些数据库重击,如果以前去某数据库还是喊喊,然后该用还用,今年从传统领域刮起的去某数据库的风,已经开始了,并且后面的乌云密布也看得见。 最近看一篇国外的开源产品提供厂商的一篇文字,主要是在询问了他的几百位客户后得出了下图中的2019年数据库的使用趋势。 从图中可以看出,MySQL以38.9%的使用率高居榜首,其次是MongoDB(24.6%)、PostgreSQL(17.4%)、Redis(8.4%)和Cassandra(3.0%)。在这些数据库中,Oracle仅占1.8%,而CouchDB、Berkeley DB、Microsoft SQL Server、Redshift、Firebase、Elasticsearch 整合后的影响力和用户的总和仅为2.4%。 但该调查报告却与DB-engine排名趋势流行度报告大相径庭,Oracle数据库在此报告中排名第一,不过笔者认为,任何文字都是可能是偏颇或有倾向性的,每个人看完后都可能有自己的想法,或认同或反对,就如同最近最热的一句话“人心中的成见是一座大山,任你怎么努力休想搬动”。 MySQL 仍然是排名第一的免费开源数据库,占开源数据库使用量的 30% 以上。这并不奇怪,根据 DB-Engines,MySQL 多年来一直保持在这个位置。根据笔者多年来的从业经验,我认为MySQL数据库确实配得上这个排名,原因如下。 1.完全开源 MySQL最强大的优势之一在于他的数据库管理系统(DBMS,Database Management System)是一个开源系统。当然,开源并不意味着免费,它还是有许多付费功能。但是开源的特点给予用户可以根据自己需要修改DBMS的自由。 MySQL采用了GPL(General Public License),这意味着授权给用户可以阅读,修改和优化源代码,这样即使是免费版的MySQL的功能也足够强大。这也是MySQL如此受欢迎的原因之 一。 2.快速更新和用户友好 在其他数据库(例如Orcale、MSSQL Sever)更新缓慢的时候,MySQL很少让他的用户等待。每当新的版本出来之后,MySQL都会成为大多数服务器的主要数据库。Linux web服务器已经成为现在web服务器的主流,MySQL在linux服务器上面也得到了广泛的应用。 3.WebsitePanel,phpMyAdmin 和MySQl的黄金组合 对于初学者来说,通过虚拟主机商提供的websitepanel控制面板学习MySQL是一个很不错的方法。用户不仅可以观看很多视频教程来学习使用 MySQL,还可以使用PhpMyAdmin通过web方式管理数据库。 PostgreSQL 以 13.4% 的开源数据库用户比例位居第二,紧随其后的是 MongoDB,占 12.2%,位列第三。 如果你经常光顾某些网站,或者大型公众号,你应该知道今年最热的事情有两个,postgresql和大数据,今年算是postgresql在中国的开始发展的元年,知道的人和使用的人也越来越多。 根据DB-engine数据库流行榜发布的数据显示,Oracle与MySQL与去年相比都产生了一定的退步,唯独postgresql呈现上升趋势,比去年同月份提高了85.18%,这进一步说明数据库领域正在涌现出更多的新生力量,与之前将所有鸡蛋都放在一个篮子里的传统策略相比,IT行业的工作者正在使用多种数据库来支持他们的产品,多数据库类型的使用在过去10年出现了爆炸式增长。 在我们的调查中,几乎有一半实际上使用不止一种类型的数据库来支持他们的应用程序,而不是单个数据库,使用多个数据库的比例为44.3%,使用一个数据库的比例为55.7%,他们喜欢的数据库组合如下。 现在,让我们仔细研究一下在单个应用程序中最常用的数据库类型。 在下面的图表中,左边列中的数据库表示该数据库类型的样本量,上面列出的数据库表示与该数据库类型组合的百分比。蓝色显示的单元格表示 100% 的部署组合,而黄色表示 0% 的组合。 因此,如下面的数据库组合热图所示,MySQL 是我们与其他数据库类型结合最频繁的数据库。但是,虽然其他数据库类型经常与 MySQL 一起使用,但这并不意味着 MySQL 部署总是使用另一种数据库类型。这可以在 MySQL 的第一行看到,其颜色为浅蓝到黄色,相比之下,MySQL 第一列的颜色要和表示 100% 组合的蓝色的匹配度高许多。 用黑色边框突出显示的单元格表示仅利用这一种数据库类型的部署,其中仅使用 MySQL 的单元格占部署总数的 23%。 其实,这些数据也比较精准的反映了国内的情况,从2005年开始,IT企业在数据库的发展方向上就已经有了一些变化。 2007年开始阿里巴巴的IT开销史无前例,一度成为IBM、Oracle中国的标杆客户,淘宝、阿里巴巴B2B和支付宝等公司,98%以上的软件系统和业务都是采用Oracle数据库提供数据服务。2009年淘宝更是上了全球排名前几位的大RAC集群,据说当年有16个节点。每天早上CPU还是跑到98%。换句话来说,三年几千万买Oracle产品+服务也没办法支撑阿里成长的速度,只能开启自研模式,于是就有了Oracle全面转向MySQL的进程。 拆分Oracle数据库+Hadoop其实也可以撑一撑,但是这样的话,还要向Oracle购买更多的License(再花几千万,不是没钱,是即便花钱也不能彻底解决问题)。因此,阿里巴巴B2B将中文站压力和数据容量最大的Offer数据库,成功从Oracle数据库+IBM小型机+EMC2存储设备,迁移到MySQL数据库+PC Server的模式,所以淘宝2013年下线了最后一个Oracle,2014年支付宝交易替换了Oracle,2016年支付宝总账全面用OceanBase替换Oracle。 发展趋势: 1.“去Oracle化”。一方面是Oracle采用scale up而不是scale out的方案;另外一个重要原因是价格。网易和阿里巴巴都曾经以Oracle作为主要的数据库解决方案,投资几千万来采购License。阿里巴巴曾经还自称是互联网企业中Oracle的最大用户。Oracle最大的优势是运维简单,应用开发方便,但是和昂贵的价格相比,这一点不再具备吸引力。 2.优化MySQL数据库。这些互联网企业采用了大量的MySQL服务器集群,最大集群在150台服务器左右。承载了包括博客、电子商务等应用。采用的优化包括: 传统的SQL优化,如减少某个查询涉及到的列,控制索引数量等 闪存介质(SSD或者Flash卡)。这是几乎所有互联网企业都采用的方法,由于测试场景各不相同,因此没法比较谁家的方案更好。大体上分成直接使用闪存介质作为存储系统;优化闪存介质访问方式进一步优化 设计MySQL存储引擎 3.NoSQL数据库。NoSQL对应用养发提出了较高的要求,在项目中不是那么容易推广,一致性要求被放松,但是“原子性”支持需要被保证。一般是为了满足高并发需要才引入。如盛大采用MongoDB,淘宝自研了Tair数据库(已经开源) 4.分布式数据库。众所周知,使用不同的SQL优化与执行方式,数据库的访问性能可能会存在上千上万倍的差距。计算存储分离的核心思想便是在数据存储层面进行一体化存储,而计算层面则有效利用每种执行引擎的特点,针对不同的业务场景进行选择和优化。 所以,如果具有超强的研发团队和运维团队,在云时代还是有机会替代Oracle的,我们也看到伴随着人口红利,在软件开发领域的我国实力已今非昔比,大部分企业的 “去IOE”的进程更多的是自发的因系统架构优化而进行,同时各种数据库技术与产品也蓬勃发展,所以,在技术上看Oracle并非不能取代,更多的是出于综合成本(改造与建设成本、分享)的考量,需要的是时间和意志。 一千个人眼里就有一千个哈姆雷特,在每个开发者和企业的眼中,只有适合自己的数据库才是最好的。
问问小秘 2020-01-06 14:58:56 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 应用场景 在对数据库有少量写请求,但有大量读请求的应用场景下,单个实例可能无法抵抗读取压力,甚至对主业务产生影响。为了实现读取能力的弹性扩展,分担数据库压力,您可以在某个地域中创建一个或多个只读实例,利用只读实例满足大量的数据库读取需求,以此增加应用的吞吐量。 简介 创建只读实例相当于复制了一个主实例,数据与主实例一致,主实例的数据更新也会通过MySQL的原生复制功能自动同步到所有只读实例。网络类型不同的主实例和只读实例之间也可以进行数据同步。只读实例跟主实例在同一地域,但可以在不同的可用区。只读实例拓扑图如下图所示: 注意 目前,云数据库RDS的以下版本支持只读实例:MySQL 5.6、MySQL 5.7(不包括MySQL 5.7基础版)。 只读实例为单个物理节点的架构(没有备节点)。 计费标准 只读实例需要额外收费,其计费方式是按时付费,费用详情请参见云数据库RDS详细价格信息中的只读实例部分。 功能特点 规格可以与主实例不一致,并可以随时更改规格(没有时间限制),便于弹性升降级。 支持按时计费,使用更灵活,费用更便宜。 不需要维护账号与数据库,全部通过主实例同步。 具有独立的白名单配置。 提供近20个系统性能指标的监控视图,如磁盘容量、IOPS、连接数、CPU利用率、网络流量等。 提供多种优化建议,如存储引擎检查、主键检查、大表检查、索引偏多、缺失索引等,用户可以根据优化建议并结合自身的应用特点来对数据库进行优化。 功能限制 只读实例有如下功能限制: 如果主实例规格内存大于等于64G,则最多允许创建10个只读实例。 如果主实例规格内存小于64G,则最多允许创建5个只读实例。 备份设置:不支持备份设置以及临时备份。 实例恢复: 不支持通过备份文件或任意时间点创建临时实例,不支持通过备份集覆盖实例。 创建只读实例后,主实例将不支持通过备份集直接覆盖实例来恢复数据。 数据迁移:不支持将数据迁移至只读实例。 数据库管理:不支持创建和删除数据库。 账号管理:不支持创建和删除账号,不支持为账号授权以及修改账号密码功能。
2019-12-01 22:57:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 应用场景 在对数据库有少量写请求,但有大量读请求的应用场景下,单个实例可能无法抵抗读取压力,甚至对主业务产生影响。为了实现读取能力的弹性扩展,分担数据库压力,您可以在某个地域中创建一个或多个只读实例,利用只读实例满足大量的数据库读取需求,以此增加应用的吞吐量。 简介 创建只读实例相当于复制了一个主实例,数据与主实例一致,主实例的数据更新也会通过MySQL的原生复制功能自动同步到所有只读实例。网络类型不同的主实例和只读实例之间也可以进行数据同步。只读实例跟主实例在同一地域,但可以在不同的可用区。只读实例拓扑图如下图所示: 注意 目前,云数据库RDS的以下版本支持只读实例:MySQL 5.6、MySQL 5.7(不包括MySQL 5.7基础版)。 只读实例为单个物理节点的架构(没有备节点)。 计费标准 只读实例需要额外收费,其计费方式是按时付费,费用详情请参见云数据库RDS详细价格信息中的只读实例部分。 功能特点 规格可以与主实例不一致,并可以随时更改规格(没有时间限制),便于弹性升降级。 支持按时计费,使用更灵活,费用更便宜。 不需要维护账号与数据库,全部通过主实例同步。 具有独立的白名单配置。 提供近20个系统性能指标的监控视图,如磁盘容量、IOPS、连接数、CPU利用率、网络流量等。 提供多种优化建议,如存储引擎检查、主键检查、大表检查、索引偏多、缺失索引等,用户可以根据优化建议并结合自身的应用特点来对数据库进行优化。 功能限制 只读实例有如下功能限制: 如果主实例规格内存大于等于64G,则最多允许创建10个只读实例。 如果主实例规格内存小于64G,则最多允许创建5个只读实例。 备份设置:不支持备份设置以及临时备份。 实例恢复: 不支持通过备份文件或任意时间点创建临时实例,不支持通过备份集覆盖实例。 创建只读实例后,主实例将不支持通过备份集直接覆盖实例来恢复数据。 数据迁移:不支持将数据迁移至只读实例。 数据库管理:不支持创建和删除数据库。 账号管理:不支持创建和删除账号,不支持为账号授权以及修改账号密码功能。
2019-12-01 22:57:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 应用场景 在对数据库有少量写请求,但有大量读请求的应用场景下,单个实例可能无法抵抗读取压力,甚至对主业务产生影响。为了实现读取能力的弹性扩展,分担数据库压力,您可以在某个地域中创建一个或多个只读实例,利用只读实例满足大量的数据库读取需求,以此增加应用的吞吐量。 简介 创建只读实例相当于复制了一个主实例,数据与主实例一致,主实例的数据更新也会通过MySQL的原生复制功能自动同步到所有只读实例。网络类型不同的主实例和只读实例之间也可以进行数据同步。只读实例跟主实例在同一地域,但可以在不同的可用区。只读实例拓扑图如下图所示: 注意 目前,云数据库RDS的以下版本支持只读实例:MySQL 5.6、MySQL 5.7(不包括MySQL 5.7基础版)。 只读实例为单个物理节点的架构(没有备节点)。 计费标准 只读实例需要额外收费,其计费方式是按时付费,费用详情请参见云数据库RDS详细价格信息中的只读实例部分。 功能特点 规格可以与主实例不一致,并可以随时更改规格(没有时间限制),便于弹性升降级。 支持按时计费,使用更灵活,费用更便宜。 不需要维护账号与数据库,全部通过主实例同步。 具有独立的白名单配置。 提供近20个系统性能指标的监控视图,如磁盘容量、IOPS、连接数、CPU利用率、网络流量等。 提供多种优化建议,如存储引擎检查、主键检查、大表检查、索引偏多、缺失索引等,用户可以根据优化建议并结合自身的应用特点来对数据库进行优化。 功能限制 只读实例有如下功能限制: 如果主实例规格内存大于等于64G,则最多允许创建10个只读实例。 如果主实例规格内存小于64G,则最多允许创建5个只读实例。 备份设置:不支持备份设置以及临时备份。 实例恢复: 不支持通过备份文件或任意时间点创建临时实例,不支持通过备份集覆盖实例。 创建只读实例后,主实例将不支持通过备份集直接覆盖实例来恢复数据。 数据迁移:不支持将数据迁移至只读实例。 数据库管理:不支持创建和删除数据库。 账号管理:不支持创建和删除账号,不支持为账号授权以及修改账号密码功能。
2019-12-01 22:57:10 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

问题

DB-Engines 2020年1月全球数据库排行榜

DB-Engines 2020年1月全球数据库排行榜出炉! 首先来看一下2019年全球最受欢迎数据库 MySQL夺冠 全球知名的数据库流行度排行榜网站DB-Engines 宣布,在过去的一年里,...
茶什i 2020-01-07 14:04:00 297 浏览量 回答数 1

问题

2018MySQL技术问答集锦,希望能给喜欢MySQL的同学一些帮助

小编发现问答专区中有很多人在问关于mysql的问题,小编把这些问题汇总一下,希望能给喜欢mysql的大家一些启示和帮助本帖不定期更新,喜欢的可以收藏哦如何搭建MySQL集群?https://yq.aliyun.com/ask/482768m...
技术小能手 2019-12-01 19:31:11 1856 浏览量 回答数 0

问题

【每日一题】Java知识大测验 | 持续更新

每天更新一题 让大家在休息时间可以轻松学习! 下面是关于JAVA的题目,每日更新~ (PS:大家要看清题号,需要答案的同学可以看下方留言) 1-24题链接 93--题链接 92...
游客ih62co2qqq5ww 2020-03-27 23:52:17 473 浏览量 回答数 1

回答

使用mysqldump工具的优点是简单易用、容易上手,缺点是停机时间较长,因此它适用于数据量不大,或者允许停机的时间较长的情况。 背景信息 由于RDS提供的关系型数据库服务与原生的数据库服务完全兼容,所以对用户来说,将原有数据库迁移到RDS实例的过程,与从一台MySQL服务器迁移到另外一台MySQL服务器的过程基本类似。 注意事项 迁移后的表不区分大小写,统一变为小写。 前提条件 已对RDS实例设置白名单,申请外网地址,以及创建数据库和账号。具体可参见快速入门。 已购买云服务器 ECS。 操作步骤 在正式迁移之前,需要先在本地数据库中创建迁移账号,并将要迁移的数据库的读写权限授权给迁移账号。 在本地数据库中创建迁移账号。 CREATE USER'username'@'host' IDENTIFIED BY 'password'; 参数说明: username:要创建的账号 host:指定该账号登录数据库的主机。如果是本地用户可以使用 localhost,如果想让该用户从任意主机登录,可以使用通配符 % password:该账号的登录密码 例:要创建账号为 William,密码为 Changme123 的账号从任意主机登录本地数据库,命令如下: CREATE USER'William'@'%' IDENTIFIED BY 'Changme123'; 在本地数据库中给迁移账号授权。 GRANT SELECT ON databasename.tablename TO 'username'@'host' WITH GRANT OPTION; GRANT REPLICATION SLAVE ON databasename.tablename TO 'username'@'host' WITH GRANT OPTION; 参数说明: privileges:该账号的操作权限,如 SELECT、INSERT、UPDATE 等。如果要授权该账号所有权限,则使用 ALL databasename:数据库名。如果要授权该账号所有的数据库权限,则使用通配符 * tablename:表名。如果要授权该账号所有的表权限,则使用通配符 * username:要授权的账号名 host:授权登录数据库的主机名。如果是本地用户可以使用 localhost,如果想让该用户从任意主机登录,可以使用通配符 % WITH GRANT OPTION:授权该账号能使用GRANT命令,该参数为可选 例:授权账号William对所有数据库和表的所有权限,并可以从任意主机登录本地数据库,命令如下。 GRANT ALL ON*.* TO 'William'@'%'; 使用 mysqldump 的数据导出工具,将本地数据库数据导出为数据文件。 说明 导出期间请勿进行数据更新。本步骤仅仅导出数据,不包括存储过程、触发器及函数。 mysqldump -h localIp -u userName -p --opt --default-character-set=utf8 --hex-blob dbName --skip-triggers --skip-lock-tables > /tmp/dbName.sql 参数说明: localIp:本地数据库服务器 IP 地址 userName:本地数据库的迁移账号 dbName:需要迁移的数据库名 /tmp/dbName.sql:备份生成的文件名 使用 mysqldump 导出存储过程、触发器和函数。 说明 若数据库中没有使用存储过程、触发器和函数,可跳过此步骤。在导出存储过程、触发器和函数时,需要将 definer 去掉,以兼容 RDS。 mysqldump -h localIp -u userName -p --opt --default-character-set=utf8 --hex-blob dbName -R | sed -e 's/DEFINER[ ]=[ ][^*]**/*/' > /tmp/triggerProcedure.sql 参数说明: localIp:本地数据库服务器 IP 地址 userName:本地数据库的迁移账号 dbName:需要迁移的数据库名 /tmp/triggerProcedure.sql:备份生成的文件名 将数据文件和存储过程文件上传到 ECS 上。 本例以文件上传到如下路径为例。 /tmp/dbName.sql /tmp/triggerProcedure.sql 登录 ECS,将数据文件和存储过程文件导入到目标 RDS 中。 mysql -h intranet4example.mysql.rds.aliyuncs.com –u userName -p dbName < /tmp/dbName.sql mysql -h intranet4example.mysql.rds.aliyuncs.com -u userName -p dbName < /tmp/triggerProcedure.sql 参数说明: intranet4example.mysql.rds.aliyuncs.com:RDS实例连接地址,本例以内网地址为例 userName:RDS数据库的迁移账号 dbName:需要导入的数据库名 /tmp/dbName.sql:要导入的数据文件名 /tmp/triggerProcedure.sql:要导入的存储过程文件名 常见问题 Q:mysqldump迁移复杂,有简单的方法吗? A:您可以使用DTS从自建MySQL迁移至RDS for MySQL。
游客yl2rjx5yxwcam 2020-03-08 16:35:05 0 浏览量 回答数 0

回答

优化大致可以分为以下方面,按照执行难易程度和对当前项目影响排序:MySQL参数优化:可以通过show variables;命令和show status;命令组合来综合分析,可调整的项目根据使用的存储引擎和项目瓶颈具体情况千差万别,需要具体问题具体分析,如果想从这方面入手,建议把问题提得更具体一点;SQL查询优化和索引优化:你可以打开慢日志记录,将需要消耗太多时间的查询记录下来,然后分析相应的SQL语句是否写的不合理,不合理就改了;再到数据库中查表结构,看是否索引设置不合理(一般where语句中的常用字段和排序字段应该加上合适的索引);增加缓存层:可考虑在MySQL与应用层中间加一个缓存层,如APC、Memcached、Redis等等,将经常使用而更新较少的数据放到缓存层中,可以很好的减轻数据库压力;优化表结构:首先这个代价稍大,可能要重新灌数据之类的,代码修改可能也会比较多,看之前的封装性好不好了。主要是根据业务需要,看是否之前的表结构有不合理的地方,比如你使用了很多但是又无法排除的join查询;分库、分表、主从分离:分库是把数据库从1个逻辑库拆分到多个逻辑库,或从1个服务器拆分到多个服务器,分表是将一个表拆分为多个表,甚至是多个物理服务器的不同表;主从分离是将读、写完全分离到不同的数据库服务器;这个方案跟4一样,也是代价比较大,但是可持续性很好,项目到达一定的数量级,必须走这一步;自己定制MySQL:开源的,可以根据自己特殊业务需要定制,太高端了点点,总之有这种可能,没搞过...
西秦说云 2019-12-02 01:33:16 0 浏览量 回答数 0

问题

解决AMH面板环境mysql-bin数据库日志文件占用硬盘资源(转自老左博客)

如果我们有在使用AMH面板或者LNMP一键安装包环境的时候,都会有遇到这样的问题。大部分新手用户可能会在安装好环境之后直接用官方给予的一键包命令安装后就开始建站。但是,随着时间的推移,部分用户会在某...
牛太浪 2019-12-01 21:12:39 7565 浏览量 回答数 4

问题

使用MySQL储存用户历史数据

使用MySQL储存用户数据。目前想增加一个功能:显示用户在过去7天的服务器使用量。目前,数据库中和该功能相关的Columns有两个:usedTraffic (int) 储存用户已经使用服务量。allTraffic (int) 储存用户能够使...
蛮大人123 2019-12-01 19:50:12 1441 浏览量 回答数 1

回答

如果您是使用阿里云的rds服务,你可以通过操作恢复到任意时间节点数据。以下是帮助文档说明教程>> 提示:这篇文档是由阿里云售后支持团队针对特定或紧急问题提供的“快速发布”文档。文档的内容以原稿呈现,未进行编辑及审核。因此,阿里云对于文档内容不做任何承诺, 并且,我们有权在未经通知您的情形下对文档内容做出编辑、修改或提供补充信息。 问题症状 数据误删除或由于账号安全等因素影响用户数据库内出现大量数据丢失。 问题原因 在指定账号权限下由于流程审核不严谨导致线上环境误操作。 数据库账户管理相关安全意识不足导致数据库账户权限出现泄露或白名单未精细化授权IP管理等因素造成用户数据篡改或丢失。 解决方案 注意:基于任意时间点的数据备份恢复,需要还原窗口时间点内保留了连续的binlog日志及对应备份集。如果日志未做备份保留仅仅能恢复至对应备份集时间点。 binlog日志保留设置:进入控制台实例详情页面,“备份恢复”->“备份设置”中[日志备份]开启同时设置[日志备份保留]天数,默认7天或者设置其他天数。 基于任意时间点恢复方法(RDS-MySQL Version5.6为例) 通过创建克隆实例将数据恢复至备份保留期限内任意时间点。 请参考:克隆实例 备注:创建克隆实例还原方式选择”按时间点”方式指定备份日志保留窗口内的时间。 通过克隆实例恢复到主实例 请参考:通过克隆实例恢复到主实例 备注:在文档第12步中选择迁移类型时您可以根据恢复的目标对象范围选择库、表不同级别粒度对象恢复。 补充建议: 数据库用户权限管理过程中尽量保持用户权限最小化授权,防止权限过大导致线上数据维护过程中误操作数据。 保持定期更新数据库账号密码或账户密码最小化传播。 数据库白名单尽量设置精细化IP地址,尽量减少IP段授权,同时生产环境杜绝使用0.0.0.0/0。
51干警网 2019-12-02 00:36:26 0 浏览量 回答数 0

问题

对比ECS自建数据库与RDS性能时的注意事项

适用场景 测试ECS自建数据库库与云数据库RDS的性能差异。 背景信息 很多用户都会对比ECS自建数据库与云数据库RDS的性能,但在测试两种数据库的性能时,不仅需要保证二者处于相同的环境下࿰...
云栖大讲堂 2019-12-01 21:42:55 1114 浏览量 回答数 0

回答

canal原理 binlog介绍 binlog是Mysql sever层维护的一种二进制日志,与innodb引擎中的redo/undo log是完全不同的日志;其主要是用来记录对mysql数据更新或潜在发生更新的SQL语句,并以"事务"的形式保存在磁盘中;Mysql binlog日志有ROW,Statement,MiXED三种格式: Row: 仅保存记录被修改细节,不记录sql语句上下文相关信息优点:能非常清晰的记录下每行数据的修改细节,不需要记录上下文相关信息。由于所有的执行的语句在日志中都将以每行记录的修改细节来记录,因此,可能会产生大量的日志内容。 Statement: 每一条会修改数据的sql都会记录在binlog中优点:只需要记录执行语句的细节和上下文环境,避免了记录每一行的变化。但是存在某些函数和存储过程不一定能够保证在slave上和master上执行结果一致。 Mixed:以上两种格式的结合。不过,新版本的MySQL对row level模式也被做了优化,并不是所有的修改都会以row level来记录,像遇到表结构变更的时候就会以statement模式来记录,如果sql语句确实就是update或者delete等修改数据的语句,那么还是会记录所有行的变更;因此,现在一般使用row level即可。 通过变量binlog_format查看当前binlog格式: binlog的位置由文件和文件的相对位置唯一确定,我们可以通过命令行查询binlog的内容: 数据库的主从复制是binlog的用途之一,其原理为: MySQL master 将数据变更写入二进制日志 MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log) MySQL slave 重放 relay log 中事件,将数据变更反映它自己的数据 canal简介 作为阿里巴巴的一个开源项目,canal 不仅在公司内部经受了跨集群、跨国同步的考验,而且已经在很多大型的互联网公司比如美团等都有广泛的应用。 canal是通过模拟成为mysql 的slave的方式,监听mysql 的binlog日志来获取数据并转存到不同的目的地(destination)。 canal架构 canal server是canal的基本部署实例,在实现上一个canal server 部署实例由多个binlog数据通道实例组成的。canal server就是一个jvm运行实例, binlog数据通道实例由Parser、Sink和store模块组成,完成binlog的解析、过滤和存储一整条链路功能。跟binlog数据通道的关系为: 其中数据通道实例的逻辑拓扑结构可表示为: canal部署 数据通道实例默认跟数据库实例一一对应,每个通道实例在部署上有自己独立的属性配置目录,目录里面维护两类配置文件: -instance.properties:配置数据库的连接信息和过滤配置等信息 canal.properties:作为所有数据通道的公共部分,用于配置全局性的信息,如mq地址、zk地址以及cannal server运行时参数等 canal server负责本实例上的所有数据通道的可用性,采用pull的消费模型供canal客户端读取消息。在部署上面,可以单独部署,在生产环境上,建议采用HA高可用部署方案: 大致步骤为: canal server要启动某个canal instance时都先向zookeeper进行一次尝试启动判断 (实现:创建EPHEMERAL节点,谁创建成功就允许谁启动) 创建zookeeper节点成功后,对应的canal server就启动对应的canal instance,没有创建成功的canal instance就会处于standby状态 一旦zookeeper发现canal server A创建的节点消失后,立即通知其他的canal server再次进行步骤1的操作,重新选出一个canal server启动instance. canal client每次进行connect时,会首先向zookeeper询问当前是谁启动了canal instance,然后和其建立链接,一旦链接不可用,会重新尝试connect. 通过合理配置数据通道的备份数量,可以实现canal server集群的高可用和部分负载均衡功能,canal在zk集群的注册信息结构为: 了解了canal的基本原理和部署方式之后,再来看看如何基于canal设计数据同步架构。 总体流程 canal server:通过binlog通讯协议拉取mysql 服务器的日志,完成解析并存储到消息系统kafka,canal client消费kafka数据写入s3包括合并和去重,结果数据以分区形式加载到hive表。涉及到的主要功能组件: mysql :需要同步的mysql服务器,对于开启gtid的阿里云 rds,因为slave binlog数据格式是经过简化的,同步的mysql服务器需要选择mysql master,对于aws rdb数据库,暂没有此要求,可以使用mysql slave。 canal server:拉取并解析mysql binlog日志,并封装成易于下游模块使用的数据结构。canal server实例是部署的基本单元,对一个数据库实例可以根据要求的可用性级别部署一个或多个canal server,如果一个数据库实例对应有多个canal server实例,因为同一个mysql同步部署单元中只能有一个主canal实例处于Active状态,于是在多canal实例的情况下需要借助zookeeper选主。 kafka:canal server将解析后的binlog数据发送到配置的kafka topic,canal server支持将同一个mysql实例的所有binlog发送到同一个topic、多个分表发送到一个topic以及每个表到独立的topic等。 canal client:拉取kafka topic数据,根据topic数据大小进行数据的并行消费、合并、排序和去重等功能。canal client可以作为常驻进程托管到实时流系统比如spark streaming、flink等,也可以是作为批处理任务托管到离线调度系统。 s3: kafka消费后的数据暂存外部系统,可以是aws的s3或者hdfs、甚至是本地文件系统等,根据使用使用环境和可用性要求选取。 hive:mysql增量数据导入到hive分区表,表结构根据mysql表的schema 自动创建。 数据消费 canal 的EventStore基于本地内存存储实现,数据的存储、读取和ack采用类似Disruptor的RingBuffer的实现思路: RingBuffer定义了3个cursor: Put : Sink模块进行数据存储的最后一次写入位置 Get : 数据订阅获取的最后一次提取位置 Ack : 数据消费成功的最后一次消费位置 canal客户端在数据消费支持并行消费、批量消费和异步消费,增大消费处理能力。 上面示例代码演示了一个从canal server集群中循环拉取消息的过程:首先设置canal server的zk地址和destination(对应一个canal server)以及订阅的库表(可以通过filter可以对destination进一步过滤筛选)等信息,然后通过调用getWithoutAck方法批量读取,如果读取并且处理没有异常抛出,就可以通过ack确认进行下一批次读取。通过这种读取canal server数据并实时消费的方式在普通场景下是可行的,但在生产环境中更适合结合kafka,下文详述。 kafka 在简单的数据同步场景,可以按照上面实现自己的canal客户端直接读取canal server的数据,但是对于生产环境使用场景,因为binlog的存储时间有限(比如阿里云rds数据库默认保存18小时),为防止数据不可用以及对于需要重复消费等场景,有必要将数据存储到第三方消息系统,如kafka或者rocketmq。在canal中,可以直接配置canal消息转存到kafka和rocketmq这两个消息系统,并可以自定义配置投递到topic的规则。如果topic存在多个分区,还可以指定数据在分区之间的路由方式,以kafka为例: 我们只关注supplier.sku_link_rel表的binlog,发送到topic为supplier.sku_link_rel中,并且设置根据表的主键id在6个分区中路由。同时忽略系统库mysql的消息,减少不必要的数据传输。对于分表的方式,还可以将多个分表的数据合并到同一个topic: 示例中,将名字以sale_order_line开头的表的数据合并到topic:order_center.sale_order_line,注意其中topic路由方式按照表的主键$pk
游客2q7uranxketok 2021-02-05 14:41:30 0 浏览量 回答数 0

回答

转自:阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问: 谁选型?是负责采购的同学、 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,但我在这里也遇到类似情况。每个数据库都有一个版本表,该表包含版本(简单地是一个整数)和该版本中已更改内容的简短注释。我使用脚本来更新数据库。每个数据库更改都可以在一个功能中进行,有时一个更改是由多个功能进行的。函数在函数名称中包含版本号。该脚本在数据库中查找最高版本号,并且仅按顺序应用具有较高版本号的功能。 这样可以轻松地更新数据库(只需添加新的更改功能),并允许我在必要时快速升级恢复的数据库(只需再次运行脚本)。 即使在此之前测试更改,也可以进行防御性更改。如果您在桌子上做了一些大的改动并且想要安全地玩: def change103(...): "Create new table." def change104(...): """Transfer data from old table to new table and make complicated changes in the process. """ def change105(...): "Drop old table" def change106(...): "Rename new table to old table" 如果change104()中出现问题(并引发异常),则可以简单地从新表中删除已转换的数据,修复更改函数并再次运行脚本。 但是我不认为在客户端连接时动态更改数据库是一个好主意。有时更改可能需要一些时间。并且访问数据库的软件应与数据库的架构匹配。您可以通过某种方式使它们保持同步。也许您可以分发新的软件版本,然后在客户端实际开始使用此新软件时要升级数据库。但是我还没有尝试过。
保持可爱mmm 2019-12-02 03:17:29 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档本小节介绍如何使用数据传输服务快速创建两个 RDS for MySQL 实例之间的实时同步作业,实现 RDS for MySQL 增量数据的实时同步。 支持功能 支持阿里云账号下两个 RDS for MySQL 实例间的实时同步。支持不同阿里云账号下的 RDS for MySQL 实例间的实时同步。暂不支持不同阿里云账号下的 RDS for MySQL 实例间的双向同步,具体支持时间将另行通知。 同步限制数据源 目前实时同步只能支持 RDS for MySQL 实例,暂不支持其他数据源类型。目标实例不支持访问模式为标准模式且只有外网连接地址的 RDS for MySQL 实例。不支持香港可用区 A 的 RDS for MySQL 实例的实时同步。对于 rename table tbl_name to new_tbl_name、create table tbl_name like new_tbl_name、 create…select…from new_tbl_name、alter table tbl_name rename to new_tbl_name,如果 new_tbl_name 不在指定的同步对象中,则不支持对此 DDL 进行复制。 同步架构目前数据传输服务提供的实时同步功能支持的同步架构有限,其仅能支持如下架构: A->B 即两个实例之间的单向同步。且要求实例 B 中同步的对象必须为只读,否则会导致同步链路异常,出现数据不一致的情况。 A->B/C/D 即一对多的分发式同步架构,这个架构对目标 RDS for MySQL 实例个数没有限制,但是要求目标实例中的同步对象必须为只读,否则会导致同步链路异常,出现数据不一致的情况。 B/C/D->A 即多对一的数据汇总架构。对于这种多对一的同步架构,为了保证同步数据一致性,要求每条同步链路同步的对象不相同。 A->B->C 即级联架构。 A->B->A 即实例A和实例B之间的双向同步架构。 注意:如果需要使用双向同步,需要在购买同步链路时,选择双向同步,并在 数据传输 DTS 控制台 中根据指引进行配置。 如果用户配置同步链路过程中,配置不在上述支持范围内的的同步架构,那么预检查中的复杂拓扑检查项会检查失败。 功能限制 不兼容触发器 如果同步对象为整个库且这个库中包含了会更新同步表内容的触发器,会导致同步数据不一致。 例如同步库为A,这个库中存在了两个表 A, B。表 A 上有一个触发器,触发器内容为在 insert 一条数据到表 A 之后,在表 B 中插入一条数据。这种情况下,在同步过程中,如果源实例有表 A 上的 insert 操作,就会导致表 B 在源实例跟目标实例数据不一致。 为了解决这个问题,只能将目标实例中的对应触发器删除掉。表 B 的数据由源实例同步过去。具体解决方案详见最佳实践中的,触发器存在情况下如何配置同步链路。 rename table 限制 rename table 操作需要满足限制条件方可正常同步,否则会导致同步数据不一致。例如同步对象只包含表 A,不包含表 B,如果同步过程中源实例执行了 rename A to B 的操作,那么改名后的表 B 的操作不会被同步到目标库。为了解决这个问题,可以选择同步表 A、B 对应的整个数据库。 准备事项在配置同步作业前,要确保同步作业的源及目标RDS实例都已经存在。如果不存在,那么请先购买RDS实例 购买 RDS 实例。 配置步骤下面我们详细介绍下创建任意两个 RDS 实例之间的同步链路的具体步骤。 购买同步链路。 进入数据传输 DTS 控制台,进入数据同步页面,点击控制台右上角 “创建同步作业” 开始作业配置。 在链路配置之前需要购买一个同步链路。同步链路目前支持包年包月及按量付费两种付费模式,可以根据需要选择不同的付费模式。 在购买页面需要配置的参数包括: 源地域 源地域为同步链路源实例所在地域。 目标地域 目标地域为同步链路目标实例所在地域。 实例规格 实例规格影响了链路的同步性能,实例规格跟性能之间的对应关系详见 数据同步规格说明。 数量 数量为一次性购买的同步链路的数量,如果购买的是按量付费实例,一次最多购买 99 条链路。 当购买完同步实例,返回数据传输控制台,点击新购链路右侧的“配置同步作业” 开始链路配置。 同步链路连接信息配置。 在这一步主要配置: 同步作业名称 同步作业名称没有唯一性要求,主要为了更方便识别具体的作业,建议选择一个有业务意义的作业名称,方便后续的链路查找及管理。 同步链路的 RDS 实例 ID 源跟目标 RDS 实例必须为两个不同的实例,选择 RDS 实例 ID 时,下拉菜单中只列出对应阿里云账号下的 RDS for MySQL 实例。 当这些内容配置完成后,可以点击授权白名单并进入下一步。 授权RDS实例白名单。 这个步骤,主要是将数据传输服务器 IP 添加到同步 RDS 实例的白名单中。避免因为 RDS 设置了白名单,数据传输服务器连接不上 RDS 导致同步作业创建失败。 为了保证同步作业的稳定性,在同步过程中,请勿将这些服务器 IP 从 RDS 实例的白名单中删除。 当白名单授权后,点击下一步,进入同步账号创建。 创建目标库上的同步账号。 这个步骤主要是在目标 RDS 实例上创建一个同步账号,账号名字为:dtssyncwriter,在同步过程中,不能删除这个账号,否则会导致同步链路中断。 选择同步对象。 当创建完目标 RDS 实例的同步账号后,即进入同步对象的选择步骤。实时同步的同步对象的选择粒度可以支持到表级别,即用户可以选择同步某些库或是同步某几张表。 如果选择的同步对象为整个库,那么这个库中所有对象的结构变更操作(例如 create table,drop view 等),都会同步到目标库。 如果选择的某张表,那么只有这个表的 drop/alter/truncate/rename table,create/drop index 的操作会同步到目标库。 当配置完同步对象后,进入同步初始化配置。 同步初始化配置。 同步初始化配置,初始化是同步链路启动的第一步,它会将源实例中已经存在同步对象的结构及数据在目标实例中初始化,作为后续增量同步数据的基线数据。 同步初始化类型细分为:结构初始化,全量数据初始化。默认情况下,需要选择结构初始化及全量初始化。 预检查。 当上面所有选项配置完成后,即进入启动之前的预检查。 当同步作业配置完成后,数据传输服务会进行限制预检查,当预检查通过后,可以点击 启动 按钮,启动同步作业。 当同步作业启动之后,即进入同步作业列表。此时刚启动的作业处于同步初始化状态。初始化的时间长度依赖于源实例中同步对象的数据量大小。当初始化完成后同步链路即进入同步中的状态,此时源跟目标实例的同步链路才真正建立完成。
2019-12-01 23:09:47 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档本小节介绍如何使用数据传输服务快速创建两个 RDS for MySQL 实例之间的实时同步作业,实现 RDS for MySQL 增量数据的实时同步。 支持功能 支持阿里云账号下两个 RDS for MySQL 实例间的实时同步。支持不同阿里云账号下的 RDS for MySQL 实例间的实时同步。暂不支持不同阿里云账号下的 RDS for MySQL 实例间的双向同步,具体支持时间将另行通知。 同步限制数据源 目前实时同步只能支持 RDS for MySQL 实例,暂不支持其他数据源类型。目标实例不支持访问模式为标准模式且只有外网连接地址的 RDS for MySQL 实例。不支持香港可用区 A 的 RDS for MySQL 实例的实时同步。对于 rename table tbl_name to new_tbl_name、create table tbl_name like new_tbl_name、 create…select…from new_tbl_name、alter table tbl_name rename to new_tbl_name,如果 new_tbl_name 不在指定的同步对象中,则不支持对此 DDL 进行复制。 同步架构目前数据传输服务提供的实时同步功能支持的同步架构有限,其仅能支持如下架构: A->B 即两个实例之间的单向同步。且要求实例 B 中同步的对象必须为只读,否则会导致同步链路异常,出现数据不一致的情况。 A->B/C/D 即一对多的分发式同步架构,这个架构对目标 RDS for MySQL 实例个数没有限制,但是要求目标实例中的同步对象必须为只读,否则会导致同步链路异常,出现数据不一致的情况。 B/C/D->A 即多对一的数据汇总架构。对于这种多对一的同步架构,为了保证同步数据一致性,要求每条同步链路同步的对象不相同。 A->B->C 即级联架构。 A->B->A 即实例A和实例B之间的双向同步架构。 注意:如果需要使用双向同步,需要在购买同步链路时,选择双向同步,并在 数据传输 DTS 控制台 中根据指引进行配置。 如果用户配置同步链路过程中,配置不在上述支持范围内的的同步架构,那么预检查中的复杂拓扑检查项会检查失败。 功能限制 不兼容触发器 如果同步对象为整个库且这个库中包含了会更新同步表内容的触发器,会导致同步数据不一致。 例如同步库为A,这个库中存在了两个表 A, B。表 A 上有一个触发器,触发器内容为在 insert 一条数据到表 A 之后,在表 B 中插入一条数据。这种情况下,在同步过程中,如果源实例有表 A 上的 insert 操作,就会导致表 B 在源实例跟目标实例数据不一致。 为了解决这个问题,只能将目标实例中的对应触发器删除掉。表 B 的数据由源实例同步过去。具体解决方案详见最佳实践中的,触发器存在情况下如何配置同步链路。 rename table 限制 rename table 操作需要满足限制条件方可正常同步,否则会导致同步数据不一致。例如同步对象只包含表 A,不包含表 B,如果同步过程中源实例执行了 rename A to B 的操作,那么改名后的表 B 的操作不会被同步到目标库。为了解决这个问题,可以选择同步表 A、B 对应的整个数据库。 准备事项在配置同步作业前,要确保同步作业的源及目标RDS实例都已经存在。如果不存在,那么请先购买RDS实例 购买 RDS 实例。 配置步骤下面我们详细介绍下创建任意两个 RDS 实例之间的同步链路的具体步骤。 购买同步链路。 进入数据传输 DTS 控制台,进入数据同步页面,点击控制台右上角 “创建同步作业” 开始作业配置。 在链路配置之前需要购买一个同步链路。同步链路目前支持包年包月及按量付费两种付费模式,可以根据需要选择不同的付费模式。 在购买页面需要配置的参数包括: 源地域 源地域为同步链路源实例所在地域。 目标地域 目标地域为同步链路目标实例所在地域。 实例规格 实例规格影响了链路的同步性能,实例规格跟性能之间的对应关系详见 数据同步规格说明。 数量 数量为一次性购买的同步链路的数量,如果购买的是按量付费实例,一次最多购买 99 条链路。 当购买完同步实例,返回数据传输控制台,点击新购链路右侧的“配置同步作业” 开始链路配置。 同步链路连接信息配置。 在这一步主要配置: 同步作业名称 同步作业名称没有唯一性要求,主要为了更方便识别具体的作业,建议选择一个有业务意义的作业名称,方便后续的链路查找及管理。 同步链路的 RDS 实例 ID 源跟目标 RDS 实例必须为两个不同的实例,选择 RDS 实例 ID 时,下拉菜单中只列出对应阿里云账号下的 RDS for MySQL 实例。 当这些内容配置完成后,可以点击授权白名单并进入下一步。 授权RDS实例白名单。 这个步骤,主要是将数据传输服务器 IP 添加到同步 RDS 实例的白名单中。避免因为 RDS 设置了白名单,数据传输服务器连接不上 RDS 导致同步作业创建失败。 为了保证同步作业的稳定性,在同步过程中,请勿将这些服务器 IP 从 RDS 实例的白名单中删除。 当白名单授权后,点击下一步,进入同步账号创建。 创建目标库上的同步账号。 这个步骤主要是在目标 RDS 实例上创建一个同步账号,账号名字为:dtssyncwriter,在同步过程中,不能删除这个账号,否则会导致同步链路中断。 选择同步对象。 当创建完目标 RDS 实例的同步账号后,即进入同步对象的选择步骤。实时同步的同步对象的选择粒度可以支持到表级别,即用户可以选择同步某些库或是同步某几张表。 如果选择的同步对象为整个库,那么这个库中所有对象的结构变更操作(例如 create table,drop view 等),都会同步到目标库。 如果选择的某张表,那么只有这个表的 drop/alter/truncate/rename table,create/drop index 的操作会同步到目标库。 当配置完同步对象后,进入同步初始化配置。 同步初始化配置。 同步初始化配置,初始化是同步链路启动的第一步,它会将源实例中已经存在同步对象的结构及数据在目标实例中初始化,作为后续增量同步数据的基线数据。 同步初始化类型细分为:结构初始化,全量数据初始化。默认情况下,需要选择结构初始化及全量初始化。 预检查。 当上面所有选项配置完成后,即进入启动之前的预检查。 当同步作业配置完成后,数据传输服务会进行限制预检查,当预检查通过后,可以点击 启动 按钮,启动同步作业。 当同步作业启动之后,即进入同步作业列表。此时刚启动的作业处于同步初始化状态。初始化的时间长度依赖于源实例中同步对象的数据量大小。当初始化完成后同步链路即进入同步中的状态,此时源跟目标实例的同步链路才真正建立完成。
2019-12-01 23:09:47 0 浏览量 回答数 0

回答

它在很大程度上取决于数据库内部的事务实现,也可能取决于您使用的事务隔离级别。我在这里假设“可重复阅读”或更高。将事务长时间保持打开状态(即使是未进行任何修改的事务)会强制数据库保持频繁删除的表的已删除或更新的行(以防万一,您决定读取它们),否则这些事务可能会被丢弃。 此外,回滚事务可能会非常昂贵。我知道在MySQL的InnoDB引擎中,回滚大事务所花的FAR时间比提交它要长(我们已经看到回滚需要30分钟)。 另一个问题与数据库连接状态有关。在分布式容错应用程序中,您永远无法真正知道数据库连接所处的状态。状态数据库连接无法轻松维护,因为它们随时可能失败(应用程序需要记住它所处的状态)。进行并重做)。可以重新连接无状态的状态,并重新发出(原子的)命令而不会(在大多数情况下)破坏状态。
保持可爱mmm 2019-12-02 03:16:26 0 浏览量 回答数 0

回答

当然要批量导入啊。 excel转换成特定SQL文件然后导入数据库。 这里去重,可以考虑一张临时表。 然后插入数据可以使用如mysql的ignore : insert ignore into table_main(id,phone,other)  select id,phone,other from table_temp_uuid; ###### 引用来自“vvtf”的评论 当然要批量导入啊。 excel转换成特定SQL文件然后导入数据库。 这里去重,可以考虑一张临时表。 然后插入数据可以使用如mysql的 ignore : insert ignore into table_main(id,phone,other)  select id,phone,other from table_temp_uuid; 临时表方案靠谱。###### 首先,判断重复用数据库的uniq来做(程序里处理uniq的报错),而不是自己写代码另外去判断。 大数据量的导入建议用csv,读一行导一行,内存占用小。如果非要用excel,记得服务器内存要设置大点。 ######你说的那两个字段加入唯一约束 . 然后开启事务,循环插入,如果插入失败,则改为更新(或你自己的逻辑). 这样快,但肯定很消耗CPU. ######为什么不在list里面去重,再一次导入######这样数据库只需要批量插入的时候维护一次索引,如果修改的其他字段没建索引,那么update是不需要维护索引的######看能不能插入之前拆出2个list,一个是重复的,一个是不重复的(这样拆之前需要select……for update,防止其他事务修改数据)###### 引用来自“death_rider”的评论 为什么不在list里面去重,再一次导入 赞同。具体设计问题不明确不好给意见。不过系统和算法设计中有点是可以肯定的:逻辑处理和数据载入尽量分开。 在单纯的算法设计中,往往不会去考虑数据迁移的成本,这是比较理科的分析方式,而在系统开发过程中,数据迁移的成本是必须要考虑的,这是工程化的必然。 数据迁移,这里是广义上的,包括,数据的转移,从磁盘到外部存储(主板上所谓的内存),从外部存储到片内存储(soc,cpu的内部cache,差异在于无需外部总线);也包括,通过网络在不同处理设备之间的转移;同时还包括数据的结构调整,如数据清洗在逻辑层面的工作。 楼主应该考虑数据的预清洗或后处理。当然具体用哪种更合适,还要自己根据数据的来源,数据之间的关联性,数据处理的实时性等要求来判断。 哈,反正是个系统设计层面的工作。不是工具选择层面的事务。 ######回复 @首席打酱油 : 把需要比对的,做md5等散列数据,可把大概率数据测出来。只有命中时才进行比对。这些工作,需要额外的数据组织,同时需要额外的编程。这些数据过滤的算法,如果用c我看不出有啥太大计算量。######目测楼主说的不能重复不仅是指Excle中的数据不能重复,而且还要Excel中的数据和现有数据库中的数据不能重复,所以不能单纯的把Excle中的数据加载到List中内存去重###### 引用来自“vvtf”的评论 当然要批量导入啊。 excel转换成特定SQL文件然后导入数据库。 这里去重,可以考虑一张临时表。 然后插入数据可以使用如mysql的 ignore : insert ignore into table_main(id,phone,other)  select id,phone,other from table_temp_uuid; 一般怎么把EXCEL转换成SQL文件呢?######如果你的excel本来就是符合load data infile的文件格式, 都不需要解析的。######就是解析excel啊。所以这个方案的耗时也就是解析excel这里。当然这可能也浪费不了多少时间的。 我这里是对MySQL的方案。 解析成对应的MySQL能解析的。比如load data infile。 或者批量insert也行。 然后source。6W条瞬间插入的。######数据直接用com接口导出(服务器处理),分布式处理也行,但是不做任何处理,极限速度,10w体积很小的,1m?连1个高清png的大小都没有,数据也是可以压缩的,重复的数据会压缩很多,上传和带宽不是瓶颈,主要是数据逻辑处理和数据库瓶颈,你处理的时候解析到内存,一个瓶颈,倒入数据库又temp table,还是内存,数据库的内存,又一个瓶颈######你要懂服务器编程才行啊,很多处理单机导出数据还可以,服务器就不这么处理了,还有就是数据库,知道temp table,stor procedure,导入导出,那是数据库初级而已######主要问题在“ Excel文档转List花费4m”,只能异步了。
kun坤 2020-06-08 19:23:25 0 浏览量 回答数 0

回答

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

问题

【精品问答】带你进入数据库领域

表格存储 Tablestore 的错误码有哪些? https://developer.aliyun.com/ask/280370 存储数据量对查询速度有影响吗? https://developer.aliyun...
谙忆 2020-04-07 20:45:48 12 浏览量 回答数 1

云产品推荐

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