optimizeTopK in view

Author: rashtao

core/src/main/java/com/arangodb/entity/arangosearch/ArangoSearchPropertiesEntity.java

@@ -41,6 +41,7 @@ public final class ArangoSearchPropertiesEntity extends ViewEntity {
     private Collection<CollectionLink> links;
     private ArangoSearchCompression primarySortCompression;
     private Collection<StoredValue> storedValues;
+    private Collection<String> optimizeTopK;
     private Boolean primarySortCache;
     private Boolean primaryKeyCache;
 
@@ -121,6 +122,14 @@ public Collection<StoredValue> getStoredValues() {
         return storedValues;
     }
 
+    /**
+     * @return An array of strings defining optimized sort expressions.
+     * @since ArangoDB 3.11, Enterprise Edition only
+     */
+    public Collection<String> getOptimizeTopK() {
+        return optimizeTopK;
+    }
+
     public Boolean getPrimarySortCache() {
         return primarySortCache;
     }

core/src/main/java/com/arangodb/model/arangosearch/ArangoSearchCreateOptions.java

@@ -43,6 +43,7 @@ public final class ArangoSearchCreateOptions {
     private Collection<PrimarySort> primarySorts;
     private ArangoSearchCompression primarySortCompression;
     private Collection<StoredValue> storedValues;
+    private Collection<String> optimizeTopK;
     private Boolean primarySortCache;
     private Boolean primaryKeyCache;
 
@@ -57,14 +58,11 @@ ArangoSearchCreateOptions name(final String name) {
     }
 
     /**
-     * @param consolidationIntervalMsec Wait at least this many milliseconds between committing index data changes
-     *                                  and making them visible to
-     *                                  queries (default: 60000, to disable use: 0). For the case where there are a
-     *                                  lot of inserts/updates, a
-     *                                  lower value, until commit, will cause the index not to account for them and
-     *                                  memory usage would
-     *                                  continue to grow. For the case where there are a few inserts/updates, a
-     *                                  higher value will impact
+     * @param consolidationIntervalMsec Wait at least this many milliseconds between committing index data changes and
+     *                                  making them visible to queries (default: 60000, to disable use: 0). For the case
+     *                                  where there are a lot of inserts/updates, a lower value, until commit, will
+     *                                  cause the index not to account for them and memory usage would continue to grow.
+     *                                  For the case where there are a few inserts/updates, a higher value will impact
      *                                  performance and waste disk space for each commit call without any added
      *                                  benefits.
      * @return options
@@ -76,26 +74,19 @@ public ArangoSearchCreateOptions consolidationIntervalMsec(final Long consolidat
 
     /**
      * @param commitIntervalMsec Wait at least this many milliseconds between committing view data store changes and
-     *                           making documents visible to
-     *                           queries (default: 1000, to disable use: 0). For the case where there are a lot of
-     *                           inserts/updates, a lower value,
-     *                           until commit, will cause the index not to account for them and memory usage would
-     *                           continue to grow. For the case
-     *                           where there are a few inserts/updates, a higher value will impact performance and
-     *                           waste disk space for each
-     *                           commit call without any added benefits. Background: For data retrieval ArangoSearch
-     *                           views follow the concept of
-     *                           “eventually-consistent”, i.e. eventually all the data in ArangoDB will be matched by
-     *                           corresponding query
-     *                           expressions. The concept of ArangoSearch view “commit” operation is introduced to
-     *                           control the upper-bound on the
-     *                           time until document addition/removals are actually reflected by corresponding query
-     *                           expressions. Once a “commit”
-     *                           operation is complete all documents added/removed prior to the start of the “commit”
-     *                           operation will be reflected
-     *                           by queries invoked in subsequent ArangoDB transactions, in-progress ArangoDB
-     *                           transactions will still continue to
-     *                           return a repeatable-read state.
+     *                           making documents visible to queries (default: 1000, to disable use: 0). For the case
+     *                           where there are a lot of inserts/updates, a lower value, until commit, will cause the
+     *                           index not to account for them and memory usage would continue to grow. For the case
+     *                           where there are a few inserts/updates, a higher value will impact performance and waste
+     *                           disk space for each commit call without any added benefits. Background: For data
+     *                           retrieval ArangoSearch views follow the concept of “eventually-consistent”, i.e.
+     *                           eventually all the data in ArangoDB will be matched by corresponding query expressions.
+     *                           The concept of ArangoSearch view “commit” operation is introduced to control the
+     *                           upper-bound on the time until document addition/removals are actually reflected by
+     *                           corresponding query expressions. Once a “commit” operation is complete all documents
+     *                           added/removed prior to the start of the “commit” operation will be reflected by queries
+     *                           invoked in subsequent ArangoDB transactions, in-progress ArangoDB transactions will
+     *                           still continue to return a repeatable-read state.
      * @return options
      */
     public ArangoSearchCreateOptions commitIntervalMsec(final Long commitIntervalMsec) {
@@ -105,14 +96,11 @@ public ArangoSearchCreateOptions commitIntervalMsec(final Long commitIntervalMse
 
     /**
      * @param cleanupIntervalStep Wait at least this many commits between removing unused files in data directory
-     *                            (default: 10, to
-     *                            disable use: 0). For the case where the consolidation policies merge segments often
-     *                            (i.e. a lot of
-     *                            commit+consolidate), a lower value will cause a lot of disk space to be wasted. For
-     *                            the case where the
-     *                            consolidation policies rarely merge segments (i.e. few inserts/deletes), a higher
-     *                            value will impact
-     *                            performance without any added benefits.
+     *                            (default: 10, to disable use: 0). For the case where the consolidation policies merge
+     *                            segments often (i.e. a lot of commit+consolidate), a lower value will cause a lot of
+     *                            disk space to be wasted. For the case where the consolidation policies rarely merge
+     *                            segments (i.e. few inserts/deletes), a higher value will impact performance without
+     *                            any added benefits.
      * @return options
      */
     public ArangoSearchCreateOptions cleanupIntervalStep(final Long cleanupIntervalStep) {
@@ -164,6 +152,16 @@ public ArangoSearchCreateOptions storedValues(final StoredValue... storedValues)
         return this;
     }
 
+    /**
+     * @param optimizeTopK An array of strings defining sort expressions that you want to optimize.
+     * @return options
+     * @since ArangoDB 3.11, Enterprise Edition only
+     */
+    public ArangoSearchCreateOptions optimizeTopK(final String... optimizeTopK) {
+        this.optimizeTopK = Arrays.asList(optimizeTopK);
+        return this;
+    }
+
     /**
      * @param primarySortCache If you enable this option, then the primary sort columns are always cached in memory.
      *                         This can improve the performance of queries that utilize the primary sort order.
@@ -231,6 +229,10 @@ public Collection<StoredValue> getStoredValues() {
         return storedValues;
     }
 
+    public Collection<String> getOptimizeTopK() {
+        return optimizeTopK;
+    }
+
     public Boolean getPrimarySortCache() {
         return primarySortCache;
     }

driver/src/test/java/com/arangodb/ArangoSearchTest.java

@@ -424,7 +424,7 @@ private void createGetAndDeleteTypedAnalyzer(ArangoDatabase db, SearchAnalyzer a
         // getAnalyzers
         SearchAnalyzer foundAnalyzer =
                 db.getSearchAnalyzers().stream().filter(it -> it.getName().equals(fullyQualifiedName))
-                .findFirst().get();
+                        .findFirst().get();
         assertThat(foundAnalyzer).isEqualTo(analyzer);
 
         // deleteAnalyzer
@@ -672,6 +672,8 @@ void arangoSearchOptions(ArangoDatabase db) {
                 .primaryKeyCache(true);
         StoredValue storedValue = new StoredValue(Arrays.asList("a", "b"), ArangoSearchCompression.none, true);
         options.storedValues(storedValue);
+        String[] optimizeTopK = new String[]{"BM25(@doc) DESC", "TFIDF(@doc) DESC"};
+        options.optimizeTopK(optimizeTopK);
 
         final ArangoSearch view = db.arangoSearch(viewName);
         view.create(options);
@@ -713,6 +715,11 @@ void arangoSearchOptions(ArangoDatabase db) {
             FieldLink nested = fieldLink.getNested().iterator().next();
             assertThat(nested.getName()).isEqualTo("f2");
         }
+
+        if (isEnterprise() && isAtLeastVersion(3, 11)) {
+            assertThat(properties.getOptimizeTopK()).containsExactly(optimizeTopK);
+        }
+
     }
 
     @ParameterizedTest(name = "{index}")