Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-14071

Remove all references to "Indexes should fit in RAM" and similar variants

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Blocked
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: manual, Server
    • Labels:
      None
    • Last comment by Customer:
      true
    • Story Points:
      2
    • Sprint:
      ServerDocs2020: Dec15 - Jan 5, ServerDocs2020: Jan5 - Jan12, ServerDocs2020: Jan12 - Jan19, ServerDocs2020: Jan19 - Jan26, ServerDocs2020: Jan26 - Feb2, ServerDocs2020: Feb2 - Feb9, ServerDocs2020: Feb9 - Feb16, ServerDocs2020: Feb16 - Feb23, ServerDocs2020: Feb23 - Mar2, ServerDocs2020: Mar2 - Mar9, ServerDocs2020: Mar9 - Mar16, ServerDocs2020: Mar16 - Mar23, ServerDocs2020: Mar23 - Mar30, ServerDocs2020: Mar30 - Apr06, ServerDocs2020: Apr6 - Apr13

      Description

      Description

      We have numerous references in our documentation where we advise customers that "indexes should fit in RAM" for optimal performance.

      For example:
      https://docs.mongodb.com/manual/tutorial/ensure-indexes-fit-ram/

      Notice we contradict the entire point of the page with the

      and

      https://docs.mongodb.com/manual/applications/indexes/
      Where we say "When your index fits in RAM, the system can avoid reading the index from disk and you get the fastest processing."

      There are a few problems with making these statements. While it's true that having indexes in RAM does make it so that you don't have to read them from disk THIS IS TRUE FOR ALL DATA USED BY THE APPLICATION. There's nothing special about having "just" indexes in RAM. The more of your "entire database" you have in RAM the better the performance will be.

      The working set is composed of both data and indexes and MongoDB offers no mechanism to pin specific data in cache. This advice ignores how WiredTiger works and gives customers flawed guidance. For instance, say you do have indexes in RAM... what about the data you need? Now you need to go to disk for it and your performance may still be inadequate?

      When customers read these statements they inevitably open support cases where we need to walk them away from what our documentation says because the issue is, ultimately, more nuanced.

      An alternative approach would emphasize the need to manage the working set, describing how indexes and data work together, and how making queries efficient makes performance optimal. I'm happy to assist if we'd like to alter the approach we're taking now.

      Scope of changes

      Impact to Other Docs

      MVP (Work and Date)

      Resources (Scope or Design Docs, Invision, etc.)

        Attachments

          Activity

            People

            Assignee:
            andrew.feierabend Andrew Feierabend (Inactive)
            Reporter:
            shakir.sadikali Shakir Sadikali
            Participants:
            Last commenter:
            Josef Ahmad Josef Ahmad
            Votes:
            3 Vote for this issue
            Watchers:
            8 Start watching this issue

              Dates

              Due:
              Created:
              Updated:
              Days since reply:
              30 weeks, 6 days ago
              Date of 1st Reply: