外刊IT评论

SQL数据库的终结(第三篇)?

在 “SQL 数据库的终结? (第一篇/共三篇)” 里我简要介绍了一下关于SQL语言和关系型数据库的背景知识，包括它的过去和将来，介绍了一些以隐藏数据库编程的复杂度为目的模式框架的流行和NoSQL 数据库的兴起。在 “SQL 数据库的终结? (第二篇)” 里，我将介绍一些现有的开源的或非开源的NoSQL数据库。在本篇里，我将会告诉大家一些因特网上关于 NoSQL 的资料，过去和将要发生的事件，以及一些关于本文前两部分的相关评论。

如果你想收集更多的关于 NoSQL 和 非关系型数据库的信息，请参考下面的一些网站，博客和文章：

下面是几个将要举行的和最近刚举行的关于 NoSQL 的会议，架构师和开发人员能从这些会议里得到很有价值的信息。下面列出的只是其中的一部分：

看看那些在 Digg 上和在Computerworld 博客上访问者留下的评论和建议是很有必要的。感谢那些参与关系和非关系数据库相关讨论的朋友。这里是从那些评论里节选的一部分：

  • Emil Eifrem (Neo4j) commented: “You talk about scaling to size and
    handling Facebook’s 100M user profiles. That’s an important use case and
    one that for example a key-value store handles brilliantly. But it
    turns out most companies aren’t Facebook. You can categorize the four
    emerging categories of NOSQL databases (key-value stores, column family
    stores, document dbs and graph databases) along the axes of scaling to
    size and scaling to complexity. For more information about that, see this
    blog post    . Graph databases (like e.g. Neo4j,
    which I’m involved with, or Sones)
    excels at representing complex and rapidly evolving domain models and
    then traversing them with high performance.”
  • Mongo-DB Developer commented: “We have seen the most common use case
    to date being use of nosql solutions as operational data store of web
    infrastructure projects. By operational, I mean, problems with real time
    writes and reads (contrast with data warehousing with bulk occasional
    loading). For these sort of problems these solutions work well and also
    fit well with agile development methods where the somewhat ‘schemaless’
    (or more accurately, columnless) nature of some of the solutions, and
    the dynamically typed nature of the storage, really helps.”
  • Peter R commented: “I have already seen, in the domain I work in,
    the movement away from straight up SQL databases. XML databases are one
    technology that will be stealing a lot of SQL’s thunder (if they haven’t
    already). Do I think SQL will ever die? No. But the key is that there
    will be/are more options that need to be thought about when designing a
    system now.”
  • Anonymous commented: “I agree object databases have a purpose. They
    are great for large datasets that need to be replicated and called by a
    key. However SQL provides a very important capability and that it is to
    be able to query data across a number of datasets very efficiently, this
    will be very hard to duplicate in a simple key value database.”
  • Johannes Ernst commented: “One of the difficulties for “normal”
    developers with many of the NoSQL technologies that you’ve described so
    far has been the learning curve and the additional work required: e.g.
    it’s easy and everybody knows how to put “every customer can place one
    or more orders” into a relational database, but what if the only thing
    you have is keys and opaque values? Compared to many other NoSQL
    alternatives, graph databases provide a high level of abstraction,
    freeing developers to concentrate on their application, while still
    bringing many of the same NoSQL benefits.For example, in InfoGrid (http://infogrid.org/), a project I’m
    involved in, you can define “Customer” and “Order” and their
    relationship, and the InfoGrid graph database takes care of storing and
    retrieving data and enforcing the relationship. In our experience, that
    makes graph databases much more approachable to developers than many
    other NoSQL technologies.”
  • Database-ed commented: “The problem is that when folks think about
    storing information that they need to retrieve, they are so ingrained to
    SQL that they fail to think of other means. The Facebook example is a
    case in point. Who is ever going to ask for an accurate report of every
    user in Facebook? If you miss something the first time you go looking,
    you can always present it later. The end user doesn’t know you lost it,
    they assume it didn’t exist at the time and now it does. Yet you still
    need to store the data for easy retrieval. One problem with SQL is that
    it ties you into the relationships. Facebook is about letting people
    build the relationships based on the fields they want to build them on,
    not the ones you might think of. I know, it can be done within the
    confines of SQL, but it is a lot harder to do when the size gets large.”
  • Raptor007 commented:
    “Some tasks that are poorly serviced by SQL may get switched over to a
    new method, but other implementations that are perfectly suited to SQL
    will continue using it. As they quoted Eric Evans in the article, “the
    whole point of seeking alternatives is that you need to solve a problem
    that relational databases are a bad fit for.”
  • Miracle Blue commented: “While I highly doubt there’s going to be any significant
    migration away from SQL and the like any time soon, I think more web
    developers will start experimenting with data stores and other data
    solutions as we move further into the cloud.”
  • TheUnGod commented:
    “And as companies turn to ask their SQL DBAs what they think of this,
    they’ll say “lets stick with SQL.” Honestly, there are so many people
    that support SQL right now that will not switch any time soon this
    article is just bogus. You can’t make a switch like that until people
    can support it properly.”
  • SteelChicken commented: “Document centric is pretty dumb if you plan on doing any
    sort of analytics and data mining. Great for workflow and such.”
  • Angusm commented: “The
    significance of the NoSQL movement is that it adds new tools that offer
    better solutions to specific problems. The future probably belongs to
    NoSQL in the sense of ‘not-only SQL’, rather than ‘no SQL’. Don’t
    imagine that NoSQL solutions offer a free lunch though. I had an
    educational experience when I changed a view definition in a CouchDB
    data store and my first trivial query took an hour to come back. CouchDB
    can be pleasingly fast when all its indexes are built, but if you have
    to rebuild those indexes from scratch … well, let’s just say that’s
    not something you want to do on a live client-facing site.”
  • Afex2win commented: “digg is one of the bigger proponents of
    Cassandra, a distributed data store in the vein of which the article is
    talking about. http://about.digg.com/blog/looking-future-cassandra“
  • Drmangrum commented:
    “SQL will be around for awhile. It’s good at doing what it was designed
    to do. However, there are many times when people use SQL simply because
    there is nothing better out there. As data complexity rises, a new
    method for accessing and persisting that data will have to be
    investigated. Part of the problem with many of the alternate solutions
    is that few people know how to use them.”

数年以后，我估计我们大多数还是要依赖于关系数据库和SQL。我当然有愿望，我将会不断的研究寻找更好的方式去弱化和封装数据访问操作。一直以来， 任何工程决策都是跟用户和业务需求相适应的。对于以后的软件工程来说，我相信，
我们一定会找到一个合适的非关系型数据存储产品。你是否正在使用非关系型数据库呢？你是否已经放弃了SQL和关系型数据库呢？你是否正在把你的数据转移到 一个公共的或私有的云数据库里呢？请发表评论。

编程就是人生！

分享这篇文章：

你也许会喜欢这些文章：

  1. 龙纹身女孩和SQL
  2. 编程趣事：SQL Error 191
  3. SQL数据库的终结?
  4. 【三分钟小测试】你对SQL性能优化知识知多少？
  5. 如何定义NoSQL
  6. SQL数据库的终结(第二篇)?
  7. 我的老公编程有瘾
  8. 是什么造就了伟大的程序员？
  9. 我在Facebook的这三年
  10. 软件架构师不等同于资深程序员

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据。