GitHub user imbajin edited a comment on the discussion: Secondary index and
full tet query in Hugegraph
1. The reason why we changed from JG's cheat mode to a built-in tokenizer to
achieve simple `full-text` indexing is because in production environment, ES
will encounter many problems in a large number of point and edge situations(And
it has increased a significant amount of write/query process burden and
maintenance costs, also have the issue of data consistency)
- In addition, based on actual user feedback, the demand for complete
full-text indexing is not very strong, and graph databases are not attempting
to create a universal DB collection similar to `PostgreSQL`
- This requires a significant amount of manpower to maintain different
backend/storage systems. Initially, this may seem like a good idea, but later
iterations may encounter a lot of trouble. This is why JG's data structure has
not changed much over the years, as it provides 2 heavy backend abstractions,
making it difficult to optimize and adjust performance separately (otherwise
the cost would be too high)
2. We do consider implementing a built-in vector index engine(like faiss-java
or `lucene`) , but please note that it is not an external implementation of a
separate **vector database** (Too heavy)
GitHub link:
https://github.com/apache/incubator-hugegraph/discussions/2739#discussioncomment-12346626
----
This is an automatically sent email for dev@hugegraph.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@hugegraph.apache.org
