Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix mode/comp params so parameter overrides work #2083

Merged

Conversation

jmazanec15
Copy link
Member

@jmazanec15 jmazanec15 commented Sep 10, 2024

Description

In #1949, the intention was to allow users to override params when specifying the mode/compression. If this cannot be done, then it will make it wont be possible to tune indexing characteristics when mode is set, and is thus a broken experience. PR fixes this so that users can override params when using mode/compression params.

The main classes are:

  1. KNNVectorFieldMapper
  2. AbstractMethodResolver
  3. KNNMethodContext
  4. MethodComponentContext
  5. EngineResolver
  6. SpaceTypeResolver

Check List

  • Commits are signed per the DCO using --signoff.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@jmazanec15 jmazanec15 changed the title Add method parameter override for mode/comp Fix mode/comp params to support parameter overrides Sep 10, 2024
@jmazanec15 jmazanec15 force-pushed the support-method-overrides branch from 497ba8f to 3347eb0 Compare September 10, 2024 13:40
@jmazanec15 jmazanec15 changed the title Fix mode/comp params to support parameter overrides Fix mode/comp params so parameter overrides work Sep 10, 2024

this.knnEngine = knnMethodContext.knnEngine;
this.spaceType = knnMethodContext.spaceType;
this.isEngineConfigured = true;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we know if engine configured or not? The engine in passed knnMethodContext might not have been configured.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will only be not configured if it is built from parsing. Otherwise, it will be configured.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 its creating ambiguity, why is this needed? why can't we rely on nulls?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issue is with respect to BWC. Currently, in the parse method, we default to nmslib. So, we cannot swap this to null or else it might break BWC. For SpaceType, which is similarly defined, @heemin32 added an "SpaceType.UNDEFINED" option. I decided to not do this and just set whether it was explicitly configured on parse in order to check if we need to update.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably add a comment why its introduced and cannot be null

if (entry.getValue() instanceof MethodComponentContext) {
parameters.put(entry.getKey(), new MethodComponentContext((MethodComponentContext) entry.getValue()));
} else {
parameters.put(entry.getKey(), entry.getValue());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious what other types will be there. Is it okay not to copy them?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR adds capability to override parameters when specifying mode and
compression. In order to do this, I add functionality for creating a
deep copy of KNNMethodContext and MethodComponentContext so that we
wouldnt overwrite user provided config. Then, re-arranged some of the
parameter resolution logic.

Signed-off-by: John Mazanec <[email protected]>
@jmazanec15 jmazanec15 force-pushed the support-method-overrides branch from 3347eb0 to 1eebcf6 Compare September 10, 2024 16:30

if (isModeConfigured && builder.vectorDataType.getValue() != VectorDataType.FLOAT) {
private void validateModeAndCompressionForDataType(KNNVectorFieldMapper.Builder builder) {
boolean isModeOrCompressionConfigured = builder.mode.isConfigured() || builder.compressionLevel.isConfigured();
Copy link
Collaborator

@shatejas shatejas Sep 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why fail for mode = in_memory and/or compression = 1x for float?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not for float - for non float we dont support setting it. I guess I can change this to support in_memory/1x for binary and byte to be no-op. Is this what you meant?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so if vector data type is float, mode is in-memory and compression is 1x, doesn't that mean it should the current code path without any quantization? what am I missing?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh nvm I think I missed the ! in the condition below

.getKnnVectorSimilarityFunction()
.getVectorSimilarityFunction();

this.fieldType = vectorDataType.createKnnVectorFieldType(knnMappingConfig.getDimension(), vectorSimilarityFunction);

if (this.hasDocValues) {
this.vectorFieldType = buildDocValuesFieldType(knnMethodContext.getKnnEngine());
this.vectorFieldType = buildDocValuesFieldType(resolvedKnnMethodContext.getKnnEngine());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is some ambiguity when to use resolved and when to use original. I am not sure if there is a way to resolve that, there is a comment around it, I think its best to add guidelines in that comment

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, Ill add a comment

@@ -14,7 +14,7 @@
/**
* KNNLibrary is an interface that helps the plugin communicate with k-NN libraries
*/
public interface KNNLibrary {
public interface KNNLibrary extends MethodResolver {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need to implement this? Would prefer punting it for now and rethink for later because no other methods are through interfaces in this interface

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what you mean. Typically, the requests are routed to the correct library via the knn engine. So, by implementing on the engine and library, we can efficiently route it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its odd when KNNLibrary doesn't follow the pattern for other functions which are stand alone but can be broken down into interfaces


this.knnEngine = knnMethodContext.knnEngine;
this.spaceType = knnMethodContext.spaceType;
this.isEngineConfigured = true;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 its creating ambiguity, why is this needed? why can't we rely on nulls?

heemin32
heemin32 previously approved these changes Sep 10, 2024
Signed-off-by: John Mazanec <[email protected]>
@jmazanec15 jmazanec15 force-pushed the support-method-overrides branch from 95b7cda to bc8cae5 Compare September 10, 2024 20:58
@jmazanec15 jmazanec15 merged commit 270ac6a into opensearch-project:main Sep 10, 2024
27 of 29 checks passed
opensearch-trigger-bot bot pushed a commit that referenced this pull request Sep 10, 2024
PR adds capability to override parameters when specifying mode and
compression. In order to do this, I add functionality for creating a
deep copy of KNNMethodContext and MethodComponentContext so that we
wouldnt overwrite user provided config. Then, re-arranged some of the
parameter resolution logic.

Signed-off-by: John Mazanec <[email protected]>
(cherry picked from commit 270ac6a)
opensearch-trigger-bot bot pushed a commit that referenced this pull request Sep 10, 2024
PR adds capability to override parameters when specifying mode and
compression. In order to do this, I add functionality for creating a
deep copy of KNNMethodContext and MethodComponentContext so that we
wouldnt overwrite user provided config. Then, re-arranged some of the
parameter resolution logic.

Signed-off-by: John Mazanec <[email protected]>
(cherry picked from commit 270ac6a)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants