[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[],[],null,["Asynchronous secondary index queries\n| **Preview**\n|\n|\n| This product or feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA products and features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nThis document provides examples of common query patterns for building\nasynchronous secondary indexes in Bigtable. The examples use IDs and\nvalues that are similar to those in\n[Data for examples](/bigtable/docs/using-filters#data) and you can\n[create a test table](/bigtable/docs/creating-test-table#create-test_table) to\ntest the queries.\n\nBefore you read this page, familiarize yourself with\n[Create an asynchronous secondary index](/bigtable/docs/asynchronous-secondary-index)\nand\n[GoogleSQL for Bigtable](/bigtable/docs/googlesql-overview).\n\nExample queries\n\nThe following examples show how to create asynchronous secondary indexes using\ndifferent GoogleSQL queries.\n\nCreate an inverted index based on a column qualifier and values\n\nThe following query creates an inverted index by extracting all key-value pairs\nfrom a column family that has a flexible schema. It uses `MAP_ENTRIES` to get an\narray of all data that the `stats_summary` column family stores, and then\n`UNNEST` to transform each key-value pair into a separate row. The resulting\nindex allows for fast lookups based on `stat_description` and `stat_value`. If\nyou add new types of statistics to the source table, then Bigtable\nincludes them in the asynchronous index automatically. \n\n SELECT\n stats.key as stat_description,\n stats.value as stat_value,\n _key as original_key,\n cell_plan as cell_plan\n FROM test_table\n CROSS JOIN UNNEST(MAP_ENTRIES(stats_summary)) stats\n ORDER BY stat_description, stat_value, original_key\n\nCreate a new row key based on existing data\n\nThe following example creates a new index key, `total_plan_capacity`, by\ncategorizing data plans that the `cell_plan` column family stores. The query\nuses `MAP_KEYS` to get all keys in `cell_plan` and `ARRAY_INCLUDES_ANY` to\nfilter for specific data plan keys. A `CASE` statement then defines the logic to\nassign a `total_plan_capacity` category that's based on the presence and values\nof these data plans. This allows for efficient lookups based on the combined\ndata plan capacity. \n\n SELECT\n CASE\n WHEN\n cell_plan['data_plan_01gb'] = \"true\"\n AND (cell_plan['data_plan_05gb'] = \"false\" OR cell_plan['data_plan_05gb'] IS NULL)\n AND (cell_plan['data_plan_10gb'] = \"false\" OR cell_plan['data_plan_10gb'] IS NULL)\n THEN 'x-small'\n\n WHEN\n cell_plan['data_plan_01gb'] = \"true\"\n AND (cell_plan['data_plan_05gb'] = \"true\")\n AND (cell_plan['data_plan_10gb'] = \"false\" OR cell_plan['data_plan_10gb'] IS NULL)\n THEN 'small'\n\n WHEN\n cell_plan['data_plan_01gb'] = \"true\"\n AND (cell_plan['data_plan_05gb'] = \"false\" OR cell_plan['data_plan_05gb'] IS NULL)\n AND (cell_plan['data_plan_10gb'] = \"true\")\n THEN 'medium'\n\n WHEN\n (cell_plan['data_plan_01gb'] = \"false\" OR cell_plan['data_plan_01gb'] IS NULL)\n AND (cell_plan['data_plan_05gb'] = \"true\")\n AND (cell_plan['data_plan_10gb'] = \"true\")\n THEN 'large'\n\n WHEN\n cell_plan['data_plan_01gb'] = \"true\"\n AND (cell_plan['data_plan_05gb'] = \"true\")\n AND (cell_plan['data_plan_10gb'] = \"true\")\n THEN 'x-large'\n END as total_plan_capacity,\n _key as original_key,\n stats_summary\n FROM test_table\n WHERE ARRAY_INCLUDES_ANY(MAP_KEYS(cell_plan), [\"data_plan_01gb\", \"data_plan_05gb\",\"data_plan_10gb\"])\n ORDER BY total_plan_capacity, original_key\n\nCreate a time-series-based index\n\nBigtable stores each cell value and its associated timestamp. By\nusing the `WITH_HISTORY=\u003eTRUE` flag in the `FROM` clause, you can retrieve all\nversions of data and their timestamps. The `UNPACK` table function then expands\nthe query results so that each timestamped value appears on its own row with a\nseparate `_timestamp` column. This lets you create an asynchronous secondary\nindex where the new row key is based on these timestamp values, enabling quick\nlookups that are based on time ranges. \n\n SELECT\n _timestamp as stats_timestamp,\n _key as original_key,\n stats_summary\n FROM UNPACK((\n select\n _key,\n stats_summary\n FROM\n test_table (WITH_HISTORY=\u003eTRUE)\n ))\n ORDER BY stats_timestamp, original_key\n\nCreate an index entry for items and values in a JSON cell\n\nBigtable is often used as a key-value store for large-scale\nworkloads, including data in formats such as JSON. The following example shows\nhow to create an asynchronous secondary index for fast lookups of data that JSON\nstores. The query uses `JSON_EXTRACT` to extract the `store_id` from a JSON\nstring within the `transaction_information` column family in a table named\n`sales`. This index allows for quick retrieval of sales transactions by specific\nstore IDs. \n\n SELECT\n JSON_EXTRACT(transaction_information[\"json\"], \"$.store_id\") as store_id,\n _key as original_key,\n transaction_information\n from sales\n ORDER BY store_id, original_key;\n\nWhat's next\n\n- [Continuous materialized view queries](/bigtable/docs/continuous-materialized-view-queries)\n- [Create and manage continuous materialized views](/bigtable/docs/manage-continuous-materialized-views)"]]