如果用 sql 数据库查询数据，不能使用 join 语句，在应用层进行 join，那还有必要使用 sql 数据库么？

[tctc4869]

假如数据查询要求在数据库不能使用 join，只能在程序里 join，那还有必要使用 sql 数据库么？

把一个服务拆分多个服务，部署在不同的服务器节点上，每个服务的数据库只当数据存储的话，还有必要都使用 sql 数据库？如果还有用，那就是服务内部还有 left join 需求吧？

这个情况下，如果不用 sql 数据库，那是不是可以考虑文档数据库，kv 数据库，列式数据库了？

各位做过微服务的程序员，你们拆分的每个服务还都用 sql 数据库？如果是，那为什么用？服务内部的数据库查询还有 left join 需求？还是用 sql 数据库用习惯了，对其他数据库不了解？如果用了其他的 nosql 数据库，那用的是哪个？

[wysnylc]

那就看你有没有钱买阿里云的 redis 或者 mongodb 之类的 nosql 数据库了
别说自己搭,就自己那点运维实力就省省吧后期炸一次全完了

[chendy]

不给 join 就不如用 mongo 这种了，不用 join 直接全部返回…

[wshcdr]

所以服务的拆分就很重要了，另外就是设计上要考虑冗余

[yty2012g]

现在只有内部管理系统的使用关系型数据库比较多。对外服务的基本是全面 Redis，内部量级的大的数据需求基本上 ES，更多的为了避免 join 采用宽表的设计，例如使用 HBase 或者 ES 这样的。

[cstj0505]

mysql ？除非你先 join 好，否则自己在程序 join 没数据库快吧，数据库至少有好几种 join 方式，可以最优选择

[saberlong]

数据库采用磁盘页作为树节点的方式，是内存资源，性能，数据持久化各方面平衡的实现方式。但这个开发起来非常麻烦。你去到 github 上找能持久化的树，要么是 mmap 方式限制非常大，要么是限制了 k,v 的数据或长度，或者是 leveldb 之类非常不稳定。leveldb 的定期合并整理在数据上来时会占用大量内存，与每个存储文件的大小有很大关系。这点我在拿 influxdb 的 tsm 存储引擎测试时验证。而 redis 之类主要只是内存存储，不符合持久化要求。因为业务需求，自己开发了一个，花费大量时间修复 bug 后才可用。仍然存在超长 value 后删除时，页不能完全回收的 bug 。外加事务支持也是很多其它存储不一定有的

[tctc4869]

在分库分表的情况下，你能在数据库 join 么？

[weizhen199]

照架构说的做啦