Elasticsearch itself has high requirements on the server, and the CPU and memory usage are also quite high. Whether to consider adding/replacing a more lightweight full-text search service, such as zinc, sonic, tantivy, typesense, meilisearch, etc. These can keep a low occupancy when full-text search is implemented.
2 Likes
Do these services also work performantly, especially with large amounts of data?
sonic works really well is the official recommendation of archivebox and in all options is the only one that can be a replace to elasticsearch.
Sonic has some good points
- Use less resource
- Support many indexes (For example, an index per user or an index per library)
From my point of view, Sonic has following drawbacks:
- Does not support HTTP
- Does not store original text snippet, which is required in Seafile to show matched text snippet in a long document
ZincSearch looks like a better alternative. Actually, we are already looking at support ZincSearch.
1 Like
Meilisearch with 30k objects the instance only used 20MB, it’s insany fast, I loved to have this a optionto seasearch because have more community:
Personally was terrible sad the move to remove ElasticSearch, because in the version 12 was frozen but lost feature, this forced the users to opt-in to use seasearch:
It’s okay add new tools, but in the same version drop feature was terrible, now I’m frozen in 11 because I don’t know if seasearch will work for me because keep ElasticSearch mean remove a important feature for my family. 
Removing support of doc/xls/ppt for full-text search is not related to the search backends (SeaSearch, ElasticSearch or Meilisearch).
Because doc/xls/ppt are in binary format, they require some heavy Java library to extract text from them.
Nowadays, it is better to use new docx/xlsx format.
1 Like
Oh!! This means docx/xlsx still works for ElasticSearch?
Yes, docx/xlsx still works