Go 1.11은 지원이 종료되었으며 2026년 1월 31일에 지원 중단됩니다. 지원 중단 후에는 조직에서 이전에 조직 정책을 사용하여 레거시 런타임의 배포를 다시 사용 설정한 경우에도 Go 1.11 애플리케이션을 배포할 수 없습니다. 기존 Go 1.11 애플리케이션은 지원 중단 날짜 이후에도 계속 실행되고 트래픽을 수신합니다. 지원되는 최신 Go 버전으로 마이그레이션하는 것이 좋습니다.
대부분의 Datastore 쿼리는 전체 항목을 결과로 반환하지만 실제로 애플리케이션이 관심을 갖는 항목의 속성은 몇 가지에 불과한 경우가 많습니다. 프로젝션 쿼리를 사용하면 실제로 필요한 항목의 특정 속성만 Datastore에 쿼리할 수 있으므로 전체 항목을 검색할 때보다 지연 시간과 비용이 낮아집니다.
프로젝션 쿼리는 SQL 쿼리 형식과 유사합니다.
SELECT name, email, phone FROM CUSTOMER
아래에 설명된 제한사항에 따라 표준 항목 쿼리에 사용할 수 있는 모든 필터링 및 정렬 기능을 사용할 수 있습니다. 쿼리는 지정된 속성(위 예시에서는 name, email, phone) 값만 채워진 요약된 결과를 반환하며 다른 모든 속성에는 데이터가 없습니다.
[[["이해하기 쉬움","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)"],[[["\u003cp\u003eThis API supports first-generation runtimes and is applicable when upgrading to corresponding second-generation runtimes, but for App Engine Go 1.12+ runtime updates, a separate migration guide should be referenced.\u003c/p\u003e\n"],["\u003cp\u003eProjection queries retrieve only specific properties of an entity, reducing latency and cost compared to retrieving the entire entity.\u003c/p\u003e\n"],["\u003cp\u003eProjection queries can use filtering and sorting features similar to standard entity queries, but they are subject to limitations like only indexed properties can be used, and projected properties cannot be used in equality filters.\u003c/p\u003e\n"],["\u003cp\u003eUsing the \u003ccode\u003eDistinct\u003c/code\u003e method with projection queries ensures that only unique result sets are returned based on the projected properties.\u003c/p\u003e\n"],["\u003cp\u003eAll properties included in a projection query must be in a Datastore index, and adding new properties to an existing projection query will require building a new index.\u003c/p\u003e\n"]]],[],null,["# Projection Queries\n\n| This API is supported for first-generation runtimes and can be used when [upgrading to corresponding second-generation runtimes](/appengine/docs/standard/\n| go\n| /services/access). If you are updating to the App Engine Go 1.12+ runtime, refer to the [migration guide](/appengine/migration-center/standard/migrate-to-second-gen/go-differences) to learn about your migration options for legacy bundled services.\n\nMost Datastore [queries](/appengine/docs/legacy/standard/go111/datastore/queries) return whole entities as their results, but often an application is actually interested in only a few of the entity's properties. *Projection queries* allow you to query Datastore for just those specific properties of an entity that you actually need, at lower latency and cost than retrieving the entire entity.\n\nProjection queries are similar to SQL queries of the form: \n\n SELECT name, email, phone FROM CUSTOMER\n\nYou can use all of the filtering and sorting features available for standard entity queries, subject to the [limitations](#Limitations_on_projections) described below. The query returns abridged results with only the specified properties (`name`, `email`, and `phone` in the example) populated with values; all other properties have no data.\n\nUsing projection queries in Go 1.11\n-----------------------------------\n\nWhen preparing a [`Query`](/appengine/docs/legacy/standard/go111/datastore/reference#Query), specify a projection using the [`Project`](/appengine/docs/legacy/standard/go111/datastore/reference#Query.Project) method: \n\n q := datastore.NewQuery(\"People\").Project(\"FirstName\", \"LastName\")\n\nYou handle the results of these queries just as you would for a standard entity query: for example, by iterating over the results.\n\nThe following example queries for the `Title`, `ReadPath`, and `DateWritten` properties of all `EventLog` entries, sorted in ascending order by `DateWritten`, and writes each property's value to the application log: \n\n q := datastore.NewQuery(\"EventLog\").\n \tProject(\"Title\", \"ReadPath\", \"DateWritten\").\n \tOrder(\"DateWritten\")\n t := q.Run(ctx)\n for {\n \tvar l EventLog\n \t_, err := t.Next(&l)\n \tif err == datastore.Done {\n \t\tbreak\n \t}\n \tif err != nil {\n \t\tlog.Errorf(ctx, \"Running query: %v\", err)\n \t\tbreak\n \t}\n \tlog.Infof(ctx, \"Log record: %v, %v, %v\", l.Title, l.ReadPath, l.DateWritten)\n }\n\nGrouping^(experimental)^\n------------------------\n\nProjection queries can use the `Distinct` method to ensure that only completely unique results will be returned in a result set. This will only return the first result for entities which have the same values for the properties that are being projected. \n\n q := datastore.NewQuery(\"Person\").\n \tProject(\"LastName\", \"Height\").Distinct().\n \tFilter(\"Height \u003e\", 20).\n \tOrder(\"-Height\").Order(\"LastName\")\n\nLimitations on projections\n--------------------------\n\nProjection queries are subject to the following limitations:\n\n- **Only indexed properties can be projected.**\n\n Projection is not supported for properties that are not indexed, whether explicitly or implicitly. Strings that are longer than 1500 bytes and byte arrays that have more than 1500 elements are not indexed.\n- **The same property cannot be projected more than once.**\n\n- **Properties referenced in an equality (`=`) filter cannot be projected.**\n\n For example, \n\n SELECT A FROM kind WHERE B = 1\n\n is valid (projected property not used in the equality filter), as is \n\n SELECT A FROM kind WHERE A \u003e 1\n\n (not an equality filter), but \n\n SELECT A FROM kind WHERE A = 1\n\n (projected property used in equality filter) is not.\n- **Results returned by a projection query should not be saved back to Datastore.**\n\n Because the query returns results that are only partially populated, you should not write them back to Datastore.\n\nProjections and multiple-valued properties\n------------------------------------------\n\nProjecting a property with multiple values will not populate all values for that property. Instead, a separate entity will be returned for each unique combination of projected values matching the query. For example, suppose you have an entity of kind `Foo` with two multiple-valued properties, `A` and `B`: \n\n entity := Foo{A: []int{1, 1, 2, 3}, B: []string{\"x\", \"y\", \"x\"}}\n\nThen the projection query \n\n q := datastore.NewQuery(\"Foo\").Project(\"A\", \"B\").Filter(\"A \u003c\", 3)\n\nwill return four entities with the following combinations of values:\n\n`A` = `1`, `B` = `'x'` \n\n`A` = `1`, `B` = `'y'` \n\n`A` = `2`, `B` = `'x'` \n\n`A` = `2`, `B` = `'y'`\n\nNote that if an entity has a multiple-valued property with no values, no entries\nwill be included in the index, and no results for that entity will be returned\nfrom a projection query including that property.\n| **Warning:** Including more than one multiple-valued property in a projection will result in an [exploding index](/appengine/docs/legacy/standard/go111/datastore/indexes#index-limits).\n\nIndexes for projections\n-----------------------\n\nProjection queries require all properties specified in the projection to be included in a Datastore [index](/appengine/docs/legacy/standard/go111/datastore/indexes). The App Engine development server automatically generates the needed indexes for you in the index configuration file, `index.yaml`, which is uploaded with your application.\n\nOne way to minimize the number of indexes required is to project the same properties consistently, even when not all of them are always needed. For example, these queries require two separate indexes: \n\n SELECT A, B FROM Kind\n SELECT A, B, C FROM Kind\n\nHowever, if you always project properties `A`, `B`, and `C`, even when `C` is not required, only one index will be needed.\n\nConverting an existing query into a projection query may require building a new index if the properties in the projection are not already included in another part of the query. For example, suppose you had an existing query like \n\n SELECT * FROM Kind WHERE A \u003e 1 ORDER BY A, B\n\nwhich requires the index \n\n Index(Kind, A, B)\n\nConverting this to either of the projection queries \n\n SELECT C FROM Kind WHERE A \u003e 1 ORDER BY A, B\n SELECT A, B, C FROM Kind WHERE A \u003e 1 ORDER BY A, B\n\nintroduces a new property (`C`) and thus will require building a new index `Index(Kind,` `A,` `B,` `C)`. Note that the projection query \n\n SELECT A, B FROM Kind WHERE A \u003e 1 ORDER BY A, B\n\nwould *not* change the required index, since the projected properties `A` and `B` were already included in the existing query."]]