互联网架构(高性能 高可用 高可扩展) 之“存储层”技术

2024-01-06 15:08

本文主要是介绍互联网架构(高性能 高可用 高可扩展) 之“存储层”技术,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

        很多人对于 BAT的技术有一种莫名的崇拜感,觉得只有天才才能做出这样的系统。其实是业务的不断发展推动了技术的发展,这样一步一个脚印,持续几年甚十几年的发展,才能达到当前技术复杂度和先进性。 
        其实 BAT的技术架构基本是一样的。 再将视⻆放大,你会发现整个互联网行 业的技术发展,最后都是殊途同归。 互联网的标准技术架构如下图所示,这张图基本上涵盖了互联网技术公司的大部分技术点,不同的公司只是在具体的技术实现 上稍有差异,但不会跳出这个框架的范畴。

针对互联网架构模板,先来聊聊互联网架构模板的存储层技术。

一、SQL

SQL即我们通常所说的关系数据。互联网行业也必须依赖关系数据,考虑到Oracle太贵,还需要专业维护,一般情况下互联网行业都是用MySQL、PostgreSQL这类开源数据库。这类数据库的特点是开源免费,拿来就用;但缺点是性能相比商业数据库要差一些。随着互联 网业务的发展,性能要求越来越高,必然要面对一个问题:将数据拆分到多个数据库实例才能满足业务的性能需求(其实 Oracle也一样,只是时间早晚的问题)。

数据库拆分满足了性能的要求,但带来了复杂度的问题:数据如何拆分、数据如何组合?这个复杂度的问题解决起来并不容 易,如果每个业务都去实现一遍,重复造轮子将导致投入浪费、效率降低,业务开发想快都快不起来。

所以互联网公司流行的做法是业务发展到一定阶段后,就会将这部分功能独立成中间件,例如百度的DBProxy、淘宝的 TDDL。不过这部分的技术要求很高,将分库分表做到自动化和平台化,不是一件容易的事情,所以一般是规模很大的公司才 会自己做。中型公司建议使用开源方案,例如MySQL官方推荐的MySQL Router360开源的数据库中间件Atlas

假如公司业务继续发展,规模继续扩大,SQL服务器越来越多,如果每个业务都基于统一的数据库中间件独立部署自己的SQL 集群,就会导致新的复杂度问题,具体表现在:

  • 数据库资源使用率不高,比较浪费。
  • SQL集群分开维护,投入的维护成本越来越高。

因此,实力雄厚的大公司此时一般都会在SQL集群上构建SQL存储平台,以对业务透明的形式提供资源分配、数据备份、迁 移、容灾、读写分离、分库分表等一系列服务,例如淘宝的UMPUnifified MySQL Platform)系统。

二、NoSQL

确切的理解应该是 Not only SQL,是SQL的补充

首先NoSQL在数据结构上与传统的SQL的不同,例如典型的Memcachekey-value结构、Redis的复杂数据结构、MongoDB 的文档数据结构;其次,NoSQL无一例外地都会将性能作为的一大卖点。NoSQL的这两个特点很好地弥补了关系数据库 的不足,因此在互联网行业NoSQL的应用基本上是基础要求。

由于NoSQL方案一般自己本身就提供集群的功能,例如Memcache的一致性Hash集群、Redis 3.0的集群,因此NoSQL在刚开 始应用时很方便,不像SQL分库分表那么复杂。一般公司也不会在开始时就考虑将NoSQL包装成存储平台,但如果公司发展 很快,例如Memcache的节点有上千甚至几千时,NoSQL存储平台就很有意义了。首先是存储平台通过集中管理能够大大提 升运维效率;其次是存储平台可以大大提升资源利用效率,2000台机器,如果利用率能提升10%,就可以减少200台机器,一年上百万元就节省出来了。

所以,NoSQL发展到一定规模后,通常都会在NoSQL集群的基础之上再实现统一存储平台,统一存储平台主要实现这几个功能:

  • 资源动态按需动态分配:例如同⼀台Memcache服务器,可以根据内存利⽤率,分配给多个业务使用。
  • 资源⾃动化管理:例如新业务只需要申请多少Memcache缓存空间就可以了,无需关注具体是哪些Memcache服务器在为自己提供服务。
  • 故障自动化处理:例如某台Memcache服务器挂掉后,有另外一台备份Memcache服务器能立刻接管缓存请求,不会导致丢失很多缓存数据

       当然要发展到这个阶段,一般也是大公司才会这么做,简单来说就是如果只有几十台NoSQL服务器,做存储平台收益不大;

但如果有几千台 NoSQL 服务器, NoSQL 存储平台就能够产生很大的收益。

三、小文件存储

        除了关系型的业务数据,互联网行业还有很多用于展示的数据。例如,淘宝的商品图片、商品描述; Facebook 的用户图片; 新浪微博的一条微博内容等。这些数据具有三个典型特征:一是数据小,一般在1MB 以下;二是数量巨大, Facebook 2013 年每天上传的照片就达到了3.5 亿张;三是访问量巨大, Facebook 每天的访问量超过 10 亿。
       由于互联网行业基本上每个业务都会有大量的小数据,如果每个业务都自己去考虑如何设计海量存储和海量访问,效率自然会 低,重复造轮子也会投入浪费,所以自然而然就要将小文件存储做成统一的和业务无关的平台。
       和 SQL NoSQL 不同的是,小文件存储不一定需要公司或者业务规模很大,基本上认为业务在起步阶段就可以考虑做小文件
统一存储。得益于开源运动的发展和最近几年大数据的火爆,在开源方案的基础上封装几个个小文件存储平台并不是太难的事情。例如,HBase Hadoop Hypertable FastDFS 等都可以作为小文件存储的底层平台,只需要将这些开源方案再包装一
下基本上就可以用了。
典型的小文件存储有:淘宝的 TFS 、京东 JFS Facebook Haystack
下图是淘宝 TFS 的架构:
http://code.taobao.org/p/tfs/fifile/305/structure.png

四、大文件存储

        互联网行业的大文件主要分为两类:一类是业务上的大数据,例如 Youtube 的视频、电影网站的电影;另一类是海量的日志数 据,例如各种访问日志、操作日志、用户轨迹日志等。和小文件的特点正好相反,大文件的数量没有小文件那么多,但每个文
件都很大,几百 MB 、几个 GB 都是常见的,几十 GB 、几 TB 也是有可能的,因此在存储上和小文件有较大差别,不能直接将小文
件存储系统拿来存储大文件。
        说到大文件,特别要提到 Google Yahoo Google 3 篇大数据论文( Bigtable/Map- Reduce/GFS )开启了一个大数据的时
代,而 Yahoo 开源的 Hadoop 系列( HDFS HBase 等),基本上垄断了开源界的大数据处理。当然,江山代有才人出,长江后
浪推前浪, Hadoop后也有更多优秀的开源方案被贡献出来。
        对照 Google 的论文构建一套完整的大数据处理方案的难度和成本实在太大,而且开源方案现在也很成熟了,所以大数据存储
和处理这块反而是最简单的,因为你没有太多选择,只能用这几个流行的开源方案,例如, Hadoop HBase Storm Hive 等。实力雄厚一些的大公司会基于这些开源方案,结合自己的业务特点,封装成大数据平台,例如淘宝的云梯系统、腾讯的 TDW系统。
下面是 Hadoop 的生态圈:
http://i.imgur.com/Dpz74XZ.jpg
总结:
        分析互联网公司架构的存储层技术,可以看到当公司规模发展到一定阶段后,基本上都是基于某个开源方案搭建
统一的存储平台。

这篇关于互联网架构(高性能 高可用 高可扩展) 之“存储层”技术的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/576718

相关文章

PostgreSQL的扩展dict_int应用案例解析

《PostgreSQL的扩展dict_int应用案例解析》dict_int扩展为PostgreSQL提供了专业的整数文本处理能力,特别适合需要精确处理数字内容的搜索场景,本文给大家介绍PostgreS... 目录PostgreSQL的扩展dict_int一、扩展概述二、核心功能三、安装与启用四、字典配置方法

Python实现对阿里云OSS对象存储的操作详解

《Python实现对阿里云OSS对象存储的操作详解》这篇文章主要为大家详细介绍了Python实现对阿里云OSS对象存储的操作相关知识,包括连接,上传,下载,列举等功能,感兴趣的小伙伴可以了解下... 目录一、直接使用代码二、详细使用1. 环境准备2. 初始化配置3. bucket配置创建4. 文件上传到os

Java中调用数据库存储过程的示例代码

《Java中调用数据库存储过程的示例代码》本文介绍Java通过JDBC调用数据库存储过程的方法,涵盖参数类型、执行步骤及数据库差异,需注意异常处理与资源管理,以优化性能并实现复杂业务逻辑,感兴趣的朋友... 目录一、存储过程概述二、Java调用存储过程的基本javascript步骤三、Java调用存储过程示

mysql中的服务器架构详解

《mysql中的服务器架构详解》:本文主要介绍mysql中的服务器架构,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1、背景2、mysql服务器架构解释3、总结1、背景简单理解一下mysqphpl的服务器架构。2、mysjsql服务器架构解释mysql的架

MySQL之InnoDB存储引擎中的索引用法及说明

《MySQL之InnoDB存储引擎中的索引用法及说明》:本文主要介绍MySQL之InnoDB存储引擎中的索引用法及说明,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐... 目录1、背景2、准备3、正篇【1】存储用户记录的数据页【2】存储目录项记录的数据页【3】聚簇索引【4】二

MySQL之InnoDB存储页的独立表空间解读

《MySQL之InnoDB存储页的独立表空间解读》:本文主要介绍MySQL之InnoDB存储页的独立表空间,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1、背景2、独立表空间【1】表空间大小【2】区【3】组【4】段【5】区的类型【6】XDES Entry区结构【

SQLite3 在嵌入式C环境中存储音频/视频文件的最优方案

《SQLite3在嵌入式C环境中存储音频/视频文件的最优方案》本文探讨了SQLite3在嵌入式C环境中存储音视频文件的优化方案,推荐采用文件路径存储结合元数据管理,兼顾效率与资源限制,小文件可使用B... 目录SQLite3 在嵌入式C环境中存储音频/视频文件的专业方案一、存储策略选择1. 直接存储 vs

Qt如何实现文本编辑器光标高亮技术

《Qt如何实现文本编辑器光标高亮技术》这篇文章主要为大家详细介绍了Qt如何实现文本编辑器光标高亮技术,文中的示例代码讲解详细,具有一定的借鉴价值,有需要的小伙伴可以了解下... 目录实现代码函数作用概述代码详解 + 注释使用 QTextEdit 的高亮技术(重点)总结用到的关键技术点应用场景举例示例优化建议

k8s上运行的mysql、mariadb数据库的备份记录(支持x86和arm两种架构)

《k8s上运行的mysql、mariadb数据库的备份记录(支持x86和arm两种架构)》本文记录在K8s上运行的MySQL/MariaDB备份方案,通过工具容器执行mysqldump,结合定时任务实... 目录前言一、获取需要备份的数据库的信息二、备份步骤1.准备工作(X86)1.准备工作(arm)2.手

MySQL存储过程之循环遍历查询的结果集详解

《MySQL存储过程之循环遍历查询的结果集详解》:本文主要介绍MySQL存储过程之循环遍历查询的结果集,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录前言1. 表结构2. 存储过程3. 关于存储过程的SQL补充总结前言近来碰到这样一个问题:在生产上导入的数据发现