Category: Database

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 的外观和感觉都相同。当然每种引擎的实现又略有不同

图数据库 Amazon Neptune ⾃自在2018年年发布以来，凭借其 多种图数据引擎的⽀支持、⾼高可⽤用、多只读副 本、跨可⽤用区复制、指定时间点恢复、安全、⾃自动备份等⼀一系列列特性，受到了了⼴广泛的关注，那么在推荐引擎 的设计和开发中怎么⽤用好Neptune，这⼀一点在官⽅方的相关⽂文档中并没有做深⼊入的说明，本⽂文就这个主题做⼀一 个展开讲解，希望对从事相关⼯工作的⼯工程师有所戒借鉴。

2016 年，AWS 推出了EKK 堆栈（Amazon Elasticsearch Service、Amazon Kinesis 和 Kibana），作为 ELK（Amazon Elasticsearch Service、开源工具 Logstash 和Kibana）的替代品，用于提取和可视化 Apache 日志。EKK 堆栈的主要功能之一是通过 Amazon Kinesis Firehose 代理处理数据转换。在本文中，我们将介绍如何优化 EKK 解决方案 — 通过 AWS Lambda 处理 Amazon Kinesis Firehose 中的数据转换。

本文主要讲述在将云下 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侧的监控以及一些优化的方法。

在本文中，我们将讨论将MongoDB 4.0数据平滑迁移到Amazon Aurora MySQL兼容版的方法。Amazon Aurora 是一种与 MySQL 和 PostgreSQL 兼容的关系数据库，专为云而打造，既具有传统企业数据库的性能和可用性，又具有开源数据库的简单性和成本效益。本文中描述的方法使用AWS DMS转换源数据，近乎零停机时间来执行迁移。