Please enable JavaScript.

Coggle requires JavaScript to display documents.

MongoDB Architecture (Indexes Indexes permit to optimize the db queries.…

- - - - BSON
        Similar to JSON but with extra data types
      - Size Limit 16MB (GridFS can be a work around / Object.bsonsize(document) - to see the document size.)
      - Support embedded documents
    - - Types
        
        Capped
        Capped collections it's a collection like the others but with predefined size limit. It's can limit the size and max documents. It's great to have a collection to log, featured, ranking... It works like a queue.
        Ex.:
        db.createCollection("my_collection", {capped: true, size: 100000, max: 10})
      - Sub Collection
        It's possible to have sub collections, just working like namespace.
        Ex.:
        db.restaurants and db.restaurants.featured
- - - - $each
      - $slice
      - $sort
  - - - sort()
      - limit()
      - skip()
- - - - Create Index
        db.posts.createIndex({ title: "text" })
        db.posts.createIndex({ title: "text", desc: "text" })
        db.posts.createIndex({ title: "text", desc: "text", author: "text"},
        ... { weights: { title: 3, desc: 2 }} }) // default is 1, so author has weight 1
        db.posts.createIndex({ "$**": "text" }) // dynamically when don't know the fields name
        db.posts.createIndex({ title: "text" }, { default_language: "portuguese" }) // the default is english
      - Query
        db.posts.find({$text: { $search: "MongoDB" }})
        db.posts.find({$text: { $search: "\"MongoDB nosql\"" }}) // search for exact
        db.posts.find({$text: { $search: "\"MongoDB\" nosql" }}) // search for exact MongoDB or nosql
        db.posts.find({$text: { $search: "MongoDB -nosql" }}) // search for MongoDB not nosql
        db.posts.find({$text: {
        $search: <string>,
        $language: <string>,
        $caseSensitive: <boolean>,
        $diacriticSensitive: <boolean>
        }, {
        score: { $meta: "textScore" }
        }
        })
- - - - Reads to Primary by Default, but can be to Secondary
        
        It's not recommended read from secondaries for many reasons, consistency, performance ...
        
        It's possible to give read preference to Primary, Secondary or Nearest
      - All writes to the primary
      - Election
        
        It's the process to choose the primary.
        
        A set member seek election when it can't find the primary and when it can be eligible.
        
        It's necessary the majority votes of the set to become the primary.
        
        If the priority is set as 0 it will never be a primary
      - Heartbeats
        * Short message to keep a set member up-to-dated about the everyone's state.
        
        It takes 2 seconds.
        
        If the primary realize that it can not reach the majority of the set it automatically became a secondary
      - Secondary Configuration
        
        Hidden
        
        It's possible set secondaries as hidden to avoid reads, recommended to less powerful or backup purpose servers.
        
        Arbiter
        
        It's possible to set as arbiter, It does not receive date, but take part in primary election
        
        Slave Delay
        
        It's possible to have a delay on sync, it helps if necessary rollback an error or it's a kind of snapshot
        
        Priority
        
        It's possible set the priority, if set as 0 it will never be a primary
        
        Building Indexes
        
        If the set member will be used just to backup or offline process can be avoid the indexes creations to accelerate the writes
- - - - Small subdocuments
        Belongs to relationship is usually a good case.
      - Data that does not change regularly (Immutable data)
      - When eventual consistency is acceptable
      - Documents that grow by small amount
      - Data that you'll perform a second query
        For example, when you need always show a author of a blog post.
      - Fast reads
      - Subdocument Indexes
        It can provide an efficient lookup.
    - - Large subdocuments
        
        One to many - if has many or large ones can avoid reallocations ( MMAPv1 engine) of the document on the disc that cause padding.
        
        Many to many - besides of avoiding the same problem of the one to many relationship, also avoiding problems when updating many documents to keep it up to dated.
      - Volatile data
        It helps to avoid problems of performance when updating subdocuments all the time.
      - When immediate consistency is necessary
      - Documents that grow a large amount
        It avoids reallocations of the document into the disc that cause padding.
      - Data that you'll often exclude from the results
      - Fast writes