在Grails Searchable 插件中使用mirrorChanges = true 时是否需要bulkIndexOnStartup？
mirrorChanges 选项将镜像通过 GORM/Hibernate 所做的所有更改，因此如果我没有对数据库进行任何外部更改，那么是否需要bulkIndexOnStartup？
问题是我们的数据集非常大（>1M 行），批量索引器可能需要 30 多分钟。
当设置为“fork”时，如果通过 GORM 进行任何更改，lucene 将崩溃，因为 lucene 不是线程安全的，并且 GORM 事务将在分叉的批量索引线程运行时尝试更新索引。
设置为 true 时，应用程序将在这 30 多分钟内完成初始化。
The mirrorChanges option will mirror all changes made through GORM/Hibernate, so if I'm not making any external changes to the database, then is bulkIndexOnStartup needed?
The problem is that our data set is very large (>1M rows) and the bulk indexer may take 30+ minutes.
When set to 'fork' lucene will crash if any changes are made though the GORM, because lucene is not thread safe and the GORM transaction will attempt to update the index while the forked bulk index thread is running.
When set to true, the application will finish initializing for those 30+ minutes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您不修改来自其他源的数据，则无需将bulkIndexOnStartup 设置为true，特别是当您将mirrorChanges 设置为true 时。这几乎就是我们在应用程序中处理它的方式。我们有一个控制器操作，它为特定类调用分叉索引器，以便我们可以在需要时按需调用它，例如，如果由于某种原因我们需要直接更新数据库。然后，我们为特定类而不是整个类集调用索引器，这样如果我们需要调用它，就不会花那么长时间。
If you are not modifying the data from another source, then you don't need to set bulkIndexOnStartup to true, specially if you set mirrorChanges to true. This is pretty much how we handle it in our application. We have a controller action that calls the indexer, forked, for a specific class so we can call it on demand in case we need to, for example if for some reason we needed to update the database directly. We then call the indexer for a specific class and not the entire set of class, in that way if we need to call it then it won't take that long.
如果您正在镜像更改，则不需要使用bulkIndexOnStartup。
我们有一个小得多的数据集，所以当我们将发布作为更多维护任务时，我们实际上将“fork”设置为一个选项来执行bulkIndexOnStartup
bulkIndexOnStartup should not be needed if you are mirroring changes.
we have a much smaller dataset so we actually do bulkIndexOnStartup with 'fork' set as an option when we do releases as more of a maintenance task