https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42835 --- Comment #76 from David Cook <dcook@prosentient.com.au> --- (In reply to Nick Clemens (kidclamp) from comment #75)
I am working here on testing both methods to compare, based on the description of issues from Luis I think that subdocuments may be a better path, it was what I had looked into when researching this previously.
A quick google provides a few pro cons for the two: parent-child is faster for indexing, but slower for searching
subdocuments can be used in sort - not in parent-child
parent-child is recommended for write heavy operations due to indexing subdocuments requiring the whole object be reindexed
Overall, I think subdocuments perform as we want and we will need to focus on indexing speed.
I am currently building out a large dataset for testing and will update as I progress
It might be worthwhile to expand a bit on the terminology / concepts, Nick. I had no idea until now that Elasticsearch had capacity to do joins between different documents in the same index: https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/parent... According to that page "The join field shouldn’t be used like joins in a relation database. In Elasticsearch the key to good performance is to de-normalize your data into documents. Each join field, has_child or has_parent query adds a significant tax to your query performance. It can also trigger global ordinals to be built." -- By subdocuments do you mean "nested documents" like https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/nested ? It seems like the maximum number of nested JSON objects in a single document defaults to 10,000. I imagine that should be suitable for most libraries? I hope... -- You are receiving this mail because: You are watching all bug changes.