The rise of NoSQL --ZT

典

Because of the internet, data has grown to a point where relational databases are not the right fit . Not all data are relational. Hence several companies (Google, Facebook, Amazon…) start building their own datastore.
2010, in my opinion, was the year of scalability, big data, and the rise of the NoSQL movement.
NoSQL was first defined as NO to SQL. But later was changed to Not Only SQL, because SQL still excels in some area while NoSQL DB will kick SQL’s derriere in some. The term “NoSQL” typically refers to non-relational, distributed databases that do not require fixed-table schemas.
NoSQL databases are schema-less, schema-full, schema-mixed. And the best part, they don’t require any JOINs. What? Yes sir! No JOINs

Column-Oriented DB. It contains one extendable column of closely related data rather than sets of information in a strictly structured table of columns and rows as is found in relational databases. In this family there is Cassandra, HBase.
Document Based DB. Data is stored and organized as a collection of documents. Users are allowed to add any number of fields of any length to a document. They tend to store JSON-based documents in their database. In this class, there is MongoDB, CouchDB.
For a full list of NoSQL DB, CLICK HERE (you see what I did here?)
http://developers.redventures.com/2011/05/the-rise-of-nosql/

黑山老妖

oodb 已经就有了很多年了。
oracle 里面的column 也早就可以放object了。

黑山老妖

还有我觉得如果rational db 设计得当还是可以解决绝大多数问题。把所有的东西都放到数据库里未必是好事。

典

可不可以这么看，因为以下这些因素
1）facebook(使用noSQL Database) 的崛起，
2）google / amazon 相继推出容易使用的document DB,
3)  Cloud的兴起及逐步普及
4）mobile应用的普及
5) JSON的逐步普及
以上这些条件及趋势，对NoSQL DB非常有利，意味着未来一段时间，会有更多的应用舍弃Oracle DB / SQL DB, 而采用NoSQL DB.

采用NoSQL DB, 将对软件开发的模式产生很大的影响。

典

最近的两个小项目中，都使用了 Document的概念，技术是很老的技术，就是在SQL Table中用一个字段保存XML 文档，一个XML 文档就是一个document所需要的全部数据。

比如说一个项目中的agreement，因为涉及到太多的东西，如果用普通normalization / denormalization去做，可能要10来个表，还要建立表之间的关系。最后决定完全忽略这些东西，直接用XML document表示。
整个项目的开发变成了客户端开发(javascript / XML), 中间层和数据库端的开发微乎其微。而且非常灵活没有约束，客户端想加些字段，加些层（类似表），都不影响数据库及中间层

当然能不能这样做也有些先决条件。

[ 本帖最后由 典 于 2011-8-28 11:58 编辑 ]

混不到坑的萝卜

原帖由 典 于 2011-8-28 11:56 发表
最近的两个小项目中，都使用了 Document的概念，技术是很老的技术，就是在SQL Table中用一个字段保存XML 文档，一个XML 文档就是一个document所需要的全部数据。

比如说一个项目中的agreement，因为涉及到太多的东西，如果用普 ...

你要是写一个内容足够丰富的文档介绍一下你的这个项目，我愿意付出200足迹分给你。(paopaobing(84))

黑山老妖

原帖由 典 于 28/8/2011 11:56 发表
最近的两个小项目中，都使用了 Document的概念，技术是很老的技术，就是在SQL Table中用一个字段保存XML 文档，一个XML 文档就是一个document所需要的全部数据。

比如说一个项目中的agreement，因为涉及到太多的东西，如果用普 ...

换汤不换药。后台还是原来的后台，只不过换了中间部分。

典

http://www.marketresearchmedia.com/2010/11/11/nosql-market/
最近，搞NoSQL DB的公司纷纷获得投资者青睐
Couchbase: 14million
Clustrix:12million (total 30million)
10gen(mongo db):6.5million
Riptano: 2.7million
membase: 15million
可以预见，IBM / 微软和oracle有一天会耐不住而收购某家NoSQL公司

典

原帖由 黑山老妖 于 2011-8-28 12:15 发表

换汤不换药。后台还是原来的后台，只不过换了中间部分。

是啊，现在还没有机会在公司直接用NoSQL DB, 以后如果有合适的项目就要玩玩。

典

原帖由 混不到坑的萝卜 于 2011-8-28 12:10 发表

你要是写一个内容足够丰富的文档介绍一下你的这个项目，我愿意付出200足迹分给你。(paopaobing(84))

真写出来你会失望，
其实就是把一个普通的asp.net的小项目，变成javascript项目了，90%以上的coding都是javascript了，server 端 / 数据库端没多少需要做的了。
因为数据库不是真正的BSON document, 而是传统的XML Document, 所以页面端用了xslt,

fyang1024

NoSQL 诞生于那些数据量超级大的公司，因为传统数据库是无法胜任它们的要求的，当数据量大到一定级别，查询性能下降明显，Join查询是慢的主要原因，于是NoSQL（No Join）就自然产生了，这是俺的一点浅薄的理解。

收路费

原帖由 典 于 2011-8-28 11:56 发表
最近的两个小项目中，都使用了 Document的概念，技术是很老的技术，就是在SQL Table中用一个字段保存XML 文档，一个XML 文档就是一个document所需要的全部数据。

比如说一个项目中的agreement，因为涉及到太多的东西，如果用普 ...

这些项目里对reporting的需求高吗？你们怎么解决？

收路费

我对NoSQL的浅薄理解就是一大hashtable
如果往后发展到access SSD的速度跟access RAM的速度一样的时候 对软件开发又会是一个怎么样的深远影响呢

典

原帖由 收路费 于 2011-9-1 07:46 发表

这些项目里对reporting的需求高吗？你们怎么解决？

这是个要考虑的因数之一，

对我们来讲，这个项目里这一部分的report要求不高，而且我们想好了应对措施， 因为
reporting是在另外1台server上，业务数据replication过去后，可以再分解成一些中间表，如果实在要求的话，数据量不大的时候可以直接query xml data.

典

有意思的是，因为项目的prototype直接在html/xml/javascript的状态下做，没有约束，
在BA阶段跟business开会，开一次会就改这些html/xml/javascript, 下次再做resentation

BA会开得差不多了，开发阶段其实也接近尾声了。所以开发速度比较快。

Limitless

做过几个nosql的项目，不是什么大项目，来说说我的看法：
nosql不是什么新鲜玩意，只是一种应用层的数据储存方式，如果数据量不是很大的话，完全可以用普通的关系数据库模拟，就像楼上说的，建一个字段或者新建个表直接保存xml或者json数据，这样可以在不用改动原数据库和程序的情况下增加新的功能，数据通过rdbms提取出来再通过程序处理nosql的数据。