[请益] 一个以上的db

楼主: groza (狗煞)   2018-10-08 11:07:53
各位先进 打给贺
小弟有幸进入一间流量还算大的公司
看完几个主要的DB后些问题想请问各位大大
他们将许多资料表再拆成许多库
例如:
DBUser
-user_users
-user_config
-user_logs
DBProduct
-prod_items
-prod_category
-prod_log
目测总数据库大约有十来个
表约近百张
请问这样的设计和将全部表放在同个DB内有何差异?
作者: acer1832a (Mike)   2018-10-08 11:18:00
安全,避免误删。我有看过有两个系统用同一个数据库用Table的prefix去区分;结果其中一个系统在做debug时把所有Table都删了,删完才想到有另一个系统的资料
作者: testPtt (测试)   2018-10-08 11:29:00
通常是不需或不希望用join的资料
作者: sweet00914 (别理我)   2018-10-08 11:34:00
风险及效能考量
作者: qrtt1 (有些事,有时候。。。)   2018-10-08 11:56:00
听起来像 event sourcing 与 CQRS 架构
作者: alihue (wanda wanda)   2018-10-08 12:02:00
https://goo.gl/KZHX4o正确答案可能依每家数据库而不同
作者: f496328mm (为什么会流泪)   2018-10-08 12:47:00
流量算大,那分开来有助于效能提升举例来说,全部有10亿笔datauser_users 只有1000笔,那我要拿里面的 data还要先从 10 亿中去找到其中的 user
作者: alan3100 (BOSS)   2018-10-08 13:16:00
分开才是正常的吧... 合在一起要不是资料太少不然就塞康如果同样的资料量全放在一起,会慢又难维护又超多index
作者: zo4j4 (happiness)   2018-10-08 14:17:00
感觉没有一个专业dba的答案欸…XD
作者: neo5277 (I am an agent of chaos)   2018-10-08 14:33:00
分库分表又名蓝色蜘蛛网这种架构满适合做成CQRS然后走API针对的是资料本身吧金融业跟资料为主的常这样做
作者: mintu (MinTu)   2018-10-08 18:03:00
蛮好奇如果这是在某些情况中蛮常见的架构,在开发环境中一样要有同样的架构吗?还是可以由设定去做要读哪个 DB 就好
作者: ripple0129 (perry tsai)   2018-10-08 19:38:00
九成以上都是效能考量为主啊,高流量下单一DB容易打到挂点吧,主要也都使用高速可完成的sql,商业逻辑复杂度都靠后端程式码解决开发环境不是问题啊,一定是设定档host+db_name,开发环境下host相同就好
作者: banqhsia (BEN)   2018-10-08 22:50:00
还有依照帐号名称分表的勒
作者: AvatarH (Avatar Hsieh)   2018-10-09 17:39:00
请问在不同数据库之间的table可以join或union吗?
作者: mathrew (Joey)   2018-10-10 07:44:00
可以啊
作者: forewero (木日一)   2018-10-10 15:05:00
不同数据库可以做join,藉这个题往下问一个问题,实务上会直接在SQL跨db join还是拉到orm做join?(ex.EF+LINQ)
作者: neo5277 (I am an agent of chaos)   2018-10-10 16:28:00
我是都orm做
作者: THEWORLDS (天下)   2018-10-10 18:31:00
分布式运算,主要是可能有很多不同站点但服务是一样的你又想要让他们所有资料总结,就会设很多个db,设计大概会是资料进去以后固定TRIGGER或跑PROCEDURE分别在抓到别的表格上面去做总结查询某些资料的话就设计个动态db去另外一个db查询,这样整个效率会高非常多又简单,大概是这样
作者: zo4j4 (happiness)   2018-10-11 19:00:00
楼上正解

Links booklink

Contact Us: admin [ a t ] ucptt.com