为什么数据库公开为 API？

应用程序在投入生产之前价值不大。对于开发人员而言，快速达到这一点意味着可以轻松访问他们需要构建的数据，而不必担心启动、管理和维护数据库的细节。

API已成为将应用程序连接到数据库的事实标准，但并非总是如此。在这里，我们将讨论软件世界发生了什么变化，以提升将数据库公开为 API 的重要性。我们还将讨论 Stargate，这是一个开源项目，它简化了开发人员使用这些 API 的方式（ 最近发布了最新版本的 Stargate，其中包括可扩展性和灵活性方面的改进）。

我们如何构建使用数据库的软件

过去，数据库管理员 (DBA) 负责查询，因为这需要数据库专家来设计开发人员与数据交互的方式。但直到最近，开发人员还需要了解很多与数据库交互的知识，即使他们不是 SQL、查询或数据模型方面的专家。

我在 1990 年代是一名熟练的开发人员，但数据库让我望而却步。我花了很多年才适应使用 SQL。仅仅提供一个“相似的 SQL”也是不够的。以 CQL（Cassandra 查询语言）为例，它的开发目的是提供一种类似于 SQL 的查询语言，用于与 Apache Cassandra 进行通信。这个想法是为与 Cassandra 的通信提供一个抽象，让那些熟悉关系数据库的人更容易这样做。

但是在网络世界中，我们有了完全独立于查询语言的身份、权限和安全的新概念。驱动程序仅通过二进制协议进行通信的概念在云中并不适用。 HTTP 是云的基础应用层协议，但大多数基于 HTTP 的 API 都很慢。低延迟选项（如 gRPC）对于分布式系统中的实时通信至关重要。

软件如何与软件对话

客户端或应用程序服务器用于与数据库对话的标准方式涉及在数据中心内运行的驱动程序。现在一切都在云端运行，但开发人员使用多种语言编写。可能会使用JavaScript 、Python 或许多不同框架中的任何一种，因此需要以不同于经典数据库驱动程序的方式抽象软件访问数据的方式——使用 API（JSON、gRPC、 GraphQL或文档）开发人员很满意。

软件与软件对话的现代方式是 API；它是隐藏数据库复杂性的抽象层。

数据的本质

数据过去更加统一；它非常适合数据库表中的行和列。但是数据的动态发生了变化。数据以无缝方式从内存中的表示形式移回数据库，无需太多干预软件。我们正在处理比人们过去处理的数据原语或 SQL 可以处理的六种左右数据类型更强大的新型数据格式。

数据库 API

API 是当今开发人员使用数据库的方式。以下是原因的总结：

• HTTP是云的网络协议。许多开发人员已经熟悉 Web API，使用 HTTP 可以使云应用程序部署变得更加容易。
• 无需在本地安装和运行数据库。在本地安装数据库需要付出努力，并且会创建另一个必须调试问题的环境。

通往简单性、可伸缩性和可扩展性的门户

数据 API 网关是一种软件基础架构，可通过各种样式的 API（包括 REST、gRPC 等）提供对数据的访问。网关使用一个或多个持久存储抽象存储和检索数据的细节。这使应用程序开发人员能够专注于编写通过易于使用的 API 访问数据的业务服务，而不必学习复杂的数据库查询语言。

Stargate是一个开源数据 API 网关，位于应用程序和它需要查询的数据库之间。它于 2020 年 9 月首次推出， Apache Cassandra被选为第一个数据库，部分原因是它解决了世界上最困难的可扩展性和可用性挑战。

数据 API 网关是一种强大的方式，使您的开发人员能够在他们熟悉的框架和结构中工作，在生产力和性能之间提供一系列权衡。 Stargate 通过将 REST、文档和 GraphQL 呈现为简单的 API 来提供 Cassandra 的强大功能。它还提供了一组 gRPC 库，用于通过 gRPC 执行 CQL，作为 CQL 本机驱动程序的更简单、轻量级和更云友好的替代方案，而不会牺牲性能。

今年， DataStax的 Stargate 工程团队一直致力于 Stargate 的架构更新。我们称之为 Stargate v2，于2022 年 10 月发布。根据Stargate 开发者社区的反馈，我们在 Stargate v2 中做了一些重要的更新，让开发者更容易使用，让社区更容易为项目做出贡献。最重要的是，Stargate v2 的高性能 gRPC API 可以提供与本地数据库驱动程序相当的速度。这使开发人员能够使用 HTTP 等对云友好的网络协议来连接应用程序和数据库，而不会损失网络性能。

可扩展和适应性强

与大量开发人员接触后，本月没有任何自上而下的策略或 API 风格能够幸免。 Stargate v2 的一个关键目标是通过使实现本身更易于理解、调试、增强和扩展，使社区能够快速轻松地添加新的 API 服务。

现在添加新的 API 服务要简单得多，REST、GraphQL 和文档 API 服务的源代码为开发人员提供了指导性的示例代码，展示了完成的 API 服务应该是什么样子。

API层应该是多模型的；开发人员希望随时找到他们喜欢的 API，而不是被迫调整他们的开发工作以适应不同的 API。如果 API 不可用，API 层应该能够适应。

云原生

将代码扔到数据库前面已经有很多年了。但实际上，构建一个可以随您的数据库扩展且具有适应性和可靠性的平台是一件新鲜事。如果您正在使用 Cassandra，您可能已经是一个高速增长的应用程序——或者渴望成为一个高速增长的应用程序。因此，它前面的一切都必须促进高增长环境。 Stargate 最初是 Cassandra 协调器代码的一个分支，因此它继承了 Cassandra 众所周知的大部分可靠性和可用性。

API 层必须完全能够大规模运行，因此 Stargate v2 的另一个目标是使其对云更加友好。促进 Stargate 可扩展性的几项更改包括：

• Stargate 现在完全容器化并在 Kubernetes pod 中运行，这使操作员可以更好地控制工作负载的扩展方式。

• API 服务已从单一的 Stargate 节点移出到单独的微服务中，这将使每个 API 能够独立扩展。

• 存储节点和协调器节点可独立部署和扩展，也使运营商能够更好地控制工作负载的扩展方式。

  
  

如果工作负载是查询密集型或存储密集型的，则可以对其进行调整，而无需将整个集群作为一个整体进行扩展。

用熟悉的东西开发

云数据服务已成为技术领域的主导主题，因此开发人员倾向于从数据抽象（如 JSON）而不是特定数据库独有的惯用语的角度来思考也就不足为奇了。 Stargate 是大量努力的结晶，旨在满足开发人员所在的位置，使他们能够在他们熟悉的框架和结构中工作。

在这里了解更多关于 Stargate 的信息。

埃德·安努夫着。