平衡自动完成搜索的服务器/客户端负载
作为前言，我正在使用 Google App Engine，它不允许 JOINS 或全文搜索。
问题：我正在尝试构建一个自动完成搜索栏（如 Google Instant Search）。为了解释的目的，假设数据库中的每个条目都是一个没有空格的大字符串。如果我输入“cr”，我会获得所有以“cr”开头的字符串的自动补全帮助。我找到了一种在 Google App Engine 中实现此搜索的方法，但每次在输入搜索栏中按下按键时将查询发布到服务器似乎是一个可怕的想法。
我在想客户端和服务器端缓存的组合可以帮助有效地做到这一点？有人有什么想法吗？或者只是有关最佳实践的提示？谢谢。
To preface, I'm working with Google App Engine which does not allow JOINS or Full Text Search.
Problem: I'm trying to build an autocompletion search bar (like Google Instant Search). For the purpose of explaining, assume that each entry in the database is a big string with no spaces. If I type in "cr", I get an autocompletion assist with all the strings that begin with "cr". I figured out a way to achieve this search in Google App Engine but it seems like a horrible idea to POST a query to the server everytime a key is pressed in the input search bar.
I'm thinking that a combination of client side and server side caching could help do this efficiently? Anybody have any ideas? Or just tips on best practices? Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
也许您可以执行诸如每次按下按键或每 1 秒一次（以频率较低者为准）“请求最多 50 个选项”之类的操作。我认为一系列的帖子请求将是一个很好的解决方案。
在服务器上，您应该预期多个相关查询，因此即使您一次只向客户端发送 50 个查询，您也可以缓存 1000 个结果，并且如果下一个查询将您带到这些结果的子集，您将受益匪浅。
Maybe you could do something like "request a max of 50 options" every time a key is pressed or every 1 second, whichever is less frequent. I think a series of post requests would be a good solution.
On the server, you should expect multiple related queries, so even though you're only sending 50 at a time to the client, you could cache 1000 results and benefit if the next query takes you to a subset of those results.
确实没有办法避免对服务器进行频繁的查询——无论是每次按键，还是在短暂的暂停之后。您可以通过让服务器不仅发送当前字符串的建议，还发送它认为最有可能的下一个字符的建议来稍微改进这一点，从而使客户端能够避免在某些情况下进行查询。不过，您的主要重点可能应该是确保服务器端快速高效。
There's really no way around doing frequent queries to the server - either every keypress, or after a slight pause. You could refine this a bit by having the server send not only the suggestions for the current string, but also for what it thinks are the most likely next characters, enabling the client to avoid the need for a query in some cases. Your main focus should probably be on making sure the server end of this is fast and efficient, though.