Melhores práticas de desempenho: indexação

Mat Keep and Henrik Ingo
October 2, 2023

Bem-vindo ao terceiro de nossa série de postagens de blog que abordam as práticas recomendadas de desempenho para MongoDB.

Nesta série, abordamos as principais considerações para alcançar o desempenho em escala em uma série de dimensões importantes, incluindo:

Modelagem de dados e dimensionamento de memória (o conjunto de trabalho)
Padrões de consulta e criação de perfil
Indexação, que abordaremos hoje
Fragmentação
Transações e preocupações de leitura/gravação
Configuração de hardware e sistema operacional
Aquecimento de bancada

Tendo ambos trabalhado para alguns fornecedores de bancos de dados diferentes nos últimos 15 anos, podemos dizer com segurança que não definir os índices apropriados é o principal problema de desempenho que as equipes de suporte técnico precisam resolver com os usuários.

Portanto, precisamos acertar… aqui estão as melhores práticas para ajudá-lo.

Índices no MongoDB

Em qualquer banco de dados, os índices suportam a execução eficiente de consultas. Sem eles, o banco de dados deve examinar todos os documentos de uma collection ou tabela para selecionar aqueles que correspondem à instrução da consulta. Se existir um índice apropriado para uma consulta, o banco de dados poderá usar o índice para limitar o número de documentos que deve inspecionar.

O MongoDB oferece uma ampla variedade de tipos de índices e recursos com ordens de classificação específicas de linguagem para oferecer suporte a padrões de acesso complexos aos seus dados. Os índices MongoDB podem ser criados e eliminados sob demanda para acomodar requisitos de aplicativos e padrões de consulta em evolução e podem ser declarados em qualquer campo de seus documentos, incluindo campos aninhados em matrizes.

Então, vamos abordar como você faz o melhor uso dos índices no MongoDB.

Use índices compostos

Índices compostos são índices compostos por vários campos diferentes. Por exemplo, em vez de ter um índice em "Sobrenome" e outro em "Nome", normalmente é mais eficiente criar um índice que inclua "Sobrenome" e "Nome" se você consultar ambos os nomes. . Nosso índice composto ainda pode ser usado para filtrar consultas que especificam apenas o sobrenome.

Siga a regra ESR

Para índices compostos, esta regra prática é útil para decidir a ordem dos campos no índice:

Primeiro, adicione os campos nos quais as consultas de igualdade são executadas
Os próximos campos a serem indexados devem refletir a ordem de classificação da consulta
Os últimos campos representam o intervalo de dados a serem acessados

Use consultas cobertas quando possível

As consultas cobertas retornam resultados diretamente de um índice, sem precisar acessar os documentos de origem e, portanto, são muito eficientes.

Para que uma consulta seja coberta todos os campos necessários para filtrar, ordenar e/ou retornar ao cliente devem estar presentes em um índice. Para determinar se uma consulta é coberta, use o método explain(). Se a saída de explain() exibir totalDocsExamined como 0, isso mostra que a consulta é coberta por um índice. Leia mais na documentação para explicar os resultados.

Um problema comum ao tentar obter consultas cobertas é que o campo ID é sempre retornado por padrão. Você precisa excluí-lo explicitamente dos resultados da consulta ou adicioná-lo ao índice.

Em clusters fragmentados, o MongoDB precisa acessar internamente os campos da chave do fragmento. Isso significa que as consultas cobertas só são possíveis quando a chave de fragmento faz parte do índice. Geralmente é uma boa ideia fazer isso de qualquer maneira.

Tenha cuidado ao considerar índices em campos de baixa cardinalidade

Consultas em campos com um pequeno número de valores exclusivos (baixa cardinalidade) podem retornar grandes conjuntos de resultados. Os índices compostos podem incluir campos com baixa cardinalidade, mas o valor dos campos combinados deve apresentar alta cardinalidade.

Elimine índices desnecessários

Os índices consomem muitos recursos: mesmo com compactação no mecanismo de armazenamento MongoDB WiredTiger, eles consomem RAM e disco. À medida que os campos são atualizados, os índices associados devem ser mantidos, incorrendo em sobrecarga adicional de CPU e E/S de disco.

O MongoDB fornece ferramentas para ajudá-lo a entender o uso do índice, que abordaremos mais adiante nesta postagem.

Os índices curinga não substituem o planejamento de índices baseado em carga de trabalho

Para cargas de trabalho com muitos padrões de consulta ad hoc ou que lidam com estruturas de documentos altamente polimórficas, os índices curinga oferecem muita flexibilidade extra. Você pode definir um filtro que indexe automaticamente todos os campos, subdocumentos e matrizes correspondentes em uma collection.

Como acontece com qualquer índice, eles também precisam ser armazenados e mantidos, portanto, adicionarão sobrecarga ao banco de dados. Se os padrões de consulta do seu aplicativo forem conhecidos antecipadamente, você deverá usar índices mais seletivos nos campos específicos acessados pelas consultas.

Use a pesquisa de texto para combinar palavras dentro de um campo

Os índices regulares são úteis para combinar o valor inteiro de um campo. Se você deseja corresponder apenas uma palavra específica em um campo com muito texto, use um índice de texto.

Se você estiver executando o MongoDB no serviço Atlas, considere usar o Atlas Full Text Search, que fornece um índice Lucene totalmentemanaged e integrado ao banco de dados MongoDB. O FTS oferece maior desempenho e maior flexibilidade para filtrar, classificar e classificar seu banco de dados para exibir rapidamente os resultados mais relevantes para seus usuários.

Use índices parciais

Reduza o tamanho e a sobrecarga de desempenho dos índices incluindo apenas os documentos que serão acessados por meio do índice. Por exemplo, crie um índice parcial no campo orderID que inclua apenas documentos de pedido com um orderStatus de "Em andamento" ou indexe apenas o campo emailAddress para documentos onde ele existir.

Aproveite as vantagens dos índices multichave para consultar matrizes

Se seus padrões de consulta exigirem acesso a elementos individuais da matriz, use um índice multichave. O MongoDB cria uma chave de índice para cada elemento do array e pode ser construído sobre arrays que contêm valores escalares e documentos aninhados.

Evite expressões regulares que não estejam ancoradas ou enraizadas

Os índices são ordenados por valor. Os curingas iniciais são ineficientes e podem resultar em varreduras completas do índice. Os curingas finais podem ser eficientes se houver caracteres iniciais que diferenciam maiúsculas de minúsculas suficientes na expressão.

Evite expressões regulares que não diferenciam maiúsculas de minúsculas

Se o único motivo para usar um regex for a insensibilidade a maiúsculas e minúsculas, use um índice que não diferencia maiúsculas de minúsculas, pois eles são mais rápidos.

Use otimizações de índice disponíveis no mecanismo de armazenamento WiredTiger

Se você estiver autogerenciando o MongoDB, poderá opcionalmente colocar índices em seu próprio volume separado, permitindo paginação de disco mais rápida e menor contenção. Consulte as opções WiredTiger para obter mais informações.

Use o Plano Explicar

Abordamos o uso do plano de explicação do MongoDB na postagem anterior sobre padrões de consulta e criação de perfil, e esta é a melhor ferramenta para verificar a cobertura do índice para consultas individuais.

Trabalhando a partir do plano de explicação, o MongoDB fornece ferramentas de visualização para ajudar a melhorar ainda mais a compreensão de seus índices e fornece recomendações inteligentes e automáticas sobre quais índices adicionar.

Visualize a cobertura do índice com MongoDB Compass e Atlas Data Explorer

Como a GUI gratuita do MongoDB Compass oferece muitos recursos para ajudá-lo a otimizar o desempenho da consulta, incluindo a exploração do seu esquema e a visualização dos planos de explicação da consulta – duas áreas abordadas anteriormente nesta série.

A guia de índices do Compass adiciona outra ferramenta ao seu arsenal. Ele lista os índices existentes para uma collection, informando o nome e as chaves do índice, juntamente com seu tipo, tamanho e quaisquer propriedades especiais. Através da guia de índice você também pode adicionar e eliminar índices conforme necessário.

Um recurso realmente útil é o uso do índice, que mostra com que frequência um índice foi usado. Ter muitos índices pode ser quase tão prejudicial ao seu desempenho quanto ter poucos, tornando esse recurso especialmente valioso para ajudá-lo a identificar e remover índices que não estão sendo usados. Isso ajuda a liberar espaço no conjunto de trabalho e elimina a sobrecarga do banco de dados resultante da manutenção do índice.

Se você estiver executando o MongoDB em nosso serviço Atlas totalmentemanaged , a visualização dos índices no Data Explorer lhe dará a mesma funcionalidade do Compass, sem que você precise se conectar ao seu banco de dados com uma ferramenta separada.

Você também pode recuperar estatísticas de índice usando o estágio aggregation pipeline $indexStats.

Recomendações de índice automatizado

Mesmo com toda a telemetria fornecida pelas ferramentas do MongoDB, você ainda é responsável por extrair e analisar os dados necessários para tomar decisões sobre quais índices adicionar.

O limite para consultas lentas varia com base no tempo médio de operações no seu cluster para fornecer recomendações pertinentes à sua carga de trabalho.

Os índices recomendados são acompanhados por consultas de amostra, agrupadas por formato de consulta (ou seja, consultas com estrutura de predicado, classificação e projeção semelhantes), que foram executadas em uma collection que se beneficiaria com a adição de um índice sugerido. O Performance Advisor não afeta negativamente o desempenho do seu Atlas cluster.

Se você estiver satisfeito com a recomendação, poderá implementar os novos índices automaticamente, sem incorrer em tempo de inatividade do aplicativo.

Qual é o próximo

Isso encerra esta última edição da série de práticas recomendadas de desempenho. A MongoDB University oferece um curso de treinamento gratuito baseado na Web sobre o desempenho do MongoDB. Esta é uma ótima maneira de aprender mais sobre o poder da indexação.

← Previous

Mejores prácticas de rendimiento: indexación

Bienvenido al tercero de nuestra serie de publicaciones de blog que cubren las mejores prácticas de rendimiento para MongoDB. En esta serie, cubrimos consideraciones clave para lograr un rendimiento a escala en una serie de dimensiones importantes, que incluyen: Modelado de datos y dimensionamiento de la memoria (el conjunto de trabajo) Patrones de consulta y creación de perfiles . Indexación, que cubriremos hoy Fragmentación Transacciones y preocupaciones de lectura/escritor Configuración de hardware y sistema operativo Calentamiento de banca Habiendo trabajado ambos para un par de proveedores de bases de datos diferentes durante los últimos 15 años, podemos decir con seguridad que no definir los índices apropiados es el problema de rendimiento número uno que los equipos de soporte técnico deben abordar con los usuarios. Así que tenemos que hacerlo bien... aquí están las mejores prácticas para ayudarle. Índices en MongoDB En cualquier base de datos, los índices apoyan la ejecución eficiente de consultas. Sin ellos, la base de datos debe escanear cada documento de una colección o tabla para seleccionar aquellos que coincidan con la declaración de la consulta. Si existe un índice apropiado para una consulta, la base de datos puede utilizar el índice para limitar la cantidad de documentos que debe inspeccionar. MongoDB ofrece una amplia gama de tipos de índices y funciones con criterios de clasificación específicos del idioma para admitir patrones de acceso complejos a sus datos. Los índices de MongoDB se pueden crear y eliminar según demanda para adaptarse a los requisitos de aplicación y patrones de consulta en evolución, y se pueden declarar en cualquier campo dentro de sus documentos, incluidos los campos anidados dentro de matrices. Entonces, veamos cómo aprovechar al máximo los índices en MongoDB. Utilice índices compuestos Los índices compuestos son índices compuestos por varios campos diferentes. Por ejemplo, en lugar de tener un índice en "Apellido" y otro en "Nombre", normalmente es más eficaz crear un índice que incluya tanto "Apellido" como "Nombre" si consulta ambos nombres. . Nuestro índice compuesto aún se puede utilizar para filtrar consultas que especifican solo el apellido. Siga la regla ESR Para índices compuestos, esta regla general resulta útil para decidir el orden de los campos en el índice: Primero, agregue los campos en los que se ejecutan las consultas de igualdad. Los siguientes campos a indexar deben reflejar el orden de clasificación de la consulta. Los últimos campos representan el rango de datos a los que se accederá. Utilice consultas cubiertas cuando sea posible Las consultas cubiertas devuelven resultados de un índice directamente sin tener que acceder a los documentos fuente y, por lo tanto, son muy eficientes. Para que se cubra una consulta, todos los campos necesarios para filtrar, ordenar y/o devolver al cliente deben estar presentes en un índice. Para determinar si una consulta es una consulta cubierta, utilice el método explain() . Si la salida de explain() muestra totalDocsExamined como 0, esto muestra que la consulta está cubierta por un índice. Lea más en la documentación para explicar los resultados . Un problema común al intentar lograr consultas cubiertas es que el campo _id siempre se devuelve de forma predeterminada. Debe excluirlo explícitamente de los resultados de la consulta o agregarlo al índice. En los clústeres fragmentados, MongoDB necesita acceder internamente a los campos de la clave del fragmento. Esto significa que las consultas cubiertas solo son posibles cuando la clave de fragmento es parte del índice. Generalmente es una buena idea hacer esto de todos modos. Tenga precaución al considerar índices en campos de baja cardinalidad Las consultas sobre campos con una pequeña cantidad de valores únicos (baja cardinalidad) pueden devolver grandes conjuntos de resultados. Los índices compuestos pueden incluir campos con baja cardinalidad, pero el valor de los campos combinados debe exhibir una alta cardinalidad. Eliminar índices innecesarios Los índices consumen muchos recursos: incluso con compresión en el motor de almacenamiento MongoDB WiredTiger, consumen RAM y disco. A medida que se actualizan los campos, se deben mantener los índices asociados, lo que genera una sobrecarga adicional de CPU y E/S de disco. MongoDB proporciona herramientas para ayudarle a comprender el uso del índice, que cubriremos más adelante en esta publicación. Los índices comodín no reemplazan la planificación de índices basada en cargas de trabajo Para cargas de trabajo con muchos patrones de consulta ad hoc o que manejan estructuras de documentos altamente polimórficas, los índices comodín le brindan mucha flexibilidad adicional. Puede definir un filtro que indexe automáticamente todos los campos, subdocumentos y matrices coincidentes en una colección. Como ocurre con cualquier índice, también deben almacenarse y mantenerse, por lo que agregarán gastos generales a la base de datos. Si los patrones de consulta de su aplicación se conocen de antemano, entonces debe utilizar índices más selectivos en los campos específicos a los que acceden las consultas. Utilice la búsqueda de texto para hacer coincidir palabras dentro de un campo Los índices regulares son útiles para hacer coincidir el valor completo de un campo. Si solo desea hacer coincidir una palabra específica en un campo con mucho texto, utilice un índice de texto . Si está ejecutando MongoDB en el servicio Atlas, considere utilizar Atlas Full Text Search , que proporciona un índice de Lucene totalmente administrado e integrado con la base de datos MongoDB. FTS proporciona mayor rendimiento y mayor flexibilidad para filtrar, clasificar y clasificar su base de datos para mostrar rápidamente los resultados más relevantes a sus usuarios. Usar índices parciales Reduzca el tamaño y la sobrecarga de rendimiento de los índices incluyendo únicamente los documentos a los que se accederá a través del índice. Por ejemplo, cree un índice parcial en el campo ID de pedido que solo incluya documentos de pedido con un estado de pedido de "En curso" o solo indexe el campo dirección de correo electrónico para los documentos donde exista. Aproveche los índices de claves múltiples para consultar matrices Si sus patrones de consulta requieren acceder a elementos de matriz individuales, utilice un índice de claves múltiples . MongoDB crea una clave de índice para cada elemento de la matriz y se puede construir sobre matrices que contienen valores escalares y documentos anidados. Evite expresiones regulares que no queden ancladas ni enraizadas Los índices están ordenados por valor. Los comodines iniciales son ineficaces y pueden dar lugar a exploraciones de índice completo. Los comodines finales pueden ser eficaces si hay suficientes caracteres iniciales que distinguen entre mayúsculas y minúsculas en la expresión. Evite las expresiones regulares que no distinguen entre mayúsculas y minúsculas Si la única razón para usar una expresión regular es que no distingue entre mayúsculas y minúsculas, use un índice que no distinga entre mayúsculas y minúsculas , ya que son más rápidos. Utilice las optimizaciones de índice disponibles en el motor de almacenamiento WiredTiger Si administra MongoDB usted mismo, puede opcionalmente colocar índices en su propio volumen separado, lo que permite una paginación del disco más rápida y una menor contención. Consulte las opciones de WiredTiger para obtener más información. Utilice el plan explicativo Cubrimos el uso del plan de explicación de MongoDB en la publicación anterior sobre patrones de consulta y creación de perfiles, y esta es la mejor herramienta para verificar la cobertura del índice para consultas individuales. Trabajando desde el plan de explicación, MongoDB proporciona herramientas de visualización para ayudar a mejorar aún más la comprensión de sus índices y proporciona recomendaciones inteligentes y automáticas sobre qué índices agregar. Visualice la cobertura del índice con MongoDB Compass y Atlas Data Explorer Como GUI gratuita para MongoDB, Compass proporciona muchas funciones para ayudarle a optimizar el rendimiento de las consultas, incluida la exploración de su esquema y la visualización de planes de explicación de consultas, dos áreas tratadas anteriormente en esta serie. La pestaña de índices en Compass agrega otra herramienta a tu arsenal. Enumera los índices existentes para una colección, informando el nombre y las claves del índice, junto con su tipo, tamaño y cualquier propiedad especial. A través de la pestaña de índice también puede agregar y eliminar índices según sea necesario. Una característica realmente útil es el uso del índice, que muestra con qué frecuencia se ha utilizado un índice. Tener demasiados índices puede ser casi tan perjudicial para el rendimiento como tener muy pocos, por lo que esta característica es especialmente valiosa para ayudarle a identificar y eliminar índices que no se están utilizando. Esto le ayuda a liberar espacio en el conjunto de trabajo y elimina la sobrecarga de la base de datos que se produce al mantener el índice. Si está ejecutando MongoDB en nuestro servicio Atlas totalmente administrado, la vista de índices en el Explorador de datos le brindará la misma funcionalidad que Compass, sin que tenga que conectarse a su base de datos con una herramienta separada. También puede recuperar estadísticas de índice utilizando la etapa de canalización de agregación $indexStats. Recomendaciones de índices automatizados Incluso con toda la telemetría proporcionada por las herramientas de MongoDB, usted sigue siendo responsable de extraer y analizar los datos necesarios para tomar decisiones sobre qué índices agregar. El umbral para consultas lentas varía según el tiempo promedio de operaciones en su clúster para brindar recomendaciones pertinentes a su carga de trabajo. Los índices recomendados van acompañados de consultas de muestra, agrupadas por forma de consulta (es decir, consultas con una estructura de predicados, clasificación y proyección similares), que se ejecutaron en una colección que se beneficiaría de la adición de un índice sugerido. El Performance Advisor no afecta negativamente el rendimiento de sus clústeres Atlas. Si está satisfecho con la recomendación, puede implementar los nuevos índices automáticamente, sin incurrir en ningún tiempo de inactividad de la aplicación. Que sigue Con esto concluye esta última entrega de la serie de mejores prácticas de rendimiento. La Universidad MongoDB ofrece un curso de capacitación gratuito basado en la web sobre el rendimiento de MongoDB . Esta es una excelente manera de aprender más sobre el poder de la indexación.

October 2, 2023

Next →

Staff Engineering at MongoDB: Your Path to Making Broad Impact

Andrew Whitaker is a Senior Staff Engineer at MongoDB. His previous experience spans tiny startups to enormous organizations like AWS, where he held several different roles focusing on databases. Before joining MongoDB, he worked at a startup building optimized machine learning models in the cloud. Read on to learn more about why Andrew decided to join MongoDB in a senior-level engineering role and how his work is driving improvement within our engineering organization. Why MongoDB I have long been a fan of MongoDB’s products and services. MongoDB the database has always been a pleasure to work with – the system “brings joy” to quote a phrase. As a Python developer, I appreciate how the Python driver feels “Pythonic” in a completely natural way. The programmer interacts with the database using Python constructs: dictionaries, lists, and primitive types. By contrast, SQL databases force me to change my mental model, and the query language feels like an add-on that does not blend with the core language. As an engineer, I am always looking to expand my knowledge and grow my skills. The scope of challenges engineers face at MongoDB is what triggered my interest in the company. We obviously have people working on core databases and distributed systems. But, we also have teams dedicated to machine learning, streaming data, analytics, networking, developer tooling, drivers, and many more areas. It is very hard to get bored working at MongoDB. Finally, I would be remiss if I did not mention the people. Overall, MongoDB’s engineering culture prioritizes intelligence, low ego, and an ability to get stuff done. CL/CI (Continuous Learning, Continuous Improvement) Working at MongoDB has provided me with opportunities for continued learning and growth. Though I do not program as much as I did earlier in my career, I have recently been exploring the Rust language. I’m excited by Rust because it avoids the tradeoffs between predictable performance and safety. My work in the search space has given me exposure to the fast moving world of AI: vector embeddings, RAG, etc. For various reasons, I think MongoDB is uniquely positioned to do well in this area. On top of this, I’m working on some initiatives that are not fully public. I can say that one focus area is improving the sharding experience for our customers. We believe MongoDB sharding is best-in-breed. Still, the process requires more manual configuration than we think is ideal: customers select the shard key, cluster type, shard count, etc. We give guidance here, but I think we can raise the bar in terms of offering a seamless experience with less “futz”. I’m also working with the search team. We believe there is a natural affinity between MongoDB’s document model and AI/ML workloads. We have some features in the works that extend this integration in new and interesting ways. I also spend a fair bit of time driving quality improvements across our suite of products. Our CTO Jim Scharf frequently refers to our “ big 4 ” goals: security, durability, availability, and performance. These goals are more important than any feature we build. I’ve been working across the company to help teams define their availability SLO/SLAs. It turns out that measuring availability is a subtle topic. For example, a naive approach of counting the percentage of failed requests can underestimate downtime because customers make fewer requests when a service is unavailable. So, the first step is to clarify the definition of availability. Finally, as a lapsed academic (in a distant life, I was a graduate student at the University of Washington Department of Computer Science and Engineering), I’m always interested in finding ways to bridge theory and practice. I’ve been collaborating with some folks in our research team to drive improvements to our replication protocols. There are theoretical results that suggest it is impossible to simultaneously achieve low latency and strong consistency (“linearizability” in the technical jargon). However, we believe there are intermediate points in the consistency/latency spectrum that have not been fully explored. This work hasn't been made into a product yet, but stay tuned. Flexible working MongoDB is a hybrid company. Like many of our engineers, I work outside the company headquarters in New York City (I live in Seattle). I appreciate MongoDB’s approach to hybrid working and that company leadership, starting with Dev , cares about the well-being of their employees. It seems there are companies that don’t seem to trust their employees to make decisions, such as which days to come into the office, so I’m thankful for the autonomy I receive at MongoDB to work in a way that’s best for me. Remote work has its challenges, but I would say that the benefit for my work/life balance has been transformative. Final thoughts I have found MongoDB engineers demonstrate a strong mix of technical depth, pragmatism, and empathy. I have yet to find the “smart jerk” prototype that seems to exist throughout the tech industry. Overall, I have found MongoDB is open to change and growth at both the team level and the individual level. There is a willingness to evolve and improve that aligns with the company’s values and leadership principles and enables the success of our technology and people. Find out more about MongoDB culture and career opportunities by joining our talent community .

November 20, 2024