Modify a table

This example shows how to modify data shards in a table and apply the changes:

1. On the Table Management page, find the table you want to modify and click Edit.

2. To modify the number of data shards, edit the basic table information:

   The edit page includes three fields: Table Name (read-only), Number of data shards, and Remarks. After you enter the number of data shards, click Next to continue.

   Note:

   • Set the number of data shards to a positive integer up to 256. A suitable number can improve full build speed and single-query performance. For some existing instances, all index tables must have the same number of data shards. Alternatively, one index table can have a single data shard if the others have an identical number of data shards.

   • If Searcher worker usage reaches its limit, you cannot increase the number of data shards. You must first scale out the Searcher workers. After scaling out, you can increase the number of shards only if the number of data shards in the table <= the number of Searcher workers. For more information about scaling out, see upgrade or downgrade.

3. After you verify the data source information, click Next:

   To make changes, you must provide the AccessKey, AccessKey Secret, Project, Table, and Partition, and configure Automatic Index Rebuild.

   Note

   For an API data source, click Next directly. For a MaxCompute data source, an OSS data source, or a DLF data source, the full data source information is not changed by default. If you need to make changes, select the option to change, enter the new configuration details, pass the Data Source Check, and then click Next.

4. Configure the fields. If needed, you can adjust the field type, advanced configurations, and other settings. After making adjustments, click Next:

   In the field configuration table, you can set properties for each field, such as Field Name, Field Type, Primary Key, Vector Field, Requires Embedding, Multi-value, Advanced Configurations, and Custom Default Value. The example table has three fields: id (INT32, set as the primary key), embedding (FLOAT, with Vector Field and Multi-value selected, using ^] as the separator), and number (INT8, with a custom default value of 0). You can add a new field by clicking the + icon at the bottom or remove an existing field by clicking Delete.

5. Configure the index schema. You can enable document expiration settings and adjust vector index configurations here. After making adjustments, click Next:

   For Automatic Document Expiration, select Disabled. Set Index Name to vector and set hybrid search to Disabled. The included fields are the primary key field id, the namespace, and the vector field vector (dense vector field). Set Vector Dimension to 1, select SquaredEuclidean for Distance Type, set Real-time Indexing to true, and select Qc for Vector Index Algorithm.

6. Confirm your edits. Select an option based on your data source type and click Confirm:

   • MaxCompute data source: For Index Rebuild Mode, select Import Full Data.

   • OSS data source: For Index Rebuild Mode, select Import Full Data.

   • API push data source: For Index Rebuild Mode, select Empty Data.

   • DLF data source: For Index Rebuild Mode, select Import Full Data.

     Important

     • After you modify a table that uses a MaxCompute data source, the index rebuilding process pulls the configured partition data and the incremental API data based on the Timestamp configuration.

     • If you select Empty Data, the system clears previously pushed data and starts tracking real-time data from the specified timestamp. Proceed with caution.

     • Timestamp: Specifies how far back the new full build should retrieve incremental API data. You can retrieve API data from the last three days.

   In the Effective Method section, select either Confirm Edits and Rebuild Index Immediately or Take Effect on Next Full Build.

7. To view the change progress, go to the Change History > Data Source Changes page:

   The page displays change records in a timeline format. The manual full indexing pipeline includes seven stages: init, trigger, scan, bs_submit, build, suez_submit, and switch. The push configuration pipeline includes four stages: init and check, publish config version, update worker info, and trigger build. Each stage is color-coded to indicate its execution status.

   Note

   After you modify a table and rebuild the index, the system generates two finite-state machine (FSM) workflows: one for push configuration and one for manual full indexing. The changes take effect only after both workflows are complete.