V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MySQL 5.5 Community Server
MySQL 5.6 Community Server
Percona Configuration Wizard
XtraBackup 搭建主从复制
Great Sites on MySQL
Percona
MySQL Performance Blog
Severalnines
推荐管理工具
Sequel Pro
phpMyAdmin
推荐书目
MySQL Cookbook
MySQL 相关项目
MariaDB
Drizzle
参考文档
http://mysql-python.sourceforge.net/MySQLdb.html
sinux
V2EX  ›  MySQL

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

  •  1
     
  •   sinux · 2015-05-27 11:04:43 +08:00 · 12099 次点击
    这是一个创建于 3480 天前的主题,其中的信息可能已经有所发展或是发生改变。
    detail是一个json字符串。

    原来的所有的外键和column全都都放到detail里面。

    他说这样可以避免外键的混乱和冲突,自己来维护外键关系。
    115 条回复    2015-06-07 16:40:25 +08:00
    1  2  
    cobola
        1
    cobola  
       2015-05-27 11:08:23 +08:00
    哈哈 你们用的是mysql么?

    oracle?

    哈哈哈
    superbear
        2
    superbear  
       2015-05-27 11:11:12 +08:00
    更新一个字段啥的,还得全部取出,编辑后再组装。。。
    finab
        3
    finab  
       2015-05-27 11:12:13 +08:00   ❤️ 1
    既然如此,干嘛用数据库? - -
    superbear
        4
    superbear  
       2015-05-27 11:13:26 +08:00
    如果用的是Mysql的话,感觉这样还不如用Mongo...
    sinux
        5
    sinux  
    OP
       2015-05-27 11:15:49 +08:00
    @cobola
    @superbear
    @finab

    用的就是mysql。
    est
        6
    est  
       2015-05-27 11:16:43 +08:00
    本来打了很多字,详细分析这种json保存为文本blob到一个字段里的优缺点,结果还是删了。

    三个字:然卵用
    scalala
        7
    scalala  
       2015-05-27 11:18:50 +08:00   ❤️ 2
    这就是把关系数据库当KV数据库用, friendfeed 2009年用的方案 http://backchannel.org/blog/friendfeed-schemaless-mysql
    sinux
        8
    sinux  
    OP
       2015-05-27 11:19:08 +08:00
    @superbear 多对多的表还是有的,只是外键都弄进去了
    Ison
        9
    Ison  
       2015-05-27 11:19:45 +08:00
    可能跟业务需求有关系。。。
    只对单条id索引读取而又不需要修改的话
    其实也不是不可理解
    当然。。。也不排除你CTO是奇葩。。。
    roushan
        10
    roushan  
       2015-05-27 11:21:19 +08:00
    现在很流行的做法,K/V的方式来设计,有比较高的扩展性。
    需要有一套比较强的中间件来支撑会比较好。
    timsims
        11
    timsims  
       2015-05-27 11:26:23 +08:00
    但是如果要对detail里某字段进行统计岂不是要把所有数据都取出来,然后再自行计算?
    zkd8907
        12
    zkd8907  
       2015-05-27 11:29:38 +08:00
    看业务吧,如果只是简单的增删改查,不涉及column的order,join操作,这样做还Ok啦。但是既然业务如此,为什么不用nosql数据库。。。
    zieglar
        13
    zieglar  
       2015-05-27 11:30:12 +08:00
    这种时候就看出 Postgres 的好用了, jsonb 操作简直爽到歪
    scalala
        14
    scalala  
       2015-05-27 11:31:07 +08:00
    @timsims 只有小网站才会直接在主业务数据库做统计的, 大流量网站在数据产生的时候就发到MQ让有需要的系统自己订阅
    Kabie
        15
    Kabie  
       2015-05-27 11:32:13 +08:00
    为啥不用mongo或者pg。。。

    mysql还搞这些幺蛾子。。。
    b821025551b
        16
    b821025551b  
       2015-05-27 11:34:28 +08:00
    个人感觉如果业务需求摆在那,几个字段或者表这么存没什么问题;如果都这么存,要数据库干嘛?
    nigelvon
        17
    nigelvon  
       2015-05-27 11:35:55 +08:00
    为啥不用mongo+1,mysql完全没用上啊。
    scalala
        18
    scalala  
       2015-05-27 11:39:03 +08:00
    mongo和这套方案完全不搭界, mongo的好处是schema-less,即数据结构很自由.
    这套方案拿mysql当KV数据库用纯粹是为了性能.
    jarlyyn
        19
    jarlyyn  
       2015-05-27 11:43:08 +08:00
    自己这边的的表基本也是这样的,多一个字段表示下数据处理的model类的keyword.
    只有需要排序的字段再单独列出。

    业务决定的。需要同一套代码管理不同项目的数据,只能在数据上增加弹性。

    不过他的理由我不太懂。。
    nigelvon
        20
    nigelvon  
       2015-05-27 11:43:50 +08:00
    @scalala 撸主说的那种方式也是自由结构呀,一个JSON字符串,想放什么就放什么。另外求解释这种方式怎么利用MySQL的性能。
    DjvuLee
        21
    DjvuLee  
       2015-05-27 11:44:44 +08:00
    @scalala mongo 是一个document类型的数据库。它把一个json看成是一个document,怎么会不搭界呢?况且mongo有sharding操作,以后也方便扩展。
    DjvuLee
        22
    DjvuLee  
       2015-05-27 11:46:50 +08:00
    大家都说的很好。如果只是这样,要么使用k-v数据库,要么使用内置json处理的postgresql。或是lz有一些其他考虑没有提到?
    learnshare
        23
    learnshare  
       2015-05-27 11:50:11 +08:00
    他这种用法,是文档数据库,用 MySQL 不合适。
    mathgl
        24
    mathgl  
       2015-05-27 11:52:00 +08:00
    mariadb 现在好像支持json了。
    matsuijurina
        25
    matsuijurina  
       2015-05-27 11:52:05 +08:00
    @jarlyyn 我觉得你的说法是比较有道理的。主要是适应多种业务模式增加数据弹性。用MySQL做KVS真的能在性能上超过MongoDB吗? 我有点怀疑。
    winnie2012
        26
    winnie2012  
       2015-05-27 11:52:41 +08:00
    这个设计有点反常规,看看各位大牛如何吹。
    scalala
        27
    scalala  
       2015-05-27 11:53:44 +08:00
    @nigelvon 把20字段都放一个json存取性能是比一个20字段的mysql表存取性能要好的. 这个方案当然也是附带了schemaless的作用.
    这样做其实就是要弱化数据库的作用,排序什么的都在应用里做(或者把需要排序的字段抽出来做索引).
    这种事本来应该用专门的KV数据库的, 估计楼主的CTO是考虑到MySQL比较成熟/熟悉.(运维等各方面都要考虑)
    nanhuo
        28
    nanhuo  
       2015-05-27 11:53:57 +08:00
    关系型数据库设计成这样是要闹哪样?干吗不用mongo
    pijingzhanji
        29
    pijingzhanji  
       2015-05-27 11:55:27 +08:00
    你CTO中了NoSQL的毒,这样还用什么mysql,用redis算了
    ichou
        30
    ichou  
       2015-05-27 11:56:04 +08:00
    不是说 MySQL 要支持 json 了么?
    nigelvon
        31
    nigelvon  
       2015-05-27 11:58:03 +08:00
    @scalala 存取性能好没用啊,而且也好不过mongo,关键是怎么查。如果不需要查的话,要MySQL干甚。
    neoblackcap
        32
    neoblackcap  
       2015-05-27 11:59:47 +08:00
    @scalala 我觉得这样做大概是为了拓展好(KV貌似没有不好),不过以前没有大批nosql数据库之前这样做我理解啊,但是现在还这样做,我真是不能理解了。我是很难想象mysql在这个方面可以跑赢mongodb的。

    所以嘛,现在的话,关系型数据就应该按照关系型数据的用法,不是关系型数据的逻辑应该放在nosql数据库中处理,没有哪个规定应用一定要只用一种数据
    jarlyyn
        33
    jarlyyn  
       2015-05-27 12:08:12 +08:00   ❤️ 1
    @matsuijurina

    和性能没关系啊。

    很基本的道理,我的业务必要考虑到可能在虚拟主机上使用。

    所以必须支持php 5.2/5.3,必须使用mysql。

    我这里的业务是给企业建站的。

    如果企业需要要给某个栏目添加一个视频,需要添加一个作者,需要添加一个副标题,需要添加一个简介,需要添加一组幻灯片。

    难道我还去调整数据库么?

    直接继承下model的基类,添加两个自动序列化/反序列化的类,后台就自动多了输入框了。然后视图里用个getModelValue('xxx')方法,就完工了。

    需求决定一切么。
    cdffh
        34
    cdffh  
       2015-05-27 12:15:00 +08:00
    他不会有涉及json内部的查询吗? 查询全是基于id的? 如果没有就没啥问题.
    mhycy
        35
    mhycy  
       2015-05-27 12:15:44 +08:00
    @jarlyyn 那么为了性能至少还需要一个永不重复的type字段, 以路径形式命名...
    zhicheng
        36
    zhicheng  
       2015-05-27 12:21:52 +08:00
    这跟 friendsfeed 的设计不一样好嘛。
    一般来讲,这事儿就是 CTO 蛋疼。一个不折腾的 CTO 也是公司之福。
    jsq2627
        37
    jsq2627  
       2015-05-27 12:23:59 +08:00
    文档数据库是最佳选择。
    在应用层做数据约束好处是可以很方便的水平扩展。坏处是如果没有很清晰的文档和规范,基本没人能 100% 做到位。
    moro
        38
    moro  
       2015-05-27 12:29:16 +08:00   ❤️ 2
    我在想,会不会有题主的CTO来开贴。。
    finian
        39
    finian  
       2015-05-27 12:30:45 +08:00
    这样用还不如直接用 nosql
    FrankFang128
        40
    FrankFang128  
       2015-05-27 12:32:25 +08:00
    坐等 CTO 发帖
    MrEggNoodle
        41
    MrEggNoodle  
       2015-05-27 12:34:00 +08:00
    @moro 哈哈哈哈哈哈。
    roricon
        42
    roricon  
       2015-05-27 12:34:59 +08:00
    是新增的表全都长这样,还是所有的表全都这样?
    如果全部表都这样,查询性能怎么解决……这样做是完全抛弃主键以外的索引了么?
    jarlyyn
        43
    jarlyyn  
       2015-05-27 12:35:04 +08:00
    @mhycy
    当然不是,留一个关键字。

    至于关键字对应的类文件,在一个配置文件里定义。
    Lullaby
        44
    Lullaby  
       2015-05-27 12:36:25 +08:00
    @FrankFang128 最近v2成了撕逼社区
    quix
        45
    quix  
       2015-05-27 13:19:22 +08:00
    这是典型的把 rdbms 当 nosql 来用... 某些情况下确实也可以..
    hkongm
        46
    hkongm  
       2015-05-27 13:22:40 +08:00
    直接上nosql啊
    quix
        47
    quix  
       2015-05-27 13:23:35 +08:00
    对于不需要索引的内容字段, Lz 的 cto 这样做应该无伤大雅.
    soli
        48
    soli  
       2015-05-27 13:24:05 +08:00
    几乎所有人都盯着业务、性能、查询、索引。。。

    好像只有 @scalala 提到了成熟度和运维。
    loading
        49
    loading  
       2015-05-27 13:38:58 +08:00 via Android
    我很多时候会在里面存json的kv数据,例如设置信息,这样就不会因为后面增加功能而担心没字段存了,一个字段全存完!

    可是像楼主描述那样,这个字段不都是一样的内容吗?
    yangzh
        50
    yangzh  
       2015-05-27 13:40:11 +08:00 via iPhone
    这个用 redis mongodb 吧哈哈
    cevincheung
        51
    cevincheung  
       2015-05-27 13:40:37 +08:00
    果断上postgresql啊
    langhua9527
        52
    langhua9527  
       2015-05-27 13:42:35 +08:00
    有查询条件怎么办?
    9hills
        53
    9hills  
       2015-05-27 13:50:56 +08:00 via iPhone
    NoSQL没问题,但是用MySQL不太好。。
    wbolor
        54
    wbolor  
       2015-05-27 13:54:58 +08:00
    记得很早前看过一篇文章 reddit 好像就是这么搞的。。。
    sivacohan
        55
    sivacohan  
       2015-05-27 14:00:49 +08:00 via Android
    是"只有",还是"都有"
    如果是都有的话,可以理解,id做主键,主键和业务无关是有优势的。detail应对来自其他部门的乱七八糟的需求。
    如果是只有的话就有点奇怪了。这完全放弃了SQL啊。每次查询点什么都是全表扫描,相当于应用层实现了一个SQL,图什么啊?而且数据量上去了,你把所有的数据都放应用里,不怕内存爆了吗?前端应用至少两个吧,你怎么保持数据的一致性?
    如果你的CTO能有理有据的解释我上面的问题,请你一定告诉我。我之前也遇到过类似的架构,解释就是移植性好,后面数据库随便换,这个理由我完全接受不了。
    Mirana
        56
    Mirana  
       2015-05-27 14:02:30 +08:00
    坐等cto来撕哔
    kenken
        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,很重要的支持事务。
    scys
        58
    scys  
       2015-05-27 14:05:27 +08:00
    找CTO撕逼~
    我自己设计的MongoDB设计的结构,直接被新来的CTO。
    一口说,MYSQL是最好的,我们还MYSQL~
    结果~我自己就去做前端了~
    kenken
        59
    kenken  
       2015-05-27 14:08:20 +08:00
    BTW: 我是CTO
    icqdany
        60
    icqdany  
       2015-05-27 14:44:11 +08:00
    @kenken
    请问第5点的,事务是怎么做的?
    coney
        61
    coney  
       2015-05-27 14:47:09 +08:00
    @kenken 还是不懂,为什么不用mongodb
    kenken
        62
    kenken  
       2015-05-27 14:47:54 +08:00
    @icqdany 大于一个表的更新 插入操作是事务的。这个是nosql很难实现的。
    hcymk2
        63
    hcymk2  
       2015-05-27 14:49:29 +08:00
    @kenken
    这样怎么做聚合统计?
    用代码实现么?
    adjusted
        64
    adjusted  
       2015-05-27 14:51:33 +08:00
    坐等ceo偶然看到帖子来发帖
    icqdany
        65
    icqdany  
       2015-05-27 14:59:45 +08:00
    @kenken 明白了,thank you.
    abscon
        66
    abscon  
       2015-05-27 15:22:04 +08:00   ❤️ 2
    似乎听到了 MySQL 在幽怨地唱着:原来你,什么都不想要~
    kenken
        67
    kenken  
       2015-05-27 15:30:28 +08:00
    @hcymk2 第2,3点。 聚合统计elasticsearch是支持的。 离线的用hadoop等大数据分析
    est
        68
    est  
       2015-05-27 15:33:55 +08:00
    @kenken 这样做是可以的,直到你的json blob撑到了1M,然后你需要从1000个这样的json里取一个1字节的int出来排序。


    hahahahaha
    shuson
        69
    shuson  
       2015-05-27 16:21:00 +08:00
    我就是CEO,我CTO是我小舅子,他爱咋做我都支持
    sinux
        70
    sinux  
    OP
       2015-05-27 16:25:36 +08:00
    @shuson ....
    20131115
        71
    20131115  
       2015-05-27 16:41:38 +08:00
    @kenken 看起来有你自己的道理,MySQL 不是这么用的,都搞成JSON,如果你增加删除字段的时候怎么操作呢?会不会增加 DBA 的运维成本。你不这样做也可以使用各种搜索服务,也可以使用各种大数据产品
    duwei
        72
    duwei  
       2015-05-27 16:50:12 +08:00
    建立楼主加上相关的项目背景。脱离背景讨论没有意义。
    Tink
        73
    Tink  
       2015-05-27 16:51:53 +08:00 via iPhone
    我感觉要是业务需求每次都需要取整个detail的话,那这样倒也不失一种办法。当然是在不换数据库的情况下
    galenzhao
        74
    galenzhao  
       2015-05-27 16:58:41 +08:00
    对 nosql事务是个纠结的地方
    好多业务逻辑 排除不掉事务。。。
    不知道cto研究过SequoiaDB没
    feisan
        75
    feisan  
       2015-05-27 17:13:08 +08:00
    建议大家看看7楼说的那篇文章,这样的设计也不是没有道理的。

    另外mogodb这个东西,不要光顾着写代码用的爽,也要考虑一下运维的难度和成熟度。
    br00k
        76
    br00k  
       2015-05-27 19:04:41 +08:00
    批量修改操作我想知道效率会怎样。。
    fy
        77
    fy  
       2015-05-27 19:26:22 +08:00
    @kenken 请问数据库是postgress吗?我想知道这种情况下,数据库会不会帮你把相同的key整合优化掉,所以数据库会比原本的json更省空间?
    franksin
        78
    franksin  
       2015-05-27 19:31:43 +08:00
    说说使用场景呗,有些特殊场景,kv也可能比较好用。
    ksupertu
        79
    ksupertu  
       2015-05-27 19:39:24 +08:00
    现在的主流设计本来就不用数据库提供的外键啊,都是自己维护一套主外键代码
    michaelye1988
        80
    michaelye1988  
       2015-05-27 20:02:56 +08:00
    我也是这样做的,我觉得很方便。现在接手的一个Android项目就遇到这个问题。服务端需要增加一个字段非常麻烦,客户端需要升级数据库。所以如果没有特别的需求,我觉得你们CTO做的没错。
    zongwan
        81
    zongwan  
       2015-05-27 20:36:21 +08:00
    @kenken
    是游戏服务器适合这种结构吗?
    如果需要合服(玩家带着的所有道具,道具有自己的强化等级等),克隆多个用户去同一个PK服
    有什么trick方法处理吗?
    yuankui
        82
    yuankui  
       2015-05-27 20:41:46 +08:00
    你确定你们的CTO不上v2ex吗?
    superisaac
        83
    superisaac  
       2015-05-27 21:48:48 +08:00
    这种用mysql作kv有个卵的性能。
    为啥不用tokumx?
    nino789pzw
        84
    nino789pzw  
       2015-05-27 22:14:07 +08:00
    @yuankui He's right there....
    arbipher
        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/
    shiznet
        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.持赞同
    falcon05
        87
    falcon05  
       2015-05-27 23:23:58 +08:00 via iPhone
    一开始我也准备喷为毛不用nosql,但看完了7楼的链接,我发现这样做还真有点道理,一种典型的用空间换时间的做法,充分利用了索引和MySQL较为成熟事务处理,可以做到快速查询跟安全存储,而且扩展性也不错。配合异步处理和自动化,就是一套完整的解决方案
    pubby
        88
    pubby  
       2015-05-28 00:31:13 +08:00
    看业务需要了,在一些业务需求多变的场合,当kv用,或者部分column当kv用有时候还是很方便的。
    cevincheung
        89
    cevincheung  
       2015-05-28 00:43:35 +08:00
    @kenken 事物指的不是单纯的操作成功,在事物过程中的其他计算才是最关键的。如果说表结构是类似这样:

    users: id, detail
    orders: id, detail
    logs: id, detail

    那为什么不干脆是一个表?或者有什么理由不去用mongodb?(事物不算,而且实现软事物并不难)
    lyragosa
        90
    lyragosa  
       2015-05-28 00:45:23 +08:00
    这种设计有好处有坏处

    喷的人一定没遇到非常复杂的多层嵌套结构

    当然你非要严格按照二范氏做他几十个表我也没办法反驳……
    JoeShu
        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的优点, 是一种很好的解决方案
    monkeylyf
        92
    monkeylyf  
       2015-05-28 07:17:46 +08:00
    也用过类似的schema设计 用postgres来实现 主要是为了灵活的应付需求改变 减少修改schema导致的db migration 稳定后的release的时候会把json里的数据拉出来当成col存
    decken
        93
    decken  
       2015-05-28 08:59:36 +08:00 via Android
    postgrep大法好
    guotie
        94
    guotie  
       2015-05-28 09:19:36 +08:00
    挺好。

    我们在每个表里增加一个attr的字段,json结构,专门用来扩展。
    CharlesL
        95
    CharlesL  
       2015-05-28 10:11:32 +08:00
    看V2的大侠们讨论,果然长知识.
    kenken
        96
    kenken  
       2015-05-28 10:25:32 +08:00
    @est 1M的json,那就得分离存储了,特殊情况需要特殊设计。但是1m这情况我这么多年也没遇到,这情况一般人会放到单纯的mysql吗?
    est
        97
    est  
       2015-05-28 10:33:25 +08:00
    @kenken 你永远无法预测用户会给你传什么东西上来。。。。reddit 他们就遇到这个事情了。好像是用户头像哪里?他们忘记做检测了。结果有个用户头像大小是2G。
    kenken
        98
    kenken  
       2015-05-28 10:36:47 +08:00
    @fy 是mysql 5.6
    kenken
        99
    kenken  
       2015-05-28 10:37:54 +08:00
    @zongwan 这个对游戏确实不熟悉,一直在做电商。 像合服我听过,但不了解是怎么操作。
    kenken
        100
    kenken  
       2015-05-28 10:40:37 +08:00
    @JoeShu 对,我们是电商,对事务要求极其严格,而且行级锁性能是非常高的。
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3658 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 04:20 · PVG 12:20 · LAX 20:20 · JFK 23:20
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.