You can use the multiple efficient index schemas of search index to solve complex query problems in big data scenarios.
A table in Table Store is a distributed NoSQL data schema. Such tables can support storage and read/write of large-scale data, such as monitoring data and log data. Originally, Table Store only supports queries based on primary key columns, such as reading data in a single row and within a specified range. Other types of queries were not available, such as queries based on non-primary key columns and the bool query.
To resolve this issue, Table Store has provided the search index feature. Based on inverted indexes and column-oriented storage, search index supports multiple queries, including but not limited to:
- Query based on non-primary key columns
- Bool query
- Full-text search
- Query by geographical location
- Prefix query
- Fuzzy query
- Nested query
Aside from queries based on primary key columns in the primary table, Table Store provides two index schemas for accelerated queries: global secondary index and search index. The following table describes the differences among the three indexes.
|Table||A table is similar to a big map. Tables only support queries based on primary key columns.||
|Global secondary index||You can create one or more global secondary indexes and issue query requests against these indexes. This way, you can perform queries based on the primary key columns of these indexes.||
|Search index||Search index uses inverted indexes, Bkd-trees, and column-oriented storage to meet various query scenarios.||All query and analysis scenarios that the table and the global secondary index do not support.|
If you have created a search index for a table, data is written to the table first. When the write is successful, success message is immediately returned to the user. At the same time, another asynchronous thread reads the newly written data from the table and writes the data to the search index. This is an asynchronous process.
The asynchronous data synchronization between a table and search index does not affect the write performance of Table Store. The indexing latency is within seconds, most of which are within 10 seconds. You can view the indexing latency in the Table Store console in real time.TTL
You cannot create a search index in a table where you have specified the time to live (TTL) parameter.max versions
You cannot create a search index in a table where you have specified the max versions parameter.
You can customize the timestamp whenever you write data to an attribute column that allows only one version. If you first write a major version number and then a minor version number, the index of the major version number may be overwritten by the index of the minor version number.
Search index can solve complex query problems in big data scenarios. Other systems such as databases and search engines can also solve data query problems. The differences between Table Store and databases and search engines are illustrated as follows:
Table Store can provide all features of databases and search engines, except for join
operations, transactions, and relevance of search results. Table Store also has high
data reliability of databases and supports advanced queries of search engines. Therefore,
Table Store can replace the common
database plus search engine architecture. If you do not need join operations, transactions, and relevance of search results,
we recommend that you use search index of Table Store.