我们将数据存储在数据仓库中,如下所示:
我们目前只有四种产品。这种变化很少发生(平均每 10 年一次)。每个工作日一次,添加四个新数据点,代表每种产品的当天价格。
在网站上,用户可以通过输入日期范围并选择一个或多个产品名称来请求此信息。分析显示该功能并未大量使用(每周大约 10 个用户请求)。
建议数据仓库每天将包含所有数据的 CSV 文件(目前 6718 行,每天增加 4 行)推送(SFTP)到 Web 服务器。然后,Web 服务器将从文件中读取数据,并在用户提出请求时显示该数据。
通常,推送只会一天一次,但不止一次推送可能会传达(不频繁的)价格修正。即使在价格修正方案中,所有数据都将在文件中交付。这种方法有什么问题?
让 Web 服务器根据用户请求向数据仓库发出请求会更好吗?或者这是否存在网络错误或性能问题的可能性更大等问题?
最佳答案
Would it be better to have the web server make a request to the data warehouse per user request?
是的。您的数据很少,因此无需尝试以某种方式“缓存”它。 (除了 CSV 可能不是执行此操作的最佳方式这一事实之外)。
没有什么能阻止您从网络服务器向数据库服务器发出这些请求。有了这么少的信息,您不会发现性能问题,但即使一切都在增长,在数据库方面(索引等)也有很多收获,这将帮助您在接下来的 100 年中生存下来这种时尚。
来自您的用户的请求数量(也非常少)不需要任何特殊处理,因此再次直接查询是最好的。
Or does this have issues such as a greater chance for network errors or performance issues?
好吧,它可能会,但这不能证明你的 CSV 方法是合理的。示例以及您不必担心的原因可能是
这对这两种方法来说都是一个问题,但是对于每天一次的方法来说,如果每天只有一个连接,万分之一的故障变化似乎会更好。但是这些问题不应该经常出现,如果出现了,你应该能够处理它们。 (重试请求,给用户一个消息)。这就是大量网站所做的事情,所以如果我说这不会成为问题,请相信我。另外,想想如果您的每日更新失败意味着什么?那会带来更大的问题!
如前所述,这是由于数据量和请求量,不是问题。即使它变成了一个,这也是一个你应该能够在不同层次上发现的问题。在数据库服务器上使用缓存系统(非 CSV)。在网络服务器上使用缓存系统。修复索引以防止性能成为问题。
但:
将您的数据仓库与您的 Web 系统分开并不奇怪。如果这是一个要求,而且它肯定可能是,你能做的最好的事情是在另一台机器上重新创建你的仓库数据库(我刚刚辩护为足以直接查询的那个)。做主从系统可能会得到很好的结果
现在您没有任何时间更新查询的数据库(主从复制将始终保持更新),但是来自网络服务器的查询不可能使您的仓库处于危险之中。利润!
关于sql - 应该如何使用数据仓库将数据提供给 Web 服务器?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18491026/