又一种数据库nosql (原来就是mapreduce,bigtable之类).
NoSQL会取代SQL数据库吗？
2010-03-30 10:10 | 10066次阅读 | 【已有73条评论】发表评论
关键词：新闻资讯 | 感谢liujiangCE的提供 | 收藏这篇资讯
最近有Twitter、Digg和Reddit等多家Web 2.0企业宣布从MySQL转而使用非关系型数据库（NoSQL）提供可伸缩的数据存储解决方案，引起了开发者对NoSQL的强烈关注。
NoSQL真的会完全取代关系型数据库吗？
对此，前Google工程师，Milo（本地商店搜索引擎）创始人Ted Dziuba最近发表标题惊人的博客“I Can't Wait for NoSQL to Die”，对NoSQL的适用范围进行了分析。他认为，NoSQL也会带来一连串的新问题，并不会成为主流，无法取代关系型数据库。
他的理由是：Cassandra等NoSQL数据库在使用上并不方便，比如，修改column family定义时就需要重启。而且NoSQL更适合Google那样的规模，而一般的互联网公司都不是Google，早早地去考虑Google那样的规 模的可扩展性，纯粹是浪费时间，存在巨大的商业风险。
他还透露，即使在Google，AdWords这样的关键产品也是基于MySQL实现的。
他在文中最后表示，NoSQL当然死不了，但是它最终会被边缘化，就像Rails被NoSQL边缘化一样。而DBA同学们也用不着担惊受怕，因为有钱招DBA的公司的决策者们都懂实际的生意是怎么回事儿。
Dziuba的文章因为言辞激烈，在社区里引起了强烈反应。
SQL数据库阵营赞同者大有人在。craigslist工程师、著名的MySQL专家Jeremy Zawodny表示，在读此文的时候，不时会心一笑。他说，NoSQL运动只是软件不断进化进程中的正常现象。关系型数据库也会继续发展，MySQL社区不断推出的XtraDB或InnoDB插件, PBXT, Drizzle都是证据。各种技术竞争的结果是，我们获得了更多解决问题的选择。
drizzle项目开发者Eric Day也表示，NoSQL有很多值得学习的，但是目前大部分实际项目的最佳选择还是关系型数据库。
NoSQL阵营当然不会坐视不理，Cassandra项目组的Eric Evans表示，Dziuba提到Cassandra修改column family定义的问题其实很容易解决。而且，NoSQL并不是要取代MySQL，事实上Twitter仍然在用MySQL。如果关系型数据库能够承担负荷，那就用好了；如果不行，请考虑NoSQL。
而德国知名博客Code Monkeyism则嘲笑Dziuba看起来并没有用MySQL做过真实项目，因为MySQL如果没有memcache，基本上无法应付网站项目。他认为，NoSQL将使SQL数据库边缘化，而且一个重要理由恰恰是可以节省DBA的开销。
digg的前任首席架构师现在也在创业的Joe Stump说，自己现在的创业项目就是用NoSQL，而且列举了一系列问题挑战SQL阵营。他表示，无论从可伸缩性、速度、成本各个方面来看，NoSQL都有SQL数据库无法企及的优势。
NoSQL
From Wikipedia, the free encyclopedia
NoSQL is a movement promoting a loosely defined class of non-relational data stores that break with a long history of relational databases and ACID guarantees.[1][2] These data stores may not require fixed table schemas, usually avoid join operations and typically scale horizontally. Academics and papers typically refer to these databases as structured storage.[3][4][5][6]
Notable production implementations include Google's BigTable and Amazon's Dynamo. However, there are also many publicly available open source variants including Apache HBase and Facebook's Cassandra.
Contents[hide] |
[edit] History
The term NoSQL was first used in 1998 as the name for a lightweight open source relational database that did not expose a SQL interface. Its author, Carlo Strozzi, claims that as the NoSQL movement "departs from the relational model altogether it should therefore have been called more appropriately "NoREL", or something to that effect".[7] The term was reintroduced in early 2009 by a Rackspace employee, Eric Evans, when Johan Oskarsson of Last.fm wanted to organize an event to discuss open source distributed databases.[8] The name was an attempt to describe the emergence of a growing number of non-relational, distributed data stores that often did not attempt to provide ACID guarantees, in reference to the popular naming scheme for classic relational database systems: MySQL, MS SQL, PostgreSQL, etc.
[edit] Architecture
Typical modern database workloads including scaling out to data sets (e.g. Digg's 3 TB for green badges,[9] Facebook's 50 TB for inbox search or eBay's 2 PB overall data), per-server performance, and rigid schemas.[citation needed]
NoSQL systems often provide weak consistency guarantees such as eventual consistency and transactions restricted to single data items, even though one can impose full ACID guarantees by adding a supplementary middleware layer.[10] Not providing relational capabilities makes it a lot easier to scale data storage by not having to pay the costs associated with relational guarantees that may not be needed by the project that uses the database.
Several NoSQL systems employ a distributed architecture, with the data being held in a redundant manner on several servers, often using a distributed hash table. In this way, the system can be scaled up easily by adding more servers, and failure of a server can be tolerated.[11]
Some NoSQL advocates promote very simple interfaces such as associative arrays or key-value pairs. Other systems, such as native XML databases, promote support of the XQuery standard.[citation needed]
[edit] Taxonomy
 | This section may require cleanup to meet Wikipedia's quality standards. Please improve this section if you can. (March 2010) |
NoSQL implementations can be categorised by their manner of implementation:
- Neo4j
- Swarm
- Key/value store on disk
- Key/value cache in RAM
- Eventually‐consistent key‐value store
- Ordered key-value store
- Tabular
- Tuple store
- Unknown
[edit] See also
- Structured storage
- List of object database management systems
- Triplestore
- CAP theorem
- DataNucleus
- Java Data Objects
- 上一篇 C++ ui framework.
- 下一篇 Cmake