业务系统用KV数据库可以吗?

mirrorspace 2020-11-27 03:54:50
如题
业务系统大多数都用关系DB,建表,建实体类,写数据查询程序,
那么如果使用KV数据库,对比使用关系DB,会有哪些好处和不好的地方呢.

主要看KV数据库的查询速度比较快了
...全文
8619 12 打赏 收藏 转发到动态 举报
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
mirrorspace 2020-12-02
  • 打赏
  • 举报
回复
感谢回复
引用 11 楼 生财 的回复:
业务系统当然可以使用KV数据库,但是默认是特定场景下的. 正常情况下使用关系型数据库. 如秒杀,点击,等需要快速反馈实时数据的情况下.
特定
生财 2020-11-30
  • 打赏
  • 举报
回复
业务系统当然可以使用KV数据库,但是默认是特定场景下的. 正常情况下使用关系型数据库. 如秒杀,点击,等需要快速反馈实时数据的情况下.
xuzuning 2020-11-28
  • 打赏
  • 举报
回复
所谓关系 就是键值对,对于你的 KV数据库,在联合考虑10 个键 时,速度也很快吗?如果是,为什么不?
  • 打赏
  • 举报
回复
.net 框架有多套高速缓存,例如 MemoryCache;也有多种丰富的 Hash 字典,例如各种实现了 IDictionary<string,object> 的类型等等。实际上随便写一个简单的服务,就能随便发布一个 k-v 服务。

大多数普通程序员很懒,稍微不注意基本上就会沦落为各行各业中最懒最贪的一群,自己不“设计、创造”,只有少数精英运用程序设计知识来集成各种从单片机到大型机的 IT 资源。很多时候普通程序员自己选择的是垃圾的开源东西,为了容易跳槽,而不是为了更好地设计和架构产品。
mirrorspace 2020-11-28
  • 打赏
  • 举报
回复
这个就复杂了,如果要引用10个关系键,那真的不合适KV,关系太复杂了.
引用 8 楼 xuzuning 的回复:
所谓关系 就是键值对,对于你的 KV数据库,在联合考虑10 个键 时,速度也很快吗?如果是,为什么不?
mirrorspace 2020-11-28
  • 打赏
  • 举报
回复
看sP1234的话, 感觉KV数据库实际上不能算真正的数据库,它的最大作用还是当作缓存,对于有复杂数据关系的业务是无能为力的,即使把数据结构设计的尽量符合KVDB的使用方式,也任然不能满足要求.
引用 5 楼 以专业开发人员为伍 的回复:
如果你学数据库原理或者使用正规课程时学过“数据库第一范式”就会知道,关系数据库自然是讲求唯一主键作为key来查询整个记录的。纠结k-v其实没什么意义!说“nosql数据库”还差不多,说“k-v”数据库就好像是说勺子就不是餐具一样。 nosql不使用关系语言,不支持事务,不能轻松地读写一条记录的任意字段组合(而是必须整个valu对象或者文档读写),甚至不能创建与合理运用除k以外的有效索引、一致性约束、级联删除和级联更新等等,当然也没有触发器存储过程等,也没有sql关系查询和查询编译技术、没有日志系统、没有各种对象管理、没有管理客户端工具、没有权限系统。等等等等。 把简单的缓存当作“数据库”,有其简单化的“好处”,但是也有滥用的标题党的意味。
  • 打赏
  • 举报
回复
许多应用根本用不起传统的商用关系数据库系统。例如许多接入服务主机需要在内存中同步某些状态信息,这些业务对性能处理速度有基本的要求,不是什么关系数据库所能承载的,必须是内存变量级访问幅度,但是又需要集群同步,那么肯定会首先想到使用个什么内存k-v服务程序,而且还是开源的。这是数据库?这其实只是外部缓存服务。
  • 打赏
  • 举报
回复
如果你学数据库原理或者使用正规课程时学过“数据库第一范式”就会知道,关系数据库自然是讲求唯一主键作为key来查询整个记录的。纠结k-v其实没什么意义!说“nosql数据库”还差不多,说“k-v”数据库就好像是说勺子就不是餐具一样。

nosql不使用关系语言,不支持事务,不能轻松地读写一条记录的任意字段组合(而是必须整个valu对象或者文档读写),甚至不能创建与合理运用除k以外的有效索引、一致性约束、级联删除和级联更新等等,当然也没有触发器存储过程等,也没有sql关系查询和查询编译技术、没有日志系统、没有各种对象管理、没有管理客户端工具、没有权限系统。等等等等。

把简单的缓存当作“数据库”,有其简单化的“好处”,但是也有滥用的标题党的意味。
八爻老骥 2020-11-27
  • 打赏
  • 举报
回复
看业务需要啊,数据结构复杂就用关系数据库,单纯的并发量比较高就用KV数据库。不闲复杂就混合着用。
mirrorspace 2020-11-27
  • 打赏
  • 举报
回复
道理很对啊, 我就没在项目里用果KV数据,但是发现KV真的有点多,不知道用于业务CRUD项目,会有哪些坑和解决方法
  • 打赏
  • 举报
回复
看需求,看需求
wanghui0380 2020-11-27
  • 打赏
  • 举报
回复
我们说现在开发是混合模式开发 so,连编程语言我们都不会要求统一,你认为我们会纠结数据库统一么 所以问题的关键不是kv数据库如何。又玩个这个vs那个,这个好处,那个不好。这个快那个不快 重要的问题(当然我不想说3遍) 1.你分析你自己的业务,拆分你的业务,自己评价那些适合关系,那些适合kv,甚至有些东西俺们说用neo4j这种图数据更适合 虽然我不想说“满脑袋只有CURD,ORM”,但是俺们neter还是应该回归编程的本质,不要总跑偏

110,536

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • Web++
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧