数据库或文件系统中的缓存API响应

Question

大多数第三方API都是速率限制的。

假设我正在从诸如Twitter API之类的REST服务中获取数据。我希望显示特定主题标签的推文列表。出于此示例的目的，返回1,000个推文的大型JSON响应。

    {
      "tweets": {
        "1": {
          "tweet": "hello",
          "name": "ben",
          "date": "2018-01-01"
        },
        "2": {
          "tweet": "hi",
          "name": "dave",
          "date": "2018-01-02"
        },
        "3": {
          "tweet": "hey",
          "name": "holly",
          "date": "2018-01-03"
        }...
      }
    }

1000条推文中的每条都有自己的属性;推文，名字，日期。

如果我在每个页面刷新时调用Twitter Api，我们很快就会达到速率限制。我只需要在几分钟内获取新的推文列表。

显然需要缓存机制。

哪个计划更好;

A）将整个JSON结果存储在本地文件系统中，并在需要时进行解析。

B）将整个JSON结果存储在一个字段中的数据库中，即“json_response”，并在需要时进行解析。

C）循环每条推文，将每条推文作为单独的行插入，每个参数都包含一个表字段（推文，创建者名称，日期，时间，网址，图片）。然后使用SELECT查询返回并重建响应。

如果整个结果存储为一个，则数据库将变得庞大，因为JSON响应包含每个推文的属性和JSON结构“推文，名称，日期”等。

如果数据被拆分为相应的字段，则需要额外的INSERT / SELECT / DB连接和解析时间。如果将新数据传递给API结果，则除非映射新的DB字段，否则不会存储它。

Answer 1

哪个计划更好

通常，这取决于。

统一回应

如果您有一组有限的响应类型，并且您希望按原样使用结果（无需任何其他过滤），请使用标准缓存解决方案（变体A）。您可以自己编写一个，但在野外有许多现成的解决方案。刷新缓存意味着再次从API检索所有数据。

简单数据库

如果将结果整体存储（变体B），除了变体A的数据库开销之外，你什么都得不到。所以不建议这样做。

结构化数据库

如果将响应拆分为单独的记录并单独存储（变体C），则可获得最佳灵活性。虽然数据库事务需要性能，但是不需要一次又一次地解析结果可能会超过这一点。您可以按任何标准过滤记录。对于刷新，您只需要获取自上次更新以来的数据，从而节省带宽。

NoSQL数据库

您的最佳选择可能是将各个记录存储在NoSQL数据库中。它可以帮助您免于单独解析结果，并自动满足结果结构的变化。