I started looking into collective.elasticsearch because some of our larger Plone sites have serious memory issues. I then discovered another related package: collective.elastic.plone.
They appear to solve similar problems, but with different architectures. collective.elasticsearch integrates deeply with portal_catalog and can move indexes such as Title, Description and SearchableText to an external search backend. collective.elastic.plone replaces SearchableText with a proxy index and uses a separate ingestion service.
I like that collective.elastic.plone supports TLS and OpenSearch out of the box, which fits our enterprise OpenSearch environment. On the other hand, collective.elasticsearch appears easier to introduce and seems to have broader community adoption.
Before choosing either package, I would like to understand the development workflow used by existing users.
As I understand it, indexes moved out of the catalog are no longer included in FileStorage backups. Our developers regularly restore these backups for testing features, troubleshooting problems and working with representative content.
This leaves me with a few questions:
- How should we decide between these two packages?
- Is anyone using them with a similar development workflow?
- How do developers obtain the corresponding search index after restoring a FileStorage backup?
I currently see several possible approaches:
- Run OpenSearch locally and rebuild the index. This provides isolation but could be very expensive for our larger sites.
- Restore an OpenSearch snapshot into a local cluster or a uniquely named index on a shared development cluster.
- Develop without OpenSearch and recreate the missing ZCatalog indexes locally, if that is supported.
- Stop using FileStorage copies and instead give developers access to isolated replicas of both the database and OpenSearch. This seems considerably more complex.
I would be interested in hearing how others handle this in practice, as well as their experiences choosing between the two packages.