我正在开发一个内置商店定位器的网站。
由于我过去开发过类似的网站，因此当我的搜索高峰严重影响数据库(mySQL)时，我遇到了一些麻烦。 所有这些过去的位置搜索引擎都在查询数据库以获得结果。
现在我采取了不同的方法，但由于我不是 100% 确定，我认为询问这个伟大的社区可以让我对这个方向感到更加安全，或者坚持我之前所做的事情。
因此，对于这个新搜索，我不会向数据库发送请求，而是使用 JSON 文件来提供搜索服务，仅当位置列表上更新、创建或删除某些内容时，该文件才会重新生成(查询数据库)。
我的疑问是，对 json 文件的高负载请求是否能与对数据库的高负载查询请求产生相同的效果？
通过 JSON 提供搜索结果以降低对数据库(和服务器资源)的影响是一个好方法还是不是一个好主意？
也许有人必须做出同样的决定并可以与我分享经验，或者也许您只是知道事情的真相并推荐我某种方法。
最佳答案
平面文件是穷人的数据库，甚至可能比重击的数据库更成问题。例如，读取和写入文件仍然需要锁定，并且无法扩展，因为所有应用服务器可能无法访问同一文件。
我的建议是以下任何一项:
对您当前的硬件进行基准测试，识别瓶颈，相应地进行扩展或扩展。
实现缓存层，这将节省对只读数据的昂贵查询。
实现真正的全文搜索引擎如ElasticSearch或SOLR .
对评论 #1 的回复:
<小时/>通过缓存数据，您可以完成同样的事情，而无需读/写平面文件(所有应用服务器必须可以访问该文件)。这只是我如何做到这一点的快速总结:
zip + 10 英里:
查询数据库，提取存储数据，json_encode，使用像 92562_10 这样的 key 结构进行缓存，然后存储在缓存中。现在，当其他用户输入 92562 + 10 时，他们将从缓存与数据库(或平面文件)中提取数据。
城市、州 + 50 英里:
与上面相同，但 key 构造可能类似于 murrieta_ca_50。
但通过缓存层，您可以获得更好的性能，并且缓存服务器将可供您的所有应用服务器使用，这比安装/配置 NFS 在网络上共享文件要容易得多。
关于php - JSON 平面文件与数据库查询，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30247663/