我和我的团队正在开展一个项目，我们需要将数据从中央来源提取到各种客户网站。
数据存储在JSON中，中心源存储在Nodejs和MongoDB上。客户端站点主要是Wordpress（其他一些第三方CMS），因此可以在PHP和MySQL上运行。
我们设置的方式是在每个请求中从中央数据库中提取数据（房地产列表），并像常规HTML一样显示。
我担心这将是资源密集型的，并且将是一个较慢的解决方案，因为需要在每个请求上查找和获取外部数据。
我的问题是：这是一个理想的解决方案吗？什么会更好？
我的第一个想法是构建一个推送/存储解决方案，其中中心源会在收集数据时将数据推出，并将数据存储在每个客户端站点上。但这显然需要在每个客户端上使用某种数据库基础结构，这可能使它比需要的更复杂。
思想？
答案 0 :(得分：1)
如果中央数据源位于同一网络上并且不会引入大量开销，那么它就不错了。您需要运行一些测试来验证来自大多数客户端的调用具有相似的响应时间。如果访问不是问题，那么中央数据库可以并行处理这么多客户端，然后让中央数据库有意义。
缺点是它会造成单点故障。如果失败，所有网站都会关闭。此外，随着负载的增加，如果未正确调整，性能将在所有节点上降低。
我会建议一个分布式模型。你每天都需要拉一个工作来在非工作时间一次获取数据并在每个客户端本地保存它。因此，您可能需要DBA来帮助您。您需要查看数据大小以及刷新数据所需的时间，以确保数据快速完成。在此期间，该网站无需关闭。此外，如果需要，不同的客户可以在不同的时间刷新。
我有类似的情况，我的团队通过批处理作业使用数据库进行数据库复制，该作业每天都在非工作时间运行（我们只采用修改/添加的记录进行复制以减少数据刷新大小，您可以实现类似的逻辑根据您的数据集）。
就客户变得复杂而言，我认为它不会从编码角度对复杂性做出重大改变。您的前端不会改变，只有对数据的调用（可能是Web服务）才会从数据库而不是中央数据存储中获取数据。
我建议保留一层抽象，通过一个接口获取数据，该接口应该有2个实现，一个从中央数据存储获取数据，另一个从本地数据存储获取。这样你就可以轻松交换。所以，是的，稍微多一些工作，但不是复杂性的显着增加。
最后要考虑的是监控要求。我们遇到过复制失败的问题，必须再次手动触发。因此，在寻找本地数据库时应该考虑这一点。在部署此类体系结构之前，您需要考虑这个问题。 这种方法更加昂贵，因为您需要更多数据库，并且可能需要DBA来监控它们。