甜橘子，专注成都网站制作网站设计与营销型网站建设与优化
QQ :532337155
电话：028-86922220
移动互联网和大数据日益发展，沉淀的数据越来越多，数据的质量、使用效率、数据安全等等各类的问题迎面而来。为了让数据发挥最大的价值，数据治理作为数智化战略的一项必要举措，列入了大多数企业的战略行动计划，业界也有“数字转型、治理先行”的说法。但是谈到数据治理，业界有一个普遍的共识，那就是 “数据治理说起来容易，做起来难”。怎么通过数据治理解决这些难题？数据治理究竟难在哪里？华为作为典型的非云原生企业是如何应对的呢？
创新互联公司从2013年创立，是专业互联网技术服务公司，拥有项目成都网站设计、成都网站建设网站策划，项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命，1280元汤旺做网站,已为上家服务,为汤旺各地企业和个人服务,联系电话:028-86922220
2018到2021年间全球8300家标杆企业中，全面拥抱数字技术的前10%企业相比后25%企业营收增速超过5倍。数字化转型浪潮下，数据资产将成为关键生产要素支撑未来数据产业化升级，是未来政企实现跨越式发展的必然选择。
根据华为在政企行业多年的深入耕耘和自身转型的实践，我们发现，优质高效的数据底座，是保障政企运营效率持续提升和业务创新升级的重要基石。我们深知打破数据孤岛、确保数据准确、促进数据共享、保障数据隐私与安全，是政企数据治理的关键。当前很多企业数据体系建设呈现出“烟囱化”的趋势，为政企数据治理带来了四大挑战：
l 进不来 ：数据来源复杂，集成难；
l 质量差 ：数据质量要求高，规则校验多，落地难；
l 出不去 ：数据烟囱林立，业务和数据匹配难，共享难；
l 不放心 ：数据安全、交互风险高。
早期的华为是典型的非数字原生企业。从2007年开始，我们通过两个阶段的持续变革，系统地完成了数据管理体系建设，实现业务感知和ROADS体验的数字化转型：
l 阶段一（2007-2017） ：设立数据管理专业组织，建立数据管理框架，发布数据管理政策，通过统一信息架构与标准、有效的数据质量改进机制，提升数据质量，实现数据全流程贯通，业务运作效率整体提升。
l 阶段二（2017-至今）： 建设数据底座，汇聚和联接全域数据，实现数据业务可视、随需共享、敏捷自助、安全透明的目标，支撑准确决策和数据创新，构筑差异化竞争力。
华为经过十多年的实践，我们总结出 “4层保障”和“2个抓手”（信息架构、数据质量） ，实现清洁数据，充分释放数据价值的核心手段。
4层保障包括：
l 政策保障： 从目的、适用范围、管理原则、问责等方面进行政策制定，公司层面需统一遵从，确保业务与IT共同参与数据治理。
l 流程保障： 建立数据管理流程，重大决议由企业变革指导委员会决策，通过变革管理体系和流程运营体系落地。
l 组织保障： 按领域任命数据管理Owner和团队，建立实体化数据管理组织承接数据管理改进目标。
l IT落地保障： 建设承载面向“联接共享”的数据底座和数据服务融合的统一IT平台，完成数据全流程流转与价值变现。
2个抓手是指：
l 信息架构： 构建面向“业务交易”的信息架构，描述业务运作和管理决策所需要的各类数据及其关系，保障企业内统一“数据语言”。
l 数据质量： 建立数据质量管理框架和运作机制，例行开展公司级数据质量评估，由企业数据管理组织定期发布报告，牵引各业务领域持续改进。
上述的4层保障和2个抓手，构成了企业数据战略资产综合治理体系，能够确保关键数据资产的有清晰的业务管理责任，IT落地有稳定清晰的原则依据，作业人员有规范的流程指导。遇到争议时，有裁决和升级处理机制，治理过程有充足的人力、组织、预算保障。只有建立起有效的数据治理环境，数据的质量和安全才能得到保障，数据的价值才能真正发挥。
作为华为数字化转型的底座，华为云沉淀了大量的实践经验和方案能力，并通过华为云Stack来赋能政企，加速各行各业的数字化转型。在数据治理领域，华为云Stack为政企提供数据湖治理中心服务（DGC）来帮助企业客户快速构建数据运营能力。DGC是数据全生命周期一站式开发运营平台，提供数据集成、数据开发、数据治理、数据服务、数据可视化等功能，支持行业知识库智能化建设，支持大数据存储、大数据计算分析引擎等数据底座。下面我们就来一起看看DGC是怎样应对我们前面提到的挑战：
l 进的来：简单高效的物理和逻辑数据集成保障数据全面入湖
非数字原生企业发展普遍有较长的 历史 ，随着不同阶段的发展需求，业务系统间存在大量复杂的集成和嵌套，数据来源多样，数据形成孤岛难以集中共享。
数据集成：简单易用的多源异构数据批量和实时接入
DGC能够提供活易用的可视化配置与迁移任务编排，将数据迁移和集成的效率提升数十倍。除主流关系型数据库支持外，还支持对象存储、NoSQL等40余种同/异构数据源及三方大数据平台批量迁移入湖。 DGC物理入湖与HetuEngine跨湖跨仓协同的逻辑入湖 作为两种重要数据集成方式协同互补，满足数据联接和用户数据消费不同场景需求，支撑客户数据湖从离线走向实时，构建物理分散、逻辑统一的逻辑数据湖。
l 理的清：从源端架构到平台工具端到端数据质量保障
企业级信息架构：结构化的方式实施有效的治理
企业在运转过程中，需要定义业务流程中涉及的人、事、物资源，实施有效的数据治理，确保各类数据在企业业务单元间高效、准确地传递，上下游流程快速执行和运作。企业长期存在信息架构与IT开发实施“两张皮”的现象，数据人员和IT人员缺乏统一协同，企业数据架构混乱，信息架构资产和产品实现逻辑割裂，数据模型资产缺失。
平台工具和服务：一体化开发设计，端到端专业服务，有机联动保障数据质量
结合华为数据治理专家团队与项目实践经验，DGC规范设计实现了一体化设计和开发，不仅确保了元数据验证、发布和注册的一致性，而且实现了产品数据模型管理和资产可视，同时辅以专业的数据治理服务团队、成熟项目管理机制和丰富的实践经验，支撑企业构建高质量的清洁数据架构和能力。在政务大数据中心通过DGC一体化平台和专业服务，完成多个委办局全量数据接入，落地数据分层架构模型设计，完成基础库与主题库的建设，实现委办局数据全流程生命周期设计与落地，涵盖数据架构和模型设计、数据标准设计、数据模型物化、数据质量稽核作业等，助力领导决策支持、宏观经济云图和惠民APP示范应用系统上线。
l 出得去：通过数据服务和数据地图实现数据自助消费
数据底座建设的目标是便捷地支撑数据消费，确保用户安全可靠地获取数据，并通过灵活的数据分析等方式，按需快捷的消费数据。
数据服务：服务化方式供应数据
通过服务化方式对外提供，用户不再直接集成数据，而是通过聚合应用模型可视化构建，涵盖API发布、管理、运维、售卖的全生命周期管理，作为业务的“可消费产品”的关键要素之一，解决了数据的可供应性。
数据地图：从查询到分析到使用一站式自助
以数据搜索为核心，综合反映数据的来源、数量、质量、分布、标准、流向、关联关系，满足多用户、多场景的数据消费需求，解决了数据“可搜索/可获取性”的难点问题。消费方获取数据后，还支持从数据查询到拖拽式分析的端到端的一站式自助作业，帮助数据消费者结合自身需要获取分析结果，满足业务运营中数据实时可视化需求。
l 用的安：从模型、制度到平台多维度打造立体化数据安全体系
安全能力模型评估：系统化安全管理抓手
数据安全能力成熟度模型是数据安全建设中的系统化框架，围绕数据全生命周期，结合业务的需求以及监管法规的要求，持续不断的提升组织整体的数据安全能力，提升数据安全水平和行业竞争力，确保数据生产要素安全流通和数字经济 健康 发展。在多个项目中，华为通过安全评估、安全加固等专业服务，助力客户高分通过等保评估，实现数据安全流通。
从制度到工具和服务：统一安全治理框架落地
数据安全治理需要从决策层到技术层，从管理制度到工具支撑和服务体系，自上而下形成贯穿整个组织架构的完整链条。企业组织内的各个层级之间需要对数据安全治理的目标达成共识，确保采取合理和适当的措施；DGC数据安全定义数据密级、认证数据源、对数据动静态脱敏及添加水印等方式以最有效的方式保护数字资产。
企业数字化转型逐步进入深水区，如何提升海量数据治理的效率和准确率，如何将专家经验固化传递都面临巨大的挑战。人工智能与数据治理深度融合将会开启数据治理的新阶段，通过AI加速企业数据生产要素的变现、进一步释放数据价值。
l 智能数据资产编目
基于AI的智能数据编目系统具备数据的学习、理解和推理能力，帮助团队实现数据自主、简化数据 探索 、实现重要数据资产智能编目推荐。
l 智能数据标准推荐/去重
通过机器学习技术，自动扫描元数据信息，提炼关键数据项，智能识别新增数据标准、冗余存量数据标准去重，提高智能化程度。
l 智能重复/异常数据检测
智能重复/异常数据检测技术，将数据根据相似读音、相似数据类型分组，通过模型计算相似度得分，超出规定阈值时，自动异常检测和识别。
l 智能主外键识别
通过筛选候选主外键时构造特征向量，并调用分类器智能判别该元数据是否为主外键，提升数据模型质量，进而优化和简化后续资产梳理和对外提供数据服务。
数据是物理世界、数字世界和认知世界相互联接转换的纽带，大规模数据交互将构成庞大的政企数据生态。政企数字化转型不能一蹴而就，数据治理亦非一朝一夕之功，治理的数据规模日趋庞大，类型千变万化，手段也更智能丰富，需要我们共同携手从制度、流程、技术、生态多维度一起努力，构建数据智能新世界。
NoSQL 数据库因其功能性、易于开发性和可扩展性而广受认可，它们越来越多地用于大数据和实时 Web 应用程序，在本文中，我们通过示例讨论 NoSQL、何时使用 NoSQL 与 SQL 及其用例。
NoSQL是一种下一代数据库管理系统 (DBMS)。NoSQL 数据库具有灵活的模式，可用于构建具有大量数据和高负载的现代应用程序。
“NoSQL”一词最初是由 Carlo Strozzi 在 1998 年创造的，尽管自 1960 年代后期以来就已经存在类似的数据库。然而，NoSQL 的发展始于 2009 年初，并且发展迅速。
在处理大量数据时，任何关系数据库管理系统 (RDBMS) 的响应时间都会变慢。为了解决这个问题，我们可以通过升级现有硬件来“扩大”信息系统，这非常昂贵。但是，NoSQL 可以更好地横向扩展并且更具成本效益。
NoSQL 对于非结构化或非常大的数据对象（例如聊天日志数据、视频或图像）非常有用，这就是为什么 NoSQL 在微软、谷歌、亚马逊、Meta (Facebook) 等互联网巨头中特别受欢迎的原因。
一些流行的 NoSQL 数据库包括：
随着企业更快地积累更大的数据集，结构化数据和关系模式并不总是适合。有必要使用非结构化数据和大型对象来更好地捕获这些信息。
传统的 RDBMS 使用 SQL（结构化查询语言）语法来存储和检索结构化数据，相反，NoSQL 数据库包含广泛的功能，可以存储和检索结构化、半结构化、非结构化和多态数据。
有时，NoSQL 也被称为“ 不仅仅是 SQL ”，强调它可能支持类似 SQL 的语言或与 SQL 数据库并列。SQL 和 NoSQL DBMS 之间的一个区别是 JOIN 功能。SQL 数据库使用 JOIN 子句来组合来自两个或多个表的行，因为 NoSQL 数据库本质上不是表格的，所以这个功能并不总是可行或相关的。
但是，一些 NoSQL DBMS 可以执行类似于 JOIN的操作——就像 MongoDB 一样。这并不意味着不再需要 SQL DBMS，相反，NoSQL 和 SQL 数据库倾向于以不同的方式解决类似的问题。
一般来说，在以下情况下，NoSQL 比 SQL 更可取：
许多行业都在采用 NoSQL，取代关系数据库，从而为某些业务应用程序提供更高的灵活性和可扩展性，下面给出了 NoSQL 数据库的一些企业用例。
内容管理是一组用于收集、管理、传递、检索和发布任何格式的信息的过程，包括文本、图像、音频和视频。NoSQL 数据库可以通过其灵活和开放的数据模型为存储多媒体内容提供更好的选择。
例如，福布斯在短短几个月内就构建了一个基于 MongoDB 的定制内容管理系统，以更低的成本为他们提供了更大的敏捷性。
大数据是指太大而无法通过传统处理系统处理的数据集，实时存储和检索大数据的系统在分析 历史 数据的同时使用流处理来摄取新数据，这是一系列非常适合 NoSQL 数据库的功能。
Zoom使用 DynamoDB（按需模式）使其数据能够在没有性能问题的情况下进行扩展，即使该服务在 COVID-19 大流行的早期使用量激增。
物联网设备具有连接到互联网或通信网络的嵌入式软件和传感器，能够在无需人工干预的情况下收集和共享数据。随着数十亿台设备生成数不清的数据，IoT NoSQL 数据库为 IoT 服务提供商提供了可扩展性和更灵活的架构。
Freshub就是这样的一项服务，它从 MySQL 切换到 MongoDB，以更好地处理其大型、动态、非统一的数据集。
拥有数十亿智能手机用户，可扩展性正成为在移动设备上提供服务的企业面临的最大挑战。具有更灵活数据模型的 NoSQL DBMS 通常是完美的解决方案。
例如，The Weather Channel使用 MongoDB 数据库每分钟处理数百万个请求，同时还处理用户数据并提供天气更新。
1、使用冗余，每个人的好友信息都在数据库中有存储，就是你说的记录一对一关系
2、数据缓存到内存，数据访问很快
3、状态信息修改异步，比如一个人登陆了，他的好友不是马上就知道，中间间隔几秒也没有关系
4、数据可能不放在关系数据库中，可能使用nosql数据库，比如mongodb,bigtable,cassandra等
项目上需要找一个硬盘型的NoSQL，用于将 Redis 中的冷数据落入硬盘。初步选型了几款 key-value 类型的NoSQL，分别有 levelDB、 rocksDB、 TiDB、 SSDB、swapDB、 Kvrocks、Tikv 。均为基于 levelDB 开发的几款NoSQL。其中因为 levelDB、rocksDB 无网络接口，不方便做分布式和高可用。， TiDB 过重，还有 swapDB 社区不够活跃且相关client API不完备。暂时选型 SSDB 。
项目需要存储的其实是一个略长的二进制字符串，初步认为，使用 对象存储 方案其实也可以替代NoSQL，所以压测对象添加当前非常火的云原生对象存储 MinIO
硬件名|配置 系统| Ubuntu(基于win10 wsl版的docker启动) 内存| 16GB(实际可用6.08G) CPU| Intel i5-8400
测试项目： 1. 写50M数据100次 2. 随机读取任意key 100次（对LRU机制不友好）
写
数据导入成功！
数据序列化成功！
a 数据大小:50.99295234680176 MB
第1次写入总用时: 797 ms
第2次写入总用时: 848 ms
第3次写入总用时: 3621 ms
第4次写入总用时: 813 ms
第5次写入总用时: 1862 ms
第6次写入总用时: 838 ms
第7次写入总用时: 2235 ms
第8次写入总用时: 836 ms
第9次写入总用时: 900 ms
第10次写入总用时: 1027 ms
第11次写入总用时: 1101 ms
第12次写入总用时: 880 ms
第13次写入总用时: 1956 ms
第14次写入总用时: 866 ms
第15次写入总用时: 2422 ms
第16次写入总用时: 852 ms
第17次写入总用时: 4511 ms
第18次写入总用时: 875 ms
第19次写入总用时: 2736 ms
第20次写入总用时: 814 ms
第21次写入总用时: 7172 ms
第22次写入总用时: 891 ms
第23次写入总用时: 7820 ms
第24次写入总用时: 836 ms
第25次写入总用时: 22103 ms
第26次写入总用时: 877 ms
第27次写入总用时: 2712 ms
第28次写入总用时: 841 ms
第29次写入总用时: 1928 ms
第30次写入总用时: 916 ms
第31次写入总用时: 839 ms
第32次写入总用时: 826 ms
第33次写入总用时: 7759 ms
第34次写入总用时: 843 ms
第35次写入总用时: 10670 ms
第36次写入总用时: 843 ms
第37次写入总用时: 9361 ms
第38次写入总用时: 821 ms
第39次写入总用时: 810 ms
第40次写入总用时: 794 ms
第41次写入总用时: 13281 ms
第42次写入总用时: 833 ms
第43次写入总用时: 811 ms
第44次写入总用时: 798 ms
第45次写入总用时: 18843 ms
第46次写入总用时: 911 ms
第47次写入总用时: 9428 ms
第48次写入总用时: 898 ms
第49次写入总用时: 17582 ms
第50次写入总用时: 903 ms
第51次写入总用时: 831 ms
第52次写入总用时: 800 ms
第53次写入总用时: 14602 ms
第54次写入总用时: 827 ms
第55次写入总用时: 5898 ms
第56次写入总用时: 856 ms
第57次写入总用时: 5693 ms
第58次写入总用时: 1050 ms
第59次写入总用时: 882 ms
第60次写入总用时: 1020 ms
第61次写入总用时: 15060 ms
第62次写入总用时: 902 ms
第63次写入总用时: 1062 ms
第64次写入总用时: 915 ms
第65次写入总用时: 7572 ms
第66次写入总用时: 823 ms
第67次写入总用时: 9649 ms
第68次写入总用时: 832 ms
第69次写入总用时: 10403 ms
第70次写入总用时: 907 ms
第71次写入总用时: 978 ms
第72次写入总用时: 789 ms
第73次写入总用时: 2111 ms
第74次写入总用时: 947 ms
第75次写入总用时: 4675 ms
第76次写入总用时: 944 ms
第77次写入总用时: 8592 ms
第78次写入总用时: 832 ms
第79次写入总用时: 2940 ms
第80次写入总用时: 842 ms
第81次写入总用时: 19835 ms
第82次写入总用时: 862 ms
第83次写入总用时: 7646 ms
第84次写入总用时: 873 ms
第85次写入总用时: 1002 ms
第86次写入总用时: 842 ms
第87次写入总用时: 9057 ms
第88次写入总用时: 801 ms
第89次写入总用时: 5117 ms
第90次写入总用时: 918 ms
第91次写入总用时: 798 ms
第92次写入总用时: 853 ms
第93次写入总用时: 7728 ms
第94次写入总用时: 810 ms
第95次写入总用时: 3969 ms
第96次写入总用时: 814 ms
第97次写入总用时: 2050 ms
第98次写入总用时: 819 ms
第99次写入总用时: 9566 ms
第100次写入总用时: 833 ms/pre
随机读
第1次读取 15总用时: 2251 ms
第2次读取 73总用时: 2045 ms
第3次读取 98总用时: 1548 ms
第4次读取 20总用时: 2683 ms
第5次读取 46总用时: 1156 ms
第6次读取 69总用时: 1160 ms
第7次读取 46总用时: 1520 ms
第8次读取 51总用时: 1381 ms
第9次读取 48总用时: 1000 ms
第10次读取 69总用时: 1400 ms
第11次读取 82总用时: 1236 ms
第12次读取 22总用时: 1140 ms
第13次读取 36总用时: 864 ms
第14次读取 66总用时: 843 ms
第15次读取 47总用时: 922 ms
第16次读取 17总用时: 885 ms
第17次读取 14总用时: 864 ms
第18次读取 64总用时: 888 ms
第19次读取 74总用时: 815 ms
第20次读取 33总用时: 866 ms
第21次读取 36总用时: 822 ms
第22次读取 78总用时: 975 ms
第23次读取 40总用时: 1186 ms
第24次读取 54总用时: 857 ms
第25次读取 92总用时: 963 ms
第26次读取 43总用时: 955 ms
第27次读取 38总用时: 853 ms
第28次读取 47总用时: 926 ms
第29次读取 62总用时: 877 ms
第30次读取 70总用时: 890 ms
第31次读取 88总用时: 895 ms
第32次读取 15总用时: 937 ms
第33次读取 3总用时: 993 ms
第34次读取 99总用时: 892 ms
第35次读取 76总用时: 818 ms
第36次读取 30总用时: 1020 ms
第37次读取 89总用时: 863 ms
第38次读取 99总用时: 819 ms
第39次读取 62总用时: 818 ms
第40次读取 1总用时: 871 ms
第41次读取 66总用时: 809 ms
第42次读取 68总用时: 847 ms
第43次读取 72总用时: 910 ms
第44次读取 50总用时: 1128 ms
第45次读取 47总用时: 898 ms
第46次读取 26总用时: 909 ms
第47次读取 35总用时: 872 ms
第48次读取 30总用时: 826 ms
第49次读取 79总用时: 904 ms
第50次读取 66总用时: 863 ms
第51次读取 2总用时: 885 ms
第52次读取 65总用时: 900 ms
第53次读取 67总用时: 1023 ms
第54次读取 16总用时: 934 ms
第55次读取 63总用时: 892 ms
第56次读取 9总用时: 894 ms
第57次读取 71总用时: 896 ms
第58次读取 20总用时: 947 ms
第59次读取 89总用时: 865 ms
第60次读取 57总用时: 872 ms
第61次读取 62总用时: 856 ms
第62次读取 14总用时: 881 ms
第63次读取 19总用时: 950 ms
第64次读取 14总用时: 876 ms
第65次读取 86总用时: 968 ms
第66次读取 12总用时: 911 ms
第67次读取 93总用时: 877 ms
第68次读取 59总用时: 886 ms
第69次读取 79总用时: 878 ms
第70次读取 49总用时: 869 ms
第71次读取 91总用时: 964 ms
第72次读取 38总用时: 838 ms
第73次读取 73总用时: 915 ms
第74次读取 8总用时: 875 ms
第75次读取 96总用时: 827 ms
第76次读取 98总用时: 826 ms
第77次读取 95总用时: 892 ms
第78次读取 36总用时: 843 ms
第79次读取 44总用时: 872 ms
第80次读取 89总用时: 863 ms
第81次读取 24总用时: 883 ms
第82次读取 89总用时: 804 ms
第83次读取 49总用时: 876 ms
第84次读取 81总用时: 873 ms
第85次读取 72总用时: 914 ms
第86次读取 68总用时: 861 ms
第87次读取 73总用时: 893 ms
第88次读取 4总用时: 880 ms
第89次读取 3总用时: 987 ms
第90次读取 76总用时: 896 ms
第91次读取 16总用时: 1010 ms
第92次读取 73总用时: 903 ms
第93次读取 83总用时: 933 ms
第94次读取 52总用时: 945 ms
第95次读取 48总用时: 901 ms
第96次读取 26总用时: 942 ms
第97次读取 37总用时: 883 ms
第98次读取 44总用时: 866 ms
第99次读取 89总用时: 921 ms
第100次读取 61总用时: 896 ms/pre
写
数据导入成功！
第1次写入总用时: 956 ms
第2次写入总用时: 912 ms
第3次写入总用时: 1241 ms
第4次写入总用时: 1564 ms
第5次写入总用时: 942 ms
第6次写入总用时: 3666 ms
第7次写入总用时: 1629 ms
第8次写入总用时: 1712 ms
第9次写入总用时: 977 ms
第10次写入总用时: 1515 ms
第11次写入总用时: 911 ms
第12次写入总用时: 1009 ms
第13次写入总用时: 1024 ms
第14次写入总用时: 1206 ms
第15次写入总用时: 984 ms
第16次写入总用时: 943 ms
第17次写入总用时: 954 ms
第18次写入总用时: 1033 ms
第19次写入总用时: 1008 ms
第20次写入总用时: 1121 ms
第21次写入总用时: 963 ms
第22次写入总用时: 949 ms
第23次写入总用时: 889 ms
第24次写入总用时: 1066 ms
第25次写入总用时: 1289 ms
第26次写入总用时: 1125 ms
第27次写入总用时: 1111 ms
第28次写入总用时: 953 ms
第29次写入总用时: 964 ms
第30次写入总用时: 1125 ms
第31次写入总用时: 998 ms
第32次写入总用时: 1993 ms
第33次写入总用时: 926 ms
第34次写入总用时: 920 ms
第35次写入总用时: 926 ms
第36次写入总用时: 1169 ms
第37次写入总用时: 1325 ms
第38次写入总用时: 1170 ms
第39次写入总用时: 1074 ms
第40次写入总用时: 1011 ms
第41次写入总用时: 931 ms
第42次写入总用时: 984 ms
第43次写入总用时: 1563 ms
第44次写入总用时: 905 ms
第45次写入总用时: 944 ms
第46次写入总用时: 1147 ms
第47次写入总用时: 1429 ms
第48次写入总用时: 934 ms
第49次写入总用时: 1133 ms
第50次写入总用时: 912 ms
第51次写入总用时: 953 ms
第52次写入总用时: 1127 ms
第53次写入总用时: 1065 ms
第54次写入总用时: 1323 ms
第55次写入总用时: 1003 ms
第56次写入总用时: 1489 ms
第57次写入总用时: 1377 ms
第58次写入总用时: 940 ms
第59次写入总用时: 1317 ms
第60次写入总用时: 912 ms
第61次写入总用时: 898 ms
第62次写入总用时: 934 ms
第63次写入总用时: 1005 ms
第64次写入总用时: 1729 ms
第65次写入总用时: 983 ms
第66次写入总用时: 1684 ms
第67次写入总用时: 908 ms
第68次写入总用时: 895 ms
第69次写入总用时: 1171 ms
第70次写入总用时: 1372 ms
第71次写入总用时: 1261 ms
第72次写入总用时: 1024 ms
第73次写入总用时: 1048 ms
第74次写入总用时: 904 ms
第75次写入总用时: 941 ms
第76次写入总用时: 928 ms
第77次写入总用时: 1806 ms
第78次写入总用时: 1052 ms
第79次写入总用时: 1030 ms
第80次写入总用时: 1092 ms
第81次写入总用时: 1117 ms
第82次写入总用时: 950 ms
第83次写入总用时: 933 ms
第84次写入总用时: 928 ms
第85次写入总用时: 935 ms
第86次写入总用时: 1908 ms
第87次写入总用时: 994 ms
第88次写入总用时: 1097 ms
第89次写入总用时: 930 ms
第90次写入总用时: 1052 ms
第91次写入总用时: 1119 ms
第92次写入总用时: 958 ms
第93次写入总用时: 987 ms
第94次写入总用时: 973 ms
第95次写入总用时: 2036 ms
第96次写入总用时: 891 ms
第97次写入总用时: 954 ms
第98次写入总用时: 951 ms
第99次写入总用时: 1044 ms
第100次写入总用时: 1366 ms/pre
随机读
第1次读取 46总用时: 40 ms
第2次读取 8总用时: 36 ms
第3次读取 28总用时: 26 ms
第4次读取 80总用时: 10 ms
第5次读取 77总用时: 13 ms
第6次读取 27总用时: 49 ms
第7次读取 86总用时: 20 ms
第8次读取 0总用时: 45 ms
第9次读取 54总用时: 34 ms
第10次读取 24总用时: 153 ms
第11次读取 78总用时: 29 ms
第12次读取 0总用时: 17 ms
第13次读取 91总用时: 56 ms
第14次读取 5总用时: 99 ms
第15次读取 23总用时: 138 ms
第16次读取 37总用时: 120 ms
第17次读取 40总用时: 156 ms
第18次读取 88总用时: 41 ms
第19次读取 76总用时: 32 ms
第20次读取 49总用时: 102 ms
第21次读取 20总用时: 179 ms
第22次读取 40总用时: 68 ms
第23次读取 6总用时: 215 ms
第24次读取 36总用时: 197 ms
第25次读取 37总用时: 30 ms
第26次读取 68总用时: 154 ms
第27次读取 14总用时: 314 ms
第28次读取 27总用时: 91 ms
第29次读取 51总用时: 255 ms
第30次读取 66总用时: 166 ms
第31次读取 86总用时: 140 ms
第32次读取 29总用时: 374 ms
第33次读取 96总用时: 235 ms
第34次读取 68总用时: 72 ms
第35次读取 74总用时: 264 ms
第36次读取 11总用时: 334 ms
第37次读取 55总用时: 316 ms
第38次读取 31总用时: 287 ms
第39次读取 93总用时: 233 ms
第40次读取 44总用时: 499 ms
第41次读取 26总用时: 312 ms
第42次读取 76总用时: 33 ms
第43次读取 11总用时: 31 ms
第44次读取 86总用时: 191 ms
第45次读取 96总用时: 217 ms
第46次读取 20总用时: 145 ms
第47次读取 1总用时: 772 ms
第48次读取 69总用时: 477 ms
第49次读取 9总用时: 320 ms
第50次读取 46总用时: 42 ms
第51次读取 34总用时: 823 ms
第52次读取 76总用时: 115 ms
第53次读取 62总用时: 635 ms
第54次读取 99总用时: 596 ms
第55次读取 64总用时: 657 ms
第56次读取 66总用时: 97 ms
第57次读取 18总用时: 461 ms
第58次读取 91总用时: 247 ms
第59次读取 46总用时: 147 ms
第60次读取 12总用时: 702 ms
第61次读取 79总用时: 545 ms
第62次读取 47总用时: 956 ms
第63次读取 17总用时: 853 ms
第64次读取 97总用时: 771 ms
第65次读取 74总用时: 368 ms
第66次读取 84总用时: 790 ms
第67次读取 72总用时: 866 ms
第68次读取 82总用时: 742 ms
第69次读取 93总用时: 313 ms
第70次读取 57总用时: 917 ms
第71次读取 61总用时: 1185 ms
第72次读取 66总用时: 162 ms
第73次读取 5总用时: 168 ms
第74次读取 68总用时: 275 ms
第75次读取 43总用时: 1108 ms
第76次读取 74总用时: 281 ms
第77次读取 65总用时: 955 ms
第78次读取 22总用时: 1169 ms
第79次读取 88总用时: 501 ms
第80次读取 80总用时: 1685 ms
第81次读取 92总用时: 1286 ms
第82次读取 89总用时: 1680 ms
第83次读取 30总用时: 1537 ms
第84次读取 41总用时: 1576 ms
第85次读取 2总用时: 2193 ms
第86次读取 52总用时: 1817 ms
第87次读取 8总用时: 323 ms
第88次读取 81总用时: 1409 ms
第89次读取 40总用时: 577 ms
第90次读取 88总用时: 598 ms
第91次读取 19总用时: 2324 ms
第92次读取 75总用时: 2275 ms
第93次读取 29总用时: 668 ms
第94次读取 77总用时: 2773 ms
第95次读取 62总用时: 484 ms
第96次读取 84总用时: 883 ms
第97次读取 32总用时: 2945 ms
第98次读取 44总用时: 884 ms
第99次读取 66总用时: 631 ms
第100次读取 38总用时: 2739 ms/pre
非常奇怪的是 MinIO 整体性能略优于 SSDB 但是理论上不太应该， SSDB 怎么说也是半内存半硬盘的NoSQL不应该比纯硬盘的 MinIO 性能要差，有可能是 SSDB 写到一定数据量后把本机内存写爆了，导致读写非常慢。但这变相验证了 SSDB 在极端情况下的不稳定。
块存储和文件存储。
1、块存储
以下列出的两种存储方式都是块存储类型：
1） DAS（Direct Attach STorage）：是直接连接于主机服务器的一种储存方式，每一台主机服务器有独立的储存设备，每台主机服务器的储存设备无法互通，需要跨主机存取资料时，必须经过相对复杂的设定，若主机服务器分属不同的操作系统，要存取彼此的资料，更是复杂，有些系统甚至不能存取。通常用在单一网络环境下且数据交换量不大，性能要求不高的环境下，可以说是一种应用较为早的技术实现。
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 三种技术的比较