MongoDB no mundo real
 Jean Carlo Nascimento aka Suissa
Links
               nosqlbr.com.br
              jquerybrasil.org
           frontendbrasil.com.br
          javascriptbrasil.com.br
        comoprogramarphp.com.br
             github.com/suissa
              about.me/suissa
                 @osuissa
Caso de Uso
MongoDB em produção na Sailthru
Sailthru
Comunicação personalizada e plataforma de
análise
https://www.sailthru.com/
Sailthru tamanho
●   200 milhões perfis de usuário
●   40 milhões emails enviados por dia
●   1000 requests por segundo
●   8 replica sets, 40 nós
●   Bilhões de documentos
Arquitetura da Sailthru
● Serviços críticos: API, link rewriting, onsite
  tracking/recommendations, email delivery,
  reporting/user interface
● Amazon EC2 e Colo(Peer1)
● Java, LAMP, Puppet, Scribe, ActiveMQ
MongoDB na Sailthru
● 2 anos de uso
● Replicaset diferentes para propósitos
  diferentes
● Coleções lógicas separadas no aplicativo
● Dados naturalmente particionados por
  cliente
Main Database
●   Banco de dados central
●   Estatísticas agregadas
●   Uso geral reduzido
●   Instancias menores
●   Coleções que não precisam escalar
●   Provavelmente nunca precisará de Sharding
Email Database
● Todos emails já enviados
● Uma das maiores coleções (meio bilhão
  documentos)
● Muitas escritas
● Coleções que não precisam escalar
● Provavelmente será a primeira coisa a usar
  Sharding
Horizon Database
● Dados de navegação para uso local
● Coleção pequena porém com muita leitura,
  poderá ser colocada em cache
● Escritas aumentarão
● Logicamente separada
Profile Database
● Perfis dos usuários (cerca de 30 milhões)
● Separado pois o acesso é mais aleatório e
  necessita de um conjunto de dados
● Grandes consultas devem acontecer apenas
  nos escravos
Migração do MySQL para MongoDB
● JSON é lingua franca
● Migrando uma tabela por vez e rodando os 2
  ao mesmo tempo
● Mudança no código para escrever nos 2
● Escrita e execução de script para "reaterrar"
  dados antigos
● Remoção do código que escreve para
  MySQL
Vantagens com MongoDB
● Desenvolvimento rápido
● Fácil armazenamento dos dados do cliente
  como JSON flexível
● Ótima performance
● Encoraja a escalabilidade
● Eles conhecem muito bem
Lições Aprendidas
●   DBRefs são um pouco pesadas
●   Use referencias legíveis
●   Índice para todas queries mais usadas
●   Tire vantagem de múltiplos índices
Dicas
● Documentos devem ser movidos quando
  ultrapassarem o tamanho esperado
● Caso possua campos que serão
  preenchidos posteriormente, ja popule com
  vazio.
● Autoinc pode ser emulado com
  findAndModify
● Cuidado com moedas, guarde em centavos
● Data BSON é bom para timestamp
● Considere antes de usar um Mapper
● Use GridFS para arquivos pouco acessados
mongod
●   Nunca finalize com kill -9
●   Nunca rode sem replicaset
●   Nunca rode sem log
●   Use journaling
Referencias
http://www.slideshare.net/ibwhite/mongodb-in-
production-at-sailthru
http://www.slideshare.net/sailthru/two-years

Mongo db no mundo real slides

  • 1.
    MongoDB no mundoreal Jean Carlo Nascimento aka Suissa
  • 2.
    Links nosqlbr.com.br jquerybrasil.org frontendbrasil.com.br javascriptbrasil.com.br comoprogramarphp.com.br github.com/suissa about.me/suissa @osuissa
  • 3.
    Caso de Uso MongoDBem produção na Sailthru
  • 4.
    Sailthru Comunicação personalizada eplataforma de análise https://www.sailthru.com/
  • 5.
    Sailthru tamanho ● 200 milhões perfis de usuário ● 40 milhões emails enviados por dia ● 1000 requests por segundo ● 8 replica sets, 40 nós ● Bilhões de documentos
  • 6.
    Arquitetura da Sailthru ●Serviços críticos: API, link rewriting, onsite tracking/recommendations, email delivery, reporting/user interface ● Amazon EC2 e Colo(Peer1) ● Java, LAMP, Puppet, Scribe, ActiveMQ
  • 7.
    MongoDB na Sailthru ●2 anos de uso ● Replicaset diferentes para propósitos diferentes ● Coleções lógicas separadas no aplicativo ● Dados naturalmente particionados por cliente
  • 9.
    Main Database ● Banco de dados central ● Estatísticas agregadas ● Uso geral reduzido ● Instancias menores ● Coleções que não precisam escalar ● Provavelmente nunca precisará de Sharding
  • 10.
    Email Database ● Todosemails já enviados ● Uma das maiores coleções (meio bilhão documentos) ● Muitas escritas ● Coleções que não precisam escalar ● Provavelmente será a primeira coisa a usar Sharding
  • 11.
    Horizon Database ● Dadosde navegação para uso local ● Coleção pequena porém com muita leitura, poderá ser colocada em cache ● Escritas aumentarão ● Logicamente separada
  • 12.
    Profile Database ● Perfisdos usuários (cerca de 30 milhões) ● Separado pois o acesso é mais aleatório e necessita de um conjunto de dados ● Grandes consultas devem acontecer apenas nos escravos
  • 13.
    Migração do MySQLpara MongoDB ● JSON é lingua franca ● Migrando uma tabela por vez e rodando os 2 ao mesmo tempo ● Mudança no código para escrever nos 2 ● Escrita e execução de script para "reaterrar" dados antigos ● Remoção do código que escreve para MySQL
  • 14.
    Vantagens com MongoDB ●Desenvolvimento rápido ● Fácil armazenamento dos dados do cliente como JSON flexível ● Ótima performance ● Encoraja a escalabilidade ● Eles conhecem muito bem
  • 15.
    Lições Aprendidas ● DBRefs são um pouco pesadas ● Use referencias legíveis ● Índice para todas queries mais usadas ● Tire vantagem de múltiplos índices
  • 16.
    Dicas ● Documentos devemser movidos quando ultrapassarem o tamanho esperado ● Caso possua campos que serão preenchidos posteriormente, ja popule com vazio. ● Autoinc pode ser emulado com findAndModify ● Cuidado com moedas, guarde em centavos ● Data BSON é bom para timestamp ● Considere antes de usar um Mapper ● Use GridFS para arquivos pouco acessados
  • 17.
    mongod ● Nunca finalize com kill -9 ● Nunca rode sem replicaset ● Nunca rode sem log ● Use journaling
  • 18.