如果用 sql 数据库查询数据，不能使用 join 语句，在应用层进行 join，那还有必要使用 sql 数据库么？
tctc4869 · 2020-06-03 17:37:25 +08:00 · 1771 次点击这是一个创建于 1618 天前的主题，其中的信息可能已经有所发展或是发生改变。
假如数据查询要求在数据库不能使用 join，只能在程序里 join，那还有必要使用 sql 数据库么？
把一个服务拆分多个服务，部署在不同的服务器节点上，每个服务的数据库只当数据存储的话，还有必要都使用 sql 数据库？如果还有用，那就是服务内部还有 left join 需求吧？
这个情况下，如果不用 sql 数据库，那是不是可以考虑文档数据库，kv 数据库，列式数据库了？
各位做过微服务的程序员，你们拆分的每个服务还都用 sql 数据库？如果是，那为什么用？服务内部的数据库查询还有 left join 需求？还是用 sql 数据库用习惯了，对其他数据库不了解？如果用了其他的 nosql 数据库，那用的是哪个？
 |
1
wysnylc 2020-06-03 18:37:13 +08:00
那就看你有没有钱买阿里云的 redis 或者 mongodb 之类的 nosql 数据库了
别说自己搭,就自己那点运维实力就省省吧后期炸一次全完了 |
 |
2
chendy 2020-06-03 18:48:08 +08:00
不给 join 就不如用 mongo 这种了，不用 join 直接全部返回…
|
 |
3
wshcdr 2020-06-03 18:50:32 +08:00
所以服务的拆分就很重要了，另外就是设计上要考虑冗余
|
 |
4
yty2012g 2020-06-03 19:02:49 +08:00
现在只有内部管理系统的使用关系型数据库比较多。对外服务的基本是全面 Redis，内部量级的大的数据需求基本上 ES，更多的为了避免 join 采用宽表的设计，例如使用 HBase 或者 ES 这样的。
|
 |
5
cstj0505 2020-06-04 08:02:56 +08:00 via Android
mysql ？除非你先 join 好，否则自己在程序 join 没数据库快吧，数据库至少有好几种 join 方式，可以最优选择
|
 |
6
saberlong 2020-06-04 08:06:22 +08:00 via Android
数据库采用磁盘页作为树节点的方式，是内存资源，性能，数据持久化各方面平衡的实现方式。但这个开发起来非常麻烦。你去到 github 上找能持久化的树，要么是 mmap 方式限制非常大，要么是限制了 k,v 的数据或长度，或者是 leveldb 之类非常不稳定。leveldb 的定期合并整理在数据上来时会占用大量内存，与每个存储文件的大小有很大关系。这点我在拿 influxdb 的 tsm 存储引擎测试时验证。而 redis 之类主要只是内存存储，不符合持久化要求。因为业务需求，自己开发了一个，花费大量时间修复 bug 后才可用。仍然存在超长 value 后删除时，页不能完全回收的 bug 。外加事务支持也是很多其它存储不一定有的
|
 |
7
tctc4869 OP 在分库分表的情况下，你能在数据库 join 么？
|
 |
8
weizhen199 2020-06-04 09:34:13 +08:00
照架构说的做啦
|
Select Language