收藏本站 | RSS订阅纳米科技-纳米资讯-纳米新闻
你现在的位置:首页 » 科技产品 » 正文
09月14日

在数据库系统中遇见"存储技术飞跃"会怎样?

作者 : admin | 分类 : 科技产品 | 超过 9 人围观 | 已有 0 人发表了看法
原标题:在数据库系统中遇见"存储技术飞跃"会怎样?
  • 上个月初,在Percona的博客中看到一篇关于计算存储的性能测试文章(详见文末的链接),其中提到的一些特性,引起了我的一些兴趣,于是,又扩展研究了一下计算存储相关的技术,突然发现计算存储这块对数据库系统来说,或许能多多少少解决一些瓶颈与痛点、甚至还能够在不影响性能的前提下大幅度降低TCO。是什么样的特性有如此魔力呢?

  • 这里先卖个关子,文中提到的内容我们稍后再说,我们先来看看数据库系统的生命周期管理中,可能碰到哪些瓶颈与痛点。然后,再介绍计算存储是如何系统性地化解这些瓶颈与痛点的。

  • PS:以下内容仅代表个人观点。另外,由于本人对MySQL比较熟悉,下面以MySQL InnoDB引擎为例简单列举几个典型的痛点进行阐述

上个月初,在Percona的博客中看到一篇关于计算存储的性能测试文章(详见文末的链接),其中提到的一些特性,引起了我的一些兴趣,于是,又扩展研究了一下计算存储相关的技术,突然发现计算存储这块对数据库系统来说,或许能多多少少解决一些瓶颈与痛点、甚至还能够在不影响性能的前提下大幅度降低TCO。是什么样的特性有如此魔力呢?

这里先卖个关子,文中提到的内容我们稍后再说,我们先来看看数据库系统的生命周期管理中,可能碰到哪些瓶颈与痛点。然后,再介绍计算存储是如何系统性地化解这些瓶颈与痛点的。

PS:以下内容仅代表个人观点。另外,由于本人对MySQL比较熟悉,下面以MySQL InnoDB引擎为例简单列举几个典型的痛点进行阐述

1、数据库系统中典型的瓶颈与痛点有哪些?

  • 数据库性能的两个关键指标:(latency)与事务的并行数量(tps),两者相辅相成,且成反比,事务的latency越低,则允许tps就越高,反之,事务的latency越高,则允许的tps就越低。越高的tps就代表着越好的性能,反之就代表越低的性能。数据库对IO的响应延迟非常敏感,其直接影响着事务的响应延迟,而事务的响应延迟则在很大程度上决定着数据库的tps高低。因此,在一个硬件规格配置合理的服务器中运行MySQL数据库,且MySQL的索引使用比较规范的场景中,我们常常能够看到最先达到瓶颈的就是IO子系统

  • 围绕着这2个关键指标,我这里罗列了4个可能出现瓶颈与痛点的典型场景,如下

数据库性能的两个关键指标:(latency)与事务的并行数量(tps),两者相辅相成,且成反比,事务的latency越低,则允许tps就越高,反之,事务的latency越高,则允许的tps就越低。越高的tps就代表着越好的性能,反之就代表越低的性能。数据库对IO的响应延迟非常敏感,其直接影响着事务的响应延迟,而事务的响应延迟则在很大程度上决定着数据库的tps高低。因此,在一个硬件规格配置合理的服务器中运行MySQL数据库,且MySQL的索引使用比较规范的场景中,我们常常能够看到最先达到瓶颈的就是IO子系统

围绕着这2个关键指标,我这里罗列了4个可能出现瓶颈与痛点的典型场景,如下

1.1. 单台数据库服务器存储能力不足

  • 存储容量不足

存储容量不足

展开全文
  • 传统解决方案

传统解决方案

* 时间紧迫时,可通过频繁删除文件来腾挪空间来临时解决

* 预算充足时,可更换更大容量的存储设备,做数据全量迁移

* 预算、时间充足时,可添加更多服务器做数据拆分

  • 存储负载过高(吞吐量过高)

存储负载过高(吞吐量过高)

  • 传统解决方案:

传统解决方案:

* 时间紧迫时,可以通过杀死存储吞吐量消耗最大的进程来临时解决

* 预算充足时,更换更高吞吐带宽的存储设备,做数据全量迁移

* 预算、时间充足时,可添加更多服务器做数据拆分

  • 缺点:

缺点:

  • 临时解决方案需要频繁关注存储的负载情况,而且常常顾此失彼

  • 更换配件需要增加额外的成本,做数据拆分更是增加了业务的复杂度和维护成本、而且还引入了一些新的问题(详见"1.4. 并发查询数过高导致数据库实例负载过高"中提到的缺点)

临时解决方案需要频繁关注存储的负载情况,而且常常顾此失彼

更换配件需要增加额外的成本,做数据拆分更是增加了业务的复杂度和维护成本、而且还引入了一些新的问题(详见"1.4. 并发查询数过高导致数据库实例负载过高"中提到的缺点)

1.2. 数据库服务器内存不足

  • 传统解决方案:

传统解决方案:

  • 临时清理不需要的表数据或者调小MySQL在各种缓存分配上的参数值,以便腾出 多的内存来使MySQL Server能够做更多的事情

  • 增加物理内存,并调大MySQL的各种缓冲分配参数值

临时清理不需要的表数据或者调小MySQL在各种缓存分配上的参数值,以便腾出 多的内存来使MySQL Server能够做更多的事情

增加物理内存,并调大MySQL的各种缓冲分配参数值

  • 缺点:

缺点:

  • 临时解决方案需要持续关注内存使用量,且需要频繁地操作,而且,这是挖东墙补西墙的做法

  • 增加物理内存,除了增加成本之外,还会对业务造成一定影响(服务器需要关机)

临时解决方案需要持续关注内存使用量,且需要频繁地操作,而且,这是挖东墙补西墙的做法

增加物理内存,除了增加成本之外,还会对业务造成一定影响(服务器需要关机)

1.3. 单个事务过大导致查询性能低下

  • 传统解决方案:将大事务拆分成小事务

传统解决方案:将大事务拆分成小事务

  • 无法拆分的大事务,在硬件规格不变的前提下,可以对读写事务分别做一些优化。例如:写可以在执行前,会话级别将binlog格式修改为statement,以减少主从实例之间传输的binlog日志量;读事务可以拆分到只读从库中,以减少主库的访问压力

无法拆分的大事务,在硬件规格不变的前提下,可以对读写事务分别做一些优化。例如:写可以在执行前,会话级别将binlog格式修改为statement,以减少主从实例之间传输的binlog日志量;读事务可以拆分到只读从库中,以减少主库的访问压力

  • 缺点:

缺点:

  • 将大事务拆分成小事务,并不会让原本大事务需要完成的工作任务少做一些,而是拆分成小事务之后,降低对其他并行事务的影响(例如:大事务可能长时间的持有锁、二进制日志文件句柄资源等,从而导致长时间的阻塞其他并行事务,导致并行事务执行失败)

将大事务拆分成小事务,并不会让原本大事务需要完成的工作任务少做一些,而是拆分成小事务之后,降低对其他并行事务的影响(例如:大事务可能长时间的持有锁、二进制日志文件句柄资源等,从而导致长时间的阻塞其他并行事务,导致并行事务执行失败)

1.4. 并发查询数过高导致数据库实例负载过高

  • 传统解决方案:

传统解决方案:

  • 杀死高负载查询会话、后续优化慢查询

  • 读写分离,并增加只读从库,扩展只读能力

  • 数据拆分,将数据分散到多个数据库实例中,扩展读/写能力。

杀死高负载查询会话、后续优化慢查询

读写分离,并增加只读从库,扩展只读能力

数据拆分,将数据分散到多个数据库实例中,扩展读/写能力。

* 对大表做数据拆分,先做垂直拆分(按业务拆分,将不同业务的字段拆分到不同的表、或不同的数据库、甚至不同的实例中),然后做水平拆分(对于无法继续拆分字段的表,如果数据量仍然大到影响性能,则可能还需要以不超过1000W行数据量的标准继续对大表执行拆分,即就是我们常说的数据分片)

  • 缺点:无论是垂直拆分还是水平拆分,都需要应用配合相应的改造,而且,数据拆分之后,会引入新的痛点,类似如下(虽然这些痛点可以通过技术改造来解决,但成本过高,而且需要较长时间来磨合才能够使其达到稳定,另外,可能需要和业务深度契合改造,不同的客户可能需要做不一样的改造):跨分片访问,导致不得不启用分布式事务来保证跨分片访问的数据一致性,而分布式事务本身除了实现起来有一定工程量之外,应用本身也需要配合改造

缺点:无论是垂直拆分还是水平拆分,都需要应用配合相应的改造,而且,数据拆分之后,会引入新的痛点,类似如下(虽然这些痛点可以通过技术改造来解决,但成本过高,而且需要较长时间来磨合才能够使其达到稳定,另外,可能需要和业务深度契合改造,不同的客户可能需要做不一样的改造):跨分片访问,导致不得不启用分布式事务来保证跨分片访问的数据一致性,而分布式事务本身除了实现起来有一定工程量之外,应用本身也需要配合改造

  • 如果分片跨了不同的实例,则无法做到数据的全局一致性备份,要实现跨实例多数据分片的全局数据一致性备份,需要中间件、数据库都做一些改造

  • 不受事务控制的DDL语句,无法通过分布式事务来保证数据的全局一致性,因此,还需要额外的机制来保证数据的全局一致性

  • 如果分片数据出现倾斜、或者访问负载出现倾斜,则还可能需要频繁地做分片数据的迁移(将大数据量的分片、高负载实例中的分片,迁移到较为空闲的实例中)

如果分片跨了不同的实例,则无法做到数据的全局一致性备份,要实现跨实例多数据分片的全局数据一致性备份,需要中间件、数据库都做一些改造

不受事务控制的DDL语句,无法通过分布式事务来保证数据的全局一致性,因此,还需要额外的机制来保证数据的全局一致性

如果分片数据出现倾斜、或者访问负载出现倾斜,则还可能需要频繁地做分片数据的迁移(将大数据量的分片、高负载实例中的分片,迁移到较为空闲的实例中)

2、计算存储是如何解决数据库的瓶颈与痛点的?

  • 针对计算存储,我这里列出3个我认为比较重要的特性,先对其原理做简单的介绍(关于相关原理的详细介绍,可参考文末的链接),然后再说说这些特性是如何解决上述数据库的瓶颈与痛点的

针对计算存储,我这里列出3个我认为比较重要的特性,先对其原理做简单的介绍(关于相关原理的详细介绍,可参考文末的链接),然后再说说这些特性是如何解决上述数据库的瓶颈与痛点的

  • 第一个重要的特性:存储支持硬件级别的原子写

第一个重要的特性:存储支持硬件级别的原子写

  • 数据库为何需要原子写?

数据库为何需要原子写?

* InnoDB 数据文件默认的Page Size为16k,文件系统默认的块大小为4k,也就是说,InnoDB数据文件的最小IO操作单位是16k,文件系统最小IO操作单位是4k,当InnoDB数据文件写入一个16k的页到文件系统时,文件系统需要将其分解成4个4k大小的块,再写入到存储设备中。由于大部分的文件系统并不支持原子写,如果文件系统在写入存储设备期间,发生了意外(例如掉电),则可能导致InnoDB的Page Size发生部分写(损坏),进而导致MySQL Server无法正常启动

* 为了避免这个问题,InnoDB引入了doublewrite特性,doublewrite用来做什么的呢?当有数据需要写入数据文件时(即刷脏),先写入doublewrite(MySQL 8.0.20版本之前,doublewrite位于共享表空间ibdata1中,8.0.20版本开始,使用独立的文件存储,且支持多个文件,但文件的最大数量是buffer pool instance的2倍,即每个buffer pool instance有2个doublewrite文件),每次1MB连续写入,数据页写入doublewrite成功之后,再将数据页写入到数据文件中,这样一来,如果发生意外导致数据页发生损坏,则在数据库执行Crash Recovery期间,会尝试从doublewrite中找到发生损坏的页进行覆盖修复,修复之后即可正常启动MySQL Server(注:Redo虽然能够支持数据恢复,但它记录的是数据页的增量修改内容,并不是记录的完整的数据页,但doublewrite中的数据页是完整的,所以,可以使用doublewrite中的完整数据页恢复损坏的数据页,然后就能够正常应用Redo)

* doublewrite分成2个部分,内存中有2M的doublewrite buffer,磁盘文件中也有2个1M的连续doublewrite空间,引入doublewrite之后的数据写入简单示意图如下,从图中我们可以看到,脏数据要成功写入到数据文件中,需要写2次磁盘(一次写入到doublewrite中,一次写入到数据文件中)

在数据库系统中遇见"存储技术飞跃"会怎样?

  • 计算存储支持原子写,对数据库的收益是什么呢?

计算存储支持原子写,对数据库的收益是什么呢?

* 既然存储支持硬件级别的原子写,那么,也就是说,数据库层面的doublewrite特性就可以关掉了,关掉之后,脏数据写入到数据文件只需要一次写磁盘即可,从而节省了一半的刷脏流量。即,在能保证数据页不发生部分写的情况下,直接就能缓解存储吞吐能力不足的燃眉之急!

  • 第二个重要的特性:数据透明压缩/解压

第二个重要的特性:数据透明压缩/解压

  • 数据库为何需要压缩/解压?

数据库为何需要压缩/解压?

* 简单来说,就是在数据量达到一定程度之后,大幅度节省存储成本,降低存储的TCO

  • 什么是数据透明压缩/解压?我们可以从目前几种主流的压缩/解压方式的角度着手来理解

什么是数据透明压缩/解压?我们可以从目前几种主流的压缩/解压方式的角度着手来理解

* 软压缩/解压(即CPU压缩):如下图所示,依赖主机CPU执行压缩与解压运算,存在大量数据复制且复制链路长,且压缩与解压运算逻辑需要应用程序自行实现与控制

在数据库系统中遇见"存储技术飞跃"会怎样?

* 硬件压缩/解压(压缩卡):如下图所示,依赖占用PCI插槽的专用压缩卡执行压缩与解压运算,虽然释放了主机CPU资源,但仍然需要在主机内存与压缩卡之间大量拷贝数据,占用大量的主机带宽资源

在数据库系统中遇见"存储技术飞跃"会怎样?

* 透明压缩/解压:如下图所示,压缩/解压的运算工作,直接由存储卡上集成的计算单元执行,对应用完全透明,数据的压缩与解压完全是在盘内执行,释放主机CPU资源的同时,也释放了主机带宽资源,也不需要在主机内存与压缩卡之间大量拷贝数据(零拷贝),而且,扩展存储卡时可同时扩展压缩/解压的计算单元,能够同时实现并行的压缩/解压运算

在数据库系统中遇见"存储技术飞跃"会怎样?

  • 计算存储支持透明的压缩/解压,对数据库的收益是什么呢?

计算存储支持透明的压缩/解压,对数据库的收益是什么呢?

* 在对应用透明、不占用主机任何资源的前提下,大幅度降低存储成本

* 在存储卡的存储单元中,存放的数据是经过压缩的,因此,大幅度减少存储数据量,对于固态存储元器件来讲,就意味着可以大幅度降低写放大,而写放大的降低能够让固态存储元器件最大化地发挥性能优势,降低IO响应延迟。因此,对于数据库来说,在实现了数据压缩的情况下,能够不影响性能,甚至性能还能有一定提高(尤其是MySQL数据库,在数据量达到一定大小之后,随着压缩比的提升,使用计算存储的透明压缩 + 关闭doublewrite,在某些场景下性能甚至有大幅度的提高)

* 因为压缩功能使得binlog占用物理空间减少,从而也降低因为存储空间不足,清理binlog的频率,同时,由于压缩/解压功能是在盘内进行(写入数据时先由盘内的计算算元进行压缩,然后再存入存储单元;读取时先从存储单元中读取,然后再由盘内的计算单元进行解压),也进一步降低了对存储设备的吞吐带宽的占用

* InnoDB的Buffer Pool主要是用于减少IO操作的,读写IO响应延迟的降低,意味着对主机内存的依赖也就随之减少,也就是说,InnoDB的Buffer Pool可以设置得更小,也就是说,可以进一步释放主机的内存资源,将其更多地用于处理用户的连接请求

  • 第三个重要的特性:计算下推到存储(当然,不同业务需要下推的计算逻辑可能有所不同,因此,不通用的计算逻辑下推,可能需要联合研发)

第三个重要的特性:计算下推到存储(当然,不同业务需要下推的计算逻辑可能有所不同,因此,不通用的计算逻辑下推,可能需要联合研发)

  • 数据库为何需要将计算下推到存储?

数据库为何需要将计算下推到存储?

* 生产环境中实际的查询类型,非等值查询(如:非唯一索引查询、联结表查询等)往往占比较高,而这些查询(尤其是查询条件涉及到多列时),在没有类似MySQL的ICP特性支持的情况下,从存储引擎读取的数据量往往会超过它们真实需要的数据量(例如:满足所有查询条件的数据可能只有10行,而实际上从存储引擎读取的数据量是100行),这是因为MySQL在执行查询时,会选择一个条件列在存储引擎中做数据的检索,将检索到的数据返回到MySQL Server,再用其余的条件列做数据过滤,过滤出满足所有条件的数据,然后再返回给客户端。这个过程中,被过滤掉的数据,其实是一种浪费,如果使用了类似MySQL ICP的特性,则可以将所有的条件列都下推到存储引擎层,直接返回满足所有条件列的数据,就不需要读取不满足所有条件的数据了。

* 虽然MySQL ICP的特性,能够避免从存储引擎读取的不必要的数据,但是,存储引擎层的过滤计算也仍然需要消耗主机CPU资源,能不能够将计算量进一步下推到存储设备呢?能!

  • 什么是计算下推到存储?下面用三个图简单说明计算下推到存储的实现逻辑

什么是计算下推到存储?下面用三个图简单说明计算下推到存储的实现逻辑

* 假设某个存在多个条件列的查询(注:这里假设多个条件列都是索引列,下不赘述),在没有类似MySQL ICP特性支持的情况下,查询执行的流程大致如下图(注意红色字体,下不赘述)。假设查询能够使用到多列索引,则会先使用索引顺序的第一个列进行数据检索(检索列),从存储引擎获取数据,然后,在MySQL Server层使用其余的条件列(过滤列),过滤出满足所有条件的数据

* 如果上述查询,有类似MySQL ICP特性支持的情况下,那么查询就能够避免从存储引擎中读取不满足所有条件的数据了,如下图,将所有的条件列(必须是索引列)都下推到存储引擎层,只读取匹配所有条件列的数据,就不再需要在MySQL Server层做数据过滤了

* 计算下推到存储设备,指的就是在类似MySQL ICP的特性上进一步优化,将计算逻辑下推到存储设备上,进一步释放主机CPU资源和主机的带宽资源,如下图

在数据库系统中遇见"存储技术飞跃"会怎样?

  • 计算存储支持将计算下推到存储设备,对数据库的收益是什么呢?

计算存储支持将计算下推到存储设备,对数据库的收益是什么呢?

* 通过上面的介绍,我想,将类似MySQL ICP的计算下推到存储设备上的收益是什么已经无需多言!如果能够将更多的计算逻辑下推到存储设备,那么,必然能够进一步释放主机的CPU、带宽,甚至是内存资源,让主机的资源能够更多地用于接受与处理用户的业务请求,从而进一步提高数据库的性能!

3、对计算存储的未来展望

  • 计算存储的诸多优良的特性,使得它能够系统性地一次性缓解、解决多个数据库的瓶颈与痛点,而不是像传统方法那样,费时费力费财不说、还常常是顾此失彼

  • 虽然说条条大路通罗马,没有解决不了的技术难题,不使用计算存储,也肯定还有其他多种多样的解决方式,但我们也要看具体是如何解决的,如果有近一点的大路,为什么要舍近求远呢?

  • 个人认为计算存储,是数据库领域一个具有前瞻性的发展方向,当然,并不是说用了计算存储就可以一劳永逸,但至少,你的数据量没有达到计算存储都吃不消的地步时,就可以或多或少避开或者延缓上文中提到的一些瓶颈与痛点。另外,还有一点很重要,对于单台服务器的TCO成本下降可能不痛不痒,但如果你的服务器规模较大,能够节省的成本不可小觑哦!

  • 至于以后,计算存储能发展成什么样,天知道,但我想,来自底层可通用的技术突破,比起在应用层做一些难以通用的技术改造更加合算,因此,我相信只要有强烈的需求存在,就必然有勇夫会持续去突破!

  • PS:以上内容,是根据一些已公开发表的文章整理得出(详见文末的链接),需要详细了解的读者,请移驾文末的参考链接,其中包括了更多的细节说明和完备的性能测试数据,希望在大家的数据库之旅的路上,本文能够对大家或多或少有所帮助!

计算存储的诸多优良的特性,使得它能够系统性地一次性缓解、解决多个数据库的瓶颈与痛点,而不是像传统方法那样,费时费力费财不说、还常常是顾此失彼

虽然说条条大路通罗马,没有解决不了的技术难题,不使用计算存储,也肯定还有其他多种多样的解决方式,但我们也要看具体是如何解决的,如果有近一点的大路,为什么要舍近求远呢?

个人认为计算存储,是数据库领域一个具有前瞻性的发展方向,当然,并不是说用了计算存储就可以一劳永逸,但至少,你的数据量没有达到计算存储都吃不消的地步时,就可以或多或少避开或者延缓上文中提到的一些瓶颈与痛点。另外,还有一点很重要,对于单台服务器的TCO成本下降可能不痛不痒,但如果你的服务器规模较大,能够节省的成本不可小觑哦!

至于以后,计算存储能发展成什么样,天知道,但我想,来自底层可通用的技术突破,比起在应用层做一些难以通用的技术改造更加合算,因此,我相信只要有强烈的需求存在,就必然有勇夫会持续去突破!

PS:以上内容,是根据一些已公开发表的文章整理得出(详见文末的链接),需要详细了解的读者,请移驾文末的参考链接,其中包括了更多的细节说明和完备的性能测试数据,希望在大家的数据库之旅的路上,本文能够对大家或多或少有所帮助!

4、参考链接

  • Percona 博客中关于ScaleFlux CSD 2000(一款来自ScaleFlux的高性能计算存储产品)的介绍:https://www.percona.com/blog/2020/08/06/how-can-scaleflux-handle-mysql-workload/技术白皮书(包含更多的CSD 2000的测试结论和数据):https://learn.percona.com/hubfs/Collateral/Whitepapers/Testing-the-Value-of-ScaleFlux.pdf

  • 微信公众号"yangyidba"中的"翻译|MySQL 基于ScaleFlux SSD性能测试":

  • 微信公众号"老叶茶馆"中的"可计算存储:数据压缩和数据库计算下推":

  • 微信公众号"ScaleFlux"中的"可计算存储: 透明压缩,数据库IO模型和SSD寿命":

  • 微信公众号"SSDFans"中的"太强大了!NVMe SSD变身内存":

  • MariaDB 中关于实现自动原子写的介绍:https://mariadb.com/kb/en/atomic-write-support/

    • https://mariadb.com/kb/en/mariadb-1055-changelog/

Percona 博客中关于ScaleFlux CSD 2000(一款来自ScaleFlux的高性能计算存储产品)的介绍:https://www.percona.com/blog/2020/08/06/how-can-scaleflux-handle-mysql-workload/技术白皮书(包含更多的CSD 2000的测试结论和数据):https://learn.percona.com/hubfs/Collateral/Whitepapers/Testing-the-Value-of-ScaleFlux.pdf

微信公众号"yangyidba"中的"翻译|MySQL 基于ScaleFlux SSD性能测试":

微信公众号"老叶茶馆"中的"可计算存储:数据压缩和数据库计算下推":

微信公众号"ScaleFlux"中的"可计算存储: 透明压缩,数据库IO模型和SSD寿命":

微信公众号"SSDFans"中的"太强大了!NVMe SSD变身内存":

MariaDB 中关于实现自动原子写的介绍:https://mariadb.com/kb/en/atomic-write-support/

  • https://mariadb.com/kb/en/mariadb-1055-changelog/

https://mariadb.com/kb/en/mariadb-1055-changelog/

作者介绍:

罗小波@ScaleFlux,《千金良方——MySQL性能优化金字塔法则》作者之一。

熟悉MySQL体系结构,擅长数据库的整体调优,喜好专研开源技术,并热衷于开源技术的推广,在线上线下做过多次公开的数据库专题分享,发表过近100篇数据库相关的研究文章。

全文完。

上一篇:荐读 下一篇:NextInput的MEMS力度传感器出货量超2000万
640*60广告位

额 本文暂时没人评论 来添加一个吧

发表评论

必填

选填

选填

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

欢迎访问纳米科技资讯网~
«   2020年9月   »
123456
78910111213
14151617181920
21222324252627
282930
搜索
网站分类
最近发表
标签列表