数据分区设计：数据量决定复杂度，及三种地理粒度分区规则

设计一个良好的[[数据分区架构的产生背景：硬件故障级高可用应付不了地理级灾难]]要考虑两个关键前置维度。第一是数据量：数据量的大小直接决定了分区规则的复杂程度，不是简单的线性扩展关系——比如用MySQL存储、单台服务器能撑500GB，2TB数据只需要4台服务器平行管理就够了，但如果数据量是200TB，绝不是简单地把服务器数量扩到800台就完事：800台规模的集群，几乎每周都可能有一两台出故障，从800台里精准定位出故障的那两台，运维复杂度本身就急剧上升；新增服务器往往还要连带修改分区相关的配置甚至规则，而这类改动理论上随时可能波及已有800台服务器的正常运行，实践中改错配置这种事情并不少见；而且如此海量的数据如果地理位置上全部扎堆在一个城市，风险很大——一旦遇到水灾、大停电这类灾难性故障，数据可能整体丢失，因此分区规则天然需要把地理容灾也考虑进去。总结来说，数据量越大，分区规则要考虑的情况就越复杂。第二是分区规则本身：地理位置有远有近，可以粗分为洲际分区、国家分区、城市分区三种粒度，具体用哪种或哪几种组合要综合考虑业务范围和成本。洲际分区面向不同大洲的用户提供服务，但跨洲通信的网络延迟已经大到不适合直接支撑在线服务，所以洲际间的数据中心通常不互通、或者仅仅作为彼此的备份而非同时对外服务；国家分区面向不同国家的用户提供服务，考虑到不同国家的语言、法律、业务规则差异，国家间的分区一般也只作备份用；城市分区则因为都在同一个国家或地区内、网络延迟本身较低、业务需求相似，可以做到多个分区同时对外提供服务，这正是支撑”业务异地多活”这类需求的地理粒度基础。