Upload
fabio-perrella
View
1.178
Download
6
Embed Size (px)
Citation preview
Coisas que aprendemos usando Mongoid com grande quantidade de
dados
@fabioperrella
Créditos também para:Claudio Bruno Martins
@marciotrindade
Objetivos
● Mostrar coisas que descobrimos
● Mostrar técnicas que usamos
● Ver se alguem fala "NAO FAÇAM ISSO!"
● Fazer alguem pensar ou falar "NOSSA, DA
PRA FAZER ISSO!"
Email Marketing - Locaweb
● SaaS
● Multi Tenant
● Grande quantidade de dados
● Grande histórico de dados
● Sistema antigo, baseado no php-list
● ==> Nova plataforma em Rails + MongoDB!
● Lançamento na próxima semana
MongoDB● Simplicidade
● Sharding: grande quantidade de dados
● Schema-free: campos customizados contatos, filtros
● Replica Set: Alta disponibilidade
● Operações Atomicas: inc, addToSet, pull, push...
● Boa performance
● Maturidade: mongosp 2011!
● Atualizações constantes! (estamos na v2.0.5)
Mongoid
● Simplicidade
● Boa documentação
● Mongo Mapper tinha bug com muitos
documentos embedados (faz tempo)
● .. e está chegando a versão 3 muito melhor!
Implementação de Campos Customizáveis
● 1a ideia - Mongoid dynamic fields (allow_dynamic_fields)
Implementação de Campos Customizáveis
● 1a ideia - Mongoid dynamic fields (allow_dynamic_fields)
● Problemas○ Proteção de campos internos (status, id, etc..)
○ Restrição no nome dos campos customizáveis
○ allow_dynamic_fields no Mongoid é global!
● Vantagens?○ Indice nos campos
Implementação de Campos Customizáveis
● 2a ideia - field custom_fields, type: hash
Implementação de Campos Customizáveis
● 2a ideia - field custom_fields, type: hash
● Vantagens○ Proteção dos campos internos
○ Liberdade no nome dos campos
● Problemas?○ Índice nos campos
Implementação de Campos Customizáveis
● Indice nas chaves de um hash! (inclusive em chaves que não existem)
Implementação de Campos Customizáveis
● Cuidado com indices!● Geração de indice faz lock do DB inteiro!
○ 10min collection com 50milhoes de documentos
● Custo alto (memoria, espaço em disco, escrita)
Implementação de Campos Customizáveis
Implementação de Campos Customizáveis● Se o cliente quiser trocar o nome dos
campos?○ Toma essa!! operador $rename =~ Alter table
● Buscas tipadas (string, date, int)Contact.where("custom_fields.date" =>
{"$lt" => Time.parse("1982-01-1")})● Operadores de condição:
http://www.mongodb.org/display/DOCS/Advanced+Queries
Implementação de Campos Customizáveis
● Bug no MongoDB, ordenação de indices
● Case Sensitive (http://jira.mongodb.
org/browse/SERVER-90)
● Fix: criar campo em lowercase{ "_id": ObjectId("4fdfd0ada53bd0206a000003"), "email": "[email protected]", "name": "PopoLala", "name_lc": "popolala"}
Implementação de Campos Customizáveis
Belongs To Many
Belongs To Many
● Opções de modelagem:○ 1) Embed Documents
○ Vantagens:■ Consulta rápida dos dados
○ Desvantagens:■ Tamanho do documento
Belongs To Many
Belongs To Many
● Problemas!
○ Tamanho máximo de um documento 4MB, 8, 16..
■ melhor não passar de 100KB
○ Alternativa quebrar em chunks -> complexidade!
○ Gridfs? não
Belongs To Many
● Opções de modelagem:○ 2) Has And Belongs to Many
○ Vantagens:■ Tamanho dos documentos menor?
■ Consistência
○ Desvantagens:■ Busca
■ Tamanho dos documentos!!!
Belongs To Many
Belongs To Many
● Opções de modelagem:○ 2) Has And Belongs to Many
■ Tamanho do documento com 201mil ObjectIds!
Belongs To Many
● Problemas!
○ Complexidade no codigo para usar only(:fields)
Belongs To Many
● Opções de modelagem:○ 3) Has And Belongs to Many!!
Belongs To Many
● Opções de modelagem:○ 3) Has And Belongs to Many!!
http://agendaculturalpiracicabana.blogspot.com.br/2012/01/dia-13-sexta-feira-vamos-cacar-o-saci.html
Belongs To Many
● Opções de modelagem:○ 3) Has And Belongs to Many
○ Vantagens:■ Tamanho dos documentos menor!
■ Consistência
○ Desvantagens:■ Busca?
■ Implementação fora do padrão
Belongs To Many
Belongs To Many
Belongs To Many
GEM (wip):
https://github.com/fabioperrella/mongoid_belongs_to_many
Belongs To Many
● Opções de modelagem:○ 3) Has And Belongs to Many
○ Indice em campos tipo array!
index :message_ids
Mongoimport
● Feature: Importação de contatos em massa
● Problema○ Listas com mais de 100mill contatos
○ Concorrência entre clientes
○ Precisa ser rápido!
● Solução○ mongoimport
Mongoimporthttp://www.mongodb.
org/display/DOCS/Import+Export+Tools#ImportExportTools-mongoimport
● Ponto positivo:○ Velocidade (mais de 8mil documentos/segundo)
● Pontos Negativos○ Validação dos dados
Não há como fazer "Merge" de dados○ Dificil tratar de erros pois roda com system
Mongoimport
● Validação dos dados
Mongoimport● to_mongo_json
○ carregar objeto com dados do CSV e validar!
○ conversão de ObjectIds
○ conversão de datas (timestamp em miliseconds)
○ conversão de Array de ObjectIds (relacionamentos)
○ conversão de Hashes
○ gerar JSON no formato do mongoimport
● Bug data < epoch (https://jira.mongodb.org/browse/SERVER-
961)
Mongoimport
● Merge de dados nao existe!○ opção "upsert" atualiza documento inteiro, não é
possivel fazer merge https://jira.mongodb.
org/browse/SERVER-1674
○ PERIGO com dados que podem ser atualizados
por outro lugar (counts, etc..)
○ Solução: Mongoid collection.update!
Mongoimport
● Merge de dados não existe!○ collection.update apenas nos campos que
precisam ser atualizados
Mongoimport
● Tratamento de erros
Updating - Atomic Operators● http://en.wikipedia.
org/wiki/Linearizability#Example_atomic_operation
● http://en.wikipedia.org/wiki/Compare-and-swap
Updating - Atomic Operators● http://www.mongodb.org/display/DOCS/Updating
● inc
● set / unset
● push
● pushAll
● addToSet e each
● pop / pull
● pullAll
● rename
Updating - Atomic Operators● inc: incrementa um número
○ pode ser usado com campo nil
Updating - Atomic Operators● inc
○ pode ser usado em hashes (mesmo vazios!)
Updating - Atomic Operators● inc com multi:true (em N documentos)
○ somente com o collection.update no mongoid
Updating - Atomic Operators● set: seta valor de um campo
○ no mongoid só é possível atualizar 1 campo com
o .set
Updating - Atomic Operators● addToSet
○ insere 1 elemento em um array se já não existir nele
○ pode fazer mais de uma operação por vez, por exemplo
com INC
Updating - Atomic Operators● addToSet com each
○ insere N elementos em um array se não existirem nele
Updating - Atomic Operators● pull / pullAll
○ remove 1 / N elementos de um array
Updating - Atomic Operators● rename
○ renomeia nome de campos, inclusive de hashes!
Sharding● Não deixe pra depois se já sabe que vai precisar!
○ tempo para implementação, testes...
○ shard balancing pode sobrecarregar máquina se já
estiver no limite
○ algumas coisas não funcionam (ou não funcionam
direito) com shard, exemplo:
■ counts
■ mongodb unique index
Sharding● não deixe pra depois se ja sabe que vai precisar!
○ mongoid shard_key (se nao tiver, dá erro em update,
inserts..)
Sharding● não deixe pra depois se ja sabe que vai precisar!
○ Safe mode: ligar no test / development, desligar em prod!
Sharding● mongoS, configServer, replicaSet, mongoDB
Sharding● Chunks, splitting e balancing
○ Chunk: pedaço de uma collection
○ Splitting: quebra de chunk quando fica grande (64M)
○ Balancing: mover chunk para outro shard quando o atual
está mais cheio
Sharding● Chunks, splitting e balancing
○ Exemplo: Collection Users com campo mês de aniversário
○ Sharding key: mês de aniversário
Começo Fim Shard
fevereiro março A
setembro +infinito A
Começo Fim Shard
-infinito fevereiro B
março setembro B
Sharding● Chunks, splitting e balancing
○ após splitting
Começo Fim Shard
fevereiro junho A
junho março A
setembro +infinito A
Começo Fim Shard
-infinito fevereiro B
março setembro B
Sharding● Escolha da shard key
○ "It is important to choose the right shard key for a
collection. If the collection is gigantic it is difficult to
change the key later. When in doubt please ask for
suggestions in the support forums or IRC". (1a linha
no site do mongodb)
○ http://www.mongodb.
org/download/attachments/2097354/how+queries+w
ork+with+sharding.pdf
Sharding● Escolha da shard key
○ pensar na escrita e leitura dos dados:
■ load balancing: na escrita deve dividir dados entre
os shards
■ na leitura tentar não varrer vários shards para ter
a resposta
Sharding● Escolha da shard key
○ como não deve ser:
■ low-cardinality: por exemplo continentes (africa,
america, europa)
■ ascending shard key: por exemplo objectid, vai
concentrar todas leituras e escritas em um shard
■ random shard key: por exemplo md5, quase sempre
vai precisar juntar os dados de varios chunks, nao vai
conseguir deixar dados parecidos juntos
Sharding● Escolha da shard key
○ recomendado: objectid + search key
Exemplo:
Inicio Fim Shard
-infinito Africa,000111 A
Africa,000111 Africa,999999 B
Africa,999999 Europa,22233 A
Europa,22233 Europa,87652 B
Europa,87652 +infinito B
Replicaset● Prefira escalar usando shards e não replicasets com leitura
nos secundário (slave_ok = true no Mongoid)
● Leitura insegura. Nos secundários podem haver dados
antigos
● Ainda em estudo por nós..
○ estratégia de backup em secundários
○ compactação de dados nos secundários
○ journaling habilitado apenas no secundário de backup
Monitoração● mongostat --discover
Monitoração● db.stats()
● db.collecionName.stats()
● rs.serverStatus()
● rs.status()
● db.currentOp()
● MongoDB Monitoring Service (MMS)
○ SaaS
○ Free!
Testes de carga● velocidade de escrita (ex: importação de contatos)
● ambiente de homologação rodando com base carregada
● analisar queries lentas com explain() no console do mongo
● simular casos extremos (ex: cliente grande com muitos
contatos)
● definir limites de segurança
● http://www.mongodb.org
● Scaling MongoDB (Kristina Chodorow)
● 50 Tips and Tricks for MongoDB Developers
(Kristina Chodorow)
● MongoDB in Action (Kyle Banker)
Referências