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