nosql数据库
软件的变化：
1.用户数量的变化：
以前的用户数量少，并且变化量不大；现在的用户数量大，并且随着时间增长；
2.应用需求的变化：
以前的软件解决流程固定的问题，把人工做的事情映射给计算机做，达到完成业务流程的速度更快，犯得错误更少，业务流程早就一文本的形式规定好了，如取款机业务，机票预订业务等等。
现在软件解决的问题业务流程是未知的，没有现有的模型去模仿的，业务规则随时会改变。实现这种业务所需要的后台数据库必须具备灵活多变的特性。
3.计算设施的变化
以前倾向于使用集中式计算设施，通过提高计算机的计算性能来适应需求的增长；
现在倾向于使用分布式计算设施，以达到以下目标：
①设施成本随着用户需求的增长线性增长；
②通过增加计算节点可以达到响应速度不变的效果；
③可以平缓的上线新功能，如果系统有新功能，可以一部分一部分节点更新，而不是先将原有系统下线。
数据库发展没有跟上发展节奏
关系数据库占据了当前数据库的主流，关系数据库是按照集中式计算模型设计的，为了用户需求的增长比较倾向于采用scale-up的策略。
然而关系数据库的最大问题是关系数据库的严格的schema,在向数据库插入数据之前必须定义好schema。所以在设计数据库的时候要考虑好以后可能会出现的字段。如果已定义的schema不能满足现有的应用，就必须改变原有的schema，这种操作对系统有较大的破坏性。
关系数据库有这些问题，就有一些改变来解决这些问题：
1.sharding
sharding就是将数据库中的数据分配到不同的服务器上。比如，全国的人口数据，可以将长江以南的放在一个数据库A，将长江以北放在另外一个数据库B。
sharding会带来一些不好的后果：
①可能需要re-shard。比如，当长江以北的数据太多，以致数据库B不能装完的时候。可能就要考虑将长江以北数据分为长江以北黄河以南和黄河以北两部分了。做这个改变的时候，原来的应用也要做相应的改变，re-shard之前我们访问长江以北的数据在数据库B，现在要改为数据库B和C了。
②损失了关系模型带来的一些好处。
③需要为每个服务器维护一份schema。在单机上改变schema就是一件难事了。
2.denormalizing
关系数据库是由多张表组成的，要更新一条记录的时候，必须锁定多张表，这样降低了数据库的吞吐量。denormalinzing存储冗余数据，将数据存储为key-value形式，这种做法将关系数据的特性全都丢失了。
3.分布式缓存
通过分布式缓存可以提高数据库的性能，但也有以下几个缺点。
①缓存能提高读性能，写数据库仍然是一个瓶颈；
②当某个缓存损坏的时候，原来在缓存的读请求会流向数据库，导致数据库访问压力急剧增大；
③又多了一层系统要维护。
以上针对关系数据库的做出的一些改变都是治标不治本的，是强行对关系数据库做一些改变以适应现在的应用需求。关系数据库已经有了一个很大的市场，原来的关系数据库厂商为了保住他们的那块蛋糕，不会积极的去解决现有需求投入研发。于是有些大公司，google，amazon什么的自己开发数据库了。这些数据库与关系数据库相比更适应现在的需求。
主要有以下特性：
①不需要定义schema,这可以适应多变的业务需求；
②自动sharding，不需要具体的应用去参与sharding的过程，sharding过程对业务是透明的；
③支持分布式查询；
④集成缓存，这样就不需要另外去维护一个缓存层了。