{"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\/es\/couchbase-gsi-index-partitioning\/","title":{"rendered":"Divide y vencer\u00e1s: partici\u00f3n del \u00edndice GSI de Couchbase."},"content":{"rendered":"

En Couchbase, los datos siempre se particionan mediante el m\u00e9todo <\/span>hash coherente<\/span><\/a> de la clave del documento en vbukets que se almacenan en los nodos de datos. Couchbase <\/span>\u00cdndice Secundario Global (IGS)<\/span><\/a> abstrae las operaciones de indexaci\u00f3n y se ejecuta como un servicio distinto dentro de la plataforma de datos Couchbase. Cuando un \u00fanico \u00edndice puede cubrir todo un tipo de documentos, todo va bien. Pero, hay casos en los que querr\u00edas particionar un \u00edndice.<\/span><\/p>\n

    \n
  1. Capacidad: Desea aumentar la capacidad porque un solo nodo no puede contener un \u00edndice grande. <\/span><\/li>\n
  2. Consultabilidad: Desea evitar reescribir la consulta para trabajar con la partici\u00f3n manual del \u00edndice utilizando un \u00edndice parcial.<\/span><\/li>\n
  3. Rendimiento: El \u00edndice \u00fanico no puede cumplir el SLA<\/span><\/li>\n<\/ol>\n

    Para solucionar esto, Couchbase 5.5 introduce la partici\u00f3n hash autom\u00e1tica del \u00edndice. Est\u00e1s acostumbrado a tener datos de bucket con hash en m\u00faltiples nodos. La partici\u00f3n del \u00edndice te permite hashear el \u00edndice en m\u00faltiples nodos tambi\u00e9n. Hay una buena simetr\u00eda.<\/span><\/p>\n

    Crear el \u00edndice es f\u00e1cil. Basta con a\u00f1adir una cl\u00e1usula PARTITION BY a la definici\u00f3n del \u00edndice CREATE.<\/span><\/p>\n

    CREAR \u00cdNDICE ih EN cliente(estado, nombre, c\u00f3digo postal, estado)\r\nPARTICI\u00d3N POR HASH(estado)\r\nWHERE tipo = \"cx\" CON {\"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
    seleccionar *\r\nfrom sistema:\u00edndices\r\nwhere espacio_clave_id = \"cliente\" and nombre = \"ih\" ;\r\n  {\r\n    \"\u00edndices\": {\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
    Ahora, realice la siguiente consulta. No es necesario un predicado adicional sobre la clave hash para que la consulta utilice el \u00edndice.   El escaneo del \u00edndice simplemente escanea todas las particiones del \u00edndice como parte del escaneo del \u00edndice.<\/span><\/p>\n
    SELECT *\r\nFROM cliente\r\nWHERE tipo = \"cx\"\r\ny nombre = \"acme\"\r\ny zip = \"94051\";\r\n\r\n<\/pre>\n
    Sin embargo, si tiene un predicado de igualdad en la clave hash, el escaneo de \u00edndice detecta la partici\u00f3n de \u00edndice correcta que tiene el rango de datos correcto y elimina el resto de los nodos de \u00edndice del escaneo de \u00edndice.    Esto hace que el escaneo de \u00edndices sea muy eficiente.<\/span><\/p>\n
    SELECT *\r\nFROM cliente\r\nWHERE tipo = \"cx\"\r\ny nombre = \"acme\"\r\ny zip = \"94051\"\r\ny estado = \"CA\";\r\n<\/pre>\n
    Ahora, veamos c\u00f3mo este \u00edndice le ayuda con tres cosas que hemos mencionado antes: Capacidad, Consultabilidad y Rendimiento.<\/span><\/p>\n
    Capacidad<\/span><\/h2>\n
    The query `<\/span>customer`.`ih` <\/b>se particionar\u00e1 en un n\u00famero especificado de particiones y cada partici\u00f3n se almacenar\u00e1 en uno de los nodos indexadores del cl\u00faster.  El indexador utiliza un algoritmo de optimizaci\u00f3n estoc\u00e1stica para determinar c\u00f3mo distribuir las particiones en el conjunto de nodos indexadores, bas\u00e1ndose en los recursos libres disponibles en cada nodo.  Alternativamente, para restringir el \u00edndice a un conjunto espec\u00edfico de nodos, utilice el par\u00e1metro nodos. Este \u00edndice crear\u00e1 ocho particiones de \u00edndice y almacenar\u00e1 cuatro de cada una en los cuatro nodos de \u00edndice especificados. \u00a0<\/span><\/p>\n
    CREAR \u00cdNDICE ih EN cliente(estado, nombre, c\u00f3digo postal, estado)\r\nPARTICI\u00d3N POR HASH(estado)\r\nWHERE type = \"cx\" CON {\"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>) se dividir\u00e1 en un n\u00famero de particiones f\u00edsicas del \u00edndice (en este caso, 8 particiones) y dar\u00e1 a la consulta la ilusi\u00f3n de un \u00edndice \u00fanico. \u00a0<\/span><\/p>\n
    Dado que este \u00edndice utiliza los m\u00faltiples nodos f\u00edsicos, el \u00edndice dispondr\u00e1 de m\u00e1s recursos de disco, memoria y CPU. El mayor almacenamiento en estos nodos permite crear \u00edndices m\u00e1s grandes.<\/span><\/p>\n
    Escriba sus consultas, como de costumbre, requiriendo predicados s\u00f3lo la cl\u00e1usula WHERE (tipo = \"cx\") y al menos en una de las claves principales del \u00edndice (por ejemplo, nombre). \u00a0<\/span><\/p>\n
    Consultabilidad<\/span><\/h2>\n
    Limitaciones en la indexaci\u00f3n de Couchbase 5.0:<\/b><\/p>\n
    Hasta Couchbase 5.0, pod\u00edas particionar manualmente el \u00edndice como se muestra a continuaci\u00f3n. Ten\u00edas que particionarlos manualmente usando la cl\u00e1usula WHERE en el CREATE INDEX.  Considera los siguientes \u00edndices, uno por estado. Usando el par\u00e1metro node, podr\u00edas colocarlos en nodos de \u00edndice espec\u00edficos o el \u00edndice intentar\u00e1 repartirse autom\u00e1ticamente dentro de los nodos de \u00edndice.<\/span><\/p>\n
    CREAR INDEX i1 ON cliente(nombre, c\u00f3digo postal, estado) WHERE estado = \"CA\";\r\nCREAR \u00cdNDICE i2 EN cliente(nombre, c\u00f3digo postal, estado) DONDE estado = \"NV\";\r\nCREAR \u00cdNDICE i3 EN cliente(nombre, c\u00f3digo postal, estado) DONDE estado = \"OR\";\r\nCREAR \u00cdNDICE i4 EN cliente(nombre, c\u00f3digo postal, estado) DONDE estado = \"WA\";\r\n<\/pre>\n
    Para una consulta simple con predicado equalify sobre el estado, todo funciona bien.<\/span><\/p>\n
    SELECT *\r\nFROM cliente\r\nWHERE state = \"CA\" and name = \"acme\" and zip = \"94051\";\r\n<\/pre>\n
    Hay dos problemas con esta partici\u00f3n manual. \u00a0\u00a0<\/span><\/p>\n
      \n
    1. Considere lo siguiente con un predicado ligeramente complejo sobre el estado.  Dado que el predicado (state IN [\"CA\", \"OR\"]) no es un subconjunto de ninguna de las cl\u00e1usulas WHERE del \u00edndice, no se puede utilizar ninguno de los \u00edndices para la consulta siguiente.<\/span><\/li>\n<\/ol>\n
      SELECT * FROM cliente\r\nWHERE state IN [\"CA\", \"OR\"] and name = ACME;\r\nSELECT * FROM cliente\r\nWHERE estado > \"CA\" y nombre = ACME;\r\n<\/pre>\n
      2. Si los datos pasan a un nuevo estado, hay que tenerlo en cuenta y crear el \u00edndice con antelaci\u00f3n.<\/span><\/p>\n
      SELECT * FROM cliente WHERE estado = \"CO\" y nombre = ACME\r\n<\/pre>\n
       \u00a0\u00a0<\/span> Si el campo es num\u00e9rico, puede utilizar la funci\u00f3n MOD().<\/span><\/p>\n
      CREATE INDEX ix1 ON cliente(nombre, c\u00f3digo postal, estado) WHERE (MOD(cxid) % 4 = 0);\r\nCREAR INDEX ix2 ON cliente(nombre, c\u00f3digo postal, estado) WHERE (MOD(cxid) % 4 = 1);\r\nCREATE INDEX ix3 ON cliente(nombre, c\u00f3digo postal, estado) WHERE (MOD(cxid) % 4 = 2);\r\nCREATE INDEX ix4 ON cliente(nombre, c\u00f3digo postal, estado) WHERE (MOD(cxid) % 4 = 3);\r\n<\/pre>\n
      Incluso en este caso, cada bloque de consulta s\u00f3lo puede utilizar un \u00edndice y requiere que las consultas se redacten cuidadosamente para que coincidan con uno de los predicados de la cl\u00e1usula WHERE.<\/span><\/p>\n
      Soluci\u00f3n:<\/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>) sobre ocho particiones de \u00edndice f\u00edsicas. \u00a0<\/span><\/p>\n
      El cliente GSI toma toda la solicitud de exploraci\u00f3n del \u00edndice y, a continuaci\u00f3n, utilizando el predicado, intenta ver si puede identificar cu\u00e1l de las particiones del \u00edndice tiene los datos necesarios para la consulta.  Este es el proceso de poda de particiones (tambi\u00e9n conocido como eliminaci\u00f3n de particiones). Para el esquema de particionado basado en hash, los predicados de igualdad y de la cl\u00e1usula IN se benefician de la poda de particiones. Todas las dem\u00e1s expresiones utilizan el m\u00e9todo de dispersi\u00f3n. Tras la eliminaci\u00f3n l\u00f3gica, el cliente GSI env\u00eda la solicitud a los nodos restantes, obtiene el resultado, lo fusiona y lo devuelve a la consulta.  La gran ventaja de esto es que las consultas pueden escribirse sin preocuparse de la expresi\u00f3n de partici\u00f3n manual. <\/span><\/p>\n
      La consulta de ejemplo siguiente ni siquiera tiene un predicado sobre la clave hash, state.  La siguiente consulta no se beneficia de la eliminaci\u00f3n de particiones. Por lo tanto, el cliente GSI escanea cada partici\u00f3n del \u00edndice en paralelo y luego fusiona el resultado de cada escaneo del \u00edndice. La gran ventaja de esto es que las consultas se pueden escribir sin preocuparse por la expresi\u00f3n de partici\u00f3n manual para que coincida con la expresi\u00f3n de \u00edndice parcial y seguir utilizando toda la capacidad de los recursos del cl\u00faster. <\/span><\/p>\n
      CREAR \u00cdNDICE ih1 EN cliente(nombre, c\u00f3digo postal, estado)\r\nPARTICI\u00d3N POR HASH(estado)\r\nWHERE type = \"cx\" CON {\"num_partition\":8}\r\n\r\nSELECT *\r\nFROM cliente\r\nWHERE tipo = \"cx\"\r\ny nombre = \"acme\"\r\ny zip = \"94051\";\r\n<\/pre>\n
      El predicado adicional sobre la clave hash (estado = \"CA\") en la consulta siguiente se beneficiar\u00e1 de la poda de particiones.  Para el procesamiento de consultas, para consultas simples con predicados de igualdad en la clave hash, se obtiene una distribuci\u00f3n uniforme de la carga de trabajo en estas particiones m\u00faltiples del \u00edndice. En el caso de consultas complejas que incluyan la agrupaci\u00f3n y la agregaci\u00f3n de las que hemos hablado anteriormente, los escaneos y las agregaciones parciales se realizan en paralelo, lo que mejora la latencia de la consulta. \u00a0<\/span><\/p>\n
      SELECT *\r\nFROM cliente\r\nWHERE tipo = \"cx\"\r\ny nombre = \"acme\"\r\ny zip = \"94051\"\r\ny estado = \"CA\";\r\n\r\n<\/pre>\n
      Puede crear \u00edndices mediante hashing en una o m\u00e1s claves, cada una de las cuales puede ser una expresi\u00f3n.  He aqu\u00ed algunos ejemplos.<\/span><\/p>\n
      CREAR \u00cdNDICE idx1 EN cliente(nombre) PARTICI\u00d3N POR HASH(META().id);\r\nCREAR \u00cdNDICE idx2 EN cliente(nombre) PARTICI\u00d3N POR HASH(nombre, zip);\r\nCREAR \u00cdNDICE idx3 EN cliente(nombre)\r\n                      PARTITION BY HASH(SUBSTR(nombre, 5, 10));\r\nCREAR \u00cdNDICE idx3 EN cliente(nombre)\r\nPARTICI\u00d3N POR\r\nHASH(SUBSTR(META().id, POSITION(META().id, \"::\")+2), zip)\r\n<\/pre>\n
      Rendimiento<\/span><\/h2>\n
      Para la mayor\u00eda de las funciones de bases de datos, el rendimiento lo es todo. Sin un gran rendimiento, demostrado por buenas pruebas comparativas, las funciones no son m\u00e1s que bonitos diagramas sint\u00e1cticos.<\/span><\/p>\n
      La partici\u00f3n de \u00edndices mejora el rendimiento de dos maneras.<\/span><\/p>\n
        \n
      1. Escalabilidad. Las particiones se distribuyen en varios nodos, lo que aumenta la disponibilidad de CPU y memoria para la exploraci\u00f3n de \u00edndices. \u00a0<\/span><\/li>\n
      2. Escaneo paralelo. Predicado correcto que proporciona a las consultas el beneficio de la poda de particiones. Incluso despu\u00e9s del proceso de poda, los escaneos de todos los \u00edndices se realizan en paralelo.<\/span><\/li>\n
      3. Agrupaci\u00f3n y agregaci\u00f3n paralelas. El art\u00edculo de DZone <\/span>Comprender la agrupaci\u00f3n y agregaci\u00f3n de \u00edndices en las consultas N1QL de Couchbase<\/span><\/a> explica la mejora fundamental del rendimiento de la agrupaci\u00f3n y agregaci\u00f3n mediante \u00edndices. \u00a0<\/span><\/li>\n
      4. El paralelismo de la exploraci\u00f3n paralela del \u00edndice (y la agrupaci\u00f3n, agregaci\u00f3n) viene determinado por el par\u00e1metro <\/span>max_paralelismo<\/span><\/a> par\u00e1metro. Este par\u00e1metro puede establecerse por nodo de consulta y\/o por solicitud de consulta.<\/span><\/li>\n<\/ol>\n
        Considere el siguiente \u00edndice y consulta:<\/span><\/p>\n
        CREAR \u00cdNDICE ih1 EN cliente(nombre, c\u00f3digo postal, estado)\r\nPARTICI\u00d3N POR HASH(estado)\r\nWHERE type = \"cx\" CON {\"num_partition\":8}\r\n\r\nselect c\u00f3digo postal, count(1) zipcount\r\nfrom cliente\r\nwhere type = \"cx\" and name is not missing\r\ngroup by zip;\r\n<\/pre>\n
        El \u00edndice est\u00e1 particionado por HASH(state), pero el predicado state no aparece en la consulta.  Para esta consulta, no podemos realizar la poda de particiones ni crear grupos dentro de los escaneos individuales de las particiones del \u00edndice.  Por lo tanto, necesitar\u00e1 una fase de fusi\u00f3n despu\u00e9s de la agregaci\u00f3n parcial con la consulta (no se muestra en la explicaci\u00f3n). Recuerda que estas agregaciones parciales se realizan en paralelo y, por tanto, reducen la latencia de la consulta.<\/span><\/p>\n
        \"\"<\/p>\n
        Considere el siguiente \u00edndice y consulta:<\/span><\/p>\n
        CREAR \u00cdNDICE ih2 EN cliente(estado, ciudad, c\u00f3digo postal, situaci\u00f3n)\r\nPARTICI\u00d3N POR HASH(c\u00f3digo postal)\r\nWHERE type = \"cx\" CON {\"num_partition\":8}\r\n<\/pre>\n
        Ejemplo a:<\/strong><\/p>\n
        select estado, count(1) zipcount\r\nde cliente\r\ndonde no falta el estado\r\nagrupar por estado, ciudad, c\u00f3digo postal;\r\n<\/pre>\n
        En el ejemplo anterior, el grupo por est\u00e1 en las claves principales (estado, ciudad, c\u00f3digo postal) del \u00edndice y la clave hash (c\u00f3digo postal) forma parte de la cl\u00e1usula de grupo por. Esto ayudar\u00e1 a la consulta a escanear el \u00edndice y crear de forma sencilla los grupos necesarios.<\/span><\/p>\n
        Ejemplo b:<\/strong><\/p>\n
        select zip, count(1) zipcount\r\nfrom cliente\r\nwhere tipo = \"cx\"\r\ny ciudad = \"San Francisco\"\r\ny estado = \"CA\"\r\ngroup by zip;\r\n\r\n<\/pre>\n
        En el ejemplo anterior, el grupo por est\u00e1 en la tercera clave (zip) del \u00edndice y la clave hash (zip) forma parte de la cl\u00e1usula de grupo por. En la cl\u00e1usula de predicado (cl\u00e1usula WHERE), hay un \u00fanico predicado de igualdad en las claves de \u00edndice anteriores a la clave zip (estado y ciudad).  Por lo tanto, incluimos impl\u00edcitamente las claves (estado, ciudad) en el grupo por sin afectar al resultado de la consulta. Esto ayudar\u00e1 a la consulta a escanear el \u00edndice y crear de forma sencilla los grupos necesarios.<\/span><\/p>\n
        Ejemplo c:<\/strong><\/p>\n
        select zip, count(1) zipcount\r\nfrom cliente\r\ndonde tipo = \"cx\"\r\ny ciudad como \"San%\"\r\ny estado = \"CA\"\r\ngroup by zip;\r\n<\/pre>\n
         <\/p>\n
        En el ejemplo anterior, el grupo por est\u00e1 en la tercera clave (zip) del \u00edndice y la clave hash (zip) forma parte de la cl\u00e1usula de grupo por. En la cl\u00e1usula de predicado (cl\u00e1usula WHERE), hay un predicado de rango sobre la ciudad. La clave del \u00edndice (ciudad) est\u00e1 antes de la clave hash (c\u00f3digo postal).  Por lo tanto, creamos agregados parciales como parte de la exploraci\u00f3n del \u00edndice y, a continuaci\u00f3n, la consulta combinar\u00e1 estos agregados parciales para crear el conjunto de resultados final. <\/span><\/p>\n
        Resumen:<\/span><\/h2>\n
        La partici\u00f3n de \u00edndices te proporciona una mayor capacidad para tu \u00edndice, mejor consultabilidad y mayor rendimiento para tus consultas.  Al aprovechar la arquitectura de escalabilidad horizontal de Couchbase, los \u00edndices mejoran la capacidad, la consultabilidad, el rendimiento y el coste total de propiedad. <\/span><\/p>\n
        Referencia:<\/span><\/h2>\n
          \n
        1. Documentaci\u00f3n de Couchbase: <\/span>https:\/\/developer.couchbase.com\/documentation\/server\/5.5\/indexes\/gsi-for-n1ql.html<\/span><\/a><\/li>\n
        2. Documentaci\u00f3n de Couchbase N1QL:\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\/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=\"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\":\"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\/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\":\"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\/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\":\"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\/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\":\"es\",\"@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\/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","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":"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\/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":"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\/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":"El blog de Couchbase","description":"Couchbase, la base de datos 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":"es"},{"@type":"Organization","@id":"https:\/\/www.couchbase.com\/blog\/#organization","name":"El blog de Couchbase","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\/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":"es","@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 es Vicepresidente de Couchbase R&D. Anteriormente, estuvo en MapR, IBM, Informix, Sybase, con m\u00e1s de 20 a\u00f1os de experiencia en dise\u00f1o y desarrollo de bases de datos. Dirigi\u00f3 el equipo de I+D de SQL y NoSQL en IBM Informix. Ha recibido dos premios President's Club en Couchbase y dos premios Outstanding Technical Achievement en IBM. Keshav es licenciado en Inform\u00e1tica e Ingenier\u00eda por la Universidad de Mysore (India), es titular de once patentes estadounidenses y tiene cuatro pendientes.","sameAs":["https:\/\/blog.planetnosql.com\/","https:\/\/x.com\/rkeshavmurthy"],"url":"https:\/\/www.couchbase.com\/blog\/es\/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 es Vicepresidente de Couchbase R&D. Anteriormente, estuvo en MapR, IBM, Informix, Sybase, con m\u00e1s de 20 a\u00f1os de experiencia en dise\u00f1o y desarrollo de bases de datos. Dirigi\u00f3 el equipo de I+D de SQL y NoSQL en IBM Informix. Ha recibido dos premios President's Club en Couchbase y dos premios Outstanding Technical Achievement en IBM. Keshav es licenciado en Inform\u00e1tica e Ingenier\u00eda por la Universidad de Mysore (India), es titular de diez patentes estadounidenses y tiene tres pendientes."}],"_links":{"self":[{"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/posts\/5002","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=5002"}],"version-history":[{"count":0,"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/posts\/5002\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/media\/5003"}],"wp:attachment":[{"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/media?parent=5002"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/categories?post=5002"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/tags?post=5002"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/es\/wp-json\/wp\/v2\/ppma_author?post=5002"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}