Lo m\u00e1s probable es que la primera respuesta sea \"depende de su caso de uso y de la forma de sus datos\", pero sinceramente eso no ayuda mucho.<\/p>\n
Esta entrada del blog trata de responder a la pregunta del rendimiento con un poco m\u00e1s de detalle y dar algunas cifras reales en t\u00e9rminos de tiempo de ejecuci\u00f3n y mostrar c\u00f3mo optimizar las consultas para obtener m\u00e1s rendimiento.<\/p>\n
Historia de fondo<\/h2>\n
Couchbase utiliza N1QL en varias herramientas y aplicaciones internas y la semana pasada hice una observaci\u00f3n muy importante.<\/p>\n
Cuando se utiliza N1QL es extremadamente importante crear \u00edndices.<\/strong><\/p>\n En una peque\u00f1a aplicaci\u00f3n, a\u00f1adir un \u00edndice a un atributo cambi\u00f3 el tiempo de ejecuci\u00f3n de +2min. a 2 segundos. No se hizo ning\u00fan cambio en la consulta en s\u00ed, \u00a1el \u00fanico cambio fue el \u00edndice!<\/p>\n Nota: El tiempo de consulta anterior no es para una sola consulta N1QL, sino para una secuencia de m\u00faltiples consultas en la aplicaci\u00f3n en una m\u00e1quina virtual relativamente poco potente.<\/p>\n<\/blockquote>\n El tiempo de ejecuci\u00f3n esperado para una consulta depende en gran medida de la complejidad de la consulta y del sistema, el Couchbase Server y el hardware.<\/p>\n Por eso, para dar una respuesta m\u00e1s precisa se necesita un banco de pruebas. Se trata de un conjunto bien definido de pruebas que pueden ejecutarse en diferentes sistemas para revelar las m\u00e9tricas de rendimiento reales de una configuraci\u00f3n determinada. De este modo, se puede obtener una medici\u00f3n para un sistema y una consulta reales.<\/p>\n As\u00ed, en lugar de limitarnos a afirmar que N1QL es r\u00e1pido, podemos probarlo en un sistema real: \u00a1tu propia configuraci\u00f3n!<\/p>\n En primer lugar, el rendimiento es un reto. Es un reto medirlo, pero el verdadero problema es que a menudo olvidamos QU\u00c9 estamos probando y, por tanto, tambi\u00e9n olvidamos cu\u00e1ndo poner en marcha el \"cron\u00f3metro\" y cu\u00e1ndo volver a pararlo.<\/p>\n Por lo tanto, al realizar una prueba es importante definir lo que se pretende medir y c\u00f3mo medirlo de forma justa, repetible y comparable.<\/p>\n En nuestro caso queremos medir la diferencia en el tiempo de ejecuci\u00f3n de una consulta N1QL predefinida cuando se utiliza un \u00edndice y cuando no se utiliza.<\/p>\n S\u00f3lo estamos interesados en el tiempo de ejecuci\u00f3n real de la consulta N1QL, independientemente de cualquier retraso espec\u00edfico de la plataforma, tales como: retrasos de red, tiempo de arranque, rendimiento del SDK, tiempos de configuraci\u00f3n\/limpieza, etc.<\/p>\n \u00a1En otras palabras, para esta prueba de rendimiento en particular, estamos ignorando todo lo que no sea el 'tiempo de ejecuci\u00f3n de la consulta' en los dos escenarios!<\/p>\n Por suerte, medir el tiempo de ejecuci\u00f3n de una consulta es muy f\u00e1cil. Cada respuesta de Couchbase Server se devuelve con un valor La m\u00e9trica anterior contiene Antes de ejecutar cualquier consulta, necesitamos algunos datos de prueba para ejecutar las consultas. La cantidad de datos de prueba que tenemos puede influir en gran medida los resultados de la prueba y por lo tanto esto debe ser configurable para cada prueba.<\/p>\n La forma de crear los datos de prueba no es en absoluto importante para nuestra prueba, como tampoco lo es el tiempo que se tarde en crearlos. Lo importante es la forma de los datos, ya que deben reflejar lo mejor posible los datos reales. Aparte de eso, tenemos un alto nivel de libertad en la forma de crearlos y el tiempo que se tarda.<\/p>\n En la mayor\u00eda de los casos es justo asumir que los documentos variar\u00e1n en tama\u00f1o y forma. A Couchbase no le afecta la forma del documento. Couchbase s\u00f3lo \"ve\" una clave que apunta a un valor. El tama\u00f1o es un tema diferente y por lo tanto los documentos en el conjunto de datos deben variar en tama\u00f1o.<\/p>\n La imitaci\u00f3n de varios documentos diferentes puede lograrse cambiando un Los criterios de los datos de prueba pueden reducirse ahora a:<\/p>\n Teniendo esto en cuenta, vamos a definir la estructura del documento JSON de la siguiente manera:<\/p>\n La estructura del documento anterior representa el documento de prueba. El tama\u00f1o de cada documento puede variar mucho, ya que todos los Es probable que un sistema real contenga m\u00e1s de un tipo de documento y al cambiar el valor de El atributo En Cargar los documentos en un bucket en Couchbase Server puede hacerse de muchas maneras. Una opci\u00f3n ser\u00eda crear previamente los documentos y cargarlos en el bucket utilizando una combinaci\u00f3n de los m\u00e9todos Otra opci\u00f3n ser\u00eda crear los datos de prueba sobre la marcha. Supongo que se le ocurrir\u00e1n otras formas de cargar los datos. Recuerde que este paso no es cr\u00edtico para el rendimiento. Haz lo que te resulte m\u00e1s f\u00e1cil.<\/p>\n Con las definiciones anteriores en su lugar, estamos listos para definir los pasos para el banco de pruebas:<\/p>\n Aunque las funciones de manipulaci\u00f3n de datos de N1QL a\u00fan est\u00e1n en fase de previsualizaci\u00f3n, ya pueden utilizarse. Eso hace que la limpieza de datos sea muy sencilla:<\/p>\n Los \u00edndices pueden eliminarse mediante la funci\u00f3n Couchbase Server devolver\u00e1 un error si el archivo Probablemente ser\u00eda posible seguir utilizando las funciones de manipulaci\u00f3n de datos de N1QL para crear un conjunto de datos aleatorios, pero tambi\u00e9n ser\u00eda un poco m\u00e1s complicado que crear los documentos en c\u00f3digo.<\/p>\n El c\u00f3digo del banco de pruebas se implementar\u00e1 utilizando .NET y los documentos se generar\u00e1n utilizando el siguiente fragmento C#:<\/p>\n El m\u00e9todo utiliza un bucle interior y otro exterior. El bucle interno define el tama\u00f1o del lote de subida. El bucle externo define el n\u00famero de lotes a subir a Couchbase Server.<\/p>\n Los bucles se a\u00f1aden para garantizar que el programa no se quede sin memoria al cargar un gran conjunto de datos.<\/p>\n Despu\u00e9s de subir los documentos de prueba a Couchbase Server es hora de ejecutar la primera parte de la prueba y registrar el tiempo de ejecuci\u00f3n:<\/p>\n Dependiendo del n\u00famero de documentos utilizados en la prueba, es probable que esta consulta agote el tiempo de espera. En mi sistema, al ejecutar esta consulta con 500.000 documentos, se agota el tiempo de espera. Con 15.000 documentos, la consulta tarda unos 15 segundos.<\/p>\n Ahora es el momento de crear los \u00edndices:<\/p>\n En \u00cdndice m\u00faltiple frente a \u00edndice \u00fanico:<\/strong> Tener varios \u00edndices independientes es beneficioso si se busca en cada atributo en consultas independientes en las que faltan otros atributos.<\/em><\/p>\n Sin embargo, tener un solo \u00edndice reduce la sobrecarga de mantener \u00edndices separados y puede simplemente reducir los requisitos de recursos y tambi\u00e9n puede acelerar la consulta a\u00fan m\u00e1s, ya que tiene la capacidad de encontrar los elementos que califican para todos los criterios de filtro de una sola vez.<\/em><\/p>\n En lugar de los tres \u00edndices independientes podr\u00edamos utilizar esto:<\/em><\/p>\n O incluso:<\/em><\/p>\n Sin embargo, me parece m\u00e1s correcto tener varios \u00edndices para este tipo de pruebas. Siempre se puede ejecutar la prueba con un solo \u00edndice y medir la diferencia en el tiempo de ejecuci\u00f3n y utilizar esa medida para tomar una decisi\u00f3n final de lo que's mejor en su caso particular.<\/em><\/p>\n Una vez creados los \u00edndices, es hora de ejecutar la segunda parte de la prueba y registrar el tiempo de ejecuci\u00f3n:<\/p>\n Nota: se trata exactamente de la misma consulta utilizada en el paso 3. No se han realizado cambios en la consulta en s\u00ed.<\/p>\n<\/blockquote>\n Los tiempos de ejecuci\u00f3n t\u00edpicos en mi sistema oscilan entre 4 y 23 ms. Es una gran diferencia. Pero, \u00bfc\u00f3mo afecta el tama\u00f1o del conjunto de datos a esta medida? Tendr\u00e1s que seguir leyendo para obtener esa respuesta.<\/p>\n Borrar todos los documentos de prueba, eliminar los \u00edndices y devolver el sistema al estado conocido antes de ejecutar la prueba. Es lo mismo que el paso 1.<\/p>\n Se podr\u00eda argumentar que el paso 1 o el paso 6 no son necesarios, pero ambos son muy importantes. Piense en el caso de que una prueba se interrumpa (se cancele, falle, etc.).<\/p>\n El \u00faltimo paso, y espero que el m\u00e1s interesante, el resultado.<\/p>\n Resultados de mi sistema:<\/p>\n Resumen de los resultados de mi sistema:<\/strong><\/p>\n MacBook Pro 16 GB de memoria, Couchbase Server ejecut\u00e1ndose en Windows 10 usando Parallels Desktop con 10 GB de memoria (Couchbase Server tiene 2 GB de memoria)<\/p>\n\n
Creaci\u00f3n de un banco de pruebas<\/h2>\n
Medida<\/code> que contiene todas las m\u00e9tricas sobre la solicitud.<\/p>\n\r\n
\"Metrics\": \r\n{\r\n \"elapsedTime\": \"1.7900093s\",\r\n \"executionTime\": \"1.7900093s\",\r\n \"resultCount\": 0,\r\n \"resultSize\": 0,\r\n \"mutationCount\": 0,\r\n \"errorCount\": 0,\r\n \"warningCount\": 0\r\n}<\/code><\/pre>\nexecutionTime<\/code> y este valor representa el tiempo de ejecuci\u00f3n en Couchbase Server, independientemente de la latencia de la red, el tiempo de ejecuci\u00f3n del c\u00f3digo de la plataforma, etc. Es exactamente lo que necesitamos.<\/p>\ntipo<\/code> en el documento JSON. De nuevo, la forma no es importante para Couchbase, pero cambiando el atributo tipo<\/code> podemos imitar distintos tipos de documentos aunque compartan la misma estructura documental.<\/p>\n\n
tipo<\/code> que puede modificarse para imitar diferentes documentos del conjunto de datos.<\/li>\n<\/ul>\n\r\n
{\r\n \"Id\": \"GUID\",\r\n \"type\": \"perfTest\",\r\n \"IndexedType\": \"person + #\",\r\n \"NoneIndexedType\": \"person + #\",\r\n \"Day\": 1->29,\r\n \"Month\": 1->12,\r\n \"Year\": 2015,\r\n \"TextSmall\": \"100->250 random chars\",\r\n \"TextMedium\": \"200->500 random chars\",\r\n \"TextLarge\": \"700->1000 random chars\",\r\n \"TextExtraLarge\": \"1200-1500 random chars\"\r\n}<\/code><\/pre>\nTexto...<\/code> tienen un tama\u00f1o y un valor aleatorios. Al tener este tama\u00f1o y contenido aleatorios, cada documento imita mejor los documentos reales de un sistema real.<\/p>\nTipo indexado<\/code> la misma estructura de documento puede imitar diferentes tipos de documento en el sistema.<\/p>\nTipo indexado<\/code> puede tomar diferentes valores predecibles en la forma: persona1<\/code>, persona2<\/code>, persona3<\/code> y persona4<\/code>. Los cuatro valores diferentes se utilizan para imitar cuatro documentos diferentes. Es posible a\u00f1adir m\u00e1s 'tipos' pero para nuestra prueba cuatro son suficientes.<\/p>\ntipo<\/code> permite buscar y eliminar f\u00e1cilmente los documentos de prueba una vez finalizada la prueba, y siempre recibe el valor perfTest<\/code>.<\/p>\ncbbackup<\/code> y cbrestore<\/code> herramientas.<\/p>\n\n
Aplicaci\u00f3n<\/h2>\n
Primer paso<\/h3>\n
\r\n
\"DELETE FROM `default` d WHERE d.type = 'perfTest' RETURNING d.Id<\/code><\/pre>\nDROP<\/code> mando:<\/p>\n\r\n
DROP INDEX `default`.`index_1` USING GSI;\r\nDROP INDEX `default`.`index_2` USING GSI;\r\nDROP INDEX `default`.`index_3` USING GSI;<\/code><\/pre>\nDROP<\/code> se ejecuta contra un \u00edndice que no existe. Esto puede solucionarse con una comprobaci\u00f3n de si el \u00edndice existe o no:<\/p>\n\r\n
SELECT * FROM system:indexes WHERE name='index_1'; \r\nSELECT * FROM system:indexes WHERE name='index_2'; \r\nSELECT * FROM system:indexes WHERE name='index_3'; <\/code><\/pre>\nPaso 2<\/h3>\n
\r\n
private static void GenerateDocuments()\r\n{\r\n int rounds = numberOfTestDocuments > batchSize ? numberOfTestDocuments \/ batchSize : 1;\r\n int testDocsPerLoop = rounds > 1 ? batchSize : numberOfTestDocuments;\r\n Random ran = new Random();\r\n\r\n for (int n = 0; n < rounds; n++)\r\n {\r\n var docs = new DictionaryPaso 3<\/h3>\n
\r\n
SELECT * FROM `default` WHERE IndexedType='person3' AND Month > 5 AND Day < 20<\/code><\/pre>\nPaso 4<\/h3>\n
\r\n
CREATE INDEX `index_1` ON `default`(IndexedType) USING GSI;\r\nCREATE INDEX `index_2` ON `default`(Month) USING GSI;\r\nCREATE INDEX `index_3` ON `default`(Day) USING GSI;<\/code><\/pre>\nCREAR \u00cdNDICE<\/code> es s\u00edncrono y vuelve cuando el \u00edndice secundario est\u00e1 creado y listo. Eso significa que este comando puede tardar un rato en completarse, dependiendo del n\u00famero de documentos de la prueba y del tama\u00f1o de tu m\u00e1quina.<\/p>\n\r\n
CREATE INDEX `index_type_month_year` ON `default`(IndexedType, Month, Year) USING GSI;<\/code><\/pre>\n\r\n
CREATE INDEX `index_type_month_year` ON `default`(IndexedType, Month, Year) WHERE IndexedType='person3' AND Month > 5 AND Day < 20 USING GSI;<\/code><\/pre>\nPaso 5<\/h3>\n
\r\n
SELECT * FROM `default` WHERE IndexedType='person3' AND Month > 5 AND Day < 20<\/code><\/pre>\n\n
Paso 6<\/h3>\n
Paso 7<\/h3>\n
![\"Test](\"https:\/\/raw.githubusercontent.com\/martinesmann\/cb-n1ql-index-demo\/master\/Content\/test-1.png\")
<\/p>\n![\"Test](\"https:\/\/raw.githubusercontent.com\/martinesmann\/cb-n1ql-index-demo\/master\/Content\/test-2.png\")
<\/p>\n