本文选自 highscalability上的一篇博客文章，作者系 tokutek公司（tokutek能够提升mongodb, mysql以及mariadb的性能20倍）的一位工程师，该公司研究的主要方向是存储引擎。csdn编译整理如下： 作为一名软件开发者，我们非常看重那些抽象化的东西。api越简单
本文选自 highscalability上的一篇博客文章，作者系 tokutek公司（tokutek能够提升mongodb, mysql以及mariadb的性能20倍）的一位工程师，该公司研究的主要方向是存储引擎。csdn编译整理如下： 
作为一名软件开发者，我们非常看重那些抽象化的东西。api越简单，对我们越有吸引力。辩证地讲，mongodb最大的优势就是“优雅”的api和它的敏捷性，这让开发者的编码过程变得异常的简单。
但是，当mongodb涉及到大数据可扩展性问题时，开发者还是需要了解一下它的底层，弄明白那些潜在的问题，然后才能快速地进行解决。如果不理解，最终可能会选择一个低效的解决方案，而且浪费了时间和金钱。本文重点介绍了，如何为大数据的扩展性问题找个一个高效的解决方案。 
定义问题 
首先，我们要确定应用的上下文，本文主要讨论的是mongodb的应用程序。这意味着，我们将研究一个分布式文档存储数据库，而且它还支持二级索引和分片集群。如果是针对其他的nosql产品，像riak或者cassandra，我们可能会讨论i/o瓶颈问题，而本文主要关注mongodb的一些特性。 
其次，这些应用能够做什么？是做联机事务处理（ oltp）还是做联机分析处理（ olap）？本文主要讨论的是oltp，因为对mongodb而言，olap还是一个不小的挑战，或者说基本不能够进行处理。 
第三，大数据是什么？通过大数据，我们能够处理和使用更多的数据，不再局限于单机ram中的那些部分。这样的话，有些数据保留在服务器上，而更多的数据则是存放在磁盘中，这就需要i/o的访问。但是请注意，我们不是在讨论数据库够不够大，而是关注那些经常被存取和使用的数据（有时称之为“工作集”）是不是很小。比如说，磁盘上虽然存储了好几年的数据，但是应用可能经常访问的只有最后一天的数据。 
第四，oltp应用的限制性因素有哪些？简而言之，就是i/o。硬盘驱动每秒钟只可以启动上百次的i/o，而另一方面，ram每秒可以实现数百万次的存取，这个限制性因素就是导致大数据应用i/o瓶颈的原因所在。 
最后，我们应该如何解决i/o瓶颈？通过分析思维，公式和直接指令给我们提供了很多种方式，但是一个持久性的解决方案就需要“理解”。用户必须着眼于应用程序的i/o特性，然后才能做出最好的设计决策。
开销模型 
未来解决i/o瓶颈，第一步需要掌握哪些数据库操作会包括i/o。 无论mongodb，还是其他的数据库类型，都有三种基本的操作：
point query：查找一个独立的文件。在一个给定的位置的文件夹（磁盘或者内存上），检索该文档。对于大数据来说，该文件可能不在内存中。此操作可能会导致一次i/o。
range query：在索引中，查找大量的连续性文件，对比point query而言，它是一个更高效的查询操作。这是因为我们查找的这些数据都是打包存放在磁盘上，可以通过极少的i/o操作来直接读入内存。range query一般检索100个文件才会启动一次i/o，相对比，100个point query检索100个文件可能就需要100次i/o操作。
write：写文件到数据库中。类似mongodb这样的数据库，都会产生i/o。而对那些“写优化”数据结构的数据库而言，比如 tokumx，仅仅需要很少的i/o。不像mongdb，“写优化”的数据结构能够通过执行多次插入来分摊i/o。
在了解三个基本操作对i/o的影响之后，还需要理解mongodb数据库语句对i/o的影响。mongodb包含了这三个基本操作，同时还构建了四个用户级别的操作： 
插入：将一个新文件写到数据库中。 查询：在集合上使用索引，这样做一个range queries和point query的整合。如果该索引是一个覆盖索引或者是集群索引，那么接下来基本上只需要做范围查询。否则的话，整合的范围查询和点查询就会被启用。 修改和删除：这是一个查询和写操作的整合。查询操作用于发现那些需要更新和删除的文件，然后写操作再对这些文件进行修改或者是删除。现在，我们理解了开销模型。不过为了解决i/o的瓶颈问题，用户还需要知道哪些应用启动了i/o操作。这就需要我们了解数据库的行为。i/o启动是源于查询操作吗？如果是这样的话，查询行为是如何影响i/o的？还是源于修改操作？如果是因为修改导致的影响，那么是因为修改过程中的查询操作还是插入操作？一旦用户掌握了哪些因素会影响 i/o，接下来就可以逐步来解决瓶颈的问题了。
假设我们明白了某个应用的i/o特性，我们就可以探讨几种途径来解决这一问题。我最喜欢的方式是这样的：首先尝试使用软件来解决该问题，如果不能完美的解决，那么再考虑硬件。毕竟软件的成本更低且易于维护。