1
cobola 2015-05-27 11:08:23 +08:00
哈哈 你们用的是mysql么?
oracle? 哈哈哈 |
2
superbear 2015-05-27 11:11:12 +08:00
更新一个字段啥的,还得全部取出,编辑后再组装。。。
|
3
finab 2015-05-27 11:12:13 +08:00 1
既然如此,干嘛用数据库? - -
|
4
superbear 2015-05-27 11:13:26 +08:00
如果用的是Mysql的话,感觉这样还不如用Mongo...
|
6
est 2015-05-27 11:16:43 +08:00
本来打了很多字,详细分析这种json保存为文本blob到一个字段里的优缺点,结果还是删了。
三个字:然卵用 |
7
scalala 2015-05-27 11:18:50 +08:00 2
这就是把关系数据库当KV数据库用, friendfeed 2009年用的方案 http://backchannel.org/blog/friendfeed-schemaless-mysql
|
9
Ison 2015-05-27 11:19:45 +08:00
可能跟业务需求有关系。。。
只对单条id索引读取而又不需要修改的话 其实也不是不可理解 当然。。。也不排除你CTO是奇葩。。。 |
10
roushan 2015-05-27 11:21:19 +08:00
现在很流行的做法,K/V的方式来设计,有比较高的扩展性。
需要有一套比较强的中间件来支撑会比较好。 |
11
timsims 2015-05-27 11:26:23 +08:00
但是如果要对detail里某字段进行统计岂不是要把所有数据都取出来,然后再自行计算?
|
12
zkd8907 2015-05-27 11:29:38 +08:00
看业务吧,如果只是简单的增删改查,不涉及column的order,join操作,这样做还Ok啦。但是既然业务如此,为什么不用nosql数据库。。。
|
13
zieglar 2015-05-27 11:30:12 +08:00
这种时候就看出 Postgres 的好用了, jsonb 操作简直爽到歪
|
15
Kabie 2015-05-27 11:32:13 +08:00
为啥不用mongo或者pg。。。
mysql还搞这些幺蛾子。。。 |
16
b821025551b 2015-05-27 11:34:28 +08:00
个人感觉如果业务需求摆在那,几个字段或者表这么存没什么问题;如果都这么存,要数据库干嘛?
|
17
nigelvon 2015-05-27 11:35:55 +08:00
为啥不用mongo+1,mysql完全没用上啊。
|
18
scalala 2015-05-27 11:39:03 +08:00
mongo和这套方案完全不搭界, mongo的好处是schema-less,即数据结构很自由.
这套方案拿mysql当KV数据库用纯粹是为了性能. |
19
jarlyyn 2015-05-27 11:43:08 +08:00
自己这边的的表基本也是这样的,多一个字段表示下数据处理的model类的keyword.
只有需要排序的字段再单独列出。 业务决定的。需要同一套代码管理不同项目的数据,只能在数据上增加弹性。 不过他的理由我不太懂。。 |
20
nigelvon 2015-05-27 11:43:50 +08:00
@scalala 撸主说的那种方式也是自由结构呀,一个JSON字符串,想放什么就放什么。另外求解释这种方式怎么利用MySQL的性能。
|
21
DjvuLee 2015-05-27 11:44:44 +08:00
@scalala mongo 是一个document类型的数据库。它把一个json看成是一个document,怎么会不搭界呢?况且mongo有sharding操作,以后也方便扩展。
|
22
DjvuLee 2015-05-27 11:46:50 +08:00
大家都说的很好。如果只是这样,要么使用k-v数据库,要么使用内置json处理的postgresql。或是lz有一些其他考虑没有提到?
|
23
learnshare 2015-05-27 11:50:11 +08:00
他这种用法,是文档数据库,用 MySQL 不合适。
|
24
mathgl 2015-05-27 11:52:00 +08:00
mariadb 现在好像支持json了。
|
25
matsuijurina 2015-05-27 11:52:05 +08:00
@jarlyyn 我觉得你的说法是比较有道理的。主要是适应多种业务模式增加数据弹性。用MySQL做KVS真的能在性能上超过MongoDB吗? 我有点怀疑。
|
26
winnie2012 2015-05-27 11:52:41 +08:00
这个设计有点反常规,看看各位大牛如何吹。
|
27
scalala 2015-05-27 11:53:44 +08:00
@nigelvon 把20字段都放一个json存取性能是比一个20字段的mysql表存取性能要好的. 这个方案当然也是附带了schemaless的作用.
这样做其实就是要弱化数据库的作用,排序什么的都在应用里做(或者把需要排序的字段抽出来做索引). 这种事本来应该用专门的KV数据库的, 估计楼主的CTO是考虑到MySQL比较成熟/熟悉.(运维等各方面都要考虑) |
28
nanhuo 2015-05-27 11:53:57 +08:00
关系型数据库设计成这样是要闹哪样?干吗不用mongo
|
29
pijingzhanji 2015-05-27 11:55:27 +08:00
你CTO中了NoSQL的毒,这样还用什么mysql,用redis算了
|
30
ichou 2015-05-27 11:56:04 +08:00
不是说 MySQL 要支持 json 了么?
|
32
neoblackcap 2015-05-27 11:59:47 +08:00
@scalala 我觉得这样做大概是为了拓展好(KV貌似没有不好),不过以前没有大批nosql数据库之前这样做我理解啊,但是现在还这样做,我真是不能理解了。我是很难想象mysql在这个方面可以跑赢mongodb的。
所以嘛,现在的话,关系型数据就应该按照关系型数据的用法,不是关系型数据的逻辑应该放在nosql数据库中处理,没有哪个规定应用一定要只用一种数据 |
33
jarlyyn 2015-05-27 12:08:12 +08:00 1
@matsuijurina
和性能没关系啊。 很基本的道理,我的业务必要考虑到可能在虚拟主机上使用。 所以必须支持php 5.2/5.3,必须使用mysql。 我这里的业务是给企业建站的。 如果企业需要要给某个栏目添加一个视频,需要添加一个作者,需要添加一个副标题,需要添加一个简介,需要添加一组幻灯片。 难道我还去调整数据库么? 直接继承下model的基类,添加两个自动序列化/反序列化的类,后台就自动多了输入框了。然后视图里用个getModelValue('xxx')方法,就完工了。 需求决定一切么。 |
34
cdffh 2015-05-27 12:15:00 +08:00
他不会有涉及json内部的查询吗? 查询全是基于id的? 如果没有就没啥问题.
|
36
zhicheng 2015-05-27 12:21:52 +08:00
这跟 friendsfeed 的设计不一样好嘛。
一般来讲,这事儿就是 CTO 蛋疼。一个不折腾的 CTO 也是公司之福。 |
37
jsq2627 2015-05-27 12:23:59 +08:00
文档数据库是最佳选择。
在应用层做数据约束好处是可以很方便的水平扩展。坏处是如果没有很清晰的文档和规范,基本没人能 100% 做到位。 |
38
moro 2015-05-27 12:29:16 +08:00 2
我在想,会不会有题主的CTO来开贴。。
|
39
finian 2015-05-27 12:30:45 +08:00
这样用还不如直接用 nosql
|
40
FrankFang128 2015-05-27 12:32:25 +08:00
坐等 CTO 发帖
|
41
MrEggNoodle 2015-05-27 12:34:00 +08:00
@moro 哈哈哈哈哈哈。
|
42
roricon 2015-05-27 12:34:59 +08:00
是新增的表全都长这样,还是所有的表全都这样?
如果全部表都这样,查询性能怎么解决……这样做是完全抛弃主键以外的索引了么? |
44
Lullaby 2015-05-27 12:36:25 +08:00
@FrankFang128 最近v2成了撕逼社区
|
45
quix 2015-05-27 13:19:22 +08:00
这是典型的把 rdbms 当 nosql 来用... 某些情况下确实也可以..
|
46
hkongm 2015-05-27 13:22:40 +08:00
直接上nosql啊
|
47
quix 2015-05-27 13:23:35 +08:00
对于不需要索引的内容字段, Lz 的 cto 这样做应该无伤大雅.
|
49
loading 2015-05-27 13:38:58 +08:00 via Android
我很多时候会在里面存json的kv数据,例如设置信息,这样就不会因为后面增加功能而担心没字段存了,一个字段全存完!
可是像楼主描述那样,这个字段不都是一样的内容吗? |
50
yangzh 2015-05-27 13:40:11 +08:00 via iPhone
这个用 redis mongodb 吧哈哈
|
51
cevincheung 2015-05-27 13:40:37 +08:00
果断上postgresql啊
|
52
langhua9527 2015-05-27 13:42:35 +08:00
有查询条件怎么办?
|
53
9hills 2015-05-27 13:50:56 +08:00 via iPhone
NoSQL没问题,但是用MySQL不太好。。
|
54
wbolor 2015-05-27 13:54:58 +08:00
记得很早前看过一篇文章 reddit 好像就是这么搞的。。。
|
55
sivacohan 2015-05-27 14:00:49 +08:00 via Android
是"只有",还是"都有"
如果是都有的话,可以理解,id做主键,主键和业务无关是有优势的。detail应对来自其他部门的乱七八糟的需求。 如果是只有的话就有点奇怪了。这完全放弃了SQL啊。每次查询点什么都是全表扫描,相当于应用层实现了一个SQL,图什么啊?而且数据量上去了,你把所有的数据都放应用里,不怕内存爆了吗?前端应用至少两个吧,你怎么保持数据的一致性? 如果你的CTO能有理有据的解释我上面的问题,请你一定告诉我。我之前也遇到过类似的架构,解释就是移植性好,后面数据库随便换,这个理由我完全接受不了。 |
56
Mirana 2015-05-27 14:02:30 +08:00
坐等cto来撕哔
|
57
kenken 2015-05-27 14:04:06 +08:00 6
我们就是这么玩的。 我们现在id和detail detail使用json存储。
1,运维成熟,稳定性更高。安全性非常高 2,搜索用elasticsearch单独做。速度更快,比mysql量级高很多,分词灵活 3,数据分析有hadoop,hive等工具。以及离线的其他pg,或者elasticsearch做运维系统。 4,最初设计也是上层的灵活性。上层字段添加非常多,业务开发也很频繁。1000+个字段的表无法每个字段都存储的。 5,很重要的支持事务。 |
58
scys 2015-05-27 14:05:27 +08:00
找CTO撕逼~
我自己设计的MongoDB设计的结构,直接被新来的CTO。 一口说,MYSQL是最好的,我们还MYSQL~ 结果~我自己就去做前端了~ |
59
kenken 2015-05-27 14:08:20 +08:00
BTW: 我是CTO
|
64
adjusted 2015-05-27 14:51:33 +08:00
坐等ceo偶然看到帖子来发帖
|
66
abscon 2015-05-27 15:22:04 +08:00 2
似乎听到了 MySQL 在幽怨地唱着:原来你,什么都不想要~
|
68
est 2015-05-27 15:33:55 +08:00
|
69
shuson 2015-05-27 16:21:00 +08:00
我就是CEO,我CTO是我小舅子,他爱咋做我都支持
|
71
20131115 2015-05-27 16:41:38 +08:00
@kenken 看起来有你自己的道理,MySQL 不是这么用的,都搞成JSON,如果你增加删除字段的时候怎么操作呢?会不会增加 DBA 的运维成本。你不这样做也可以使用各种搜索服务,也可以使用各种大数据产品
|
72
duwei 2015-05-27 16:50:12 +08:00
建立楼主加上相关的项目背景。脱离背景讨论没有意义。
|
73
Tink 2015-05-27 16:51:53 +08:00 via iPhone
我感觉要是业务需求每次都需要取整个detail的话,那这样倒也不失一种办法。当然是在不换数据库的情况下
|
74
galenzhao 2015-05-27 16:58:41 +08:00
对 nosql事务是个纠结的地方
好多业务逻辑 排除不掉事务。。。 不知道cto研究过SequoiaDB没 |
75
feisan 2015-05-27 17:13:08 +08:00
建议大家看看7楼说的那篇文章,这样的设计也不是没有道理的。
另外mogodb这个东西,不要光顾着写代码用的爽,也要考虑一下运维的难度和成熟度。 |
76
br00k 2015-05-27 19:04:41 +08:00
批量修改操作我想知道效率会怎样。。
|
77
fy 2015-05-27 19:26:22 +08:00
@kenken 请问数据库是postgress吗?我想知道这种情况下,数据库会不会帮你把相同的key整合优化掉,所以数据库会比原本的json更省空间?
|
78
franksin 2015-05-27 19:31:43 +08:00
说说使用场景呗,有些特殊场景,kv也可能比较好用。
|
79
ksupertu 2015-05-27 19:39:24 +08:00
现在的主流设计本来就不用数据库提供的外键啊,都是自己维护一套主外键代码
|
80
michaelye1988 2015-05-27 20:02:56 +08:00
我也是这样做的,我觉得很方便。现在接手的一个Android项目就遇到这个问题。服务端需要增加一个字段非常麻烦,客户端需要升级数据库。所以如果没有特别的需求,我觉得你们CTO做的没错。
|
81
zongwan 2015-05-27 20:36:21 +08:00
|
82
yuankui 2015-05-27 20:41:46 +08:00
你确定你们的CTO不上v2ex吗?
|
83
superisaac 2015-05-27 21:48:48 +08:00
这种用mysql作kv有个卵的性能。
为啥不用tokumx? |
84
nino789pzw 2015-05-27 22:14:07 +08:00
@yuankui He's right there....
|
85
arbipher 2015-05-27 22:28:04 +08:00
别撕了,别撕了,看新闻
MySQL 5.7.7 JSON labs release http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/ |
86
shiznet 2015-05-27 22:36:30 +08:00
@feisan 看了下7楼的文章,写于2009年。我查了下wiki,nosql在09年才开始普及(不知道这样说可以么)。如果放到现在的话,friendfeed还会继续选择使用mysql做kv存储么,我个人表示怀疑。
不过我对将mysql作为schema-less的存储持中立,对文章中提到的:scaling our existing features to accomodate more traffic turned out to be much less of an issue than adding new features.持赞同 |
87
falcon05 2015-05-27 23:23:58 +08:00 via iPhone
一开始我也准备喷为毛不用nosql,但看完了7楼的链接,我发现这样做还真有点道理,一种典型的用空间换时间的做法,充分利用了索引和MySQL较为成熟事务处理,可以做到快速查询跟安全存储,而且扩展性也不错。配合异步处理和自动化,就是一套完整的解决方案
|
88
pubby 2015-05-28 00:31:13 +08:00
看业务需要了,在一些业务需求多变的场合,当kv用,或者部分column当kv用有时候还是很方便的。
|
89
cevincheung 2015-05-28 00:43:35 +08:00
@kenken 事物指的不是单纯的操作成功,在事物过程中的其他计算才是最关键的。如果说表结构是类似这样:
users: id, detail orders: id, detail logs: id, detail 那为什么不干脆是一个表?或者有什么理由不去用mongodb?(事物不算,而且实现软事物并不难) |
90
lyragosa 2015-05-28 00:45:23 +08:00
这种设计有好处有坏处
喷的人一定没遇到非常复杂的多层嵌套结构 当然你非要严格按照二范氏做他几十个表我也没办法反驳…… |
91
JoeShu 2015-05-28 02:03:35 +08:00
以前做过类似的设计,不过稍有区别,就是要把索引字段需要抽取出来,不然性能会很差
优点很多: 1. 处理灵活,适合业务变化比较快的产品 2. 支持事物,适合对数据一致性要求高的场景 3. 支持行级锁,因为直到2.4版本,mongodb还只支持db级别的锁 4. mysql要比mongodb稳定的多,各种问题都有很成熟的解决方案 5. 很多云服务和运维服务不支持nosql。 6. 性能问题,mongodb对内存和磁盘空间的消耗实在是很大,尤其内存小于热数据的时候。 这种方案是综合了mysql和nosql的优点, 是一种很好的解决方案 |
92
monkeylyf 2015-05-28 07:17:46 +08:00
也用过类似的schema设计 用postgres来实现 主要是为了灵活的应付需求改变 减少修改schema导致的db migration 稳定后的release的时候会把json里的数据拉出来当成col存
|
93
decken 2015-05-28 08:59:36 +08:00 via Android
postgrep大法好
|
94
guotie 2015-05-28 09:19:36 +08:00
挺好。
我们在每个表里增加一个attr的字段,json结构,专门用来扩展。 |
95
CharlesL 2015-05-28 10:11:32 +08:00
看V2的大侠们讨论,果然长知识.
|
96
kenken 2015-05-28 10:25:32 +08:00
@est 1M的json,那就得分离存储了,特殊情况需要特殊设计。但是1m这情况我这么多年也没遇到,这情况一般人会放到单纯的mysql吗?
|