键值。键值数据库可以满足游戏、零售和移动等应用程序的高可用性、低延迟需求。它的模式比较灵活，在会议管理、服务广告内容和管理用户或产品文件方面有卓越的表现。总之，当数据不是按一定模式，而是包含很多种代码的时候，可以使用键值数据库。
但如果要管理不同数据集之间复杂的关系，或使用非限定的键进行查询，键值数据库的表现就欠佳了。
文档数据库。这种数据库特别适合用于为每一个文档存储不同种类的数据，可以实现跨数据的弹性的搜索。如果你的模式不是网格式的，你又需要指定键之外的东西进行查询，那么文档存储绝对是一个不错的选择。文档数据库适合应用于事件日志，线上购物，内容管理和深度分析流程。对于要求快速原型的项目来说，文档数据库的模式灵活性也是一大亮点。
不过，文档数据库不适合复杂的事务处理。对于要求数据压缩的应用程序来说，文档数据库并不是一个很好的选择，因为弹性模式意味着跨文档的数据不一致，也不可能被有效压缩。
列式存储。这种数据库以列的方式存储数据。与一个键(或识别符)相关的有很多列。和其他NoSQL数据库一样，它的模式很灵活，一个列式家族可以由不同的列组成。另外，列式存储中的数据可以通过列访问，而不是键。
列式存储并不是一个新概念，它的变体过去作为一种概念应用于关系型数据库中(比如SAP Sybase IQ和IBM DB2 BLU)。虽然关系型列式存储也聚焦与列，但它不允许跨行的列有所不同，这是它与NoSQL列式存储不同之处。
对于不经常写，但要频繁地一次读取很多行的几列的情况下，列式存储是很有效率的。对于时间日志、内容管理、分析的计算和分类，列式存储都很有效。如果你有要过期的数据，列式存储非常有用，因为你可以建立一列，让它自动过期。
如果是跨度很广的查询，不要用列式存储，因为你可能不得不重新设计列。另外，列式存储不是很适合ACID事务。
图型数据库。这种数据库可能是和传统数据库以及其他NoSQL数据库区别最大的。图型数据库适用于数据元素之间相互关联，而且彼此之间关系的数量不确定的情况。
图型数据库最常用于社交媒体网络，比如LinkedIn和Facebook。当然也有一些其他的应用程序，比如分配路线和调度、定位系统、公共交通连接、地图、课程计划和网络拓扑结构等。图型数据库的另一个实践在于推荐引擎，常用语在线零售商。
图型数据库不适合用于数据经常改变，常发生大规模数据之间实时更新的情况。另外，如果你计划跨网络分区数据库的话，图型数据库很可能会性能下降。
六大考虑因素
NoSQL数据库之间的很多不同给技术选择带来了难度。不同的数据库类型和产品有不同的架构。即使同样是NoSQL数据库，不同类型之间也有所不同，没有统一标准，即便是访问数据的标准也不相同。这意味着在不同的数据库中访问数据，有不同的工具和应用程序需要采用和学习。以下是需要考虑的一些方面。
快速变化。NoSQL领域是持续变动的，特性不断提升、功能不断增加、甚至会产生新产品。在选择NoSQL数据库时，很难跟上最新最好的功能和产品。
对ACID的支持能力越来越强。NoSQL的一个早期卖点是它支持不要求全部ACID支持的事务。取代ACID，NoSQL提升了最终一致的基本可用软件状态服务(BASE)。虽然如此，很多应用程序依然依赖ACID，NoSQL对ACID事务的支持是用户的需求，也是它自己在不断完善的。
缺少对多平台的支持。大多数NoSQL数据库起源于开源运动，因此基本上都运行在Linux上，(或者Unix的变体)。如果你需要在Windows或者主机上部署数据库，你需要考虑商业产品，因为商业产品对多平台部署的支持性更好。
增加对SQL的支持。没有SQL，查询通常非常基础，可能要求使用高级语言的复杂的代码。当然，产品与产品之间也有所不同，不过最好选择支持SQL的NoSQL数据库，因为很多开发者熟悉的还是SQL语言。
开发多种类型数据库的能力。一些NoSQL数据库允许你用键值对、文档和图型的弹性的组合建模和部署数据。另外，关系型数据库开始采用NoSQL能力。使用能够开发多种类型数据库存储的数据库系统能帮助你的组织获得普适的持久性。
注意技术的版本。很多开源项目运行了很多年，但也没有第一版。这些软件可能很好用，但慎重的公司一般不会选择没有发行第一版的技术。