{"id":2249,"date":"2016-05-19T22:59:51","date_gmt":"2016-05-19T22:59:51","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=2249"},"modified":"2025-10-09T07:13:03","modified_gmt":"2025-10-09T14:13:03","slug":"faster-indexing-and-query-with-memory-optimized-global-secondary-indexes-gsi-part-ii","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/faster-indexing-and-query-with-memory-optimized-global-secondary-indexes-gsi-part-ii\/","title":{"rendered":"Indexaci\u00f3n y consulta m\u00e1s r\u00e1pidas: Introducci\u00f3n a los \u00edndices secundarios globales optimizados para memoria - PARTE II"},"content":{"rendered":"

En PARTE I<\/a>, hemos cubierto las diferencias en la indexaci\u00f3n con \u00edndices locales y globales. Tambi\u00e9n hemos concluido con las 2 opciones de almacenamiento que Couchbase Server proporciona para los \u00edndices secundarios globales: GSI est\u00e1ndar y GSI optimizado para memoria. Vamos a sumergirnos ahora en GSI optimizado para memoria;<\/p>\n

\u00bfQu\u00e9 es un \u00edndice secundario global optimizado para memoria?<\/h2>\n

En post anterior sobre \u00edndices globales y locales<\/a>hemos hablado extensamente de c\u00f3mo los \u00edndices globales reducen la latencia de las consultas frente a los \u00edndices locales. Tambi\u00e9n vimos lo dif\u00edcil que puede ser mantener estos \u00edndices globales: Los \u00edndices globales requieren un subconjunto de nodos para mantener un gran cluster de nodos. En el caso de Couchbase Server, 10-100K ops\/sec es la norma para un cluster. <\/span><\/p>\n

Desaf\u00edos\u00a0\u00a1no terminan ah\u00ed! La indexaci\u00f3n global puede ser a\u00fan m\u00e1s dif\u00edcil en casos como los \u00edndices de matrices (m\u00e1s informaci\u00f3n sobre los \u00edndices de matrices\u00a0<\/span>aqu\u00ed<\/a>). Los \u00edndices de matrices indexan los elementos de una <\/span>incrustado\u00a0array en un documento JSON y las mutaciones a documentos con arrays amplifican un documento<\/span>\u00a0a muchas escrituras de \u00edndice.\u00a0<\/span>El \u00edndice secundario global optimizado para memoria (MOI) se ha creado espec\u00edficamente para resolver los retos de estas aplicaciones m\u00e1s exigentes.\u00a0itinerario de viaje, marcador\u00a0<\/em>y\u00a0detecci\u00f3n del fraude<\/em>\u00a0- No hay problema.<\/p>\n

MOI puede proporcionar m\u00e1s de 10 veces mejor latencia y rendimiento bajo mutaciones m\u00e1s r\u00e1pidas a los datos en comparaci\u00f3n con GSI est\u00e1ndar y aqu\u00ed es c\u00f3mo lo hace:<\/p>\n

    \n
  1. El procesamiento sin bloqueo para la indexaci\u00f3n simplemente permite una concurrencia masiva al mantener la mutaci\u00f3n entrante al \u00edndice.<\/li>\n
  2. La estructura Skiplist optimiza el almacenamiento en memoria, a diferencia de los \u00edndices B+Tree.<\/li>\n
  3. Forzar el almacenamiento del \u00edndice en memoria, significa que MOI no funciona a velocidades de disco para almacenar el \u00edndice - en su lugar toma instant\u00e1neas regulares a disco s\u00f3lo para recuperaci\u00f3n.<\/li>\n<\/ol>\n

    \u00cdndices secundarios globales est\u00e1ndar y optimizados para memoria<\/h3>\n

    Los \u00edndices optimizados para memoria se a\u00f1aden en la versi\u00f3n 4.5 como opci\u00f3n de almacenamiento adicional para los GSI. Los \u00edndices secundarios globales est\u00e1ndar existen desde la versi\u00f3n 4.0. Los administradores pueden configurar GSI con el almacenamiento GSI est\u00e1ndar, que utiliza ForestDB por debajo, para los \u00edndices que no caben en memoria o pueden elegir el GSI optimizado en memoria para una indexaci\u00f3n y consultas en memoria m\u00e1s r\u00e1pidas.<\/p>\n

    Normalmente, los \u00edndices se crean para reducir la latencia de las consultas y mantener los \u00edndices en memoria reduce la latencia mucho m\u00e1s. MOI est\u00e1 dise\u00f1ado para reducir la latencia y <\/span>m\u00e1s alto\u00a0Las necesidades de rendimiento y MOI requieren m\u00e1quinas con mucha memoria para mantener el \u00edndice en RAM. El GSI est\u00e1ndar puede volcarse al disco cuando se agota la memoria. El rendimiento del subsistema IO pasa a ser <\/span>extremadamente\u00a0importante para que la GSI est\u00e1ndar pueda funcionar bien. Sin embargo, a diferencia de la GSI est\u00e1ndar, h<\/span>MOI no requiere un subsistema de E\/S de alto rendimiento. Como MOI se ejecuta a velocidades en memoria, los tiempos de indexaci\u00f3n inicial y continua son m\u00e1s r\u00e1pidos con MOI en comparaci\u00f3n con GSI est\u00e1ndar.\u00a0<\/span><\/p>\n

    La siguiente tabla resume las principales diferencias entre los GSI est\u00e1ndar y los optimizados para memoria;<\/p>\n

    <\/p>\n

    Creaci\u00f3n y gesti\u00f3n de GSI optimizados para memoria<\/h3>\n

    Independientemente del tipo de tienda, CREATE INDEX es la forma de crear \u00edndices secundarios globales en Couchbase Server. De hecho no hay opciones espec\u00edficas de MOI en la sentencia CREATE INDEX. En general, la alta disponibilidad y la mec\u00e1nica de particionado permanecen iguales con GSI est\u00e1ndar vs optimizado para memoria. Sin embargo, es importante tener en cuenta que MOI viene con estad\u00edsticas adicionales y alertas para ayudar con la colocaci\u00f3n de \u00edndices y con la gesti\u00f3n de \u00edndices.<\/p>\n

    Colocaci\u00f3n de \u00edndices optimizados en memoria en el cl\u00faster del servidor Couchbase<\/h4>\n

    Los \u00edndices optimizados para memoria proporcionan 2 estad\u00edsticas importantes que pueden guiar la colocaci\u00f3n de MOI con la cl\u00e1usula NODES en CREAR \u00cdNDICE<\/a>.<\/p>\n