从可查询的分布式解决方案，如MongoDB，到简单的分布式Key/Value存储解决方案，如Cassandra。此外，还有Riak，Tokyo Cabinet，Voldemort，CouchDB和Redis。但目前仅有少量的NoSQL项目支持在Windows平台上运行，如果要说到生产应用那就更少了。
Memcached传统上认为它不属于NoSQL的范畴，而是一个分布式Key/Value内存缓存解决方案，它可以用来存储各种各样的临时数据集，存储方式和其它NoSQL数据库解决方案没有什么差别。
NorthScale提供了适合于32位和64位Windows平台的Memcached程序包，可从这里免费下载。
MongoDB是一个基于文档（json风格）的数据存储引擎，通过它的自动分片功能可实现良好的水平扩展能力，它使用了一个简单但功能很强大的基于JavaScript/JSON的查询语言，提供了快速插入和更新能力，主要归功于它的低开销原子修改程序。此外，使用Map/Reduce实现了跨多个MongoDB数据库聚合和数据处理。MongoDB背后的10Gen公司前不久正式宣布了对Windows平台的支持。MongoDB目前的最新版本是1.6.0，许多大型Web站点现在都在使用它。关于MongoDB Windows版本的更多信息请移步这里，对应的版本可从这里下载。
sones GraphDB
sones GraphDB是一个企业图形数据存储引擎，它使用C#语言开发，并且是开源的，对于非商业目的可以免费下载，但如果用于商业目的则需要购买商业许可。
图形数据库和我们常说的NoSQL数据库存储方式是不同的，它们更善于处理一类特定的问题：数据集包含了大量的关系，需要快速高效地遍历这些关系。
图形数据库一个常见的用例就是用来存储社交关系或社交图，通常，这些社交图由许多节点组成，节点之间存在许多独立的关系，这是传统关系数据库很难处理好的问题域。如果你对sones GraphDB感兴趣，可从这里下载它的源代码，更多信息请访问该项目的官方网站。
Voldemort是一个分布式Key/Value存储系统，LinkedIn用它解决了网站的高扩展性存储问题，简单的分区功能已经不能满足LinkedIn的需要。Voldemort使用Java编写，因此借助Java的跨平台特性，它也可以运行在Windows平台上。请阅读这篇文章了解如何在Windows平台上安装Voldemort。NoSQL项目机会
对于Microsoft世界来说这是一个激动人心的时刻，但目前Microsoft阵营采用NoSQL的节奏还非常慢，因对机会也比较多，如果能开发出优秀的NoSQL托管存储解决方案，一定会很受欢迎。
ESENT分布式数据存储
关于ESENT，我能想到最恰当的比喻是，它是Microsoft世界的BerkeleyDB，鲜为人知，很少有.NET开发人员使用它，但它的性能和可靠性已经经受住了时间的考验。ESENT是一个原生支持Windows的嵌入式数据库引擎，它是CodePlex上的一个托管项目，最新的Windows版本已经内置了esent.dll。我做了一些测试，它的速度真是太快了，每秒可以执行大约10万次插入操作，够变态吧。关于性能的更多统计数字请看这里。
内存字典式分布式数据存储
内存字典式分布式数据存储和ESENT有点类似，但不同的是它的数据完全存储在内存中。他可以作为分布式缓存的基础，也可以跨一系列节点复制数据而实现持久化，任何时间只要有一个节点可用，数据都是可以访问的，Amazon或其它基于云的非持久化 服务器 解决方案可以完美地实现托管，我是这种解决方案的坚决支持者。
最后的想法
对.NET开发人员来说，使用NoSQL解决方案目前还有一些限制，但随时间的推移，肯定会有越来越多的NoSQL解决方案可供选择，作为一名.NET开发人员，我们也应该参与到这些项目中去，以期早日解决现在存在的问题，这也是.NET开发人员的一次难得的机会。
我认为能给Microsoft阵营介绍NoSQL解决方案是一件非常兴奋的事，以后我也将努力参与到这些项目中去，如果你也愿意成为一名志愿者，我们随时欢迎你。
原文名：NoSQL on The Microsoft Platform
【编辑推荐】
memcached和redis的区别
medis与Memcached的区别传统MySQL+ Memcached架构遇到的问题 实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题： 需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。 与MySQL数据库数据一致性问题。 数据命中率低或down机，大量访问直接穿透到DB，MySQL无法支撑。 4.跨机房cache同步问题。 众多NoSQL百花齐放，如何选择 最近几年，业界不断涌现出很多各种各样的NoSQL产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的问题，实际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的tradeoffs，在实际应用中做到扬长避短，总体上这些NoSQL主要用于解决以下几种问题 1.少量数据存储，高速读写访问。 此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。 2.海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。 3.这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。 前者是一个完全无中心的设计，节点之间通过gossip方式传递集群信息，数据保证最终一致性，后者是一个中心化的方案设计，通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log，然后定期compat归并到磁盘上，将随机写优化为顺序写，提高写入性能。 free，auto-sharding等。 比如目前常见的一些文档数据库都是支持schema-free的，直接存储json格式数据，并且支持auto-sharding等功能，比如mongodb。 面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。 Redis适用场景，如何正确的使用 前面已经分析过，Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-backed的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用Memcached,何时使用Redis呢?如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点： 1Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。 2Redis支持数据的备份，即master-slave模式的数据备份。 3Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。 抛开这些，可以深入到Redis内部构造去观察更加本质的区别，理解Redis的设计。 在Redis中，并不是所有的数据都一直存储在内存中的。 这是和Memcached相比一个最大的区别。 Redis只会缓存所有的 Key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计 算出哪些key对应的value需要swap到磁盘。 然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。 这种特性使得Redis可以 保持超过其机器本身内存大小的数据。 当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。 同时由于Redis将内存 中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个 操作，直到子线程完成swap操作后才可以进行修改。 使用Redis特有内存模型前后的情况对比： VM off: 300k keys, 4096 bytes values: 1.3G used VM on:300k keys, 4096 bytes values: 73M used VM off: 1 million keys, 256 bytes values: 430.12M used VM on:1 million keys, 256 bytes values: 160.09M used VM on:1 million keys, values as large as you want, still: 160.09M used当 从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。 在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。 这种策略在客户端的数量较小，进行 批量操作的时候比较合适。 但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。 所以Redis运行我们设置I/O线程 池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。 如果希望在海量数据的环境中使用好Redis，我相信理解Redis的内存设计和阻塞的情况是不可缺少的。
请问mongodb为什么比mysql效率高,求详细,
首先是内存映射机制，数据不是持久化到存储设备中的，而是暂时存储在内存中，这就提高了在IO上效率以及操作系统对存储介质之间的性能损耗。 （毕竟内存读取最快） 其次，NoSQL并不是不使用sql，只是不使用关系。 没有关系的存在，就表示每个数据都好比是拥有一个单独的存储空间，然后一个聚集索引来指向。 搜索性能一定会提高的。 第三，语言。 使用javascript语法进行操作更加高效、直接。 这些是MongoDB针对关系型数据库的效率要高的原因。 但是不能仅仅看重效率，这种数据库的设计带来的弊端也是有的。 例如数据关系的维护会带来很多冗余数据、客户端代码需要大量针对数据库进行的IO操作、数据挖掘难以实现等等。 所以，应当针对应用系统来选择合适的数据存储介质才是优先需要考虑的。
SQL Server中的时间函数有那些，最好举例说明?
SQL数据库中有各种不同的函数，下面为您介绍SQL中的时间函数，如果您是才接触SQL的新手，不妨一看，相信会对您有所帮助。 --基于时间SQL函数--getdate() --返回当前系统日期和时间。 select getdate()DateAdd--在向指定日期加上一段时间的基础上，返回新的 datetime 值。 DATEADD ( datepart , number, date ) --例：向当天的时间增加5天select dateadd(dd,5,getdate())datediff --返回跨两个指定日期的日期和时间边界数。 DATEDIFF ( datepart , startdate , enddate )--例：返回2005-01-01与当天有多少天select datediff(dd,2005-01-01,getdate())--把时间字段的数据变为年月Select Convert(Varchar(6),GetDate(),112)--字符串变时间select convert(datetime,left(@t,len(@t)-4)+:+left(right(@t,4),2)+:+right(@t,2))ISDATE--确定输入表达式是否为有效的日期DATEPART--返回代表指定日期的指定日期部分的整数DATEPART ( datepart , date ) --如：返回当前是几月select datepart(mm,getdate())DATENAME--返回代表指定日期的指定日期部分的字符串--datepart ,datename的区别：前者返回是整数，后者返回是字符串。
发表评论