[Share]OpenSearch FAQs

1. How Are Users Billed for OpenSearch?
OpenSearch uses the QPS and document quantity as a reference, but as it is currently in beta testing, all its services are free. Therefore, you do not have to worry about billing.

2. How Many Documents Can I Upload?
In theory, there is no limit. For document quantity under 5 million, you can make your own adjustments as needed. For big data applications with over 5 million documents, you can apply for more quota.

3. How Long After Uploading Documents Can I Retrieve Them?
When using the API or SDK method to upload documents, they will be available in a matter of minutes. Currently, we are working to accelerate the process, so documents will soon be available in only seconds.

4. How Long Is the Search Latency?
The latency is closely related to the number of recall docs, the sort expressions, and the query statement complexity. Generally, it can vary from dozens to hundreds of milliseconds. You can independently create an application to measure it.

5. Can I Specify the Segmentation Method?
Segmentation is used in two processes, indexing and querying. Currently, the whole system uses public configurations and does not allow user customization. However, at present, the OpenSearch system supports multiple segmenting methods: 1) STRING: unsegmented, exact matching; 2) TEXT: segmented by term; and 3) SWS_TEXT: segmented by word. For a single field, the segmentation methods for indexing and querying are the same.

6. Does It Provide Correction and Synonym Query Functions?
At present, we are doing more work on query analysis and will soon allow users to specify various query term processing chains and custom dictionaries, such as correction, synonym, normalize, professional dictionaries, and LBS location rewriting. This will let users optimize the query results based on their actual scenarios.

7. Are Applications and Tables Related? Are There Restrictions and Performance Issues When Configuring Multiple Tables?
There are two concepts involved in this question: tables and applications.
Applications: An application can be understood as a search service. For websites, this is commonly a search box.
Tables: A single application can have multiple tables. This function was designed in order to make it easier to import data. For example, a forum has posts and users, so data exists in two areas. Therefore, it will correspond to two OpenSearch tables: a post table, including post IDs, titles, content, author IDs, URLs, No. of views, creation times, etc.; and a user table, including author IDs, author names, author URLs, etc. The two tables are associated through author IDs. This makes it easier for users to update data, as they only have to update the data to the corresponding table. Users can use the join operation within OpenSearch, ensuring that the data is sent to the engine as one large table.
The above is the table and application design scenario.

8. Are There OpenSearch Tutorials?
Currently, the OpenSearch help documents include a  Quick Start Guide and Typical Cases. These resources focus on how to use OpenSearch to create a search service.
In the future, we will gradually release common site-creation templates (WordPress, dicuz, etc.) and comparative analyses for mainstream open source search products. These resources will be available for you to reference. We would also be very grateful to anyone who would help us with this. After all, many hands make light work. We truly want to make this product a benchmark in the search field.

9. When Will This Product Support Related Searches and Drop-down Prompts?
We already plan to do this, and should support these functions some time in the future. Please check back later.

very nice and informative  keep it up