这是一个创建于 165 天前的主题，其中的信息可能已经有所发展或是发生改变。
我刚加入一家新公司，发现他们在生产环境中同时使用 SQL （关系型）数据库和 NoSQL 数据库。大约 90%的数据（尤其是核心内容）存储在 SQL 数据库中，而用户相关数据（例如个人资料、访问权限等）存储在 NoSQL 数据库中。然而，这些数据源之间的所有连接操作都是在应用层用代码处理的，这使得即使是简单的查询（统计具有特定属性的用户数量）也变得比实际需要的更复杂。据我所知，这个公司的业务模型是高度关系型的，将所有内容保留在 postgreSQL 中可以显著简化架构，并使后端更易于长期维护。在这种情况下，我很难看出在新项目中同时使用 SQL 和 NoSQL 有什么实际好处。采用这种方法真的有什么好处吗？好像前端在 NoSQL 方面更有经验，所以他们选择了 NoSQL ，然后转向 SQL 来处理应用程序内容。我注意到的问题是，由于架构原因，原本需要 2 周的新功能后端开发却需要 2 个月
 | 1 Martin123123 165 天前 实际上业务系统没必要关联这么多用户具体信息把，只需要一个用户唯一 id ，不太理解你们为什么会从 2 周 -> 2 月 这种场景可能是计划把 user 相关的东西抽出来做 sso |
 | 2 duzhuo 165 天前 听起来像是历史遗留的屎山 |
 | 3 niubiman 165 天前 这个问题的最好答案还是得问项目的架构负责人，单从你的描述看不出来这么设计的缘由，或许有一些历史遗留原因，也或许是有一些未来业务的考量，都不好说 |
| 4 niubiman 165 天前 @Martin123123 我们目前就是把用户抽离出来做了 sso ， 但是这种做法也不一定非要采用 nosql |
 | 5 qxdo1234 165 天前 要看数据量有多大了，是否值得用上 noSQL 了。应该不至于用个 noSQL 就足以把需求时间从 2 周拉长到 2 个月吧？ |
 | 6 coderzhangsan 165 天前 我以为是用 nosql 做数据缓存，没想到是 nosql 和 sql 各自存储和维护相关数据，确实有点坑啊。 "好像前端在 NoSQL 方面更有经验，所以他们选择了 NoSQL 。"，这话的意思让我像想到了另外一句话："前端娱乐圈"。 |
 | 7 xiaomushen 165 天前 nosql 在业务系统中，只适合做数据缓存 |
 | 8 fffq 165 天前 后端是不是以前前端兼着干的？ |
 | 9 iugo 165 天前 如果用 pg, 可以全部数据都在 SQL 上, 部分频繁的读操作或者简单且临时的业务配合 NoSQL 使用. NoSQL 在性能上是有优势的, 尤其是可以比较容易做到分布式, 从而提高并发读写性能. |
| 10 Martin123123 165 天前 @niubiman 描述的只是一种可能性，楼主说的场景就算用户表不是 nosql 也会存在的，真正的原因只有架构负责人才知道，一开始就是全部用的 mongo 踩坑了才陆续把需要优化的地方挪到 pg 这种情况也正常 @coderzhangsan 具体得看业务是怎么实现的，云函数之类的用起来也方便 但是我不认为两个库会导致开发周期相差这么长 |
 | 11 iamzcr 164 天前 1 、可能是历史问题。 2 、nosql(mongodb)的场景常用于第三方 api 接口返回的不确定性数据格式，如果某些第三方数据返回的数据格式更新比较频繁，而这些接口的数据又不是那么重要，mongodb 是一个很好的存储方式。 |
Select Language