Category: Database

数据是公司最为重要的资产之一，这些数据部分存储在数据库之中，金融，电信，能源等很多企业使用Oracle来承载他们的核心交易及业务系统，Oracle的市场份额一度接近50%，维护Oracle系统通常需要专业DBA，主机工程师，存储工程师，网络工程师合作，才能保证数据库系统稳定运行，这需要大量的投资，上云能大幅度提升数据库系统的稳定性，降低运维复杂度和强度，同时也能降低投资（这包括License和硬件的一次行投资以及持续的运维成本）,这有助于帮助客户更加专注于自身的业务。上云的过程中要确保数据完整一致上云，是IT部门非常重要的一个任务。

随着 IoT 设备的普及，如何安全、灵活地管理对设备的控制权限变得更加复杂。在以往简单的应用场景中，控制端 APP 仅仅需要使用 AWS IoT 平台对一个设备进行控制。但随着家庭拥有的物联网设备愈加丰富，控制端 APP 需要同时控制多个设备。另外，某些终端设备还需要提供给多人控制，例如家具式的智能排插能够支持被所有的家人打开或者关闭，因此就出现一个控制端 APP 能够控制多个设备端，或者多个用户能够相互控制多个设备的权限管理问题。
对这两种场景，本文分别介绍如何结合 AWS STS 服务，以临时安全凭证的方式在多设备和多用户的场景下精细化地向控制端 APP 分发和管理控制权限。

降低成本、提高可用性和可扩展性是采用 AWS 方案的主要原因。Trimble 决定从 Oracle 迁移到开源数据库平台，来优化当前的授权费用。Trimble 还通过使用 Amazon RDS 运行数据库来帮助保证可靠性和降低运营支持开销。

在由西云数据运营的 AWS 中国（宁夏）区域正式推出第3个可用区后，AWS中国区域的用户可以更加灵活地来部署跨越3个可用区的应用程序及数据库架构，进一步加强系统高可用性和容错能力，并提升业务的连续性。
本文将重点介绍 SQL Server Always On Linux 可用性组在 AWS 中国（宁夏）区域的安装、配置、只读副本以及故障转移等。

直到现在，从大量非结构化或半结构化内容中提取价值一直都很困难，并且需要机器学习 (ML) 方面的背景。Amazon Comprehend 消除了这些进入障碍，让数据工程师和开发人员可以轻松访问丰富、持续训练的自然语言处理服务。

您可以通过将来自 Amazon Comprehend 的分析与关系业务信息相结合来构建完整的分析解决方案，从而生成有价值的趋势分析。

我们都曾有过那样的经历！您需要对重要的生产数据库执行快速且看似简单的修复。您编写了查询，简单检查了一遍，然后运行查询。几秒钟后，您意识到自己忘记了 WHERE 子句，结果丢弃了错误的表格，或者犯了另一个严重的错误，并中断了查询，但损失已经无法挽回。您深呼吸了一下，透过齿缝发出“嘶”的一声，希望一个“撤消”选项出现在您眼前。接下来该怎么办呢？

全新的 Amazon Aurora 回溯功能
今天，我要为您介绍 Amazon Aurora 的全新回溯功能。就当今技术而言，该功能非常接近于实际为您提供了“撤消”选项。

关系数据库管理系统支撑着最重要的联机交易类应用，存放着最重要的数据资产，所以在用户IT系统里占据着非常核心的位置。现实情况往往是审计功能虽然使用并不复杂的统的商业数据库管理系统，但是鲜见有用户打开审计功能。Amazon Aurora MySQL全新发布，高级审计功能强劲在哪，本期大咖专栏带你一探究竟。

继静态加密之后，Amazon DynamoDB 团队趁热打铁，再次为大家献上有用的功能。在 AWS re:Invent 2017 上，我们为 DynamoDB 表推出了全局表和按需备份与还原功能。今天，我们进一步推出了连续备份和时间点还原 (PITR) 功能。

对于 Amazon Aurora，您可能已有所了解。Aurora 是一种完全托管、可自动扩展到 64 TB 的数据库存储，提供与 MySQL 兼容或与 PostgreSQL 兼容的版本。创建 Aurora 数据库实例时，您可以选择所需的实例大小，并可以选择使用只读副本提高读取吞吐量。如果处理要求或查询率发生变化，您可以选择修改实例大小或根据需要更改只读副本的数目。此模型在工作负载可预测、请求速率和处理要求较高的环境中运行极佳。 在某些情况下，工作负载可能是间歇性和/或不可预知的，并且每天或每周可能有仅持续数分钟或数小时的请求高峰。限时抢购、偶发或一次性事件、在线游戏、报告工作负载 (每小时或每天)、开发/测试和新上线应用程序都具有上述特点。要分配恰好够用的容量很难；按固定价格付费又不够明智。 Amazon Aurora Serverless 发布 我们于今日推出 Amazon Aurora Serverless 预览版 (立即注册)。此新配置专为多变的工作负载设计，让您能够以秒为单位为所用的数据库资源付费。 此无服务器模型构建在处理和存储清晰分离的基础上，处理和存储清晰分离是 Aurora 架构的一部分 (有关更多信息，请参阅 Design Considerations for High-Throughput Cloud-Native Relational Databases)。您不必预先选择数据库实例大小，而是创建一个终端节点，根据需要设置所需的最小和最大容量，然后向此终端节点发出查询。终端节点是一个简单代理，它将查询路由到快速扩展的数据库资源队列。这样，即使在后台执行扩展操作，您的连接也能保持不变。扩展操作极为迅速，新资源可在 5 秒内上线。下图说明了这些功能是如何结合在一起的： 存储和处理是分开的，因此处理容量可以缩减至零 (此时，您只需支付存储费用)。我认为这一点很棒，它有可能催生随开即用的新型瞬时应用程序。基于可随时启用以处理请求的“热”资源池进行扩展 (可在数秒内完成)。新增资源基于现有的已缓存和已缓冲内容，可实现全速运行。这让您能够毫不费力地将现有 Aurora 数据库转换为无服务器模型。 基于 Aurora 容量单位计费，每个单位代表计算能力与内存的组合。以 1 秒为增量进行计量，每个新增资源最低计 1 分钟。 敬请关注 2018 年初，我将向大家介绍有关 Amazon Aurora […]

去年年底，我提到过我们向 Amazon Aurora 添加 PostgreSQL 兼容性的计划。公告发布后不久，我们推出了封闭测试版，并于今年年初发布了一个公开预览版。在测试版和预览版期间，我们收到了很多极好的反馈，我们将倾尽全力确保产品满足乃至超出大家的期望！ 现已正式发布 非常高兴告诉大家：兼容 PostgreSQL 的 Amazon Aurora 现已正式发布，您现在就可以在四个 AWS 区域 (将在更多区域发布) 使用它。它兼容 PostgreSQL 9.6.3，可自动扩展为支持高达 64 TB 的存储 (后台采用 6 路复制技术以提升性能和可用性)。 与兼容 MySQL 的 Amazon Aurora 一样，这是一个完全托管版本，非常容易设置和使用。在性能方面，吞吐量最高可达您自己运行 PostgreSQL 时的 3 倍 (可以参阅 Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases 了解我们如何做到这一点)。 您可以从 RDS 控制台启动兼容 PostgreSQL 的 Amazon Aurora 实例：引擎选择 […]