SQL与NoSQL的一些内容汇总
使用SQL进行开发或者操作，我这就不进行说明，相信大家都明白；
基于NoSQL的操作是这样一种理论：内存是新的硬盘 硬盘是新的磁带。此话出自图灵奖得主Jim Gray。我理解的意思是这样（当然思维还是局限于目前的SQL理论操作）：在数据的存取中，我们忽略进行数据的文件存放操作，将必要的存取信息放置到内存当中（相当于硬件指令存取的Cache），将固定的当前不使用的数据按照一定的方式放置到硬盘当中。
我几乎是这样理解的，拿SQL Server 2005进行比较，数据存储文件、日志文件，如果我们使用Studio分离的话可以将数据以文件的形式存储，NoSQL理论将目前的连接数据库的管理平台、驱动程序等功能弱化，以一定的接口形式（为高级语言JAVA等）进行操作，因此能够实现无模式的结构，直接形成一个利用内存进行读写的数据库操作。
以下是找的篇文章的内存汇总：
摘出来的内容：
一、
问题一：宕机数据丢失
我们先看一下几个杰出的NoSQL代表，Cassandra，MongoDB，Redis。他们几乎都使用了同一种存储模式，就是将写操作在内存中进行，定时或按某一条件将内存中的数据直接写到磁盘上。这样做的好处是我们可以充分利用内存在随机IO上的优势，而避免了直接写磁盘带来的随机IO瓶颈：磁盘寻道时间。当然，坏处就是如果遭遇宕机等问题时，可能会丢失一些数据。
解决宕机丢数据的问题有两个方法：
1.实时记录操作日志
这时通常的做法是当一个写操作到达，系统首先会往日志文件里追加一条写记录，成功后再操作内存进行写数据操作。而由于日志文件是不断追加的，因此也就保证了不会有大量的随机IO产生。
2.Quorum NRW
问题二：内存容量的限制
当我们将内存当作硬盘来用的时候，我们必然会面临容量问题。这也是我们上面说到的数据会定时flush到磁盘的原因，当内存中的数据已经超出可用内存的大小，那么我们就需要将其进行落地操作，对swap的过度使用是不符合我们初衷的，也是达不到高效随机IO的效果的。这里也有两种解决方案：
1.应用层swap 2.多版本的数据合并
二、
如何设计消息动态功能呢?我们先来分析几个问题:
社区的动作比较频繁，产生的动态数据是实时存储，还是缓存后延迟存储，对效率有什么影响。
每个人产生的动态消息要在被关注的人之间分发，数据的膨胀速度非常快，如何解决大数据量的存储问题？
数据量非常庞大的时候，如何能提高我们读取的效率，普通的做法是采用缓存功能，是不是有其他的方法，能够保证程序即方便开发，又高效呢？
参考： SNS中好友动态功能的设计思路
综合考虑以上因素，我们放弃了利用关系数据库的方案，而采用现在比较流行的MongoDB来存储。主要原因：
采用缓存机制进行存储和读取处理，增加开发的难度。
MongoDB是一个解决海量存储的文档型数据库，无模式的结构可以让存储的数据结构更加灵活。在普通的关系数据库中，不同类型的消息的内容要存在一个字段中，一般采用JSON的格式存储，然后根据不同类型在解析显示出来。而MongoDB的无模式结构，就可以自由的定义各种字段，一个表中都可以存储不同字段定义的数据，前台可以直接引用，非常方便。
在大数据量下的查询中，MongoDB的查询性能还是非常好的，所以MongoDB都可以作为基础缓存层。更为重要的是，MongoDB的写性能要远远强过非关系数据库。通过这个特性，我们就无需在设立缓存层，而直接实时的插入和查询，方便的开发。
基于NoSQL的操作是这样一种理论：内存是新的硬盘 硬盘是新的磁带。此话出自图灵奖得主Jim Gray。我理解的意思是这样（当然思维还是局限于目前的SQL理论操作）：在数据的存取中，我们忽略进行数据的文件存放操作，将必要的存取信息放置到内存当中（相当于硬件指令存取的Cache），将固定的当前不使用的数据按照一定的方式放置到硬盘当中。
我几乎是这样理解的，拿SQL Server 2005进行比较，数据存储文件、日志文件，如果我们使用Studio分离的话可以将数据以文件的形式存储，NoSQL理论将目前的连接数据库的管理平台、驱动程序等功能弱化，以一定的接口形式（为高级语言JAVA等）进行操作，因此能够实现无模式的结构，直接形成一个利用内存进行读写的数据库操作。
以下是找的篇文章的内存汇总：
摘出来的内容：
一、
问题一：宕机数据丢失
我们先看一下几个杰出的NoSQL代表，Cassandra，MongoDB，Redis。他们几乎都使用了同一种存储模式，就是将写操作在内存中进行，定时或按某一条件将内存中的数据直接写到磁盘上。这样做的好处是我们可以充分利用内存在随机IO上的优势，而避免了直接写磁盘带来的随机IO瓶颈：磁盘寻道时间。当然，坏处就是如果遭遇宕机等问题时，可能会丢失一些数据。
解决宕机丢数据的问题有两个方法：
1.实时记录操作日志
这时通常的做法是当一个写操作到达，系统首先会往日志文件里追加一条写记录，成功后再操作内存进行写数据操作。而由于日志文件是不断追加的，因此也就保证了不会有大量的随机IO产生。
2.Quorum NRW
问题二：内存容量的限制
当我们将内存当作硬盘来用的时候，我们必然会面临容量问题。这也是我们上面说到的数据会定时flush到磁盘的原因，当内存中的数据已经超出可用内存的大小，那么我们就需要将其进行落地操作，对swap的过度使用是不符合我们初衷的，也是达不到高效随机IO的效果的。这里也有两种解决方案：
1.应用层swap 2.多版本的数据合并
二、
如何设计消息动态功能呢?我们先来分析几个问题:
社区的动作比较频繁，产生的动态数据是实时存储，还是缓存后延迟存储，对效率有什么影响。
每个人产生的动态消息要在被关注的人之间分发，数据的膨胀速度非常快，如何解决大数据量的存储问题？
数据量非常庞大的时候，如何能提高我们读取的效率，普通的做法是采用缓存功能，是不是有其他的方法，能够保证程序即方便开发，又高效呢？
参考： SNS中好友动态功能的设计思路
综合考虑以上因素，我们放弃了利用关系数据库的方案，而采用现在比较流行的MongoDB来存储。主要原因：
采用缓存机制进行存储和读取处理，增加开发的难度。
MongoDB是一个解决海量存储的文档型数据库，无模式的结构可以让存储的数据结构更加灵活。在普通的关系数据库中，不同类型的消息的内容要存在一个字段中，一般采用JSON的格式存储，然后根据不同类型在解析显示出来。而MongoDB的无模式结构，就可以自由的定义各种字段，一个表中都可以存储不同字段定义的数据，前台可以直接引用，非常方便。
在大数据量下的查询中，MongoDB的查询性能还是非常好的，所以MongoDB都可以作为基础缓存层。更为重要的是，MongoDB的写性能要远远强过非关系数据库。通过这个特性，我们就无需在设立缓存层，而直接实时的插入和查询，方便的开发。
MongoDB有一个ORM的实现，项目地址：http://code.google.com/p/morphia/
MongoDB的地址http://www.mongodb.org/
ORM示例地址：http://code.google.com/p/morphia/
