58同城大数据量架构挑战：100亿帖子的属性查询优化

"这篇文档主要讨论的是在大数据量和复杂查询需求背景下，如何进行数据库架构设计，特别是针对帖子业务的问题。作者是具有丰富经验的前百度高级工程师、58同城和58到家的高级架构师，他分享了从初级解决方案到优化解决方案的过程，以及在面对100亿数据量、10万并发开发、1万属性和复杂查询时的思考。 （1）需求背景 帖子业务是58同城的核心，拥有10亿级别的帖子量，每秒处理几十万级别的查询请求，同时每个品类的属性各不相同，接近一万种，且各种属性组合都有查询需求。这种业务对数据库架构提出了严峻挑战。 （2）初级解决方案 初版设计考虑通过扩展列来创建组合索引以满足组合查询，例如index_1(c1,c2)、index_2(c2,c3)和index_3(c1,c3)。但随着业务的发展和新属性的增加，这样的设计很快就会面临索引数量过多和三属性查询无法处理的问题。初期的帖子表设计是tiezi(tid,uid,c1,c2,c3)，后来为了适应房产类别，扩展为tiezi(tid,uid,c1,c2,c3,c10,c11,c12,c13)。 （3）潜在解决方案 另一种尝试是进行垂直拆分，为每个业务（如招聘和房产）创建独立的帖子服务和搜索服务，如tiezi_zhaopin和tiezi_fangchan。虽然这种方法看似提高了业务灵活性，但在实际操作中，如需跨业务查询（如按uid查询用户发布的所有帖子）则变得复杂。 （4）优化解决方案 对于上述问题，优化可能涉及到更复杂的架构设计，如使用分布式数据库系统，比如水平分区（Sharding）、数据切片（Partitioning）、读写分离、缓存策略等，以解决大规模数据和高并发查询的问题。同时，可能需要引入NoSQL数据库来处理异构属性，并使用搜索引擎如Elasticsearch来支持高效的全文本和多属性组合查询。此外，可能还需要建立服务化架构，通过API Gateway进行统一的请求路由和授权，以及利用微服务理念让每个业务线独立发展和维护自己的数据存储。 （5）总结 数据库架构设计是应对大数据和复杂业务的关键，需要平衡灵活性、扩展性和维护性。在设计时，要考虑业务的长远发展，避免因短期需求而做出的决策导致长期的技术债务。同时，持续学习和跟踪最新的数据库技术趋势也是至关重要的，以确保架构能够适应不断变化的业务需求。"