Cette conférence visait à échanger autour de MongoDB, la base de donnée orienté document.

Bien que l’utilisant depuis maintenant plusieurs mois, j’ai été agréablement surpris du niveau de finition auquel sont arrivés les équipes de 10gen avec MongoDB. On sent ici une réelle démarche pragmatique et non dogmatique.

La variété des outils d’admin (voir http://github.com/RedBeard0531/Mongo_Presentations/blob/master/20100521-mongony/notes_for_admin_talk), les stratégies mise en place pour la gestion des index, une feuille de route claire, tout ça contribue à donner confiance dans l’avenir de cette solution.

[edit : toutes les vidéos sont maintenant disponibles : http://lacantine.ubicast.eu/categories/mongofr/ ]

Voici quelques notes prise à la volée :

Ruby et MongoDB par la pratique par Yann Klis (@yannski)

slides

Yann Klis à MongoFr

• driver Ruby standard
• ODM (Object Document Mapper), équivalent ORM pour SGBDR
  • Mongoid
  • Mongomapper

  != ActiveRecord : ça ressemble mais ce n’est pas équivalent

• Choix de Mongoid
  • stable 1.x pour Rails 2
  • stable 2.x pour Rails 3
  • dans la branche 2.x
  • basé sur ActiveModel
  • Choisi sur (depuis plusieurs mois):
  • présence des criteria
  • lisibilité du code source
  • documentation
  • support plus précoce Rails 3
  • utilisé sur un gros projet en production (Hashrocket)
• Exemple Mongoid
  • Pas d’héritage mais include module
  • Déclaration des fields
  • embed document
  • Query language, enchainement de requête (ActiveModel like) via les objets Criteria
  • Equivalent scope via les criteria
  • existence de modules complémentaires
  • versioning
  • timestamp
• Ecosystème
  • ActiveModel comme couche d’abstraction
  • Authentification
  • Utilisation Devise
    • version >= 1.1rc1 (utilise Mongoid, avant utilise MongoMapper)
  • state_machine, >= 0.9.2
  • carrierwave pour gestion assets

  impossible d’utiliser (ou très difficile) :

  • paperclip: lié à Activerecord
  • Authlogic : trop complexe et trop lié à Activerecord
• Modélisation
  • particuliérement adapté à appli Web
  • embarqué tous les documents liés
• Quand on vient de AR
  • MongoDB est Schemaless, pas l’appli
  • Pas de fonction OR depuis les drivers —> passer par Javascript (du coup pas d’index)
  • group / sort —> 10000 résultats seulements
  • Id != ObjectId
  • selon les versions, utilisé comme string (old)
  • Accéder au driver
  • MapReduce
  • ActiveModel::Serializers::Xml pour to_xml

Schema Design (Kyle Banker @hwaet)

Kyle Banker à MongoFr

• Principes
  • Play with it : http://tray.mongodb.org
  • Design goals :
  • between key value store and a relational database
  • What’s the basic unit of data
  • Blobs ?
  • Rows ?
  • Columns ?
  • Documents ?
  • How can we operate on that data ?
  • Dynamic query
  • Secondary index
  • atomic update
  • What are your application have to do ?
  • read write ratio ?
  • how’s updated .
• Using rich doc
  • Order contains Items details, address in one document
  • What we can do with a rich document
  • secondary index on inner attributes
  • atomic update
  • map reduce
  • advantages
  • pre-joined
  • holistic representation
  • easily manipulated by mongodb
• simplifying relations
  • a lot of very simple relations can be compressed in a single document
  • i.e.: tags, votes
• Embed vs references
  • Single document or reference
  • Post and comments, comments are embedded in post
  • slice operator for paginators
  • nested documents
  • you can use classical relations by reference as well if necessary
• E-commerce
  • Product as rich document
  • using indexed array keys
  • no many to many relations : collection on both side
  • update both
  • query symmetrical
  • wish list as embedded doc
  • array of objects in user doc
  • product reviews
  • independent document
  • votes on reviews
• Think about design questions
• Look at the shell
• Watch for new features
• Use rich doc
• simplifying

Indexing and query optimizer

• all documents have entry in indexes
• a missing fieldnis indexed as NULL
• unique constraint allways allow duplicate NULL
• A field with an array : one entry in index by element of array
• sort elimination through index, both ways
• use explain() after query —> db.post.find(…).explain()
• hint : way to use or avoid an index

Replication and ReplicaSet

• ./mongod —master
  • —> oplog + local db
• ./mongod —slave —source

localdb : reserved name, never replicated
store replication data :

• On Master
  • local.oplog.$main (capped collection)
  • local.slaves
  • db.printReplicationInfo()
• On Slave
  • local.sources
    use local
    db.sources.find()
    db.printSlaveReplicationInfo()
• delayed slave
• Replica Sets
  • better Replica Pairs
  • next month (1.6 ETA July 2010)
  • a cluster of N servers
  • any node can be primary
  • consensus election of the primary
  • auto failover
  • auto recovrery
  • all writes to primary
  • reads primary or secondary
  • write committed if duplicated on a majority of servers of the set
  • data may be visible before cluster commited
  • this data can be dropped on recovery of master
  • configuration is in a single config document
  • member type :
  • “DR” (priority < 1.0) : distant, …
  • with sharding

Sharding

Methods of distribution

• ad-hoc
• consistent hashing (Dynamo)
• range based (BigTable)

Mongo Sharding :

slides

• distribute databases, collections, objects in a collection
• you choose
• balancing, migrations, management automatic
• Range Based : via minkey/maxkey, collection broken in chunk
• almost no loosing functionality in sharding
• client code the same
• 3+ config servers
• mongos servers :
  • sharding routers
  • acts as mongod to client
  • one or more
• Multi DataCenter
  • intelligent geo honing
  • auto failover
• limitations
  • can’t have unique address not based on shard key
  • current version limited to ~20 petabytes

MongoDB at Silentale (Nicolas Fouché)

• Une collection / user
  • sécurité de séparation de donnée
  • migrer les données d’un user …
  • toutes les données sur un user, gagne espace index
• sharding
  • custom algo
• replica pairs
• amazon : m1.xlarge insances
  • 64 bits pour BDD + grandes
  • 15Gb RAM
• Pourquoi MongoDB
  • plus facile d’acces depuis activerecord
  • stoquage et requetage de tableaux
  • support de la part de 10gen
• Problèmes rencontrés
  • ruby driver (fixed maintenant)
  • permettait de stoquer des données non UTF8
  • permettait de
  • replication problems
• version 1.4.3 en production
• pas de transactions, mais atomic updates
• count :
  • couteux sur grosse base (full scan)
  • utiliser $inc $dec pout gérer un compteur
  • évite la pagination standard, utiliser les custom cursors
  • pas de total sur les pages
• query operators
  • query sur les tableau de hash de tableau …
  • map/reduce
• Stats
  • ~100M documents
  • ~1.5TB of data
  • > 1.5TB of indices
  • 15Gb RAM / shards
  • IO bound
• Too slow :
  • premier query sur une base lent, suivant rapide
  • solutions
  • séparer en différentes base de données
  • une pour meta data
  • une pour les documents
  • une dédiée pour les recherches full text
  • sortir d’amazon —> serveurs dédiés avec SSD
• Wish list
  • manque cache management : permettre de spécifier des données qu’on veut garder en cache (une collection)
• full text recherche :
  • custom : construire un tableau de mots et l’indexer (via $in, et à l’avenir $or)