如何筛选?(如何筛选日期范围)
612
2022-05-30
#1:您是否准备好接受开发人员/系统管理员的培训成本?
如果你是一家成熟的IT软件开发公司,那么你很有可能已经有了熟悉SQL的人。这个组不仅包括开发人员,还包括数据库管理员(DBA)。
除非您打算为新的NOSQL项目进行招聘,否则将会有对现有开发人员和DBA的培训成本。额外的培训也可能会延长项目交付日期。
一种简单的思考方式是:
计算您的团队成员(开发人员和DBA)拥有关系数据库技术的总年数。
计算出通过培训或新招聘获得经验相同NoSQL经验年数的成本。
最后,弄清楚你从这个成本中得到了什么。你的投资回报率?
在这个特定的项目中,这个团队的开发人员以前都没有NoSQL经验,但是有大量的SQL Server经验。使用NoSQL解决方案在培训中增加了大约1个sprint,当然,这也是由于缺乏经验和设计上的失误。
#2:您的数据事务是基于什么?或者,您需要什么级别的事务支持?
如果您的系统需要ACID属性,那么您最好还是坚持使用RDBMS解决方案。否则,您将花费大量的时间试图在您的应用程序/业务逻辑层复制ACID保证,并且您可能仍然没有RDBMS解决方案那么高效。
#3: 您需要Web/高可伸缩性吗?
总是在先计算出您需要什么样的可伸缩性。在这个特殊的例子中,我们正在为微软内部游戏工作室构建系统。
有10到15个游戏工作室正在考虑中——这取决于有多少注册用户使用这个系统
每个工作室最多有3-5个活跃的游戏标题。
每个游戏标题为三个环境存储遥测模式——开发、预生产(PPE)和生产
对于每个标题,将会有2-5个数据科学家同时修改游戏标题数据
每一个标题事件都有大约50 KB的max事件数据
我们被要求存储所有的版本——我们估计这个数字是1000除以一个标题的生命周期
有了以上粗略的估计,我们就可以计算并发性和存储需求:
总并发数 = 工作室数量 * 标题数量每工作室 * 用户数量每标题
= 15 * 5 * 5 = 375 并发用户
最大存储 = 工作室数量 * 标题数量每工作室 * 环境数量 * 事件存储大小每版本* 需要存储的版本数
= 15 * 5 * 3 * 50 KB * 1000 = 11250000 KB = 11.25 GB最大存储
SQL Azure支持1024个并发打开连接,并且能够很容易地支持并发需求。另外,在考虑云计算时,11.25 GB实际上是一个非常小的数字。
这个系统并不是下一个FaceBook或必应——那么NoSQL的路线真的值得吗?
#4:NoSQL解决方案真的能帮你省钱吗?
在纸面上,Azure表存储是一种更便宜的选择,因为它的每Gb数据仅为美分,而SQL Azure则在此期间收取大约5美元的数据。
但是因为我们系统的存储空间不会超过12 GB——这真的很重要吗?每月60美元是我们在同一个系统上花30分钟写代码的钱。
因此,在决定使用NoSQL仅仅是因为它的单位成本更低之前,先弄清楚节省下来的钱是否占了预算的很大一部分。
#5:你需要吸引风险投资吗?
有趣的是,硅谷对NoSQL有偏见。这是因为感觉上NoSQL被认为具有内在的可伸缩性,并且RDBMS被认为是不可伸缩的。记住,关键字是“感觉上”!
这种可扩展性的感觉可能会让投资者相信,你的软件正处于正确的轨道上,准备好接受大规模的采用,从而吸引他们的投资资金。
许多NoSQL公司本身就是风投公司,这也给他们带来了积极的偏见。
最后,围绕“NoSQL”的所有营销活动都有助于推动投资者对你的产品的正面情绪。
#6:你是在雇佣创业精神的人吗?
如果你打算雇佣创业精神的人,他们中的很多人可能已经有NoSQL的知识了。
然而,如果你不在一个主要的科技中心,那么获得这些人才的机会就很少了。您所在的区域可能有一个现成的RDBMS开发人员池——试图在这样的区域中招募NoSQL工程师和DBA可能会延迟项目交付日期,并且由于供应需求曲线,也会花费您更多的钱。
我的建议是与你的招聘机构/人力资源部门合作,对开发者进行市场调查,并将其纳入你的技术选择中。
#7:你的客户在下游使用什么技术?
考虑这样一个场景:您向客户交付分析数据。您正在使用NoSQL来存储分析数据。然而,您的一个客户决定坚持使用基于SQL的报告系统。
这对你来说意味着什么?
这意味着您现在需要将所有NoSQL数据转换为SQL格式,并通过Azure数据工厂等服务将其向下推到客户的SQL数据库。这是您需要承担额外的开发和运营成本。如果您的所有下游客户都在使用SQL,那么您需要认真地考虑是否使用NoSQL和做所有这些昂贵的数据转换对您的系统有意义吗?
#8:对于你的产品,可用性是否胜过一致性?
如果你正在建立一个像Facebook newsfeed这样的系统,你可能会希望这个系统是高可用性的,并且是最终一致。
另一方面,如果您正在构建一个银行系统(或者像我们的案例那样的模式存储),您可能希望支持强一致性,并放弃高可用性。
无论采用哪种方式,您都应该首先考虑CAP定理的含义,然后决定您的系统是否需要SQL或NoSQL解决方案。
#9:您是否预期对数据库模式进行大量更改?
如果您期望对数据库模式进行大量更改,就像移动应用程序、实时分析、内容管理系统等经常发生的情况一样,那么NoSQL解决方案可能就是一种方法。
您可以使用一个分区方案,它允许您以一种比大多数SQL数据库允许的更方便的方式更新您的数据库模式。
#10:你想用NoSQL来获得个人的充实/满足吗?
请不要这样做!
我曾见过一些人,他们只是迷恋于学习一个NoSQL系统,并将其放入他们的简历中。这并没有什么错——我对NoSQL技术也很着迷。
但是,请不要让这成为选择技术堆栈背后的驱动因素(有意识的或下意识的)。如果你愿意的话,你可以在自己的时间里学习。
谁赢得了数据库战争?
坦率地说 – 没有哪个玩家能赢者通吃!
在很多情况下,您可能需要SQL和NoSQL技术在同一系统中并存。 例如,如果您正在构建像Instagram这样的照片共享应用程序,则您的照片可能位于NoSQL数据库中,而您的登录/ ACL信息可能位于SQL数据库中。
---------------------------------------
本文转自无鳍的鱼博客51CTO博客
NoSQL数据库
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。