Google Sheets作为Web应用程序的数据库服务

Google Sheets作为数据库服务在许多情况下都很棒，但也有一些限制。

像Google Sheets或Airtable这样的电子表格服务已经被许多人、团队和公司使用。让它们更有趣的是，它们向非技术用户介绍了无代码运动，为有趣的可能性打开了大门。

NO-CODE就像星巴克(Starbuck)一样，也是一种为不喝咖啡的人准备的咖啡。星巴克的伟大之处不在于它的味道，而是它让更多的人享受咖啡。换句话说，无代码是一种面向非程序员的编程语言。

最近，我研究了在集成到无代码构建器Inverr- 时将Google Sheet用作数据库服务。它可能适用于每月访问量低于500万次的网站或应用程序，具有足够大的数据存储空间供小型应用程序使用。不过，它也有一些局限性。

在这篇文章中，我将讨论使用Google Sheet作为数据库服务时的一些技术问题，它的影响，以及如何克服它。

数据库的主要功能是存储、检索和搜索数据。虽然Google Sheets在存储和检索数据方面做得很好，但Google Sheets中的搜索部分有点棘手。

在许多应用程序上，搜索提供了可发现性。例如，当您构建电影发现应用程序时，用户可以按名称、类别或受欢迎程度搜索电影。没有搜索，电影应用程序与电影列表没有什么不同。

为了使用搜索功能，Google Sheets API提供了一个名为“developerMetadata”的属性。它是每个单元格上的附加数据，对Google Sheets用户是不可见的。在搜索时，它将使用这些附加数据。

“developerMetadata”对每个电子表格有30,000个字符的限制。它太小了，做不了什么大事。不过，您可以通过仅存储重要术语来优化句子、段落。

Google Sheets的存储限制为500,000,000个单元格(包括空白单元格)，每个工作表最多256列。

让我们以电影发现应用为例，它至少需要6个属性(id、标题、描述、发布日期、评级、类别)。粗略估计，您最多只能存储5,000,000/6=~833K电影。由于目前有555913部电影上映，理论上还是可以接受的。

使用Google Sheet API时的另一个限制是其请求配额。从每100秒500个请求(或每秒5个请求)开始，超过时开始收费。在许多情况下，使用适当的缓存技术将减少对Google Cloud API服务的请求数量。

这是一个不切实际的衡量标准，但为了测试限制并获得更好的概览，我尝试从包含大型数据集的电子表格中获取数据。

上图展示了每秒从Google Sheet检索数千个单元格的性能。一次获得100k细胞大约需要2秒，100k/6=~16k电影。这是可以接受的性能，并且随着单元数量的增加而增长。

Google Sheets就像一个数据库，有自己的演示文稿。例如，您有一个每月费用的电子表格。它包含一份费用清单，以及它们的类别。最后，它可以由当月所有费用的总和得到总费用值。

当将其用作电子表格时，布局自由度很方便，但对于数据库来说却是一场噩梦。因为数据库总是遵循某种固定的布局。它允许数据库引擎计算距离并在数据行之间导航。没有没有布局的数据库设计。

此外，除非您决定不让任何人接触该电子表格，否则有人可能会通过重命名选项卡或将其删除而意外地将其搞砸。

总而言之，Google Sheets被广泛用作工具。但是作为一个数据库，它也有一些限制。通过适当的缓存和优化，可以安全地将其用作月访问量为5.000.000次的网站/应用程序的数据库。

此外，在许多情况下，它的搜索限制可能是一个巨大的瓶颈。您可以使用“developerMetadata”来启用数据查找。由于有30k个字符的限制，最好只存储“元”数据。