数据库是任何应用程序性能最关键的部分之一。当谈到 Baklib 时，考虑到高度可扩展的 SaaS 环境，我们总是致力于提高应用程序的性能。

我们不断尝试提高应用程序的性能，在密切监视应用程序是否有任何挫折和改进的同时，我们发现每天都会通过特定端点进行大量数据库写入。

Baklib 有两个方面，一方面是用户撰写文章、审阅文章和管理整体知识库的门户。第二部分是知识库站点，客户将在其中消费知识库的内容。

进一步深入

用外行人的话说，与人们撰写文章和管理知识库的门户相比，面向公众的知识库网站将获得更多的浏览量。我们开始监控面向客户的知识库站点正在使用的所有端点并收集它们的指标。

作为知识库，跟踪是应用程序最重要的部分之一，我们在其中显示知识库的浏览/阅读/喜欢/不喜欢的总数等……所有这些信息都必须在用户访问知识库网站时收集，我们在门户上整合并显示指标。我们注意到，为了收集分析，我们之前使用过此 API (Update Tracking Information)，它负责从知识库站点收集所有指标并将其写入数据库。

想象一个基本流程

每当用户访问知识库站点时，用户可能会访问多篇文章、阅读它们、花时间在一些需要更多上下文的文章上，或者用户甚至可能喜欢/不喜欢各种文章。现在，即使我们粗略估计每个用户至少看到 5 篇文章并与它们交互，也需要 5 次单独的数据库命中才能将信息写入我们的数据库。

查看此 API 的平均点击次数对我们的数据库产生了巨大影响。每天的平均点击量为 145K，如果我们观察一周的点击量，这个数字非常巨大，达到了 821K。我们确信我们应该采取一些措施来解决这个问题。

我们得出的解决方案

分析并不是立即需要的最直接的信息。每当 500 个用户访问该网站时，我们认为在门户中立即显示分析是没有意义的，因为知识库中没有人会查看当前日期时间或今天的分析。

我们完全改变了我们的分析架构，因此对数据库的数据库命中次数大大低于以前。我们最终得到的架构如下图所示。

我们开始使用排队机制，通过根据项目对结果进行分组来合并结果并将结果写入数据库。为了简单起见，我们假设有两个网站。

docs.Baklib.com

docs.abk.com

可能有多个用户访问不同用例的产品文档站点。根据我们的新架构，为 Baklib 收集的所有信息将被分组为一个集合，并通过单个 BulkWrite 操作写入数据库。通过这种方式，我们减少了对数据库进行的最大连接数和写入数。

我们推出分析架构后的新指标图表。平均每天的数据库写入次数为 2K，一周的写入次数为 12K

结论

差异是巨大的，我们可以看到包括 API 服务器和数据库在内的整体运营成本略有下降。因此，请考虑对任何此类场景进行排队，在这种情况下，不再立即需要分析等数据，可以通过显着减少服务器和数据库上的总体负载来提高应用程序的性能。

| | | || — | — | — || |旧实施 |新架构||每日数据库写入| 144,993 | 144,993 2,135 | 2,135|每周数据库写入| 821,628 | 12,813 | 12,813