我们设计关系数据库Schema的都有一套完整的方案，而NoSQL却没有这些。半年前笔者读了本《SQL反模式》的书，觉得非常好。就开始留意，对于NoSQL是否也有反模式？好的反模式可以在我们设计Schema告诉哪里是陷阱和悬崖。NoSQL宣传的时候往往宣称是SchemaLess的，这会让人误解其不需要设计Schema。但如果不意识到设计Schema的必要，陷阱就在一直在黑暗中等着我们。这篇文章就总结一些别人的，也有自己犯过的深痛的设计Schema错误。
NoSQL数据库最主流的有文档数据库，列存数据库，键值数据库。三者分别有代表作MongoDB，HBase和Redis。如果将NoSQL比作兵器的话，可以这样(MySQL是典型的关系型数据库，一样参与比较)：">
MySQL产生年代较早，而且随着LAMP大潮得以成熟。尽管其没有什么大的改进，但是新兴的互联网使用的最多的数据库。就像传统的菜刀，结构简单，几百年没有改进。但是不妨碍产生各式各样的刀法，只要有一把，就能胜任厨房里的大部分事务。MySQL也是一样，核心已经稳定。但是切库，分表，备份，监控，等等手段一应俱全。MongoDB是个新生事物，提供更灵活的Schema，Capped Collection，异步提交，地理位置索引等五花十色的功能。就像瑞士军刀，不但可以当刀用，还可以开瓶盖，剪指甲。但是他也不比MySQL强，因为还缺乏时间的磨砺。一是系统本身的稳定性，二是开发，运维需要更多经验才能流行。HBase是个仗势欺人的大象兵。依仗着Hadoop的生态环境，可以有很好的扩展性。但是就像象兵一样，使用者需要养一头大象(Hadoop),才能驱使他。Redis是键值存储的代表，功能最简单。提供随机数据存储。就像一根棒子一样，没有多余的构造。但是也正是因此，他的伸缩性特别好。就像悟空手里的金箍棒，大可捅破天，小能成缩成针。文档数据库的得失
关系模型试图将数据库模型和数据库实现分开，让开发者可以脱离底层很好的操作数据。但笔者以为关系模型在一些应用场景下有弱点，现在已经不得不面对。
SQL弱点一：必须支持Join。因为数据不能够有重复。所以使用范式的关系模型会不可避免的大量Join。如果参与Join的是一张比内存小的表还好。但是如果大表Join或者表分布在多台机器上的话，Join就是性能的噩梦。SQL弱点二：计算和存储耦合。关系模型作为统一的数据模型既可以用于数据分析，也可以用于在线业务。但这两者一个强调高吞吐，一个强调低延时，已经演化出完全不同的架构。用同一套模型来抽象显然是不合适的。Hadoop针对的就是计算的部分。MongoDB,Redis等针对在线业务。两者都抛弃了关系模型。
针对这两个梦魇。文档数据库如MongoDB的的主要目的是提供更丰富的数据结构来抛弃Join来适应在线业务。当然也不是MongoDB完全不能用Join，不能拿来做数据分析，讨论这个只是见仁见智的问题。所以文档数据库并不比关系数据库强大，由于对Join的弱支持，功能会弱许多。设计关系模型的时候，通常只需要考虑好数据直接的关系，定义数据模型。而设计文档数据库模型的时候，还需要考虑应用如何使用。因此设计好一个的文档数据库Schema比设计关系模型更加的困难。除此之外，由于文档数据库事务的支持也是比较弱，一般NoSQL只会提供一个行锁。这也给设计Schema更加增加了难度。对于文档数据库的使用有很多需要注意的地方，本文只关注模型设计的部分。
反模式一：惯性思维/沿用关系模型
关系模型是数据存储的经典模型，使用数据模型范式的好处非常的明显。但是由于文档数据库不支持Join(包括和外键息息相关的外键约束)等特性，习惯性的沿用关系模型有的时候会出现问题。需要利用起文档数据库提供的丰富的数据模型来应对。
值得一提的是文档数据库的设计和关系模型不同，是灵活多样的。对于同一个情形，可以设计出有多种能够工作的模型，没有绝对意义上最好的模型。
下图是关系模型和文档模型的对比。
关系模型 VS 文档模型
这个一个博客的数据模型，有Blog,User等表。左侧是关系模型，右侧是文档模型。这个文档模型并不是完全合理，可以作为“正反两面教材”在下文不断阐述。
问题一：存在描述多对多的关系表症状：文档数据库中存储在有纯粹的关系表，例如：
id user_id blog_id 0 0 0 1 0 1 这样的表就算在关系模型中也是不妥的，因为这个ID非常的多余，可以用联合主键来解决。但是在文档数据库中，由于必须强制单主键，不得不采取这样的设计。
坏处：
破坏数据完备性。由于ID是主键，在数据模型上没有约束来保证不出现重复的user_id,blog_id对。一旦数据出现重复，更新删除都是问题。索引过多。由于是关系表，必须在user_id和blog_id上面分别建一个索引。影响性能。
解决方案：使用文档数据库典型的处理多对多的办法。不是建立一张关系表，而是在其中一个文档(如User)中，加入一个List字段。
user_id user_name blog_id[] …… 0 Jake 0,1 …… 1 Rose 1,2 ……
问题二:没有区分"一对多关系"和“多对一关系”症状：关系模型不区分“一对多”和“多对一”，对于文档数据库来讲，关系模型只有“多对一”。就像这张Comment表：
comment_id user_id content …… 0 0 “NoSQL反模式是好文章” …… 1 0 “是氨 ……
如果整个模型都是这样的“多对一”关系就需要反思了。
坏处：
额外索引。如果客户端已知user_id,需要获得User信息和Comment信息，需要执行两次查询。其中一次查询需要使用索引。并且要在客户端自己Join。这样可能有潜在性能问题。
解决方案：问题的核心在于是已知user_id查询两张表，还是已知comment_id查询两张表。如果是已知comment_id这样的设计就是合理的，但是如果是已知user_id来查询，把关系放在user表里的设计更合理一些。
user_id user_name comment_id[] …… 0 Jake 0,1 …… 1 Rose 1,2 ……
这样的设计，就可以避免一个索引。同理，对于多对多也是一样的，通过合理的安排字段的位置可以避免索引。
正确使用的场合：
关系型模型是非常成功的数据模型，合理的沿用是非常好的。但是由于文档数据库的特点，需要适当的调整，这样得出的数据模型，尽管性能不是最优，但是有最好的灵活性。并且也有利于和关系数据库转换。
反模式二：处处引用客户端Join
症状：数据库设计中充满了xx_id的字端，在查询的时候需要大量的手动Join操作。就涉及到了这个反模式。正如上面提到的博客的关系模型，如果已知blog_id查询comments，需要至少执行3次查询，并且手动Join。
坏处：
手动Join，麻烦且易出错。文档数据库不支持Join且没有外键保证。因此需要在客户端Join，这样的操作对于软件开发来讲是比较繁琐的。由于没有外键保证，因此不能保证取得的ID在数据库里面是有数据的。在处理的时候需要不断判断，容易出错。多次查询。如果引用过多，查询的时候需要多次查询才能查到足够的数据。本来文档数据库是很快的，但是由于多次查询，给数据库增加了压力，获取全部数据的时间也会增加。事务处理繁琐。文档数据库一般不支持一般意义上事务，只支持行锁。如果文档数据库有给多个连接。在插入的时候，事务的处理就是噩梦。在文档数据库中使用事务，需要使用行锁，在进行大量的处理。太过繁琐，感兴趣的读者可以搜一下。
解决方案：适当使用内联数据结构。由于文档数据库支持更复杂的数据结构可以将引用转换为内联的数据，而不用新建一张表。这样做可以解决上面的一些问题，是一个推荐的方案。就像上面博客的例子一样。将五张表简化成了两张表。那什么时候使用内联呢？一般认为
使用内联可以解决读性能问题，明显减少Query的次数的时候。可以简化数据模型，化简表之间的关系，而同时不会影响灵活性的时候。事务可以得到简化为单行事务的时候正确使用的场合：
范式化的使用场景，文档数据库会被多个应用使用。由于数据库设计无法估计多个应用现在及将来的查询情况，需要极大的灵活性。在这个时候，使用引用比内联靠谱。
反模式三 滥用内联后患无穷
问题一 妨碍到查询的内联症状：频繁查询一些内联字段，丢弃其他字段。
坏处：
无ID约束：使用内联字段和引用不同，是没有ID约束的。因此不能通过ID(主键)来管理，如果经常需要单独操作内联对象会非常不便。索引泛滥：如果以内联字段为条件进行查询，需要建立索引。有可能造成索引泛滥。性能浪费：大部分文档数据库的实现是按行存储的，也就意味着，尽管只查询一个字段，但是DB需要将整行从磁盘中取出。如果字段够小，文档够大，是很不合算的。
解决方案：如果出现以上的症结，就可以考虑使用引用代替内联了。内联特性主要的用途在于提高性能，如果出现性能不升反降，那就没有意义了。如果对性能有很强烈的要求，可以考虑使用重复数据，同样的数据即在内联字段中也在引用的表里面。这样可以结合内联和引用的性能优势。缺点是数据出现重复，维护会比较麻烦。
问题二 无限膨胀的内联症状：List,Map类型的内联字段不断膨胀，而且没有限制。就像前面提到的Blog的内联字段Comment。如果对每一篇Blog的Comment数量没有限制的话，Comment会无限膨胀。轻则影响性能，重则插入失败。
Blog_id content Comment[] …… 0 “…” “NoSQL反模式是好文章”, “是氨,”无限增长中”… …… 坏处：
插入失败。文档数据库的每条记录都有最大大小，并且也有推荐最佳的大校一般不会超过4M。就像刚刚提到的例子，如果是篇热门的博文的话，评论的大小很容易就超过4M。届时文档将无法更新，新的评论无法插入。性能拖油瓶。由于内联字段膨胀，其大小将远远超过其他部分，影响其他部分的性能表现。并且因此导致该记录大小频繁变化，对档数据库的数据文件内部可能因此产生很多碎片。
解决方案：设定最大数目或者使用引用。还是Blog和Comment的例子，可以将Comment从Blog中剥离出成一张表。如果考虑到性能，可以在Blog表中新建一个字段如最近的评论。这样既保证了性能，又能够预防膨胀。
Blog_id content last_five_comment[] …… 0 “…” “NoSQL反模式是好文章”, “是氨,”最多5条”… …… 问题三 无法维护的内联症状：DBA想单独维护内联字段，但无法做到。
坏处：
权限管理难。数据库的权限管理的最小粒度是表。如果使用内联技术，就意味着内联部分必须和其他字段用同一个权限来管理。没有办法在DB级别隐藏。切表难。如果发现一张表的庞大需要切表。这个时候就比较纠结了。如果一刀切，partion Key的选择；索引的失效都会成为问题。如果觉得拆为两张表，就会很好操作的话，就是内联的过度使用了 。备份难。关系数据库中每张表可以有不同的备份策略。但是如果内联起来，这样的备份就做不到了。解决办法：设计数据库模型的时候需要考量之后的维护操作，尤其是内联的字段需不需要单独的维护。需要和运维商量。如果对内联的字段有单独维护的要求，可以拆分出来作为引用。
问题四 盯死应用的内联症状：应用可以非常好的运行在数据库上。但是当新的应用接入的时候会很麻烦。因为设计数据模型的时候考虑到了查询。所以当有新应用，新查询接入的时候，就会难于使用原有的模型。
坏处：
新应用接入难。当新的应用试图使用同一个数据库的时候，接入比较困难。因为查询时不同的，需要调整数据模型才能适应。但是调整模型又会影响原有应用。集成难。不同的关系型数据库可以集成在一起，共同使用。但是对于文档数据库，虽然功能上可以互补，但是由于内联数据结构的差异，也比较难于集成。ETL难。现在大部分的数据分析系统使用的是关系模型，就连Hadoop虽然不用关系模型，但是其上的Hive的常用工具也是按关系模型设计的。
解决方案：
使用范式设计数据库，即用引用代替内联。或者在使用内联的时候，给每个内联对象一个全局唯一的Key，保证其和关系模型直接可以存在映射关系，这样可以提高数据模型的灵活性。如Blog表：
Blog_id content Comment[] …… 0 “…” [{"id"=1,"content"=“NoSQL反模式是好文章”}, {"id"=2,"content"=“是氨}…] ……
这样的设计既可以利用到内联的好处，又能将其和关系模型映射起来。确定是需要手动维护comment_id，保证其全局唯一性。
反模式四：在线计算
症状：有一些运行时间很长的Query,由于有聚合计算，索引也不能解决。随着数据量的增长，逐渐成为性能瓶颈。
坏处：
影响用户体验。在线业务中，如果一个查询大于4s，用户体验会急剧下降。按主键和按索引的查询都能满足要求。但是聚合操作往往需要扫描全表或者大量的数据，随着数据量的增加，查询时间会变长，用户不可容忍。影响数据库性能。长查询的坏处数不清。在线上应用中，如果出现长查询，可能会霸占数据的大部分资源，包括IO，连接，CPU等等。导致其他很好的查询，轻则性能也下降，重者无法使用数据库。长查询可以称之为DB杀手。
解决方案：首先要权衡，这个聚合操作是不是必要的，必须实时完成。如果没有必要实时完成的话，可以采取离线操作的方案。在夜深人静的时候，跑一个长查询，将结果缓存起来，给第二天使用。如果必须实时完成，则可以新建一个字段，用“incr”这样的操作，在运行的时候，实时聚合结果。而不是查询的时候执行一次长查询。如果逻辑比较复杂，或者觉得大量“incr”操作给数据库系统带来了压力，可以使用Storm之类的实时数据处理框架。总之，要慎用长查询。
反模式五：把内联Map对象的Key当作ID用
症状：文档数据库支持内联Map类型。将其中Map的Key当作数据库的主键来用。
Blog_id content Comment{} …… 0 “…” {"1"=“NoSQL反模式是好文章”, "2"=“是氨} …… 这个反模式很容易犯，因为在编程语言中Map数据结构就是这么用的。但是对于数据库模型来说，这是不折不扣的反模式。
坏处：
无法通过数据库做各种(><=)查询。对于关系型数据库来说，虽然数据结构可以很灵活，但查询的时候都是按层次的。比如comment.id，comment.content。也就是说其Map类型中的Key可以理解为属性名的，而不是用作ID。因此一旦这样使用，就脱离的数据库管制，无法使用各种查询功能。无法通过索引查询。文档数据可建立索引是需要列名的。比如comment.id。而这样的数据结构没有固定的列名，因此无法建立索引。
解决方案：使用数组+Map来解决。如：
Blog_id content Comment[] …… 0 “…” [{"id"=1,"content"=“NoSQL反模式是好文章”}, {"id"=2,"content"=“是氨}…] …… 这样，就可以使用comment.id作为索引，也可以使用数据库的查询功能。简单有效。Map类型中的Key是属性名，Value是属性值。这样的用法是文档数据库数据模型的本意，因此其提供的各种功能才能利用上。否则就无法使用。
反模式六：不合理的ID
症状：使用String甚至更复杂数据结构作为的ID，或者全部使用数据库提供的自生成ID。如：
id(该ID系系统自生成） Blog_id content …… 0 0 ... …… 坏处:
ID混乱。如果使用数据库提供的自生成ID，同时表中还有一个类似有主键含义的Blog_id，这样很不好，容易造成逻辑混乱。由于文档数据库不支持ID的重命名，习惯关系数据库做法的人可能会再建立一个自己的逻辑ID字段。这是没有必要的。索引庞大，性能低下。ID是数据库的非常重要的部分。ID的长度将决定索引(包括主键的索引)的大小，直接影响到数据库性能。如果索引比内存小，性能会很好。但一旦索引大小超过内存，出现数据交换，性能会急剧下降。一个Long占8字节，一个20个字符的UTF8 String占用约60个字节。相差10倍之巨，不能不考虑。
解决方案：尽量使用有一定意义的字段做ID，并且不在其他字段中重复出现。不使用复杂的数据类型做ID，只使用int,long或者系统提供的主键类型做ID。
文档数据库的反模式总结
阐述了这么多的反模式，下面有个一览表，涵盖了上面所有的反模式。这个一览表，是按照文档数据库模型建立的。是个文档数据库模型的例子。
ID 反模式名 问题 0 存在描述多对多的关系表 [{ID：00
症状：文档数据库中存储在有纯粹的关系表
坏处：[破坏数据完备性，索引过多]
解决方案：加入一个List字段
},{
ID：01
症状：关系模型不区分“一对多”和“多对一”
坏处：额外索引
解决方案：合理的安排字段的位置
}] 1 处处引用客户端Join [{
ID：10
症状：查询的时候需要大量的手动Join操作
坏处：[手动Join，多次查询, 事务处理繁琐]
解决方案：适当使用内联数据结构。
}] 2 滥用内联后患无穷 [{
ID：20
症状：频繁查询一些内联字段，丢弃其他字段
坏处：[无ID约束，索引泛滥, 性能浪费]
解决方案：使用引用代替内联了,允许重复数据
},{
ID：21
症状：List,Map类型的内联字段不断膨胀，而且没有限制
坏处：[插入失败, 性能拖油瓶]
解决方案：设定最大数目或者使用引用。
},{
ID：22
症状：DBA想单独维护内联字段，但无法做到
坏处：[权限管理难, 切表难, 备份难]
解决方案：设计数据库模型的时候需要考量之后的维护操作
},{
ID：23
症状：应用可以非常好的运行在数据库上。但是当新的应用接入的时候会很麻烦。内联盯死了应用
坏处：[新应用接入难, 集成难, ETL难]
解决方案：使用范式设计数据库，即用引用代替内联。保证其和关系模型直接可以存在映射关系
}] 3 在线计算 [{
ID：30
症状：有一些运行时间很长的Query, 逐渐成为性能瓶颈。
坏处：[影响用户体验，影响数据库性能]
解决方案：取消不必要的聚合操作. 运行的时候，实时聚合结果.使用第三方实时或非实时工具。如Hadoop，Storm.
}] 4 把内联Map对象的Key当作ID用 [{
ID：40
症状：文档数据库支持内联Map类型。将其中Map的Key当作数据库的主键来用。
坏处：[无法通过数据库做各种(><""" =)查询，无法通过索引查询]
解决方案：使用数组+Map来解决。
}] 5 不合理的ID [{
ID：50
症状：用String甚至更复杂数据结构作为的ID，或者全部使用数据库提供的自生成ID。
坏处：[ID混乱，索引庞大]
解决方案：尽量使用有一定意义的字段做ID。不使用复杂的数据类型做ID。
}]
本文试图总结了笔者知道的重要的文档数据库的反模式。现在关于NoSQL数据模型设计模式的讨论才刚刚起步，将来也许会逐渐自成体系。对于列数据库和Key-Value的反模式，笔者等到有了足够积累的时候，再和大家分享。
