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

2020-11-01 20:26:37

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个字符的限制,最好只存储“元”数据。