Category: Database

本文介绍了如何设置RDS MySQL的日志，并通过Lambda把RDS的日志转储到S3上面。

在客户的实际工作中，可能会遇到MYSQL RDS写入性能问题。本文将对影响MYSQL RDS写入性能的一些参数和配置进行探讨，最后会通过sysbench工具对参数调整效果进行测试。希望本文起到“抛砖引玉”的作用，给大家的数据库调优工作带来一些参考。

在本章节中主要描述，如何使用源MySQL数据库执行数据库迁移到MySQL数据库的目标Amazon RDS的最佳实践。同时由于(源和目标数据库引擎是相同的)——模式结构、数据类型和数据库代码在源和目标数据库之间是兼容的，这意味着这种迁移不需要任何模式转换。

Amazon Neptune是一个高性能图数据库，并对图的存储和查询进行了优化，可以存储数十亿个关系并将图形查询延迟降低到毫秒级。它也是一个托管的图数据库，能快速创建图数据库集群，减少了运维和管理图数据库的工作，让我们把工作重心放在业务开发和创新上。Amazon Neptune 支持常见的图形模型 Property Graph 和 W3C 的 RDF 及其关联的查询语言 Apache TinkerPop Gremlin 和 SPARQL，从而使您能够轻松构建查询以有效地分析高度互连数据集。它支持社交网络分析、建议引擎、欺诈检测、知识图谱、药物开发和网络安全等应用案例。

Amazon RDS Performance Insights为 Amazon RDS 提供了一个直观的调优界面，可帮助您发现和调查 RDS 数据库的性能问题。对于所有数据库引擎类型（例如 RDS for MySQL、RDS for PostgreSQL 和 Amazon Aurora）而言， Performance Insights 的外观和感觉都相同。当然每种引擎的实现又略有不同

本文主要讲述在将云下 PostgreSQL 数据库迁移到 RDS PostgreSQL 的指导原则及最佳实践，这里主要通过pg_dump来完成迁移。

介绍使用开源组件 ProxySQL 实现 Amazon Aurora 集群的读写分离

地理信息是一种特定的空间信息，无论在科学研究还是日常生活中都有广泛应用。我们通常使用计算机和相关软件对地理信息进行储存、管理、运算、分析、显示等操作。
我们对地理信息最常见的使用是导航，对地理信息最有前景的使用场景是自动驾驶。这两种场景都对地理信息的存储和使用有许多新的需求，这些需求包括对地理信息的实时更新、并发读写、版本控制、高可用和高可靠等。
当前,地理信息存储和处理方式，无论是传统方法把地理信息存放在二进制文件中， 还是把地理信息存放在传统的关系数据库里，都无法满足上面提到的新需求。而使用Amazon Aurora可以更好的满足这些新的需求。

AWS 官方并未提供前端展现工具或服务，来实现对 Neptune 图数据库数据分析的可视化，下面我们将结合基于浏览器的 VIS.js 动态可视化库，通过Serverless方式，采用 Amazon S3 静态网站托管与 Amazon API Gateway、AWS Lambda服务，来实现对 Neptune 图数据库数据分析的可视化。

这篇文章根据遇到的各种客户问题从SQL latency的角度切入来谈一下latency问题的定位，RDS MySQL侧的监控以及一些优化的方法。