CTO，新设计的所有的表都只有 id 和 detail。我不是很理解，求解释。

detail

字符串

JSON

115 条回复 • 2015-06-07 16:40:25 +08:00

1 2

❮

❯

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...

5

sinux

OP

2015-05-27 11:15:49 +08:00

@cobola
@superbear
@finab

用的就是mysql。

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

8

sinux

OP

2015-05-27 11:19:08 +08:00

@superbear 多对多的表还是有的，只是外键都弄进去了

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 操作简直爽到歪

14

scalala

2015-05-27 11:31:07 +08:00

@timsims 只有小网站才会直接在主业务数据库做统计的, 大流量网站在数据产生的时候就发到MQ让有需要的系统自己订阅

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 了么？

31

nigelvon

2015-05-27 11:58:03 +08:00

@scalala 存取性能好没用啊，而且也好不过mongo，关键是怎么查。如果不需要查的话，要MySQL干甚。

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的? 如果没有就没啥问题.

35

mhycy

2015-05-27 12:15:44 +08:00

@jarlyyn 那么为了性能至少还需要一个永不重复的type字段, 以路径形式命名...

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

是新增的表全都长这样，还是所有的表全都这样？
如果全部表都这样，查询性能怎么解决……这样做是完全抛弃主键以外的索引了么？

43

jarlyyn

2015-05-27 12:35:04 +08:00

@mhycy
当然不是，留一个关键字。

至于关键字对应的类文件，在一个配置文件里定义。

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 这样做应该无伤大雅.

48

soli

2015-05-27 13:24:05 +08:00

几乎所有人都盯着业务、性能、查询、索引。。。

好像只有 @scalala 提到了成熟度和运维。

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

60

icqdany

2015-05-27 14:44:11 +08:00

@kenken
请问第5点的，事务是怎么做的？

61

coney

2015-05-27 14:47:09 +08:00

@kenken 还是不懂，为什么不用mongodb

62

kenken

2015-05-27 14:47:54 +08:00

@icqdany 大于一个表的更新插入操作是事务的。这个是nosql很难实现的。

63

hcymk2

2015-05-27 14:49:29 +08:00

@kenken
这样怎么做聚合统计？
用代码实现么？

64

adjusted

2015-05-27 14:51:33 +08:00

坐等ceo偶然看到帖子来发帖

65

icqdany

2015-05-27 14:59:45 +08:00

@kenken 明白了，thank you.

66

abscon

2015-05-27 15:22:04 +08:00

2

似乎听到了 MySQL 在幽怨地唱着：原来你，什么都不想要~

67

kenken

2015-05-27 15:30:28 +08:00

@hcymk2 第2，3点。聚合统计elasticsearch是支持的。离线的用hadoop等大数据分析

68

est

2015-05-27 15:33:55 +08:00

@kenken 这样做是可以的，直到你的json blob撑到了1M，然后你需要从1000个这样的json里取一个1字节的int出来排序。

hahahahaha

69

shuson

2015-05-27 16:21:00 +08:00

我就是CEO，我CTO是我小舅子，他爱咋做我都支持

70

sinux

OP

2015-05-27 16:25:36 +08:00

@shuson ....

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

@kenken
是游戏服务器适合这种结构吗?
如果需要合服(玩家带着的所有道具,道具有自己的强化等级等),克隆多个用户去同一个PK服
有什么trick方法处理吗?

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吗？

97

est

2015-05-28 10:33:25 +08:00

@kenken 你永远无法预测用户会给你传什么东西上来。。。。reddit 他们就遇到这个事情了。好像是用户头像哪里？他们忘记做检测了。结果有个用户头像大小是2G。

98

kenken

2015-05-28 10:36:47 +08:00

@fy 是mysql 5.6

99

kenken

2015-05-28 10:37:54 +08:00

@zongwan 这个对游戏确实不熟悉，一直在做电商。像合服我听过，但不了解是怎么操作。

100

kenken

2015-05-28 10:40:37 +08:00

@JoeShu 对，我们是电商，对事务要求极其严格，而且行级锁性能是非常高的。

1 2

❮

❯