oracle rds 运维服务_我应该为无服务器应用程序选择哪个数据库？

选择正确的数据库对应用程序的成本和性能具有最直接的影响之一。无服务器环境也不例外。通过考虑诸如访问模式，模式（数据模型）和预期性能之类的参数，可以在逻辑上为您的数据库类型做出最佳决策。

通常，数据库具有两种广泛的分类：SQL关系数据库或规范化数据库以及NoSQL或非规范化数据库。对于特定的用例，例如建模图，内存缓存系统等，也出现了第三种分类。

但是在本文中，我们将探讨SQL和NoSQL数据库的某些方面，并研究AWS为这些相应类型的数据库提供的服务。

SQL数据库

SQL或关系数据库使用结构化查询语言来处理数据。它是一种功能强大的语言，是处理数据的最灵活的选择之一。您可以进行复杂的查询以进行检索，如果您要执行OLAP（联机分析处理）数据分析，这将非常方便。

SQL擅长大规模处理多行事务。如果您不完全了解您的应用程序随时间推移可能具有的访问模式并且不期望指数增长，那么这种类型的数据库是正确的选择。

但是，SQL数据库具有其共同的缺点。在开始使用数据库之前，需要先定义模式，这需要进行大量的准备和计划。设置完数据模型后，您将需要在整个应用程序中维护该结构。

由于SQL系统具有垂直扩展能力，因此可扩展性也可能会出现问题。增加更多的CPU和RAM来处理负载可能会变得非常昂贵，并且可以“扩展”的数量有限。您始终可以添加更多服务器或“横向扩展”，但这需要大量的工作并且成本很高。

NoSQL数据库

与SQL不同，NoSQL数据库没有特定的查询语言，并且拥护使用非规范化数据集的概念。

它们的类型包括：

• 基于文件
• 键/值对
• 图形数据
• 面向列的数据结构

通过将所有内容简单地放入一个具有系统访问模式的集合中，消除了跨表的复杂联接是NoSQL数据库的重点。它们的高性能，可伸缩性和可扩展性使NoSQL非常适合无服务器开发。

NoSQL数据库因能够扩展以处理巨大的OLTP（在线事务处理）工作负载和管理不同的数据集而闻名。另外，更改架构不会中断您当前正在运行的应用程序。

动态模式+最高性能=最佳数据库选项，对吗？并非如此。如果不确定应用程序需要哪种数据模式，那么最好避免NoSQL或先花时间学习NoSQL，然后再动手。

以这种方式思考，由于NoSQL系统具有灵活性和开发人员普遍的熟悉度，因此初创公司可能会通过选择SQL数据库而尽快获得MVP，但NoSQL数据库由于其非常高的性能可以带来未来的收益。可扩展性。唯一的障碍是适当的数据建模，以便有效地满足未来数据访问的需求。

那些从SQL背景开始使用NoSQL而对访问模式没有正确理解的人可能会陷入困境或像使用SQL一样使用NoSQL。随着应用的增长，这也将影响您的应用。

话虽如此，让我们探讨一下Amazon的SQL和NoSQL服务的托管版本：RDS和DynamoDB，以及它们在无服务器应用程序中的性能。

Amazon RDS与DynamoDB

亚马逊RDS

Amazon Relational Database Service（RDS）带有六个引擎供您选择，它们分别是MySQL，PostgreSQL，MariaDB，Oracle，SQL Server和它们自己的实现Aurora。

如前所述，关系数据库遵循结构化数据建模的一组模式，并由用于数据处理的SQL语言控制。因此，如果您决定使用Amazon RDS，则需要注意以下几个关键方面。

您的Lambda函数是按使用付费的，但是您将为RDS实例按小时计费，除非您选择的引擎是Aurora Serverless。

使用Lambda管理连接限制很重要。Lambda确实会在容器到期时终止连接，但是当应用程序处于压力下时，MAX CONNECTIONS问题仍然隐约可见。

利用RDS代理，降低RDS的连接超时，实施缓存策略，限制并发连接等是解决此问题的一些方法。

亚马逊的Aurora数据库服务（MySQL或PostgreSQL）可以证明是一个不错的选择，尤其是在读取性能（跨区域）方面，因为它们具有比RDS同类产品更快的复制能力。

与RDS相比，Aurora在性能和高可用性方面确实存在明显差异，但成本增加。如果您的用例需要，则应选择Aurora。对于完全无服务器的系统，Aurora Serverless可能是下一个最好的选择，但是它的性能还远远不够。

它的主要问题是应对冷启动。理想情况下，应选择Aurora Serverless进行测试或处理小型且不一致的工作负载。

亚马逊DynamoDB

现在，如果DynamoDB是满足您的应用程序存储需求的选择，那么您将获得以下内容。

与大多数NoSQL数据库不同，DynamoDB不是基于服务器的。它是按请求付费的价格，非常适合无服务器方式。这使得完全分布式无服务器系统的想法成为现实。

只要定义了吞吐量限制，DynamoDB实际上就可以拥有无​​限的并发请求。

还有一个名为PAY_PER_REQUEST的附加模型，该模型允许您的DynamoDB数据库缩放为0。

凭借毫秒级的性能，DynamoDB几乎可以处理您承受的所有负载。

如果您需要更好的读取时间，则DAX（DynamoDB加速器）是Amazon提供的完全托管的内存中缓存解决方案。因此，性能和可伸缩性是您对DynamoDB的后顾之忧。

从成本和性能的角度来看，带有Lambda的DynamoDB似乎是一个不错的选择。唯一的障碍是设计表格，以有效地维护应用程序可能具有的各种访问模式。

监控桑德拉

Thundra的无服务器可观察性和监视平台可通过提供有关您的应用程序的可行见解来进一步提高成本和性能。跟踪应用程序的各种服务之间的详细信息，以找出效率低下的区域，然后可以修复这些区域。对于数据库，特别是对于RDS实例，具有对长时间运行的查询的洞察力可以准确地告诉您需要优化应用程序的哪个特定部分。

让我们来概述一下Thundra的样子。一旦签了，Thundra引导您完成您的插装lambda函数的新手上路程序。您的体系结构和仪表板屏幕应如下所示。

结论

我们已经了解了SQL和NoSQL数据库是如何发挥其优势和劣势的。我们还快速浏览了Amazon的数据库服务，以及如何使用Thundra之类的平台对其进行监视如何增强您的指标跟踪功能以进行无服务器优化。

SQL数据库将在大多数用例中完成工作，更不用说它们强大的数据访问和处理功能，前提是您不期望大规模的毫秒级性能。

另一方面，即使在高峰使用时，像DynamoDB这样的NoSQL数据库也可以完成所有繁重的工作，而您不必担心服务器管理或故障转移。

很有可能获得类似于SQL查询的结果，但是DynamoDB需要在数据建模和了解如何为有效访问模式建立索引的索引方面学习。