admin1973的专栏

一、需求缘起分页需求互联网很多业务都有分页拉取数据的需求，例如：（1）微信消息过多时，拉取第N页消息（2）京东下单过多时，拉取第N页订单（3）浏览58同城，查看第N页帖子 这些业务场景对应的消息表，订单表，帖子表分页拉取需求有这样一些特点：（1）有一个业务主键id, 例如msg_id, order_id, tiezi_id

一、一些常见的SQL实践（1）负向条件查询不能使用索引select * from order where status!=0 and stauts!=1not in/not exists都不是好习惯可以优化为in查询：select * from order where status in(2,3) （2

假设订单业务表结构为：order(oid, date, uid, status, money, time, …)其中：oid，订单ID，主键date，下单日期，有普通索引，管理后台经常按照date查询uid，用户ID，有普通索引，用户查询自己订单status，订单状态，有普通索引，管理后台经常按照status查询mon

一、缘起《100亿数据1万属性数据架构设计》文章发布后，不少朋友对58同城自研搜索引擎E-search比较感兴趣，故专门撰文体系化的聊聊搜索引擎，从宏观到细节，希望把逻辑关系讲清楚，内容比较多，分上下两期。 主要内容如下，本篇（上）会重点介绍前三章：（1）全网搜索引擎架构与流程（2）站内搜索引擎架构与流程（3）搜索原理、流程与核心数据结构（4

转载自：http://mp.weixin.qq.com/s/DVjUKkArMaKSb2hTGTpiVg一、如何通过连接访问下游工程架构中有很多访问下游的需求，下游包括但不限于服务/数据库/缓存，其通讯步骤是为：（1）与下游建立一个连接（2）通过这个连接，收发请求（3）交互结束，关闭连接，释放资源 这个连接是什么呢，通过连接怎么调用下游接

对于version + ext方案，还是有很多朋友质疑“线上不可能这么用”。本篇将讲述一下58同城最核心的数据“帖子”的架构实现技术细节，说明不仅不是“不可能这么用”，而是大数据，可变属性，高吞吐场景下的“常用手段”。 一、背景描述及业务介绍问：什么是数据库扩展的version + ext方案？使用ext来承载不同业务需求的个性化属性，使用version来标识e

一、问题的提出互联网有很多“数据量较大，并发量较大，业务复杂度较高”的业务场景，其典型系统分层架构如下：（1）上游是业务层biz，实现个性化的业务逻辑（2）中游是服务层service，封装数据访问（3）下游是数据层db，存储固化的业务数据 服务化分层架构的好处是，服务层屏蔽下游数据层的复杂性，例如缓存、分库

一、什么是高可用高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务，我们说系统的可用性是100%。如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系

一、缘起（1）并发量大，流量大的互联网架构，一般来说，数据库上层都有一个服务层，服务层记录了“业务库名”与“数据库实例”的映射关系，通过数据库连接池向数据库路由sql语句以执行：如上图：服务层配置用户库user对应的数据库实例物理位置为ip（其实是一个内网域名）。 （2）随着数据量的增大，数据要进行水平切分，分库后将数据分布到不同的数据库实例（甚至物

一、缘起当数据库的数据量非常大时，水平切分和垂直拆分是两种常见的降低数据库大小，提升性能的方法。假设有用户表：user(uid bigint,name varchar(16),pass varchar(16),age int,sex tinyint,flag tinyint,sign varchar(64),intro

军规适用场景：并发量大、数据量大的互联网业务军规：介绍内容解读：讲解原因，解读比军规更重要 一、基础规范（1）必须使用InnoDB存储引擎解读：支持事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高 （2）必须使用UTF8字符集解读：万国码，无需转码，无乱码风险，节省空间 （3）数据表、数

军规：必须使用UTF8字符集和DBA负责人确认后，纠正为“新库默认使用utf8mb4字符集”。这点感谢网友的提醒，utf8mb4是utf8的超集，emoji表情以及部分不常见汉字在utf8下会表现为乱码，故需要升级至utf8mb4。默认使用这个字符集的原因是：“标准，万国码，无需转码，无乱码风险”，并不“节省空间”。一个潜在坑：阿里云上RDS服务如果要从

缘起：有个朋友问我分区表在58的应用，我回答不出来，在我印象中，百度、58都没有听说有分区表相关的应用，业内进行一些技术交流的时候也更多的是自己分库分表，而不是使用分区表。于是去网上查了一下，并询问了58到家的DBA专家，将自己收到的信息沉淀下来，share给大伙。 解决什么问题？回答：当mysql单表的数据库过大时，数据库的访问速度会下降，“数据量大”问题的常见解决方案是

Canal增量同步MySQL数到Elasticsearch调研背景由于业务发展迅速,店铺商品分库越来越多(目前已有8个MySQL分库)且分库中表数据行数越来越大,大的表已经达到了5KW+,业务需要对商品模糊查询或根据其他字段查询,这些查询的字段很多在数据库中都没有索引,查询命中数据很慢(有些数据根本就查询不出来)且会给数据库库带来很大的压力.所以目前希望将MySQL中的商品数据实时同步到E...