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