knowhere 2.0.0
Knowhere-2.0
At Knowhere 2.0, our aim is to be more accessible by lowering the barriers to learning and contribution. This involves restructuring our code for improved readability and scalability. Also, the previous version of our code has been relocated to the Knowhere-1.x
branch.
Inheritance
Knowhere 1.x inherited its structure from FAISS. However, as more indexes were integrated, this structure became difficult to maintain and understand. Knowhere 2.0 reworks this by adapting a one-layer FLAT inheritance structure.
In Knowhere 2.0, all indexes inherit from the IndexNode class, which has a clean structure. Furthermore, any new joining index in the future only needs to implement this IndexNode
class.
API
Knowhere 2.0 has simplified its interfaces by eliminating unused legacy interfaces and combining duplicate ones.
Config
Knowhere 1.x uses JSON as its configuration format, which requires custom code for serialization, deserialization, validation, and more. This can sometimes make it difficult to understand and extend the code.
In Knowhere 2.0, all you need to do is write a configuration class that inherits from the BaseConfig class for each index. Knowhere will take care of the rest of the work, including serialization, deserialization, and validation.
Here is an example code:
class SimpleConfig : public BaseConfig {
public:
KNOHWERE_DECLARE_CONFIG(BaseConfig) {
KNOWHERE_CONFIG_DECLARE_FIELD(k)
.set_default(15)
.description("search for top k similar vector.")
.for_all();
}
};
Error code
Instead of throwing multiple exceptions, Knowhere 2.0 will catch all exceptions and convert them into error codes. This will enhance the library's usability and readability, while also ensuring the caller's safety as Knowhere continues to expand.
Next step
As previously mentioned, our goal with Knowhere 2.0 is to be more open. As a result, we are working to improve the contribution experience. For instance, we are still in the process of creating a simple and straightforward set of APIs for third-party contributors who are interested in helping us expand our SIMD support.
In our future updates, we will prioritize support for more indexes, such as GPU-based and SCANN, which are critical areas for our development efforts.