|
【如内容违法或虚假，请联系上述邮件删除】这是我第二次为新项目深化调研NoSQL，也是第二次决议放弃NoSQL。跟我上次发表的“为什么选择运用NoSQL如此艰难”的结论一样，我们最终决议放弃NoSQL，运用传统关系型数据库。
我从上个帖子的许多评论中得出评价NoSQL的一大问题——其处置计划指向的中心是“取决于你的需求”。但固然需求明白，仍需求花时间调研并搞分明一个特定的NoSQL引擎能否正是你所需。有太多方面，你不可能评价一切的。更糟的是，你得费力的从engine-specific文档中解读出它能否能够完成你的目的，那些文档大多是相似选择关系型数据或者ACID的处置计划。
相比之下，假如运用关系型SQL数据库，大多数状况下，不论是哪种特定产品，你都能知道它的工作方式，不需求重复比对选择，也比较成熟稳定。选择RDBMS能大大降低做错误决议的风险。
NoSQL的吸收力在于具有可扩展性和超高吞吐量的才干。就算其扩展性真的优于RDBMS，但是理想世界的事实是，99%的应用程序都不会变卦数据模型。比如Stock Exchange，它是访问量最大的网站之一，它们的商品效劳器是运转在MSSQL上的。而且很难想象NoSQL需求多么庞大的存储空间，置办一个60-core、高达6TB内存的效劳器基本是不可能的。所以运用NoSQL的实践益处又是什么？
起初我以为无方式存储是NoSQL的一个优势，但我曾经改动了我这个观念。至少关于关系型页面应用程序，无方式只不过是在增加代码复杂度。此外，我喜欢结构，特别是数据结构。在数据归档、文件存储、或事情日志这类数据处置中无方式是很有用的，但是关于非社交类的页面应用程序却没有任何优势。
与关系数据库比起来，文档存储会使程序的每个部分都变得愈加复杂。关于那种能够将文件名作为key，文件内容作为value的平行文件存储（key-value数据库），NoSQL是很有优势的，你能够在这类文件中存储任何所需内容，读取的时分也会很便当，但这种存储很脑残。我的结论是，NoSQL在管理和优化所存储的文件时是十分复杂的，关于存储的数据内容它一无所知。关系数据库一切的智能操作NoSQL全都没有，你必需用代码来完成那些SQL自带的功用，这对大多数应用程序来说都是不合理的。
即便是建造NoSQL引擎的人也很难描画自己产品的用例，NoSQL的很多评论都在采购自己的产品，却并没有提供任何特别令人信服的理由。很少有SaaS应用程序用非关系型数据，理想状况是，RDBMS系统要比NoSQL系统多的多，一旦一切的炒作逐步中止，NoSQL引擎的数量降到合理的范围，NoSQL将会成为这些合理应用范围内的有用工具。在未来，我以为NoSQL能够成为SQL系统的构件而不是替代品，往常我依然坚持运用SQL。
成都学ui网 http://ui.ixueyun.com/ 搜集整理itarg1a(关注老榕树网络旗下“网络思维”微信公众号:wlsw360 (每天都有好文章)
本帖如有虚假或违法，请联系邮箱删除，本社区删贴不收任何费用，欢迎举报。老榕树社区属老榕树网络旗下网站，旨在为老榕树用户提供创业咨询、网站建设技术交流、源码下载、提供各种实用工具。如有部分帖子涉及违法、虚假，请你第一时间与社区联系，把需要删除的社区链接提供给我们，我们核实之后，第一时间删除。邮箱：125175998@qq.com | 
发表于 2017-3-13 10:52:01
收藏
分享
淘帖