Configuração
Nesta página
- Gerando configuração padrão
- Carregando configuração do Mongoid
- Opções de configuração do Mongoid
- Padrões baseados em versão
- Pré-processamento de ERb
- Exploração madeireira
- Aplicação Ruby on Rails
- Autônomo
- Fuso horário
- Definindo fuso horário em dados carregados do MongoDB
- Configurando
SSLContext
- Compactação de rede
- Criptografia do lado do cliente
- Uso com servidores forking
- Puma
- Unicórnio
- Passageiro(a)
- Middleware de cache de query
- Ativando o cache de query para solicitações da web do Rack
- Habilitando cache de query para ActiveJob
- Configuração de desenvolvimento
O Mongoid é normalmente configurado por meio de um arquivo mongoid.yml
que especifica opções e clientes. A configuração mais simples é a seguinte, que configura o Mongoid para se comunicar com um servidor MongoDB em "localhost:27017" e usar o banco de dados denominado "mongoid".
development: clients: default: database: mongoid hosts: - localhost:27017
A chave de nível superior no arquivo de configuração, development
no exemplo acima, refere-se ao nome de ambiente que o aplicativo está executando, isto é, development
, test
ou production
. A chave de terceiro nível, default
no exemplo acima, refere-se ao nome do cliente Mongo. A maioria dos aplicativos utilizará um único cliente denominado default
.
Gerando configuração padrão
Se você estiver usando Ruby on Rails, você pode fazer com que o Mongoid gere um arquivo de configuração padrão para você executando o seguinte comando:
rails g mongoid:config
O arquivo de configuração será colocado no config/mongoid.yml
. Um inicializador também será criado e colocado em config/initializers/mongoid.rb
. É recomendado que toda a configuração seja especificada no config/mongoid.yml
, mas se você preferir, o inicializador do mongoid.rb
também pode ser utilizado para definir as opções de configuração. Observe, porém, que as configurações em mongoid.yml
sempre têm precedência sobre as configurações no inicializador.
Se você não estiver utilizando Ruby on Rails, você poderá copiar a configuração mínima fornecida acima e salvá-la como config/mongoid.yml
.
Carregando configuração do Mongoid
Se você estiver utilizando Ruby on Rails, a configuração Mongoid será carregada automaticamente para o ambiente atual como armazenado no Rails.env
quando o aplicativo carregar.
Talvez seja necessário configurar o ORM para que seu aplicativo seja Mongoid adicionando o seguinte a application.rb
:
config.generators do |g| g.orm :mongoid end
Se você não estiver usando Ruby on Rails, a configuração Mongoid deve ser carregada manualmente. Isto pode ser feito através do método Mongoid.load!
, que utiliza o caminho do arquivo de configuração como seu argumento, como segue:
# Use automatically detected environment name Mongoid.load!("path/to/your/mongoid.yml") # Specify environment name manually Mongoid.load!("path/to/your/mongoid.yml", :production)
Quando o Mongoid é solicitado a detectar automaticamente o nome do ambiente, ele o faz examinando as seguintes fontes, em ordem:
Se o
Rails
constante de nível superior for definido,Rails.env
.Se o
Sinatra
constante de nível superior for definido,Sinatra::Base.environment
.A variável de ambiente do
RACK_ENV
.A variável de ambiente do
MONGOID_ENV
.
Também é possível configurar o Mongoid diretamente no Ruby, sem usar um arquivo de configuração. Esse estilo de configuração não é compatível com o conceito de ambientes - independentemente da configuração fornecida, ele é aplicado ao ambiente atual - mas é compatível com a definição de vários clientes.
Mongoid.configure do |config| config.clients.default = { hosts: ['localhost:27017'], database: 'my_db', } config.log_level = :warn end
Observação
O Mongoid deve ser configurado antes que qualquer componente dele seja usado ou referenciado. Depois que um componente é usado ou referenciado, a alteração da configuração pode não aplicar alterações aos componentes já instanciados.
Opções de configuração do Mongoid
O exemplo anotado mongoid.yml
a seguir demonstra como o Mongoid pode ser configurado.
O Mongoid delega ao driver Ruby para configuração do cliente. Consultea documentação do driver para obter detalhes sobre as opções driver.
development: # Configure available database clients. (required) clients: # Defines the default client. (required) default: # Mongoid can connect to a URI accepted by the driver: # uri: mongodb://user:password@mongodb.domain.com:27017/my_db_development # Otherwise define the parameters separately. # This defines the name of the default database that Mongoid can connect to. # (required). database: my_db_development # Provides the hosts the default client can connect to. Must be an array # of host:port pairs. (required) hosts: - localhost:27017 options: # Note that all options listed below are Ruby driver client options (the mongo gem). # Please refer to the driver documentation of the version of the mongo gem you are using # for the most up-to-date list of options. # Change the default write concern. (default = { w: 1 }) # write: # w: 1 # Change the default read preference. Valid options for mode are: :secondary, # :secondary_preferred, :primary, :primary_preferred, :nearest # (default: primary) # read: # mode: :secondary_preferred # tag_sets: # - use: web # The name of the user for authentication. # user: 'user' # The password of the user for authentication. # password: 'password' # The user's database roles. # roles: # - 'dbOwner' # Change the default authentication mechanism. Valid options include: # :scram, :scram256, :mongodb_cr, :mongodb_x509, :gssapi, :aws, :plain. # MongoDB Server defaults to :scram, which will use "SCRAM-SHA-256" if available, # otherwise fallback to "SCRAM-SHA-1" (:scram256 will always use "SCRAM-SHA-256".) # This setting is handled by the MongoDB Ruby Driver. Please refer to: # https://mongodb.com/pt-br/docs/ruby-driver/current/reference/authentication/ # auth_mech: :scram # The database or source to authenticate the user against. # (default: the database specified above or admin) # auth_source: admin # Force a the driver cluster to behave in a certain manner instead of auto- # discovering. Can be one of: :direct, :replica_set, :sharded. Set to :direct # when connecting to hidden members of a replica set. # connect: :direct # Changes the default time in seconds the server monitors refresh their status # via hello commands. (default: 10) # heartbeat_frequency: 10 # The time in seconds for selecting servers for a near read preference. (default: 0.015) # local_threshold: 0.015 # The timeout in seconds for selecting a server for an operation. (default: 30) # server_selection_timeout: 30 # The maximum number of connections in the connection pool. (default: 5) # max_pool_size: 5 # The minimum number of connections in the connection pool. (default: 1) # min_pool_size: 1 # The time to wait, in seconds, in the connection pool for a connection # to be checked in before timing out. (default: 5) # wait_queue_timeout: 5 # The time to wait to establish a connection before timing out, in seconds. # (default: 10) # connect_timeout: 10 # How long to wait for a response for each operation sent to the # server. This timeout should be set to a value larger than the # processing time for the longest operation that will be executed # by the application. Note that this is a client-side timeout; # the server may continue executing an operation after the client # aborts it with the SocketTimeout exception. # (default: nil, meaning no timeout) # socket_timeout: 5 # The name of the replica set to connect to. Servers provided as seeds that do # not belong to this replica set will be ignored. # replica_set: name # Compressors to use for wire protocol compression. (default is to not use compression) # "zstd" requires zstd-ruby gem. "snappy" requires snappy gem. # Refer to: https://www.mongodb.com/pt-br/docs/ruby-driver/current/reference/create-client/#compression # compressors: ["zstd", "snappy", "zlib"] # Whether to connect to the servers via ssl. (default: false) # ssl: true # The certificate file used to identify the connection against MongoDB. # ssl_cert: /path/to/my.cert # The private keyfile used to identify the connection against MongoDB. # Note that even if the key is stored in the same file as the certificate, # both need to be explicitly specified. # ssl_key: /path/to/my.key # A passphrase for the private key. # ssl_key_pass_phrase: password # Whether to do peer certification validation. (default: true) # ssl_verify: true # The file containing concatenated certificate authority certificates # used to validate certs passed from the other end of the connection. # ssl_ca_cert: /path/to/ca.cert # Whether to truncate long log lines. (default: true) # truncate_logs: true # Configure Mongoid-specific options. (optional) options: # Allow BSON::Decimal128 to be parsed and returned directly in # field values. When BSON 5 is present and the this option is set to false # (the default), BSON::Decimal128 values in the database will be returned # as BigDecimal. # # @note this option only has effect when BSON 5+ is present. Otherwise, # the setting is ignored. # allow_bson5_decimal128: false # Application name that is printed to the MongoDB logs upon establishing # a connection. Note that the name cannot exceed 128 bytes in length. # It is also used as the database name if the database name is not # explicitly defined. (default: nil) # app_name: nil # When this flag is false, callbacks for embedded documents will not be # called. This is the default in 9.0. # # Setting this flag to true restores the pre-9.0 behavior, where callbacks # for embedded documents are called. This may lead to stack overflow errors # if there are more than cicrca 1000 embedded documents in the root # document's dependencies graph. # See https://jira.mongodb.org/browse/MONGOID-5658 for more details. # around_callbacks_for_embeds: false # Sets the async_query_executor for the application. By default the thread pool executor # is set to `:immediate`. Options are: # # - :immediate - Initializes a single +Concurrent::ImmediateExecutor+ # - :global_thread_pool - Initializes a single +Concurrent::ThreadPoolExecutor+ # that uses the +async_query_concurrency+ for the +max_threads+ value. # async_query_executor: :immediate # Mark belongs_to associations as required by default, so that saving a # model with a missing belongs_to association will trigger a validation # error. # belongs_to_required_by_default: true # Set the global discriminator key. # discriminator_key: "_type" # Raise an exception when a field is redefined. # duplicate_fields_exception: false # Defines how many asynchronous queries can be executed concurrently. # This option should be set only if `async_query_executor` is set # to `:global_thread_pool`. # global_executor_concurrency: nil # When this flag is true, any attempt to change the _id of a persisted # document will raise an exception (`Errors::ImmutableAttribute`). # This is the default in 9.0. Setting this flag to false restores the # pre-9.0 behavior, where changing the _id of a persisted # document might be ignored, or it might work, depending on the situation. # immutable_ids: true # Include the root model name in json serialization. # include_root_in_json: false # # Include the _type field in serialization. # include_type_for_serialization: false # Whether to join nested persistence contexts for atomic operations # to parent contexts by default. # join_contexts: false # When this flag is false (the default as of Mongoid 9.0), a document that # is created or loaded will remember the storage options that were active # when it was loaded, and will use those same options by default when # saving or reloading itself. # # When this flag is true you'll get pre-9.0 behavior, where a document will # not remember the storage options from when it was loaded/created, and # subsequent updates will need to explicitly set up those options each time. # # For example: # # record = Model.with(collection: 'other_collection') { Model.first } # # This will try to load the first document from 'other_collection' and # instantiate it as a Model instance. Pre-9.0, the record object would # not remember that it came from 'other_collection', and attempts to # update it or reload it would fail unless you first remembered to # explicitly specify the collection every time. # # As of Mongoid 9.0, the record will remember that it came from # 'other_collection', and updates and reloads will automatically default # to that collection, for that record object. # legacy_persistence_context_behavior: false # When this flag is false, a document will become read-only only once the # #readonly! method is called, and an error will be raised on attempting # to save or update such documents, instead of just on delete. When this # flag is true, a document is only read-only if it has been projected # using #only or #without, and read-only documents will not be # deletable/destroyable, but they will be savable/updatable. # When this feature flag is turned on, the read-only state will be reset on # reload, but when it is turned off, it won't be. # legacy_readonly: false # The log level. # # It must be set prior to referencing clients or Mongo.logger, # changes to this option are not be propagated to any clients and # loggers that already exist. # # Additionally, only when the clients are configured via the # configuration file is the log level given by this option honored. # log_level: :info # Store BigDecimals as Decimal128s instead of strings in the db. # map_big_decimal_to_decimal128: true # Preload all models in development, needed when models use inheritance. # preload_models: false # When this flag is true, callbacks for every embedded document will be # called only once, even if the embedded document is embedded in multiple # documents in the root document's dependencies graph. # This is the default in 9.0. Setting this flag to false restores the # pre-9.0 behavior, where callbacks are called for every occurrence of an # embedded document. The pre-9.0 behavior leads to a problem that for multi # level nested documents callbacks are called multiple times. # See https://jira.mongodb.org/browse/MONGOID-5542 # prevent_multiple_calls_of_embedded_callbacks: true # Raise an error when performing a #find and the document is not found. # raise_not_found_error: true # Raise an error when defining a scope with the same name as an # existing method. # scope_overwrite_exception: false # Return stored times as UTC. # use_utc: false # Configure Driver-specific options. (optional) driver_options: # When this flag is off, an aggregation done on a view will be executed over # the documents included in that view, instead of all documents in the # collection. When this flag is on, the view filter is ignored. # broken_view_aggregate: true # When this flag is set to false, the view options will be correctly # propagated to readable methods. # broken_view_options: true # When this flag is set to true, the update and replace methods will # validate the parameters and raise an error if they are invalid. # validate_update_replace: false
Padrões baseados em versão
O Mongoid suporta a definição das opções de configuração para os padrões de versões específicas. Isso é útil para atualizar para uma nova versão Mongoid. Ao atualizar sua versão Mongoid, o seguinte deve ser definido em Mongoid::Config
:
Mongoid.configure do |config| config.load_defaults <OLD VERSION> end
Dessa forma, ao atualizar para uma nova versão do Mongoid, seu código será executado com as opções de configuração da versão anterior do Mongoid. Então, um a um, você pode alterar os sinalizadores de recursos para a nova versão e testar se o seu código ainda funciona conforme o esperado. Uma vez que todos os novos sinalizadores de recursos tenham sido contabilizados, a chamada para load_defaults
pode ser alterada para incluir a nova versão, e todos os sinalizadores de recursos alterados podem ser removidos.
Por exemplo, suponha que estejamos atualizando de 7.5 para 8.0. Entre essas duas versões, duas sinalizações de recurso foram adicionadas: legacy_attributes
e map_big_decimal_to_decimal128
. Antes de atualizar para o Mongoid 8, adicione o seguinte ao seu Mongoid::Config
:
Mongoid.configure do |config| config.load_defaults 7.5 end
Após atualizar para Mongoid 8.0 em seu Gemfile
, quaisquer sinalizadores de feição permanecerão definidos para seu 7.5 comportamento padrão: legacy_attributes: true,
map_big_decimal_to_decimal128: false
. Você pode então inverter esses sinalizadores de recursos um por um para o 8.0 comportamento:
Mongoid.configure do |config| config.load_defaults 7.5 config.legacy_attributes = false # config.map_big_decimal_to_decimal128 = true end
Recomendamos fazer isso um de cada vez, então, no exemplo acima, deixamos a segunda bandeira comentada. Depois de verificar se seu código funciona conforme o esperado com o sinalizador legacy_attributes
desativado, a configuração map_big_decimal_to_decimal128
pode ser descomentada. Depois que essa funcionalidade também for verificada, ambas as linhas podem ser removidas e o load_defaults
substituído por:
Mongoid.configure do |config| config.load_defaults 8.0 end
Pré-processamento de ERb
Ao carregar um arquivo de configuração, o Mongoid processa com ERb antes de analisá-lo como YAML. Isso permite, por exemplo, construir o conteúdo do arquivo de configuração no runtime baseado em variáveis de ambiente:
development: clients: default: uri: "<%= ENV['MONGODB_URI'] %>"
Observação
Ao emitir valores de ERb, verifique se os valores são YAML válidos e escape-os conforme necessário.
Observação
Como a renderização de ERb é executada antes da análise de YAML, todas as diretivas ERb no arquivo de configuração são avaliadas, incluindo aquelas que ocorrem nos comentários de YAML.
Exploração madeireira
Ao configurar o registro, é importante ter em mente que o Mongoid fornece uma camada de modelo sobre o driver Ruby do MongoDB, e o driver despacha as operações CRUD para o sistema do MongoDB. Portanto, parte da saída de registro em um aplicativo usando o Mongoid vem do próprio Mongoid e parte vem do driver.
O cliente Mongo é uma instância do cliente do driver Ruby, portanto, o registrador de um cliente Mongo é o registrador do driver Ruby, não o registrador do Mongoid. Em outras palavras:
# Ruby driver logger, not Mongoid logger Mongoid.client(:default).logger
Dependendo se o Mongoid é usado em um aplicativo Ruby on Rails e como o driver Mongoid e Ruby são configurados, eles podem usar a mesma instância do registrador ou instâncias diferentes, potencialmente com configurações diferentes.
Aplicação Ruby on Rails
Quando usado em um aplicativo Ruby on Rails, o Mongoid, por padrão, herda o registrador e o nível de registro do Rails e define o registrador do driver para a mesma instância de registrador:
Rails.logger === Mongoid.logger # => true Mongoid.logger === Mongo::Logger.logger # => true
Para alterar o nível do registro, use a configuração padrão do Rails. Coloque o seguinte em um dos arquivos de configuração do ambiente, como config/environments/production.rb
:
Rails.application.configure do config.log_level = :debug end
Observação
A opção de configuração log_level
do Mongoid não é usada quando o Mongoid opera em um aplicativo Rails, pois o Mongoid herda o nível de registro do Rails nesse caso.
Para configurar o Mongoid ou o registrador de driver de forma diferente do registrador do Rails, use um inicializador da seguinte maneira:
Rails.application.configure do config.after_initialize do # Change Mongoid log destination and/or level Mongoid.logger = Logger.new(STDERR).tap do |logger| logger.level = Logger::DEBUG end # Change driver log destination and/or level Mongo::Logger.logger = Logger.new(STDERR).tap do |logger| logger.level = Logger::DEBUG end end end
Observação
Atualmente, não há provisão na biblioteca padrão Ruby Logger
para retornar o dispositivo de registro (ou seja, o objeto IO
) que um registrador está usando. Ter, por exemplo, o Mongoid e/ou o driver Ruby logando no arquivo de registro padrão do Rails (por exemplo. log/development.log
), mas com um nível diferente do registrador Rails padrão (Rails.logger
), o arquivo deve ser aberto separadamente e o objeto IO
resultante deve ser passado para o construtor Logger
.
Observação
Como por padrão, o Mongoid define seu próprio registrador e o registrador do driver para a mesma instância que o registrador do Rails, modificar qualquer uma das instâncias afeta todas elas. Por exemplo, o nível de registro de alterações a seguir para todos os três registradores, a menos que o aplicativo tenha atribuído uma instância Logger
separada a Mongo::Logger.logger
conforme descrito acima:
Mongoid::Logger.logger.level = Logger::DEBUG
Autônomo
When not loaded in a Ruby on Rails application, Mongoid respects the log_level
top level configuration option. Ele pode ser fornecido no arquivo de configuração da seguinte maneira:
development: clients: default: # ... options: log_level: :debug
... ou ao configurar a linha Mongoid:
Mongoid.configure do |config| config.log_level = :debug end
O destino de registro padrão no Mongoid 7.1 e superior é de erro padrão. O destino de registro padrão no Mongoid 7.0 e inferior é de saída padrão. Para alterar o destino do registro, crie uma nova instância de registrador da seguinte maneira:
Mongoid.logger = Logger.new(STDERR).tap do |logger| logger.level = Logger::DEBUG end
Para alterar o nível de registo do driver ou destino Ruby:
Mongo::Logger.logger = Logger.new(STDERR).tap do |logger| logger.level = Logger::DEBUG end
Para definir o registrador do driver para ser igual ao registrador Mongoid:
Mongo::Logger.logger = Mongoid.logger
Observação
O Mongoid não altera o registrador do driver quando executado no modo standalone.
Fuso horário
O Mongoid usa a funcionalidade de fuso horário do ActiveSupport, que é muito mais robusta do que a biblioteca padrão do Ruby. É importante ressaltar que o ActiveSupport permite a configuração do Time.zone
, uma variável global de thread que fornece contexto para trabalhar com valores de data e hora.
Embora um tratamento completo dos fusos horários em Ruby esteja fora do escopo deste tutorial, a maneira mais fácil e confiável de obter o tratamento correto do fuso horário é a seguinte:
Configure o fuso horário do sistema operacional para UTC. Por exemplo, no Linux:
cp /usr/share/zoneinfo/UTC /etc/localtime
Defina o fuso zona padrão do seu aplicação para UTC:
# If using Rails, in application.rb: class Application < Rails::Application config.time_zone = 'UTC' end # If not using Rails: Time.zone = 'UTC'
Em cada controlador e classe de trabalho, defina o fuso horário apropriado em um
before_filter
o mais cedo possível. Como exemplo, se cada usuário do seu aplicativo puder definir seu próprio fuso horário, você pode fazer:
class ApplicationController < ActionController::Base before_filter :fetch_user, :set_time_zone def set_time_zone Time.zone = @user.time_zone end end
A partir daqui, você pode trabalhar com horários naturalmente no fuso horário local. Por exemplo, em uma visualização:
Turned into a pumpkin after <%= cinderella.updated_at.seconds_after_midnight %> seconds!
Use métodos ActiveSupport em vez da biblioteca padrão Ruby.
Time.zone.now
ouTime.current` instead of ``Time.now
Date.current
em vez deDate.today
Observe que os últimos métodos da biblioteca padrão Ruby fazem referência ao fuso zona do seu sistema (por exemplo UTC) e não o valor de
Time.zone
. Como é muito fácil confundir esses métodos com nomes semelhantes, recomendamos usar o cop Rails/TimeZone do Rubocop em seu CI.
Definindo fuso horário em dados carregados do MongoDB
O MongoDB armazena todos os horários em UTC sem informações de fuso zona . Os modelos Mongoid carregam e retorna valores de tempo como instâncias de ActiveSupport::TimeWithZone
. Você pode definir a opção use_utc
para controlar como o Mongoid define o fuso zona ao carregar do banco de banco de dados:
Se falso (padrão), o Mongoid utilizará
Time.zone
para definir o fuso horário dos valores de hora que são carregados do banco de dados.Se verdadeiro, o Mongoid sempre definirá o fuso horário como UTC nos valores de hora carregados.
use_utc
afeta apenas como os dados são carregados e não afeta como os dados são persistidos. Por exemplo, se você atribuir uma instância Time
ou ActiveSupport::TimeWithZone
a um campo de tempo, as informações de fuso horário da instância atribuída sempre serão utilizadas independentemente da configuração do use_utc
. Como alternativa, se você atribuir um valor de string a um campo de tempo, qualquer informação de fuso horário na string será usada se estiver presente. Se a string não incluir informações de fuso horário, ela será analisada de acordo com Time.zone
. Para ilustrar:
Time.use_zone("Asia/Kolkata") do # String does not include time zone, so "Asia/Kolkata" will be used ghandi.born_at = "1869-10-02 7:10 PM" # Time zone in string (-0600) will be used amelia.born_at = "1897-07-24 11:30 -0600" end
Configurando SSLContext
Pode ser desejável configurar ainda mais as opções de TLS em seu aplicativo, por exemplo, ativando ou desativando determinadas cifras.
Isso pode ser feito definindo ganchos de contexto TLS no driver Ruby -- os ganchos de contexto TLS são Proc
fornecidos pelo usuário que serão invocados antes de qualquer conexão de soquete TLS no driver e podem ser usados para modificar o OpenSSL::SSL::SSLContext
subjacente usado pelo soquete.
Para definir hooks de contexto TLS, adicione Proc
(s) à array Mongo.tls_context_hooks
. Isso pode ser feito em um inicializador. O exemplo abaixo adiciona um gancho que habilita apenas a cifra "AES256-SHA".
Mongo.tls_context_hooks.push( Proc.new { |context| context.ciphers = ["AES256-SHA"] } ) # Only the AES256-SHA cipher will be enabled from this point forward
Cada Proc
em Mongo.tls_context_hooks
passará um objeto OpenSSL::SSL::SSLContext
como seu único argumento. Esses procs serão executados sequencialmente durante a criação de soquete.
Aviso
Os hooks de contexto TLS são globais e afetarão todas as instâncias Mongo::Client
em um aplicativo.
Para obter mais informações sobre os hooks de contexto TLS, incluindo as práticas recomendadas para atribuí-los e removê-los, consulte a documentação do driver Ruby.
Compactação de rede
O Mongoid suporta compressão de mensagens de e para servidores MongoDB . Essa funcionalidade é fornecida pelo driver Ruby, que implementa os três algoritmos compatíveis com os servidores MongoDB :
Snappy: a
snappy
compactação pode ser usada ao se conectar a servidores MongoDB começando com 3.4 versão e requer o snappy biblioteca a ser instalada.zlib: a
zlib
compactação pode ser usada ao se conectar a MongoDB servidores começando com 3.6 liberação.Zstandard: a
zstd
compactação pode ser usada ao se conectar a servidores MongoDB começando com 4.2 versão e requer o zstd-ruby biblioteca a ser instalada.
Para usar a compactação de protocolo de fio, configure as opções do driver Ruby em mongoid.yml
:
development: # Configure available database clients. (required) clients: # Define the default client. (required) default: # ... options: # These options are Ruby driver options, documented in # https://mongodb.com/pt-br/docs/ruby-driver/current/reference/create-client/ # ... # Compressors to use. (default is to not use compression) # Valid values are zstd, zlib or snappy - or any combination of the three compressors: ["zstd", "snappy"]
Se nenhum compressor for explicitamente solicitado, o driver não usará a compressão, mesmo que as dependências necessárias para um ou mais compressores estejam presentes no sistema.
O driver escolhe o primeiro compressor dos solicitados que também é suportado pelo servidor. O compressor zstd
é recomendado, pois produz a maior compressão com o mesmo consumo de CPU em comparação com os outros compressores.
Para compatibilidade máxima do servidor, todos os três compressores podem ser especificados, por exemplo, como compressors: ["zstd", "snappy", "zlib"]
.
Criptografia do lado do cliente
Ao carregar o arquivo de configuração, o Mongoid permitirá que o arquivo contenha instâncias BSON::Binary
utilizadas para especificar o keyId
no mapa de esquema para a criptografia do lado do cliente, como o seguinte exemplo demonstra:
development: clients: default: database: blog_development hosts: [localhost:27017] options: auto_encryption_options: key_vault_namespace: 'keyvault.datakeys' kms_providers: local: key: "z7iYiYKLuYymEWtk4kfny1ESBwwFdA58qMqff96A8ghiOcIK75lJGPUIocku8LOFjQuEgeIP4xlln3s7r93FV9J5sAE7zg8U" schema_map: blog_development.comments: properties: message: encrypt: keyId: - !ruby/object:BSON::Binary data: !binary |- R/AgNcxASFiiJWKXqWGo5w== type: :uuid bsonType: "string" algorithm: "AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic" bsonType: "object"
Uso com servidores forking
Ao usar o Mongoid com um servidor web de bifurcação, como o Puma, ou qualquer aplicação que de outra forma bifurca para gerar processos filho, considerações especiais se aplicam.
Se possível, recomendamos não realizar nenhuma operação do MongoDB no processo principal antes da bifurcação, o que evitará armadilhas relacionadas à bifurcação.
Uma explicação técnica detalhada de como o mongo Ruby Driver lida com a bifurcação é fornecida em driver's "Usage with Forking Servers" documentation
<https://www.mongodb.com/pt-br/docs/ruby-driver/current/reference/create-client/#usage-with-forking-servers>
. Em resumo, para evitar vários erros de conexão, como Mongo::Error::SocketError
e Mongo::Error::NoServerAvailable
, você deve fazer o seguinte:
Desconecte os clientes do MongoDB no processo Ruby pai imediatamente antes da bifurcação usando
Mongoid.disconnect_clients
. Isso garante que o processo pai e filho não reutilize acidentalmente os mesmos soquetes e tenha conflitos de E/S. Observe que oMongoid.disconnect_clients
não interrompe nenhuma operação do MongoDB a bordo e se reconectará automaticamente quando você executar novas operações.Reconecte seus clientes MongoDB no processo Ruby filho imediatamente após a bifurcação usando
Mongoid.reconnect_clients
. Isso é necessário para reiniciar os threads de monitoramento do driver no processo filho.
A maioria dos servidores web fornece hooks que podem ser usados por aplicativos para executar ações quando os processos de trabalho são bifurcados. Veja a seguir exemplos de configuração para vários servidores web Ruby comuns.
Puma
Usar o on_worker_boot
gancho para reconectar clientes nos trabalhadores e os ganchos before_fork
e on_refork
para fechar clientes no processo pai (Documentação Puma).
# config/puma.rb # Runs in the Puma master process before it forks a child worker. before_fork do Mongoid.disconnect_clients end # Required when using Puma's fork_worker option. Runs in the # child worker 0 process before it forks grandchild workers. on_refork do Mongoid.disconnect_clients end # Runs in each Puma child process after it forks from its parent. on_worker_boot do Mongoid.reconnect_clients end
Unicórnio
Use o hook de after_fork
para reconectar clientes nos funcionários, e o hook de before_fork
para fechar clientes no processo principal (documentação Unicorn):
# config/unicorn.rb before_fork do |_server, _worker| Mongoid.disconnect_clients end after_fork do |_server, _worker| Mongoid.reconnect_clients end
Passageiro(a)
Use o hook de starting_worker_process
para reconectar clientes nos funcionários (documentação de Passageiro). O Passageiro parece não ter um hook invocado no processo principal antes da bifurcação dos funcionários.
if defined?(PhusionPassenger) PhusionPassenger.on_event(:starting_worker_process) do |forked| Mongoid.reconnect_clients if forked end end
Middleware de cache de query
Ativando o cache de query para solicitações da web do Rack
O MongoDB Ruby Driver fornece um middleware Rack que habilita ocache de query para a duração de cada solicitação da web. Abaixo está um exemplo de como habilitar o Query Cache Middleware em uma aplicação Ruby on Rails:
# config/application.rb # Add Mongo::QueryCache::Middleware at the bottom of the middleware stack # or before other middleware that queries MongoDB. config.middleware.use Mongo::QueryCache::Middleware
Consulte o guia Rails on Rack para obter mais informações sobre como usar o middleware Rack em aplicativos Rails.
Habilitando cache de query para ActiveJob
O MongoDB Ruby Driver também fornece middleware de cache de query para o ActiveJob. Você pode habilitá-lo para todos os trabalhos em um inicializador:
# config/initializers/active_job.rb # Enable Mongo driver query cache for ActiveJob ActiveSupport.on_load(:active_job) do include Mongo::QueryCache::Middleware::ActiveJob end
Ou para uma classe de trabalho específica:
class MyJob < ActiveJob::Base include Mongo::QueryCache::Middleware::ActiveJob end
Configuração de desenvolvimento
A configuração padrão do impulsionador é adequada para o sistema de produção. Em desenvolvimento, algumas configurações podem ser ajustadas para proporcionar uma melhor experiência ao desenvolvedor.
:server_selection_timeout
: defina isso como um valor baixo (por exemplo,1
) se o servidor MongoDB estiver sendo executado localmente e você o iniciar manualmente. Um tempo limite de seleção de servidor baixo fará com que o driver falhe rapidamente quando não houver nenhum servidor em execução.
Exemplo de configuração de desenvolvimento recomendada:
development: clients: default: database: mongoid hosts: - localhost:27017 options: server_selection_timeout: 1