{"id":1313,"date":"2018-04-11T18:14:09","date_gmt":"2018-04-12T01:14:09","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/"},"modified":"2018-04-11T18:14:09","modified_gmt":"2018-04-12T01:14:09","slug":"couchbase-gsi-index-partitioning","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/couchbase-gsi-index-partitioning\/","title":{"rendered":"Divide and Conquer: Couchbase GSI Index partitioning."},"content":{"rendered":"\n

In Couchbase, data is always partitioned using the <\/span>consistent hash<\/span><\/a> value of the document key into vbukets which are stored on the data nodes. \u00a0Couchbase <\/span>Global Secondary Index (GSI)<\/span><\/a> abstracts the indexing operations and runs as a distinct service within the Couchbase data platform. \u00a0When a single index can cover a whole type of documents, everything is good. But, there are cases where you\u2019d want to partition an index.<\/span><\/p>\n\n\n\n

    \n
  1. Capacity: You want increased capacity because a single node is unable to hold a big index <\/span><\/li>\n\n\n
  2. Queriability: You want to avoid rewriting the query to work with manual partitioning of the index using a partial index.<\/span><\/li>\n\n\n
  3. Performance: Single index is unable to meet the SLA<\/span><\/li>\n\n<\/ol>\n\n\n\n

    To address this, Couchbase 5.5 introduces automatic hash partitioning of the index. \u00a0You\u2019re used to having bucket data hashed into multiple nodes. Index partitioning enables you to hash the index into multiple nodes as well. \u00a0There is good symmetry.<\/span><\/p>\n\n\n\n

    Creating the index is easy. \u00a0Simply add a PARTITION BY clause to the CREATE index definition.<\/span><\/p>\n\n\n

    [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”plsql” decode=”true”]CREATE INDEX ih ON customer(state, name, zip, status)
    \nPARTITION BY HASH(state)
    \nWHERE type = “cx” WITH {“num_partition”:8}
    \n[\/crayon]<\/p>\n\n\n\n

    \"\"<\/p>\n\n\n\n

    This as the following meta data in the system:indexes. \u00a0Note the new field partition with the hash expression. The HASH(state) is the basis on which the index logically named `<\/span>customer`.`ih`<\/b> is divided into a number of physical index partitions. By default, the number of index partitions are 16 and it can be changed by specifying num_partition parameter. \u00a0In the example above, we create 8 partitions for the index `<\/span>customer`.`ih`<\/b>.<\/span><\/p>\n\n\n

    [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”plsql” decode=”true”]select *
    \nfrom system:indexes
    \nwhere keyspace_id = “customer” and name = “ih” ;
    \n {
    \n “indexes”: {
    \n “condition”: “(`type` = “cx”)”,
    \n “datastore_id”: “https:\/\/127.0.0.1:8091”,
    \n “id”: “b3ce745f84256319”,
    \n “index_key”: [
    \n “`state`”,
    \n “`name`”,
    \n “`zip`”,
    \n “`status`”
    \n ],
    \n “keyspace_id”: “customer”,
    \n “name”: “ih”,
    \n “namespace_id”: “default”,
    \n “partition”: “HASH(`state`)”,
    \n “state”: “online”,
    \n “using”: “gsi”
    \n }
    \n }<\/p>\n

    [\/crayon]<\/p>\n\n\n\n

    Now, issue the following query. You don\u2019t need additional predicate on the hash key for the query to use the index. \u00a0\u00a0The index scan simply scans all of the index partitions as part of the index scan.<\/span><\/p>\n\n\n

    [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”plsql” decode=”true”]SELECT *
    \nFROM customer
    \nWHERE type = “cx”
    \nand name = “acme”
    \nand zip = “94051”;<\/p>\n

    [\/crayon]<\/p>\n\n\n\n

    However, if you do have an equality predicate on the hash key, index scan detects the right index partition having the right range of data and prunes rest of the index nodes from the index scan. \u00a0\u00a0\u00a0This makes the index scan very efficient.<\/span><\/p>\n\n\n

    [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”plsql” decode=”true”]SELECT *
    \nFROM customer
    \nWHERE type = “cx”
    \nand name = “acme”
    \nand zip = “94051”
    \nand state = “CA”;
    \n[\/crayon]<\/p>\n\n\n\n

    Now, let\u2019s look at how this index helps you with three things we mentioned before: Capacity, Queriability and Performance.<\/span><\/p>\n\n\n\n

    Capacity<\/span><\/h2>\n\n\n\n

    The query `<\/span>customer`.`ih` <\/b>will be partitioned to a specified number of partitioned with each partition stored on one of the index nodes on the cluster. \u00a0The indexer uses a stochastic optimization algorithm to determine how to distribute the partitions onto the set of indexer nodes, based on the free resource available on each node. \u00a0Alternatively, to restrict the index to a specific set of nodes, use the nodes parameter. This index will create eight index partitions and store four each on the four index nodes specified. \u00a0<\/span><\/p>\n\n\n

    [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”mysql” decode=”true”]CREATE INDEX ih ON customer(state, name, zip, status)
    \nPARTITION BY HASH(state)
    \nWHERE type = “cx” WITH {“num_partition”:8,
    \n“nodes”:[“172.23.125.32:9001”, “172.23.125.28:9001”, “172.23.93.82:9001″,”172.23.45.20:9001” ]}
    \n[\/crayon]<\/p>\n\n\n\n

    \"\"<\/p>\n\n\n\n

    \u00a0<\/p>\n\n\n\n

    So, with this hash partitioned index, \u00a0one logical index (`<\/span>customer`.`ih`<\/b>) will be partitioned into a number of physical index partitions (in this case, 8 partitions) and give the query an illusion of a single index. \u00a0<\/span><\/p>\n\n\n\n

    Because this index uses the multiple physical nodes, the index will have more disk, memory and CPU resources available. Increased storage in these nodes makes it possible to create larger indexes.<\/span><\/p>\n\n\n\n

    You write your queries, as usual, requiring predicates only the WHERE clause (type = “cx”) an at least on one of the leading index keys (e.g. name). \u00a0<\/span><\/p>\n\n\n\n

    Queriability<\/span><\/h2>\n\n\n\n

    Limitations in the Couchbase 5.0 indexing:<\/b><\/p>\n\n\n\n

    Until Couchbase 5.0, you could manually partition the index like below. You had to partition them manually using the WHERE clause on the CREATE INDEX. \u00a0Consider the following indexes, one per state. By using the node parameter, you could place them in specific index nodes or the index will try to automatically spread out within the index nodes.<\/span><\/p>\n\n\n

    [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”mysql” decode=”true”]CREATE INDEX i1 ON customer(name, zip, status) WHERE state = “CA”;
    \nCREATE INDEX i2 ON customer(name, zip, status) WHERE state = “NV”;
    \nCREATE INDEX i3 ON customer(name, zip, status) WHERE state = “OR”;
    \nCREATE INDEX i4 ON customer(name, zip, status) WHERE state = “WA”;
    \n[\/crayon]<\/p>\n\n\n\n

    For a simple query with equalify predicate on state, it all works well.<\/span><\/p>\n\n\n

    [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”mysql” decode=”true”]SELECT *
    \nFROM customer
    \nWHERE state = “CA” and name = “acme” and zip = “94051”;
    \n[\/crayon]<\/p>\n\n\n\n

    There are two issues with this manual partitioning. \u00a0\u00a0<\/span><\/p>\n\n\n\n

      \n
    1. Consider the following with slightly complex predicate on the state. \u00a0Because the predicate (state IN [“CA”, “OR”]) is not a subset of any of the WHERE clauses of the index, none of the indexes can be used for the query below.<\/span><\/li>\n\n<\/ol>\n\n\n

      [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”mysql” decode=”true”]SELECT * FROM customer
      \nWHERE state IN [“CA”, “OR”] and name = ACME;
      \nSELECT * FROM customer
      \nWHERE state > “CA” and name = ACME;
      \n[\/crayon]<\/p>\n\n\n\n

      2. If you get data to a new state, you\u2019d to be aware of it and create the index in advance.<\/span><\/p>\n\n\n

      [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”mysql” decode=”true”]SELECT * FROM customer WHERE state = “CO” and name = ACME
      \n[\/crayon]<\/p>\n\n\n\n

      \u00a0\u00a0<\/span> If the field numerical field, you can use the the MOD() function.<\/span><\/p>\n\n\n

      [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”mysql” decode=”true”]CREATE INDEX ix1 ON customer(name, zip, status) WHERE (MOD(cxid) % 4 = 0);
      \nCREATE INDEX ix2 ON customer(name, zip, status) WHERE (MOD(cxid) % 4 = 1);
      \nCREATE INDEX ix3 ON customer(name, zip, status) WHERE (MOD(cxid) % 4 = 2);
      \nCREATE INDEX ix4 ON customer(name, zip, status) WHERE (MOD(cxid) % 4 = 3);
      \n[\/crayon]<\/p>\n\n\n\n

      Even this work around each query block can only use one index and requires queries to be written carefully to match one of the predicates in the WHERE clause.<\/span><\/p>\n\n\n\n

      Solution:<\/b><\/p>\n\n\n\n

      As you see from the figure above, the interaction between the query and index goes through the GSI client sitting inside each query node. \u00a0Each GSI client gives the illusion of a single logical index (`<\/span>customer`.`ih`<\/b>) on top of eight physical index partitions. \u00a0<\/span><\/p>\n\n\n\n

      The GSI client takes all of the index scan request and then using the predicate, tries to see if it can identify which of index partitions has the data needed for the query. \u00a0This is the process of partition pruning (aka partition elimination). For the hash based partitioning scheme, equality and IN clause predicates get the benefit of partition pruning. All other expressions use the scatter-gather method. After the logical elimination, GSI client sends the request to the remaining nodes, gets the result, merges the result and sends the result back to query. \u00a0The big benefit of this is that queries can be written without worrying about the manual partitioning expression. <\/span><\/p>\n\n\n\n

      Example query below does not even have a predicate on the hash key, state. \u00a0The below query does not get the benefit of partition elimination. Therefore, the GSI client issues scan to every index partition in parallel and then merges the result from each of the index scan. The big benefit of this is that queries can be written without worrying about the manual partitioning expression to match the partial index expression and still use the full capacity of the cluster resources. <\/span><\/p>\n\n\n\n

      [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”plsql” decode=”true”]select *
      \nfrom system:indexes
      \nwhere keyspace_id = “customer” and name = “ih” ;
      \n {
      \n “indexes”: {
      \n “condition”: “(`type` = “cx”)”,
      \n “datastore_id”: “https:\/\/127.0.0.1:8091”,
      \n “id”: “b3ce745f84256319”,
      \n “index_key”: [
      \n “`state`”,
      \n “`name`”,
      \n “`zip`”,
      \n “`status`”
      \n ],
      \n “keyspace_id”: “customer”,
      \n “name”: “ih”,
      \n “namespace_id”: “default”,
      \n “partition”: “HASH(`state`)”,
      \n “state”: “online”,
      \n “using”: “gsi”
      \n }
      \n }<\/p>\n

      [\/crayon]<\/p>\n0<\/p>\n\n\n\n

      Additional predicate on the hash key (state = \u201cCA\u201d) in the query below will benefit from partition pruning. \u00a0For query processing, for simple queries with equality predicates on hash key, you get uniform distribution of the workload on these multiple partitions of the index. For complex queries including the grouping & aggregation we discussed above, the scans, partial aggregations are done in parallel, improving the query latency. \u00a0<\/span><\/p>\n\n\n\n

      [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”plsql” decode=”true”]select *
      \nfrom system:indexes
      \nwhere keyspace_id = “customer” and name = “ih” ;
      \n {
      \n “indexes”: {
      \n “condition”: “(`type` = “cx”)”,
      \n “datastore_id”: “https:\/\/127.0.0.1:8091”,
      \n “id”: “b3ce745f84256319”,
      \n “index_key”: [
      \n “`state`”,
      \n “`name`”,
      \n “`zip`”,
      \n “`status`”
      \n ],
      \n “keyspace_id”: “customer”,
      \n “name”: “ih”,
      \n “namespace_id”: “default”,
      \n “partition”: “HASH(`state`)”,
      \n “state”: “online”,
      \n “using”: “gsi”
      \n }
      \n }<\/p>\n

      [\/crayon]<\/p>\n1<\/p>\n\n\n\n

      You can create indexes by hashing on one or more keys, each of which could be an expression. \u00a0Here are some examples.<\/span><\/p>\n\n\n\n

      [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”plsql” decode=”true”]select *
      \nfrom system:indexes
      \nwhere keyspace_id = “customer” and name = “ih” ;
      \n {
      \n “indexes”: {
      \n “condition”: “(`type` = “cx”)”,
      \n “datastore_id”: “https:\/\/127.0.0.1:8091”,
      \n “id”: “b3ce745f84256319”,
      \n “index_key”: [
      \n “`state`”,
      \n “`name`”,
      \n “`zip`”,
      \n “`status`”
      \n ],
      \n “keyspace_id”: “customer”,
      \n “name”: “ih”,
      \n “namespace_id”: “default”,
      \n “partition”: “HASH(`state`)”,
      \n “state”: “online”,
      \n “using”: “gsi”
      \n }
      \n }<\/p>\n

      [\/crayon]<\/p>\n2<\/p>\n\n\n\n

      Performance<\/span><\/h2>\n\n\n\n

      For majority of database features, performance is everything. Without a great performance, proven by good benchmarks, the features are simply pretty syntax diagrams!<\/span><\/p>\n\n\n\n

      Index partitioning gives you improved performance in two ways.<\/span><\/p>\n\n\n\n

        \n
      1. Scale out. The partitions are distributed into multiple nodes, increasing the CPU and memory availability of for the index scan. \u00a0<\/span><\/li>\n\n\n
      2. Parallel scan. Right predicate giving queries the benefit of partition pruning. Even after the pruning process, scans of all the indexes are done in parallel.<\/span><\/li>\n\n\n
      3. Parallel grouping and aggregation. The DZone article <\/span>Understanding Index Grouping and Aggregation in Couchbase N1QL Queries<\/span><\/a> explains the core performance improvement of grouping and aggregation using indexes. \u00a0<\/span><\/li>\n\n\n
      4. The parallelism of the index parallel scan (and grouping, aggregation) is determined by the <\/span>max_parallelism<\/span><\/a> parameter. This parameter can be set per query node and\/or per query request.<\/span><\/li>\n\n<\/ol>\n\n\n\n

        Consider the following index and query:<\/span><\/p>\n\n\n\n

        [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”plsql” decode=”true”]select *
        \nfrom system:indexes
        \nwhere keyspace_id = “customer” and name = “ih” ;
        \n {
        \n “indexes”: {
        \n “condition”: “(`type` = “cx”)”,
        \n “datastore_id”: “https:\/\/127.0.0.1:8091”,
        \n “id”: “b3ce745f84256319”,
        \n “index_key”: [
        \n “`state`”,
        \n “`name`”,
        \n “`zip`”,
        \n “`status`”
        \n ],
        \n “keyspace_id”: “customer”,
        \n “name”: “ih”,
        \n “namespace_id”: “default”,
        \n “partition”: “HASH(`state`)”,
        \n “state”: “online”,
        \n “using”: “gsi”
        \n }
        \n }<\/p>\n

        [\/crayon]<\/p>\n3<\/p>\n\n\n\n

        The index is partitioned by HASH(state), but state predicate is missing from the query. \u00a0For this query, we cannot do partition pruning or create groups within individual scans of the index partitions. \u00a0Therefore, it will need a merge phase after the partial aggregation with the query (not shown in the explain). Remember, these partial aggregations happen in parallel and therefore reduces the latency of the query.<\/span><\/p>\n\n\n\n

        \"\"<\/p>\n\n\n\n

        Consider the following index and query:<\/span><\/p>\n\n\n\n

        [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”plsql” decode=”true”]select *
        \nfrom system:indexes
        \nwhere keyspace_id = “customer” and name = “ih” ;
        \n {
        \n “indexes”: {
        \n “condition”: “(`type` = “cx”)”,
        \n “datastore_id”: “https:\/\/127.0.0.1:8091”,
        \n “id”: “b3ce745f84256319”,
        \n “index_key”: [
        \n “`state`”,
        \n “`name`”,
        \n “`zip`”,
        \n “`status`”
        \n ],
        \n “keyspace_id”: “customer”,
        \n “name”: “ih”,
        \n “namespace_id”: “default”,
        \n “partition”: “HASH(`state`)”,
        \n “state”: “online”,
        \n “using”: “gsi”
        \n }
        \n }<\/p>\n

        [\/crayon]<\/p>\n4<\/p>\n\n\n\n

        Example a:<\/strong><\/p>\n\n\n\n

        [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”plsql” decode=”true”]select *
        \nfrom system:indexes
        \nwhere keyspace_id = “customer” and name = “ih” ;
        \n {
        \n “indexes”: {
        \n “condition”: “(`type` = “cx”)”,
        \n “datastore_id”: “https:\/\/127.0.0.1:8091”,
        \n “id”: “b3ce745f84256319”,
        \n “index_key”: [
        \n “`state`”,
        \n “`name`”,
        \n “`zip`”,
        \n “`status`”
        \n ],
        \n “keyspace_id”: “customer”,
        \n “name”: “ih”,
        \n “namespace_id”: “default”,
        \n “partition”: “HASH(`state`)”,
        \n “state”: “online”,
        \n “using”: “gsi”
        \n }
        \n }<\/p>\n

        [\/crayon]<\/p>\n5<\/p>\n\n\n\n

        In the above example, the group by is on the leading keys (state, city, zip) of the index and hash key (zip) is part of the group by clause. This will help the query to scan the index and simply created the required groups.<\/span><\/p>\n\n\n\n

        Example b:<\/strong><\/p>\n\n\n\n

        [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”plsql” decode=”true”]select *
        \nfrom system:indexes
        \nwhere keyspace_id = “customer” and name = “ih” ;
        \n {
        \n “indexes”: {
        \n “condition”: “(`type` = “cx”)”,
        \n “datastore_id”: “https:\/\/127.0.0.1:8091”,
        \n “id”: “b3ce745f84256319”,
        \n “index_key”: [
        \n “`state`”,
        \n “`name`”,
        \n “`zip`”,
        \n “`status`”
        \n ],
        \n “keyspace_id”: “customer”,
        \n “name”: “ih”,
        \n “namespace_id”: “default”,
        \n “partition”: “HASH(`state`)”,
        \n “state”: “online”,
        \n “using”: “gsi”
        \n }
        \n }<\/p>\n

        [\/crayon]<\/p>\n6<\/p>\n\n\n\n

        In the above example, the group by is on the third key (zip) of the index and hash key (zip) is part of the group by clause. In the predicate clause (WHERE clause), there is single equality predicate on the leading index keys before the key zip (state and city). \u00a0Therefore, we implicitly include the keys (state, city) in the group by without affecting the query result. This will help the query to scan the index and simply created the required groups.<\/span><\/p>\n\n\n\n

        Example c:<\/strong><\/p>\n\n\n\n

        [crayon theme=”github” whitespace-before=”1″ whitespace-after=”1″ lang=”plsql” decode=”true”]select *
        \nfrom system:indexes
        \nwhere keyspace_id = “customer” and name = “ih” ;
        \n {
        \n “indexes”: {
        \n “condition”: “(`type` = “cx”)”,
        \n “datastore_id”: “https:\/\/127.0.0.1:8091”,
        \n “id”: “b3ce745f84256319”,
        \n “index_key”: [
        \n “`state`”,
        \n “`name`”,
        \n “`zip`”,
        \n “`status`”
        \n ],
        \n “keyspace_id”: “customer”,
        \n “name”: “ih”,
        \n “namespace_id”: “default”,
        \n “partition”: “HASH(`state`)”,
        \n “state”: “online”,
        \n “using”: “gsi”
        \n }
        \n }<\/p>\n

        [\/crayon]<\/p>\n7<\/p>\n\n\n\n

        \u00a0<\/p>\n\n\n\n

        In the above example, the group by is on the third key (zip) of the index and hash key (zip) is part of the group by clause. In the predicate clause (WHERE clause), there is range predicate on city. The index key (city) is before the hash key(zip). \u00a0So, we create partial aggregates as part of the index scan and then then query will merge these partial aggregates to create the final resultset. <\/span><\/p>\n\n\n\n

        Summary:<\/span><\/h2>\n\n\n\n

        Index partition gives you increased capacity for your index, better queriability and higher performance for your queries. \u00a0By exploiting the Couchbase scale-out architecture, indexes improve your capacity, queriability, performance and TCO. <\/span><\/p>\n\n\n\n

        Reference:<\/span><\/h2>\n\n\n\n
          \n
        1. Couchbase documentation: <\/span>https:\/\/developer.couchbase.com\/documentation\/server\/5.5\/indexes\/gsi-for-n1ql.html<\/span><\/a><\/li>\n\n\n
        2. Couchbase N1QL documentation:\u00a0<\/span>https:\/\/developer.couchbase.com\/documentation\/server\/5.5\/indexes\/gsi-for-n1ql.html#<\/a><\/li>\n\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

          In Couchbase, data is always partitioned using the consistent hash value of the document key into vbukets which are stored on the data nodes. \u00a0Couchbase Global Secondary Index (GSI) abstracts the indexing operations and runs as a distinct service within the Couchbase data platform. \u00a0When a single index can cover a whole type of documents, […]<\/p>\n","protected":false},"author":55,"featured_media":1312,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[136,54,17,18],"tags":[141,30,6],"ppma_author":[291],"class_list":["post-1313","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-best-practices-and-tutorials","category-couchbase-server","category-performance","category-n1ql-query","tag-index","tag-json","tag-nosql-database"],"yoast_head":"\nCouchbase GSI Index partitioning - The Couchbase Blog<\/title>\n<meta name=\"description\" content=\"See how index partition helps increase capacity for your index, better queriability and higher performance and TCO for your queries.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.couchbase.com\/blog\/es\/couchbase-gsi-index-partitioning\/\" \/>\n<meta property=\"og:locale\" content=\"es_MX\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Divide and Conquer: Couchbase GSI Index partitioning.\" \/>\n<meta property=\"og:description\" content=\"See how index partition helps increase capacity for your index, better queriability and higher performance and TCO for your queries.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.couchbase.com\/blog\/es\/couchbase-gsi-index-partitioning\/\" \/>\n<meta property=\"og:site_name\" content=\"The Couchbase Blog\" \/>\n<meta property=\"article:published_time\" content=\"2018-04-12T01:14:09+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/5\/2026\/05\/Screen-Shot-2018-04-11-at-5.36.15-PM.png\" \/>\n\t<meta property=\"og:image:width\" content=\"2530\" \/>\n\t<meta property=\"og:image:height\" content=\"645\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Keshav Murthy\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@rkeshavmurthy\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Keshav Murthy\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/couchbase-gsi-index-partitioning\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/couchbase-gsi-index-partitioning\\\/\"},\"author\":{\"name\":\"Keshav Murthy\",\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/#\\\/schema\\\/person\\\/c261644262bf98e146372fe647682636\"},\"headline\":\"Divide and Conquer: Couchbase GSI Index partitioning.\",\"datePublished\":\"2018-04-12T01:14:09+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/couchbase-gsi-index-partitioning\\\/\"},\"wordCount\":2284,\"commentCount\":2,\"publisher\":{\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/couchbase-gsi-index-partitioning\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/5\\\/2026\\\/05\\\/Screen-Shot-2018-04-11-at-5.36.15-PM.png\",\"keywords\":[\"Index\",\"JSON\",\"NoSQL Database\"],\"articleSection\":[\"Best Practices and Tutorials\",\"Couchbase Server\",\"High Performance\",\"SQL++ \\\/ N1QL Query\"],\"inLanguage\":\"es\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/couchbase-gsi-index-partitioning\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/couchbase-gsi-index-partitioning\\\/\",\"url\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/couchbase-gsi-index-partitioning\\\/\",\"name\":\"Couchbase GSI Index partitioning - The Couchbase Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/couchbase-gsi-index-partitioning\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/couchbase-gsi-index-partitioning\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/5\\\/2026\\\/05\\\/Screen-Shot-2018-04-11-at-5.36.15-PM.png\",\"datePublished\":\"2018-04-12T01:14:09+00:00\",\"description\":\"See how index partition helps increase capacity for your index, better queriability and higher performance and TCO for your queries.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/couchbase-gsi-index-partitioning\\\/#breadcrumb\"},\"inLanguage\":\"es\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/couchbase-gsi-index-partitioning\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"es\",\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/couchbase-gsi-index-partitioning\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/5\\\/2026\\\/05\\\/Screen-Shot-2018-04-11-at-5.36.15-PM.png\",\"contentUrl\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/5\\\/2026\\\/05\\\/Screen-Shot-2018-04-11-at-5.36.15-PM.png\",\"width\":2530,\"height\":645},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/couchbase-gsi-index-partitioning\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Divide and Conquer: Couchbase GSI Index partitioning.\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/\",\"name\":\"The Couchbase Blog\",\"description\":\"Couchbase, the NoSQL Database\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"es\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/#organization\",\"name\":\"The Couchbase Blog\",\"url\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"es\",\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/5\\\/2026\\\/06\\\/logo.svg\",\"contentUrl\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/5\\\/2026\\\/06\\\/logo.svg\",\"width\":\"1024\",\"height\":\"1024\",\"caption\":\"The Couchbase Blog\"},\"image\":{\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/#\\\/schema\\\/person\\\/c261644262bf98e146372fe647682636\",\"name\":\"Keshav Murthy\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"es\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/af74df754db27152971d0aed2f323ead5a1f9fe5afd0209af91e12e784451224?s=96&d=mm&r=g4e51d72fc07c662aa791316deafffac4\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/af74df754db27152971d0aed2f323ead5a1f9fe5afd0209af91e12e784451224?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/af74df754db27152971d0aed2f323ead5a1f9fe5afd0209af91e12e784451224?s=96&d=mm&r=g\",\"caption\":\"Keshav Murthy\"},\"description\":\"Keshav Murthy is a Vice President at Couchbase R&D. Previously, he was at MapR, IBM, Informix, Sybase, with more than 20 years of experience in database design & development. He lead the SQL and NoSQL R&D team at IBM Informix. He has received two President's Club awards at Couchbase, two Outstanding Technical Achievement Awards at IBM. Keshav has a bachelor's degree in Computer Science and Engineering from the University of Mysore, India, and has received twenty four US patents.\",\"sameAs\":[\"https:\\\/\\\/blog.planetnosql.com\\\/\",\"https:\\\/\\\/x.com\\\/rkeshavmurthy\"],\"url\":\"https:\\\/\\\/www.couchbase.com\\\/blog\\\/es\\\/author\\\/keshav-murthy\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Couchbase GSI Index partitioning - The Couchbase Blog","description":"See how index partition helps increase capacity for your index, better queriability and higher performance and TCO for your queries.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.couchbase.com\/blog\/es\/couchbase-gsi-index-partitioning\/","og_locale":"es_MX","og_type":"article","og_title":"Divide and Conquer: Couchbase GSI Index partitioning.","og_description":"See how index partition helps increase capacity for your index, better queriability and higher performance and TCO for your queries.","og_url":"https:\/\/www.couchbase.com\/blog\/es\/couchbase-gsi-index-partitioning\/","og_site_name":"The Couchbase Blog","article_published_time":"2018-04-12T01:14:09+00:00","og_image":[{"width":2530,"height":645,"url":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/5\/2026\/05\/Screen-Shot-2018-04-11-at-5.36.15-PM.png","type":"image\/png"}],"author":"Keshav Murthy","twitter_card":"summary_large_image","twitter_creator":"@rkeshavmurthy","twitter_misc":{"Written by":"Keshav Murthy","Est. reading time":"11 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/#article","isPartOf":{"@id":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/"},"author":{"name":"Keshav Murthy","@id":"https:\/\/www.couchbase.com\/blog\/#\/schema\/person\/c261644262bf98e146372fe647682636"},"headline":"Divide and Conquer: Couchbase GSI Index partitioning.","datePublished":"2018-04-12T01:14:09+00:00","mainEntityOfPage":{"@id":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/"},"wordCount":2284,"commentCount":2,"publisher":{"@id":"https:\/\/www.couchbase.com\/blog\/#organization"},"image":{"@id":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/#primaryimage"},"thumbnailUrl":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/5\/2026\/05\/Screen-Shot-2018-04-11-at-5.36.15-PM.png","keywords":["Index","JSON","NoSQL Database"],"articleSection":["Best Practices and Tutorials","Couchbase Server","High Performance","SQL++ \/ N1QL Query"],"inLanguage":"es","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/","url":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/","name":"Couchbase GSI Index partitioning - The Couchbase Blog","isPartOf":{"@id":"https:\/\/www.couchbase.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/#primaryimage"},"image":{"@id":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/#primaryimage"},"thumbnailUrl":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/5\/2026\/05\/Screen-Shot-2018-04-11-at-5.36.15-PM.png","datePublished":"2018-04-12T01:14:09+00:00","description":"See how index partition helps increase capacity for your index, better queriability and higher performance and TCO for your queries.","breadcrumb":{"@id":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/#breadcrumb"},"inLanguage":"es","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/"]}]},{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/#primaryimage","url":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/5\/2026\/05\/Screen-Shot-2018-04-11-at-5.36.15-PM.png","contentUrl":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/5\/2026\/05\/Screen-Shot-2018-04-11-at-5.36.15-PM.png","width":2530,"height":645},{"@type":"BreadcrumbList","@id":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.couchbase.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Divide and Conquer: Couchbase GSI Index partitioning."}]},{"@type":"WebSite","@id":"https:\/\/www.couchbase.com\/blog\/#website","url":"https:\/\/www.couchbase.com\/blog\/","name":"The Couchbase Blog","description":"Couchbase, the NoSQL Database","publisher":{"@id":"https:\/\/www.couchbase.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.couchbase.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"es"},{"@type":"Organization","@id":"https:\/\/www.couchbase.com\/blog\/#organization","name":"The Couchbase Blog","url":"https:\/\/www.couchbase.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/www.couchbase.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/5\/2026\/06\/logo.svg","contentUrl":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/5\/2026\/06\/logo.svg","width":"1024","height":"1024","caption":"The Couchbase Blog"},"image":{"@id":"https:\/\/www.couchbase.com\/blog\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/www.couchbase.com\/blog\/#\/schema\/person\/c261644262bf98e146372fe647682636","name":"Keshav Murthy","image":{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/secure.gravatar.com\/avatar\/af74df754db27152971d0aed2f323ead5a1f9fe5afd0209af91e12e784451224?s=96&d=mm&r=g4e51d72fc07c662aa791316deafffac4","url":"https:\/\/secure.gravatar.com\/avatar\/af74df754db27152971d0aed2f323ead5a1f9fe5afd0209af91e12e784451224?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/af74df754db27152971d0aed2f323ead5a1f9fe5afd0209af91e12e784451224?s=96&d=mm&r=g","caption":"Keshav Murthy"},"description":"Keshav Murthy is a Vice President at Couchbase R&D. Previously, he was at MapR, IBM, Informix, Sybase, with more than 20 years of experience in database design & development. He lead the SQL and NoSQL R&D team at IBM Informix. He has received two President's Club awards at Couchbase, two Outstanding Technical Achievement Awards at IBM. Keshav has a bachelor's degree in Computer Science and Engineering from the University of Mysore, India, and has received twenty four US patents.","sameAs":["https:\/\/blog.planetnosql.com\/","https:\/\/x.com\/rkeshavmurthy"],"url":"https:\/\/www.couchbase.com\/blog\/es\/author\/keshav-murthy\/"}]}},"acf":[],"authors":[{"term_id":291,"user_id":55,"is_guest":0,"slug":"keshav-murthy","display_name":"Keshav Murthy","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/posts\/1313","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/users\/55"}],"replies":[{"embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/comments?post=1313"}],"version-history":[{"count":0,"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/posts\/1313\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/media\/1312"}],"wp:attachment":[{"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/media?parent=1313"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/categories?post=1313"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/tags?post=1313"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/ppma_author?post=1313"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}