{"id":5002,"date":"2018-04-11T18:14:09","date_gmt":"2018-04-12T01:14:09","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=5002"},"modified":"2025-06-13T20:20:06","modified_gmt":"2025-06-14T03:20:06","slug":"couchbase-gsi-index-partitioning","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/couchbase-gsi-index-partitioning\/","title":{"rendered":"Dividir e conquistar: particionamento do \u00edndice GSI do Couchbase."},"content":{"rendered":"

No Couchbase, os dados s\u00e3o sempre particionados usando o <\/span>hash consistente<\/span><\/a> da chave do documento em vbukets que s\u00e3o armazenados nos n\u00f3s de dados. Couchbase <\/span>\u00cdndice Secund\u00e1rio Global (GSI)<\/span><\/a> abstrai as opera\u00e7\u00f5es de indexa\u00e7\u00e3o e \u00e9 executado como um servi\u00e7o distinto dentro da plataforma de dados do Couchbase. Quando um \u00fanico \u00edndice pode abranger um tipo inteiro de documentos, tudo est\u00e1 bem. Por\u00e9m, h\u00e1 casos em que voc\u00ea deseja particionar um \u00edndice.<\/span><\/p>\n

    \n
  1. Capacidade: Voc\u00ea deseja aumentar a capacidade porque um \u00fanico n\u00f3 n\u00e3o \u00e9 capaz de manter um \u00edndice grande <\/span><\/li>\n
  2. Possibilidade de consulta: Voc\u00ea deseja evitar reescrever a consulta para trabalhar com o particionamento manual do \u00edndice usando um \u00edndice parcial.<\/span><\/li>\n
  3. Desempenho: O \u00edndice \u00fanico n\u00e3o consegue atender ao SLA<\/span><\/li>\n<\/ol>\n

    Para resolver isso, o Couchbase 5.5 introduz o particionamento autom\u00e1tico de hash do \u00edndice. Voc\u00ea est\u00e1 acostumado a ter dados de bucket com hash em v\u00e1rios n\u00f3s. O particionamento do \u00edndice permite que voc\u00ea fa\u00e7a hash do \u00edndice em v\u00e1rios n\u00f3s tamb\u00e9m. H\u00e1 uma boa simetria.<\/span><\/p>\n

    Criar o \u00edndice \u00e9 f\u00e1cil. Basta adicionar uma cl\u00e1usula PARTITION BY \u00e0 defini\u00e7\u00e3o do \u00edndice CREATE.<\/span><\/p>\n

    CREATE INDEX ih ON customer(state, name, zip, status) \r\nPARTITION BY HASH(state) \r\nWHERE type = \"cx\" WITH {\"num_partition\":8}\r\n<\/pre>\n
    \"\"<\/p>\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
    select * \r\nfrom system:indexes \r\nwhere keyspace_id = \"customer\" and name = \"ih\" ;\r\n  {\r\n    \"indexes\": {\r\n      \"condition\": \"(`type` = \\\"cx\\\")\",\r\n      \"datastore_id\": \"https:\/\/127.0.0.1:8091\",\r\n      \"id\": \"b3ce745f84256319\",\r\n      \"index_key\": [\r\n        \"`state`\",\r\n        \"`name`\",\r\n        \"`zip`\",\r\n        \"`status`\"\r\n      ],\r\n      \"keyspace_id\": \"customer\",\r\n      \"name\": \"ih\",\r\n      \"namespace_id\": \"default\",\r\n      \"partition\": \"HASH(`state`)\",\r\n      \"state\": \"online\",\r\n      \"using\": \"gsi\"\r\n    }\r\n  }\r\n\r\n<\/pre>\n
    Agora, emita a seguinte consulta. Voc\u00ea n\u00e3o precisa de um predicado adicional sobre a chave de hash para que a consulta use o \u00edndice.   A varredura do \u00edndice simplesmente varre todas as parti\u00e7\u00f5es do \u00edndice como parte da varredura do \u00edndice.<\/span><\/p>\n
    SELECT * \r\nFROM customer \r\nWHERE type = \"cx\" \r\nand name = \"acme\" \r\nand zip = \"94051\";\r\n\r\n<\/pre>\n
    Entretanto, se voc\u00ea tiver um predicado de igualdade na chave de hash, a varredura de \u00edndice detectar\u00e1 a parti\u00e7\u00e3o de \u00edndice correta com o intervalo correto de dados e remover\u00e1 o restante dos n\u00f3s de \u00edndice da varredura de \u00edndice.    Isso torna a varredura de \u00edndice muito eficiente.<\/span><\/p>\n
    SELECT * \r\nFROM customer \r\nWHERE type = \"cx\" \r\nand name = \"acme\" \r\nand zip = \"94051\"\r\nand state = \"CA\";\r\n<\/pre>\n
    Agora, vamos ver como esse \u00edndice o ajuda com os tr\u00eas aspectos que mencionamos anteriormente: Capacidade, capacidade de consulta e desempenho.<\/span><\/p>\n
    Capacidade<\/span><\/h2>\n
    The query `<\/span>customer`.`ih` <\/b>ser\u00e1 particionado em um n\u00famero especificado de parti\u00e7\u00f5es, com cada parti\u00e7\u00e3o armazenada em um dos n\u00f3s de indexa\u00e7\u00e3o no cluster.  O indexador usa um algoritmo de otimiza\u00e7\u00e3o estoc\u00e1stica para determinar como distribuir as parti\u00e7\u00f5es no conjunto de n\u00f3s do indexador, com base no recurso livre dispon\u00edvel em cada n\u00f3.  Como alternativa, para restringir o \u00edndice a um conjunto espec\u00edfico de n\u00f3s, use o par\u00e2metro nodes. Esse \u00edndice criar\u00e1 oito parti\u00e7\u00f5es de \u00edndice e armazenar\u00e1 quatro em cada um dos quatro n\u00f3s de \u00edndice especificados. \u00a0<\/span><\/p>\n
    CREATE INDEX ih ON customer(state, name, zip, status) \r\nPARTITION BY HASH(state) \r\nWHERE type = \"cx\" WITH {\"num_partition\":8, \r\n\"nodes\":[\"172.23.125.32:9001\", \"172.23.125.28:9001\", \"172.23.93.82:9001\",\"172.23.45.20:9001\" ]}\r\n<\/pre>\n
    \"\"<\/p>\n
     <\/p>\n
    So, with this hash partitioned index, \u00a0one logical index (`<\/span>customer`.`ih`<\/b>) ser\u00e1 particionado em v\u00e1rias parti\u00e7\u00f5es de \u00edndice f\u00edsico (neste caso, 8 parti\u00e7\u00f5es) e dar\u00e1 \u00e0 consulta a ilus\u00e3o de um \u00fanico \u00edndice. \u00a0<\/span><\/p>\n
    Como esse \u00edndice usa v\u00e1rios n\u00f3s f\u00edsicos, ele ter\u00e1 mais recursos de disco, mem\u00f3ria e CPU dispon\u00edveis. O aumento do armazenamento nesses n\u00f3s possibilita a cria\u00e7\u00e3o de \u00edndices maiores.<\/span><\/p>\n
    Voc\u00ea escreve suas consultas, como de costume, exigindo predicados apenas na cl\u00e1usula WHERE (type = \"cx\") e, pelo menos, em uma das principais chaves de \u00edndice (por exemplo, name). \u00a0<\/span><\/p>\n
    Capacidade de consulta<\/span><\/h2>\n
    Limita\u00e7\u00f5es na indexa\u00e7\u00e3o do Couchbase 5.0:<\/b><\/p>\n
    At\u00e9 o Couchbase 5.0, voc\u00ea podia particionar manualmente o \u00edndice como abaixo. Voc\u00ea tinha que particion\u00e1-los manualmente usando a cl\u00e1usula WHERE no CREATE INDEX.  Considere os seguintes \u00edndices, um por estado. Ao usar o par\u00e2metro node, voc\u00ea pode coloc\u00e1-los em n\u00f3s de \u00edndice espec\u00edficos ou o \u00edndice tentar\u00e1 se espalhar automaticamente dentro dos n\u00f3s de \u00edndice.<\/span><\/p>\n
    CREATE INDEX i1 ON customer(name, zip, status) WHERE state = \"CA\";\r\nCREATE INDEX i2 ON customer(name, zip, status) WHERE state = \"NV\";\r\nCREATE INDEX i3 ON customer(name, zip, status) WHERE state = \"OR\";\r\nCREATE INDEX i4 ON customer(name, zip, status) WHERE state = \"WA\";\r\n<\/pre>\n
    Para uma consulta simples com o predicado equalify no estado, tudo funciona bem.<\/span><\/p>\n
    SELECT * \r\nFROM customer \r\nWHERE state = \"CA\" and name = \"acme\" and zip = \"94051\";\r\n<\/pre>\n
    H\u00e1 dois problemas com esse particionamento manual. \u00a0\u00a0<\/span><\/p>\n
      \n
    1. Considere o seguinte com um predicado ligeiramente complexo sobre o estado.  Como o predicado (state IN [\"CA\", \"OR\"]) n\u00e3o \u00e9 um subconjunto de nenhuma das cl\u00e1usulas WHERE do \u00edndice, nenhum dos \u00edndices pode ser usado para a consulta abaixo.<\/span><\/li>\n<\/ol>\n
      SELECT * FROM customer \r\nWHERE state IN [\"CA\", \"OR\"] and name = ACME; \r\nSELECT * FROM customer \r\nWHERE state > \"CA\" and name = ACME;\r\n<\/pre>\n
      2. Se voc\u00ea obtiver dados em um novo estado, dever\u00e1 estar ciente disso e criar o \u00edndice com anteced\u00eancia.<\/span><\/p>\n
      SELECT * FROM customer WHERE state = \"CO\" and name = ACME\r\n<\/pre>\n
       \u00a0\u00a0<\/span> Se o campo for um campo num\u00e9rico, voc\u00ea poder\u00e1 usar a fun\u00e7\u00e3o MOD().<\/span><\/p>\n
      CREATE INDEX ix1 ON customer(name, zip, status) WHERE (MOD(cxid) % 4 = 0);\r\nCREATE INDEX ix2 ON customer(name, zip, status) WHERE (MOD(cxid) % 4 = 1);\r\nCREATE INDEX ix3 ON customer(name, zip, status) WHERE (MOD(cxid) % 4 = 2);\r\nCREATE INDEX ix4 ON customer(name, zip, status) WHERE (MOD(cxid) % 4 = 3);\r\n<\/pre>\n
      Mesmo com esse trabalho, cada bloco de consulta s\u00f3 pode usar um \u00edndice e exige que as consultas sejam escritas cuidadosamente para corresponder a um dos predicados na cl\u00e1usula WHERE.<\/span><\/p>\n
      Solu\u00e7\u00e3o:<\/b><\/p>\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>) em cima de oito parti\u00e7\u00f5es de \u00edndice f\u00edsico. \u00a0<\/span><\/p>\n
      O cliente GSI recebe todas as solicita\u00e7\u00f5es de varredura do \u00edndice e, usando o predicado, tenta identificar quais parti\u00e7\u00f5es do \u00edndice t\u00eam os dados necess\u00e1rios para a consulta.  Esse \u00e9 o processo de poda de parti\u00e7\u00e3o (tamb\u00e9m conhecido como elimina\u00e7\u00e3o de parti\u00e7\u00e3o). Para o esquema de particionamento baseado em hash, os predicados de cl\u00e1usula de igualdade e IN obt\u00eam o benef\u00edcio da poda de parti\u00e7\u00e3o. Todas as outras express\u00f5es usam o m\u00e9todo de coleta dispersa. Ap\u00f3s a elimina\u00e7\u00e3o l\u00f3gica, o cliente GSI envia a solicita\u00e7\u00e3o para os n\u00f3s restantes, obt\u00e9m o resultado, mescla o resultado e envia o resultado de volta para a consulta.  A grande vantagem disso \u00e9 que as consultas podem ser escritas sem se preocupar com a express\u00e3o de particionamento manual. <\/span><\/p>\n
      A consulta de exemplo abaixo nem sequer tem um predicado sobre a chave de hash, estado.  A consulta abaixo n\u00e3o obt\u00e9m o benef\u00edcio da elimina\u00e7\u00e3o da parti\u00e7\u00e3o. Portanto, o cliente GSI emite uma varredura para cada parti\u00e7\u00e3o de \u00edndice em paralelo e, em seguida, mescla o resultado de cada uma das varreduras de \u00edndice. A grande vantagem disso \u00e9 que as consultas podem ser escritas sem se preocupar com a express\u00e3o de particionamento manual para corresponder \u00e0 express\u00e3o de \u00edndice parcial e ainda usar a capacidade total dos recursos do cluster. <\/span><\/p>\n
      CREATE INDEX ih1 ON customer(name, zip, status) \r\nPARTITION BY HASH(state) \r\nWHERE type = \"cx\" WITH {\"num_partition\":8}\r\n\r\nSELECT * \r\nFROM customer \r\nWHERE type = \"cx\" \r\nand name = \"acme\" \r\nand zip = \"94051\";\r\n<\/pre>\n
      O predicado adicional sobre a chave de hash (estado = \"CA\") na consulta abaixo se beneficiar\u00e1 da poda de parti\u00e7\u00e3o.  No processamento de consultas, para consultas simples com predicados de igualdade na chave de hash, voc\u00ea obt\u00e9m uma distribui\u00e7\u00e3o uniforme da carga de trabalho nessas v\u00e1rias parti\u00e7\u00f5es do \u00edndice. Para consultas complexas, incluindo o agrupamento e a agrega\u00e7\u00e3o que discutimos acima, as varreduras e as agrega\u00e7\u00f5es parciais s\u00e3o feitas em paralelo, melhorando a lat\u00eancia da consulta. \u00a0<\/span><\/p>\n
      SELECT * \r\nFROM customer \r\nWHERE type = \"cx\" \r\nand name = \"acme\" \r\nand zip = \"94051\"\r\nand state = \"CA\";\r\n\r\n<\/pre>\n
      Voc\u00ea pode criar \u00edndices fazendo hashing em uma ou mais chaves, sendo que cada uma delas pode ser uma express\u00e3o.  Aqui est\u00e3o alguns exemplos.<\/span><\/p>\n
      CREATE INDEX idx1 ON customer(name) PARTITION BY HASH(META().id);\r\nCREATE INDEX idx2 ON customer(name) PARTITION BY HASH(name, zip);\r\nCREATE INDEX idx3 ON customer(name) \r\n                      PARTITION BY HASH(SUBSTR(name, 5, 10));\r\nCREATE INDEX idx3 ON customer(name) \r\nPARTITION BY \r\nHASH(SUBSTR(META().id, POSITION(META().id, \"::\")+2), zip)\r\n<\/pre>\n
      Desempenho<\/span><\/h2>\n
      Para a maioria dos recursos de banco de dados, o desempenho \u00e9 tudo. Sem um \u00f3timo desempenho, comprovado por bons benchmarks, os recursos s\u00e3o simplesmente diagramas de sintaxe bonitos!<\/span><\/p>\n
      O particionamento de \u00edndices proporciona um melhor desempenho de duas maneiras.<\/span><\/p>\n
        \n
      1. Dimensionamento. As parti\u00e7\u00f5es s\u00e3o distribu\u00eddas em v\u00e1rios n\u00f3s, aumentando a disponibilidade da CPU e da mem\u00f3ria para a varredura de \u00edndice. \u00a0<\/span><\/li>\n
      2. Varredura paralela. Predicado correto que fornece \u00e0s consultas o benef\u00edcio da poda de parti\u00e7\u00e3o. Mesmo ap\u00f3s o processo de poda, as varreduras de todos os \u00edndices s\u00e3o feitas em paralelo.<\/span><\/li>\n
      3. Agrupamento e agrega\u00e7\u00e3o paralelos. O artigo da DZone <\/span>Entendendo o agrupamento e a agrega\u00e7\u00e3o de \u00edndices nas consultas N1QL do Couchbase<\/span><\/a> explica o aprimoramento do desempenho principal do agrupamento e da agrega\u00e7\u00e3o usando \u00edndices. \u00a0<\/span><\/li>\n
      4. O paralelismo da varredura paralela do \u00edndice (e agrupamento, agrega\u00e7\u00e3o) \u00e9 determinado pelo par\u00e2metro <\/span>max_parallelism<\/span><\/a> par\u00e2metro. Esse par\u00e2metro pode ser definido por n\u00f3 de consulta e\/ou por solicita\u00e7\u00e3o de consulta.<\/span><\/li>\n<\/ol>\n
        Considere o \u00edndice e a consulta a seguir:<\/span><\/p>\n
        CREATE INDEX ih1 ON customer(name, zip, status) \r\nPARTITION BY HASH(state) \r\nWHERE type = \"cx\" WITH {\"num_partition\":8}\r\n\r\nselect zip, count(1) zipcount\r\nfrom customer\r\nwhere type = \"cx\" and name is not missing\r\ngroup by zip;\r\n<\/pre>\n
        O \u00edndice \u00e9 particionado por HASH(state), mas o predicado state est\u00e1 ausente da consulta.  Para essa consulta, n\u00e3o podemos fazer a poda de parti\u00e7\u00e3o ou criar grupos em varreduras individuais das parti\u00e7\u00f5es do \u00edndice.  Portanto, ela precisar\u00e1 de uma fase de mesclagem ap\u00f3s a agrega\u00e7\u00e3o parcial com a consulta (n\u00e3o mostrada na explica\u00e7\u00e3o). Lembre-se de que essas agrega\u00e7\u00f5es parciais acontecem em paralelo e, portanto, reduzem a lat\u00eancia da consulta.<\/span><\/p>\n
        \"\"<\/p>\n
        Considere o \u00edndice e a consulta a seguir:<\/span><\/p>\n
        CREATE INDEX ih2 ON customer(state, city, zip, status) \r\nPARTITION BY HASH(zip) \r\nWHERE type = \"cx\" WITH {\"num_partition\":8}\r\n<\/pre>\n
        Exemplo a:<\/strong><\/p>\n
        select state, count(1) zipcount\r\nfrom customer\r\nwhere state is not missing\r\ngroup by state, city, zip;\r\n<\/pre>\n
        No exemplo acima, o group by est\u00e1 nas chaves principais (state, city, zip) do \u00edndice e a chave hash (zip) faz parte da cl\u00e1usula group by. Isso ajudar\u00e1 a consulta a fazer a varredura do \u00edndice e simplesmente criar\u00e1 os grupos necess\u00e1rios.<\/span><\/p>\n
        Exemplo b:<\/strong><\/p>\n
        select zip, count(1) zipcount\r\nfrom customer\r\nwhere type = \"cx\" \r\nand city = \"San Francisco\"\r\nand state = \"CA\"\r\ngroup by zip;\r\n\r\n<\/pre>\n
        No exemplo acima, o group by est\u00e1 na terceira chave (zip) do \u00edndice e a chave hash (zip) faz parte da cl\u00e1usula group by. Na cl\u00e1usula de predicado (cl\u00e1usula WHERE), h\u00e1 um \u00fanico predicado de igualdade nas principais chaves de \u00edndice antes da chave zip (estado e cidade).  Portanto, inclu\u00edmos implicitamente as chaves (state, city) no group by sem afetar o resultado da consulta. Isso ajudar\u00e1 a consulta a fazer a varredura do \u00edndice e simplesmente criar\u00e1 os grupos necess\u00e1rios.<\/span><\/p>\n
        Exemplo c:<\/strong><\/p>\n
        select zip, count(1) zipcount\r\nfrom customer\r\nwhere type = \"cx\" \r\nand city like \"San%\"\r\nand state = \"CA\"\r\ngroup by zip;\r\n<\/pre>\n
         <\/p>\n
        No exemplo acima, o group by est\u00e1 na terceira chave (zip) do \u00edndice e a chave hash (zip) faz parte da cl\u00e1usula group by. Na cl\u00e1usula de predicado (cl\u00e1usula WHERE), h\u00e1 um predicado de intervalo na cidade. A chave de \u00edndice (city) est\u00e1 antes da chave de hash (zip).  Portanto, criamos agregados parciais como parte da varredura do \u00edndice e, em seguida, a consulta mesclar\u00e1 esses agregados parciais para criar o conjunto de resultados final. <\/span><\/p>\n
        Resumo:<\/span><\/h2>\n
        A parti\u00e7\u00e3o de \u00edndice oferece maior capacidade para o seu \u00edndice, melhor capacidade de consulta e maior desempenho para suas consultas.  Ao explorar a arquitetura de scale-out do Couchbase, os \u00edndices melhoram a capacidade, a capacidade de consulta, o desempenho e o TCO. <\/span><\/p>\n
        Refer\u00eancia:<\/span><\/h2>\n
          \n
        1. Documenta\u00e7\u00e3o do Couchbase: <\/span>https:\/\/developer.couchbase.com\/documentation\/server\/5.5\/indexes\/gsi-for-n1ql.html<\/span><\/a><\/li>\n
        2. Documenta\u00e7\u00e3o do N1QL do Couchbase:\u00a0<\/span>https:\/\/developer.couchbase.com\/documentation\/server\/5.5\/indexes\/gsi-for-n1ql.html#<\/a><\/li>\n<\/ol>","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 […]<\/p>","protected":false},"author":55,"featured_media":5003,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[1815,1816,9417,1812],"tags":[1505,1261,1725],"ppma_author":[8929],"class_list":["post-5002","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"],"acf":[],"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\/pt\/couchbase-gsi-index-partitioning\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\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\/pt\/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=\"article:modified_time\" content=\"2025-06-14T03:20:06+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2018\/04\/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=\"10 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\",\"dateModified\":\"2025-06-14T03:20:06+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/\"},\"wordCount\":1526,\"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\/1\/2018\/04\/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\":\"pt-BR\",\"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\/1\/2018\/04\/Screen-Shot-2018-04-11-at-5.36.15-PM.png\",\"datePublished\":\"2018-04-12T01:14:09+00:00\",\"dateModified\":\"2025-06-14T03:20:06+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\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/#primaryimage\",\"url\":\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2018\/04\/Screen-Shot-2018-04-11-at-5.36.15-PM.png\",\"contentUrl\":\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2018\/04\/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\":\"pt-BR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/#organization\",\"name\":\"The Couchbase Blog\",\"url\":\"https:\/\/www.couchbase.com\/blog\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2023\/04\/admin-logo.png\",\"contentUrl\":\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2023\/04\/admin-logo.png\",\"width\":218,\"height\":34,\"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\":\"pt-BR\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/#\/schema\/person\/image\/4e51d72fc07c662aa791316deafffac4\",\"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, holds eleven US patents and has four US patents pending.\",\"sameAs\":[\"https:\/\/blog.planetnosql.com\/\",\"https:\/\/x.com\/rkeshavmurthy\"],\"url\":\"https:\/\/www.couchbase.com\/blog\/pt\/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\/pt\/couchbase-gsi-index-partitioning\/","og_locale":"pt_BR","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\/pt\/couchbase-gsi-index-partitioning\/","og_site_name":"The Couchbase Blog","article_published_time":"2018-04-12T01:14:09+00:00","article_modified_time":"2025-06-14T03:20:06+00:00","og_image":[{"width":2530,"height":645,"url":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2018\/04\/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":"10 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","dateModified":"2025-06-14T03:20:06+00:00","mainEntityOfPage":{"@id":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/"},"wordCount":1526,"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\/1\/2018\/04\/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":"pt-BR","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\/1\/2018\/04\/Screen-Shot-2018-04-11-at-5.36.15-PM.png","datePublished":"2018-04-12T01:14:09+00:00","dateModified":"2025-06-14T03:20:06+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":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/www.couchbase.com\/blog\/couchbase-gsi-index-partitioning\/#primaryimage","url":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2018\/04\/Screen-Shot-2018-04-11-at-5.36.15-PM.png","contentUrl":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2018\/04\/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":"Blog do Couchbase","description":"Couchbase, o banco de dados NoSQL","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":"pt-BR"},{"@type":"Organization","@id":"https:\/\/www.couchbase.com\/blog\/#organization","name":"Blog do Couchbase","url":"https:\/\/www.couchbase.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/www.couchbase.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2023\/04\/admin-logo.png","contentUrl":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2023\/04\/admin-logo.png","width":218,"height":34,"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":"pt-BR","@id":"https:\/\/www.couchbase.com\/blog\/#\/schema\/person\/image\/4e51d72fc07c662aa791316deafffac4","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 \u00e9 vice-presidente de P&D da Couchbase. Anteriormente, ele trabalhou na MapR, IBM, Informix e Sybase, com mais de 20 anos de experi\u00eancia em design e desenvolvimento de bancos de dados. Ele liderou a equipe de P&D de SQL e NoSQL na IBM Informix. Ele recebeu dois pr\u00eamios President's Club na Couchbase e dois Outstanding Technical Achievement Awards na IBM. Keshav \u00e9 bacharel em Ci\u00eancia da Computa\u00e7\u00e3o e Engenharia pela Universidade de Mysore, \u00cdndia, det\u00e9m onze patentes nos EUA e tem quatro patentes pendentes nos EUA.","sameAs":["https:\/\/blog.planetnosql.com\/","https:\/\/x.com\/rkeshavmurthy"],"url":"https:\/\/www.couchbase.com\/blog\/pt\/author\/keshav-murthy\/"}]}},"authors":[{"term_id":8929,"user_id":55,"is_guest":0,"slug":"keshav-murthy","display_name":"Keshav Murthy","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/af74df754db27152971d0aed2f323ead5a1f9fe5afd0209af91e12e784451224?s=96&d=mm&r=g","author_category":"","last_name":"Murthy","first_name":"Keshav","job_title":"","user_url":"https:\/\/blog.planetnosql.com\/","description":"Keshav Murthy \u00e9 vice-presidente de P&D da Couchbase. Anteriormente, ele trabalhou na MapR, IBM, Informix e Sybase, com mais de 20 anos de experi\u00eancia em design e desenvolvimento de bancos de dados. Ele liderou a equipe de P&D de SQL e NoSQL na IBM Informix. Recebeu dois pr\u00eamios President's Club na Couchbase e dois Outstanding Technical Achievement Awards na IBM. Keshav \u00e9 bacharel em Ci\u00eancia da Computa\u00e7\u00e3o e Engenharia pela Universidade de Mysore, \u00cdndia, det\u00e9m dez patentes nos EUA e tem tr\u00eas patentes pendentes nos EUA."}],"_links":{"self":[{"href":"https:\/\/www.couchbase.com\/blog\/pt\/wp-json\/wp\/v2\/posts\/5002","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.couchbase.com\/blog\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.couchbase.com\/blog\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/pt\/wp-json\/wp\/v2\/users\/55"}],"replies":[{"embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/pt\/wp-json\/wp\/v2\/comments?post=5002"}],"version-history":[{"count":0,"href":"https:\/\/www.couchbase.com\/blog\/pt\/wp-json\/wp\/v2\/posts\/5002\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/pt\/wp-json\/wp\/v2\/media\/5003"}],"wp:attachment":[{"href":"https:\/\/www.couchbase.com\/blog\/pt\/wp-json\/wp\/v2\/media?parent=5002"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/pt\/wp-json\/wp\/v2\/categories?post=5002"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/pt\/wp-json\/wp\/v2\/tags?post=5002"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/pt\/wp-json\/wp\/v2\/ppma_author?post=5002"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}