小对象存储

① 使用MinIO搭建对象存储服务

之前我使用的是阿里云OSS,想了解阿里云OSS的小伙伴参考SpringBoot整合阿里云OSS

docker run -d -p 9000:9000 -p 9001:9001 --name minio -e MINIO_ACCESS_KEY=qbb -e MINIO_SECRET_KEY=startqbb -v /opt/minio/data:/data -v /opt/minio/config:/root/.minio minio/minio server /data --console-address ":9000" --address ":9001"

注意:9000是我们浏览器访问控制台的端口,而9001是SDK代码操作的端口

yum -y install ntp ntpdate :安装插件工具
hwclock --systohc :同步时间
docker restart minio镜像ID :重启镜像

② 数据存储形式有哪几种

【块存储】

典型设备：磁盘阵列，硬盘

块存储主要是将裸磁盘空间整个映射给主机使用的，就是说例如磁盘阵列里面有5块硬盘（为方便说明，假设每个硬盘1G），然后可以通过划逻辑盘、做Raid、或者LVM（逻辑卷）等种种方式逻辑划分出N个逻辑的硬盘。（假设划分完的逻辑盘也是5个，每个也是1G，但是这5个1G的逻辑盘已经于原来的5个物理硬盘意义完全不同了。例如第一个逻辑硬盘A里面，可能第一个200M是来自物理硬盘1，第二个200M是来自物理硬盘2，所以逻辑硬盘A是由多个物理硬盘逻辑虚构出来的硬盘。）

接着块存储会采用映射的方式将这几个逻辑盘映射给主机，主机上面的操作系统会识别到有5块硬盘，但是操作系统是区分不出到底是逻辑还是物理的，它一概就认为只是5块裸的物理硬盘而已，跟直接拿一块物理硬盘挂载到操作系统没有区别的，至少操作系统感知上没有区别。

此种方式下，操作系统还需要对挂载的裸硬盘进行分区、格式化后，才能使用，与平常主机内置硬盘的方式完全无异。

优点：

1、 这种方式的好处当然是因为通过了Raid与LVM等手段，对数据提供了保护。

2、 另外也可以将多块廉价的硬盘组合起来，成为一个大容量的逻辑盘对外提供服务，提高了容量。

3、 写入数据的时候，由于是多块磁盘组合出来的逻辑盘，所以几块磁盘可以并行写入的，提升了读写效率。

4、 很多时候块存储采用SAN架构组网，传输速率以及封装协议的原因，使得传输速度与读写速率得到提升。

缺点：

1、采用SAN架构组网时，需要额外为主机购买光纤通道卡，还要买光纤交换机，造价成本高。

2、主机之间的数据无法共享，在服务器不做集群的情况下，块存储裸盘映射给主机，再格式化使用后，对于主机来说相当于本地盘，那么主机A的本地盘根本不能给主机B去使用，无法共享数据。

3、不利于不同操作系统主机间的数据共享：另外一个原因是因为操作系统使用不同的文件系统，格式化完之后，不同文件系统间的数据是共享不了的。例如一台装了WIN7/XP，文件系统是FAT32/NTFS，而Linux是EXT4，EXT4是无法识别NTFS的文件系统的。就像一只NTFS格式的U盘，插进Linux的笔记本，根本无法识别出来。所以不利于文件共享。

【文件存储】

典型设备：FTP、NFS服务器

为了克服上述文件无法共享的问题，所以有了文件存储。

文件存储也有软硬一体化的设备，但是其实普通拿一台服务器/笔记本，只要装上合适的操作系统与软件，就可以架设FTP与NFS服务了，架上该类服务之后的服务器，就是文件存储的一种了。

主机A可以直接对文件存储进行文件的上传下载，与块存储不同，主机A是不需要再对文件存储进行格式化的，因为文件管理功能已经由文件存储自己搞定了。

优点：

1、造价交低：随便一台机器就可以了，另外普通以太网就可以，根本不需要专用的SAN网络，所以造价低。

2、方便文件共享：例如主机A（WIN7，NTFS文件系统），主机B（Linux，EXT4文件系统），想互拷一部电影，本来不行。加了个主机C（NFS服务器），然后可以先A拷到C，再C拷到B就OK了。（例子比较肤浅，请见谅……）

缺点：

读写速率低，传输速率慢：以太网，上传下载速度较慢，另外所有读写都要1台服务器里面的硬盘来承担，相比起磁盘阵列动不动就几十上百块硬盘同时读写，速率慢了许多。

【对象存储】

典型设备：内置大容量硬盘的分布式服务器

对象存储最常用的方案，就是多台服务器内置大容量硬盘，再装上对象存储软件，然后再额外搞几台服务作为管理节点，安装上对象存储管理软件。管理节点可以管理其他服务器对外提供读写访问功能。

之所以出现了对象存储这种东西，是为了克服块存储与文件存储各自的缺点，发扬它俩各自的优点。简单来说块存储读写快，不利于共享，文件存储读写慢，利于共享。能否弄一个读写快，利 于共享的出来呢。于是就有了对象存储。

首先，一个文件包含了了属性（术语叫metadata，元数据，例如该文件的大小、修改时间、存储路径等）以及内容（以下简称数据）。

以往像FAT32这种文件系统，是直接将一份文件的数据与metadata一起存储的，存储过程先将文件按照文件系统的最小块大小来打散（如4M的文件，假设文件系统要求一个块4K，那么就将文件打散成为1000个小块），再写进硬盘里面，过程中没有区分数据/metadata的。而每个块最后会告知你下一个要读取的块的地址，然后一直这样顺序地按图索骥，最后完成整份文件的所有块的读取。

这种情况下读写速率很慢，因为就算你有100个机械手臂在读写，但是由于你只有读取到第一个块，才能知道下一个块在哪里，其实相当于只能有1个机械手臂在实际工作。

而对象存储则将元数据独立了出来，控制节点叫元数据服务器（服务器+对象存储管理软件），里面主要负责存储对象的属性（主要是对象的数据被打散存放到了那几台分布式服务器中的信息），而其他负责存储数据的分布式服务器叫做OSD，主要负责存储文件的数据部分。当用户访问对象，会先访问元数据服务器，元数据服务器只负责反馈对象存储在哪些OSD，假设反馈文件A存储在B、C、D三台OSD，那么用户就会再次直接访问3台OSD服务器去读取数据。

这时候由于是3台OSD同时对外传输数据，所以传输的速度就加快了。当OSD服务器数量越多，这种读写速度的提升就越大，通过此种方式，实现了读写快的目的。

另一方面，对象存储软件是有专门的文件系统的，所以OSD对外又相当于文件服务器，那么就不存在文件共享方面的困难了，也解决了文件共享方面的问题。

所以对象存储的出现，很好地结合了块存储与文件存储的优点。

最后为什么对象存储兼具块存储与文件存储的好处，还要使用块存储或文件存储呢？

1、有一类应用是需要存储直接裸盘映射的，例如数据库。因为数据库需要存储裸盘映射给自己后，再根据自己的数据库文件系统来对裸盘进行格式化的，所以是不能够采用其他已经被格式化为某种文件系统的存储的。此类应用更适合使用块存储。

2、对象存储的成本比起普通的文件存储还是较高，需要购买专门的对象存储软件以及大容量硬盘。如果对数据量要求不是海量，只是为了做文件共享的时候，直接用文件存储的形式好了，性价比高。

③ Java中数组对象的存储位置

原帖地址：http://hi..com/sqldebug/blog/item/9758b9ffa605e51a09244d91.html

数组单一说在栈中还是堆中都是错误的，分为几种情况：

1、固定数组在函数体内分配是在栈中的

我们做一个试验，一般DELPHI程序线程的栈大小是1M，如果我们函数体中申请4M大小的数组，报栈溢出，则表示数据的大小是在栈中的。

const
CArrayCount = 1024*1024*4;

procere TForm1.btnMainThreadClick(Sender: TObject);
var
MainThreadArray: array[1..CArrayCount] of Char;
i: Integer;
begin
for i := Low(MainThreadArray) to High(MainThreadArray) do
MainThreadArray[i] := #0;
end;

我把以上代码在主线程中测试时，确实报了栈溢出，如果这时你把DELPHI程序的栈调大为6M则正确，表示在函数体中申请的数组是在栈中的。

2、固定数组在类中分配是在堆中的

我们在类中加一下定义语句

FFixArray: array[1..CArrayCount] of Char;

程序正常，表示在类中分配固定数组是在堆中的。

3、固定数组全局变量是在堆中的

我们在程序定义全部数组

GFixArray: array[1..CArrayCount] of Char;

程序也正常，表示全局固定长度是在堆中的。

3、动态数组不管在函数体中、类中、全局变量都是在堆中

如果你会汇编，看一下汇编就明白了。DELPHI这么实现是合理的，在函数里中分配的固定长度数组放在栈中可以加快运行效率，而且在多线程的情况下，不用像堆分配有加锁。只是大家在写程序的过程中注意在函数里定义太长的数组需要注意，否则栈溢出，程序就崩溃了。

④ 大量小文件存储，如何选择存储方案

1、Raid0
2、固态硬盘
3、Fat32：拷贝大量小文件(如拷贝照片、文档转移等)速度很快，但不支持存储单个大于4GB的文件。
NTFS：支持大文件存储，管理性能比Fat32强很多，但是拷贝大量小文件时速度较慢。

⑤ 不属于对象存储的存储类型

块存储和文件存储。

1、块存储

以下列出的两种存储方式都是块存储类型：

1） DAS（Direct AttachSTorage）：是直接连接于主机服务器的一种储存方式，每一台主机服务器有独立的储存设备，每台主机服务器的储存设备无法互通，需要跨主机存取资料时，必须经过相对复杂的设定，若主机服务器分属不同的操作系统，要存取彼此的资料，更是复杂，有些系统甚至不能存取。通常用在单一网络环境下且数据交换量不大，性能要求不高的环境下，可以说是一种应用较为早的技术实现。

2）SAN（Storage Area Network）：是一种用高速（光纤）网络联接专业主机服务器的一种储存方式，此系统会位于主机群的后端，它使用高速I/O 联结方式， 如 SCSI, ESCON及 Fibre- Channels。一般而言，SAN应用在对网络速度要求高、对数据的可靠性和安全性要求高、对数据共享的性能要求高的应用环境中，特点是代价高，性能好。例如电信、银行的大数据量关键应用。它采用SCSI 块I/O的命令集，通过在磁盘或FC（Fiber Channel）级的数据访问提供高性能的随机I/O和数据吞吐率，它具有高带宽、低延迟的优势，在高性能计算中占有一席之地，但是由于SAN系统的价格较高，且可扩展性较差，已不能满足成千上万个CPU规模的系统。

2、文件存储

通常，NAS产品都是文件级存储。NAS（Network Attached Storage）：是一套网络储存设备，通常是直接连在网络上并提供资料存取服务，一套 NAS 储存设备就如同一个提供数据文件服务的系统，特点是性价比高。例如教育、政府、企业等数据存储应用。

它采用NFS或CIFS命令集访问数据，以文件为传输协议，通过TCP/IP实现网络化存储，可扩展性好、价格便宜、用户易管理，如目前在集群计算中应用较多的NFS文件系统，但由于NAS的协议开销高、带宽低、延迟大，不利于在高性能集群中应用。

下面，我们对DAS、NAS、SAN三种技术进行比较和分析：

表格 1 三种技术的比较

⑥ 海量小文件用什么存储好

海量小文件优先选择对象存储，不用考虑元数据管理的问题，如果是老系统的话需要改造支持对象存储。我们公司现在用的元核云的YC-DOS分布式对象存储，稳定性和性能都还不错。

⑦ oss对象存储会减小页面的资源大小吗

对的！
在当今的云计算世界中，对象存储是一种使用HTTP API存储和检索非结构化数据和元数据对象的工具。这样的服务不是将文件分成块并使用文件系统将它们存储在磁盘上，而是与存储在网络上的整个对象一起工作。这些对象可以是图像文件，日志，HTML文件或任何自主字节块。它们是非结构化的，因为它们没有必须响应的特定方案或格式。

由于API由标准HTTP请求组成，因此很快就会出现大多数编程语言的库。要保存数据对象，只需向对象库发送HTTP PUT请求即可。可以使用常规GET请求检索文件和元数据。大多数对象存储服务还可以向用户发布文件，从而无需维护Web服务器来托管静态资产。

此外，对象存储服务仅针对已用空间收费（对于某些用户，还支付HTTP请求和带宽）。对于可以获得高质量存储，放置资产而不会过度支付的小型应用程序而言，这是一个很好的选择，并根据需要扩展存储。

⑧ 对象存储是什么对象存储的基本定义

对象存储是一种将数据作为对象进行管理的计算机数据存储体系结构，与其他存储体系结构（例如将数据作为文件层级管理的文件系统）以及将数据作为块和扇区内的块进行管理的块存储相对。每个对象通常包括数据本身，可变数量的元数据和全局独立标识符。

对象存储可以在多个级别实现，包括设备级别（对象存储设备），系统级别和接口级别。在每种情况下，对象存储都试图实现其他存储架构无法解决的功能，例如可以由应用程序直接编程的接口，可以再多个物理硬件实例的命名空间，以及数据管理功能，如数据复制和数据分发在对象级粒度。

相比于数据库这种面向结构化数据存储的技术，对象存储主要面向存储大量的非结构化数据。

(8)小对象存储扩展阅读：

对象存储、文件存储和块存储的区别如下：

1、速度不同

块存储：低延迟（10ms），热点突出；

文件存储：不同技术各有不同；

对象存储：100ms-1s，冷数据；

2、可分步性不同

块存储：异地不现实；

文件存储：可分布式，但有瓶颈；

对象存储：分步并发能力高；

3、文件大小不同

块存储：大小都可以，热点突出；

文件存储：适合大文件；

对象存储：适合各种大小；

4、接口不同

块存储：Driver，kernel mole ；

文件存储：POSIX；

对象存储：Restful API ；

5、典型技术不同

块存储：SAN；

文件存储： HDFS，GFS；

对象存储：Swift，Amazon S3；

6、适合场景不同

块存储：银行；

文件存储：数据中心；

对象存储：网络媒体文件存储。

⑨ 分布式存储极简艺术Minio解析

 MinIO 对象存储系统是为海量数据存储、人工智能、大数据分析而设计，基于
Apache License v2.0 开源协议的对象存储系统，它完全兼容 Amazon S3 接口，单个对象的最大可达 5TB，适合存储海量图片、视频、日志文件、备份数据和容器/虚拟机镜像等。作为一个开源服务，MinIO 在设计上汲取了Glusterfs的相关经验不教训，系统复杂度上作了大量简化，目前大小只有40+M，部署只需要一个命令即可完成！另外，minio舍弃了传统分布式存储扩容所需要的迁移流程，采用联盟模式添加集群的方式，极大简化了扩容流程；除此之外，minio还具有纠删编码、比特位保护、单写多读（worm)、下面来依次简要解析一下Mioio的特点及具体实现：

  元数据和数据一起存放在磁盘上。元数据以明文形式存放在元数据文件里（xl.json）。假定对象名字为key_name, 它所在桶的名字是bucket_name, disk路径就是/disk，那么存储路径就是：/disk/bucket_name/key_name，windows下C盘存放桶名为test，对象名为minio.exe示例如图：

其中part.1是实际存储数据（单机模式为原生数据，分布式为纠删码分块），xl.json是如下所示的json字符串：

  在同一集群内，MinIO 自己会自劢生成若干纠删组，用于分布存放桶数据。一个纠删组中的一定数量的磁盘发生的故障（故障磁盘的数量小于等于校验盘的数量），通过纠删码校验算法可以恢复出正确的数据。MinIO 集成了 Reed-Solomon 纠删码库，MinIO 存储对象数据时，首先把它分成若干等长的片段（对于大对象，默认按 5MB 切片)，然后每一个片段会纠删算法分成若干分片，包括数据分片不校验分片，每个分片放置在一个纠删组的某个节点上。对象的每一个数据分片、校验分片都被“防比特位衰减”算法所保护。

  MinIO 会根据对象名（类似于文件系统的全路径名)，使用 crc32 哈希算法计算出一个整数。然后使用这个整数除以纠删组的个数，得到一个余数。这个余数，可以作为纠删组的序号，这样就确定了这个对象所在的纠删组。MinIO 采用 CRC32 哈希算法，不 glusterfs 的Davies Meyer哈希算法（性能、冲突概率不md4, md5相近）不一样的是，CRC32算法的哈希值分布较不均匀，但运算速度极快，高出 md4 数倍。相对于容量均衡，MinIO 更看重数据的写入速度。

纠删组如何配置？
官方文档说明如下：

 也就是说纠删组的总大小只能从这7中情况中根据你提供的盘的个数（或者说路径个数）来自动选取最大值的，我们 不能灵活地配置m+k纠删存储格式。但这样说又不是很准确 ，因为虽然不能配置任意的m+k，但是在系统已经选取好擦除编码集的的个数后（也就是m+k），可以使用storage class存储类来自定义m和k的数量，默认是1:1的。
存储类：
 MinIO支持配置两种存储类别，精简冗余类别和标准类别，默认是标准类别（1：1），可以在启动MinIO服务器之前使用设置的环境变量来定义这些类。使用环境变量定义每个存储类别的数据和奇偶校验磁盘后，您可以 在上传对象时通过请求元数据字段设置对象的存储类别x-amz-storage-class 。然后，MinIO服务器通过将对象保存在特定数量的数据和奇偶校验磁盘中来兑现存储类。具体配置和使用可以参考官方文档 https://github.com/minio/minio/tree/master/docs/erasure/storage-class

传统的扩展方式的劣势
  通过增加节点来扩展单集群，一般需要进行数据均衡，否则群集内各存储节点会因负载不均而出现新的瓶颈。除了数据均衡操作的时机这个问题以外，在均衡过程中一般需要仍存储使用率高的节点吐使用率低的节点迁移数据。当集群扩容后，大量已经写入的文件落点会出现改变，文件需要迁移到真实的落点。当存储系统容量比较大时，则会发生大量的文件/对象进行迁移,迁移过程可能由于占用大量资源而导致上层应用性能下降。而且当文件/对象迁移过程中，机器故障可能会导致一些意想不到的情冴,尤其是有大量业务的时候。当然针对此类问题，Gluterfs之类的文件系统有一些比较复杂的处理办法。
不支持扩展优势

⑩ 对象存储、块存储、文件存储分别是什么有什么区别

你可以把块理解成整个硬盘，文件理解成硬盘中的文件，对象理解成很多台服务器中的很多块硬盘。