因此，我有一个主 indexedDB 对象存储，其中包含大约 30.000 条记录，我必须在这些记录上运行全文搜索查询。使用 ydn fts 插件执行此操作会生成第二个对象存储，其中包含大约 300.000 条记录。现在，由于生成这个“索引”数据存储需要很长时间，我认为分发索引的内容也更快。这反过来生成了一个大约 7MB 的 zip 文件，在客户端解压缩后会提供超过 40MB 的数据。目前，我循环遍历这些数据，将其一一插入（异步，因此回调时间用于解析下一行），这大约需要 20 分钟。当我通过网络工作者在我的应用程序后台执行此操作时，这并非完全不可接受，但仍然感觉非常低效。一旦它被填充，数据库实际上足够快，甚至可以在中高端移动设备上使用，但是移动设备上 20 分钟到 1 小时的填充时间简直太疯狂了。有什么建议可以改进吗？或者是最小化记录数量的唯一选择？（这意味着编写我自己的全文搜索......不是我期待的）
问问题
393 次
1 回答
1
对于移动浏览器，您的数据量非常大。除非用户经常使用您的应用程序，否则不值得将所有数据发送给客户端。您应该使用服务器端进行全文搜索，同时抓住机会，如本示例应用程序所示。这样，用户不必等待全文搜索索引。
全文搜索需要索引除一些词干词之外的所有标记（词）。仅当lang设置为时才会激活词干提取en。您应该分析您的应用程序的哪些部分需要时间。我猜浏览器花费了大部分时间，在这种情况下，除了并行化之外，您无法进行太多优化。发送索引数据（如上所述）不会有太大帮助（但请通过比较确认）。Web 工作者也无济于事。我认为您的应用程序没有因索引而导致响应缓慢的问题。
除了索引时间慢之外，您还有其他抱怨吗？
于 2014-02-17T04:36:33.720 回答