mongo db brief intro

Reference:https://zhuanlan.zhihu.com/p/20786671?refer=bittiger

面试中如何胡侃知识点（以MongoDB为例）？

Mingche Su  · 18 天前

在面试时候有时会遇到考官问你一些你列举的关键词（知识点），如何跟考官侃侃呢？

举例子：could you tell me what you know about NoSQL（MongoDB)?

下面列举了回答问题的几个维度：

第一个维度：被考官牵着鼻子走（面试者初期的状态）：不知道怎么讲（或者压根不会），考官问什么你回答什么，这样会非常被动。其实大部分时候面试如果遇到不会的知识点（如果不是onsite的时候）可以Google的，但是切记在网上查知识点的时候，要用百度“xx是什么” 或者Google查汉语的解释：“xx是什么”，大部分不在美国接受本科的同学看到陌生的技术名词，在紧张的情况下是无法理解的。汉语毕竟是母语，理解得比较快，这样可以给面试官的感觉是你懂知识点，在国内学过，只是不知道怎么用英文表达，至少还是能弥补一小下的。

如果Onsite的时候真的不会某个知识点，你可以就反问面试官大概是什么东西，诱导他说一个大的范围知识，然后谈论一个相近的知识，反问面试官一个问题，最后说你听过这个知识点，与他在激烈讨论下，显得你们在谈笑风生；

比如面试问你MongoDB知不知道，你可以反问下这个大概是什么？面试官很可能就会说NoSQL的一种了，这时候你恰巧知道hbase，可以多扯扯hbase的东西，然后说MongoDB啊，以前听说啊，但是没用过，有机会可以尝试，你再反问它们为什么用MongoDB而不用hbase，你各种列举hbase的优点，达到浑水摸鱼的效果；

第二个维度：罗列知识点，诱敌深入（正常面试者的水平））：

首先你要装成是专家，然后自信的选择几个层面讲起：

• What is MongoDB

• Main features of MongoDB

• Application of MongoDB

• Who's using MongoDB

• When NOT to Use Document Stores
  特此申明：以上几张图来自于CMU NoSQL Database Management 95737课件，仅为本文举例说明，无任何商业用途。

  在面试中：基本答几个熟悉的层面就OK了，面试本身很多时候具有卖弄的成分，给面试官觉得很猛，实际上这些问题面试官也不一定很清楚，重要的就是你要很有观点，而且对新技术感兴趣，了解最新前沿技术动态。

  比如这里卖弄的点吧，说说哪些公司在用，这些就能体现出：你对IT行业很了解，调研过很多公司技术栈，然后你会的东西你要多说，这样引导考官问你熟知的东西，然后开始给他讲，他就会觉得你很博学。

  其余卖弄的点：主要四种NoSQL：

  • Column Family Databases
    
  • Document Databases
    
  • Key-Value Databases
    
  • Graph Databases
    

  每种database 都点评下，会给人感觉很牛的样子.

  第三个维度：用生长的方法来谈（大师级的答案，基本这样答，考官会哭的）。什么是生长的方法？就是从一颗种子开始谈，讲一讲它是如何张成参天大树的。MongoDB是怎么来的，如何演化的？

  刚开始给面试官讲一个实际的例子 （工作中碰到的实际问题）：

  假设我们有很多app信息信息需要存储，包括URL、PageSource、ID和Name等，如何写入硬盘呢？很简单，顺序地写就可以了。

  写好了之后，善变的我突然想加一个Version信息在第二块中，但是我们不能直接在第二块之后添加，因为这些数据在硬盘中是连续写的。

  所以我们可以在最后重写第二块的数据，加上Version信息，然后将之前已有的第二块信息删除。

  这样的方法会使数据不连续（产生磁盘碎片），中间有很大的gap，读取数据的时候很麻烦。这种情况下如何提速呢？可以在数据块之间建立指针，嗖地就跳过去了。
  

  

  这样查找变得简单了，可是仍然没有解决产生磁盘碎片的问题。如何既能加入新信息而又不移动已有数据呢？就是在每个数据块之后添加一些冗余的padding，这样新的数据就可以直接添加了。

  以上是我们的幻想，想象中有足够大的、连续的硬盘空间可以写。理想很丰满，现实却很骨感，真正的硬盘往往已经不连续了，存在着大大小小的磁盘碎片，我们只能插空写。

  你看这样我们可能就会将文件写的很碎了，要跳来跳去，读写性能很差。如何避免这种琐碎呢？就是申请一个比较大的空间，尽可能地连续写。

  那么如何申请大小合适的空间呢？策略就是double上升。我们从16M开始，不够就申请32M，再不够申请64M…直到2G为止（不再double，不够再申请还是2G）。

  解决了写还要解决读，比如如何查找ID范围在5000到7000范围内的app信息呢？我们就可以对ID建索引，比如BST，每个节点都指向对应的文档。

  这就是MongoDB的实现。MongoDB将document存储在硬盘上，每个document都可以随意添加，有schema-free的特点。MongoDB在document尾部添加了padding，并且document之间有前向和后项指针，成倍地申请硬盘空间，用B树（BST的升级版）做索引。