Perguntas frequentes

Por que estou tendo problemas para me conectar a uma instância do MongoDB?

Se você tiver problemas para se conectar a um sistema do MongoDB, consulte o Guia de Solução de Problemas de Conexão para obter possíveis soluções.

Em que o driver Kotlin é diferente do KMongo?

O driver Kotlin é o driver oficial do MongoDB para o Kotlin. Ele é desenvolvido pela equipe do MongoDB e fornece uma API nativa para que aplicativos Kotlin se conectem ao MongoDB e trabalhem com dados. Ele é implementado envolvendo o driver Java do MongoDB.

KMongo é uma biblioteca popular desenvolvida na comunidade para trabalhar com o MongoDB a partir de aplicativos Kotlin. É um invólucro em torno do driver Java que foi criado antes da criação do driver oficial do Kotlin para atender às necessidades da comunidade Kotlin.

O driver do Kotlin foi desenvolvido em colaboração com o criador do KMongo, Giulien Buret, para oferecer aos usuários um driver com suporte oficial.

O driver oficial do Kotlin e o KMongo têm API geralmente semelhantes. Semelhanças notáveis entre o driver Kotlin e o KMongo incluem:

• Suporte para operações síncronas e baseadas em corrotina

• Suporte usando classes de dados para representar documentos MongoDB

• Suporte para serialização do KotlinX

• Suporte para API CRUD do MongoDB e API de agregação

Embora o driver oficial do Kotlin e o KMongo sejam semelhantes, existem algumas diferenças principais:

• O driver oficial não tem suporte integrado para reator, rxjava2, jackson , ou GSON.

• O driver oficial não suporta comandos de shell do MongoDB.

Para obter informações mais detalhadas, consulte Migre a partir do KMongo.

Como funciona o pool de conexões no Kotlin Driver?

Cada instância MongoClient tem um pool de conexões integrado para cada servidor em sua topologia do MongoDB. Os pools de conexões abrem soquetes sob demanda para oferecer suporte às operações simultâneas do MongoDB em seu aplicativo de threads múltiplas.

O tamanho máximo de cada conjunto de conexões é definido pela opção maxPoolSize, que padroniza para 100. Se o número de conexões em uso com um servidor atingir o valor de maxPoolSize, a próxima solicitação para esse servidor aguardará até que uma conexão fique disponível.

Cada instância MongoClient abre dois soquetes adicionais por servidor em sua topologia MongoDB para monitorar o estado do servidor.

Por exemplo, um cliente conectado a um conjunto de réplicas de 3 nós abre 6 soquetes de monitoramento. Ele também abre quantos soquetes forem necessários para oferecer suporte aos threads de um aplicativo em cada servidor, até o valor de maxPoolSize. Se maxPoolSize for 100 e o aplicativo usar apenas o primário (o padrão), somente o pool de conexões primárias crescerá e poderá haver no máximo 106 conexões totais. Se a aplicação usar uma preferência de leitura para consultar os nós secundários, seus pools também crescerão e poderá haver um total 306 conexões.

Além disso, os pools de conexões têm taxa limitada de modo que cada pool de conexões só pode criar, no máximo, o valor de maxConnecting conexões em paralelo a qualquer momento. Qualquer thread adicional para de esperar nos seguintes casos:

• Um dos threads existentes termina de criar uma conexão, ou uma conexão existente é verificada novamente no pool.

• A capacidade do driver de reutilizar conexões existentes melhora devido aos limites de taxa na criação de conexões.

Você pode configurar o número mínimo de conexões simultâneas para cada servidor com a opção minPoolSize , que padroniza para 0. O pool de conexões será inicializado com este número de tomadas. Se os soquetes forem fechados devido a qualquer erro de rede, fazendo com que o número total de soquetes (em uso e ociosos) caia abaixo do mínimo, mais soquetes serão abertos até que o mínimo seja atingido.

Você pode definir o número máximo de milésimos de segundo que uma conexão pode permanecer ociosa no grupo antes de ser removida e substituída pela opção maxIdleTimeMS , que padroniza para 0 (sem limite).

A seguinte configuração padrão para um MongoClient funciona para a maioria dos aplicativos:

val client = MongoClient("<connection string>")

Crie um cliente uma vez para cada processo e reutilize-o para todas as operações. É um erro comum criar um novo cliente para cada solicitação, o que é muito ineficiente.

Para oferecer suporte a um grande número de operações simultâneas do MongoDB em um processo, você pode aumentar o maxPoolSize. Quando o pool atinge seu tamanho máximo, threads adicionais aguardam a disponibilidade de soquetes.

O driver não limita o número de threads que podem aguardar a disponibilidade de soquetes, e é responsabilidade do aplicativo limitar o tamanho de seu pool para limitar o enfileiramento durante um pico de carga. Os threads aguardam a quantidade de tempo especificada na opção waitQueueTimeoutMS , que padroniza para 120000 (120 segundos).

Um thread que aguarda mais do que o período de tempo definido por waitQueueTimeoutMS para um soquete gera um erro de conexão. Use essa opção se for mais importante limitar a duração das operações durante um pico de carga do que concluir cada operação.

Quando MongoClient.close() é chamado por qualquer thread, o driver fecha todos os soquetes ociosos e fecha todos os soquetes que estão em uso à medida que são retornados ao pool.

Para saber mais sobre como se conectar ao MongoDB, consulte o Guia de Conexão.