Hashed合伙人Ethan Kyuntae Kim:未来每个人都可以更自由地通过区块链来赚钱

2018年6月3日,由全球最大开发者社区优快云和专注以太坊生态建设的领先企业灵钛科技主办,以太坊爱好者社区、柏链道捷、火星财经、金色财经、Unitimes、区块链大本营协办的「2018以太坊技术及应用大会·中国」在北京·悠唐皇冠假日酒店隆重举行。

本次大会围绕以太坊生态、以太坊核心技术、以太坊优质应用展开,邀请了众多国内外顶级开发者、以太坊团队核心成员,以及顶级项目负责人齐聚于此,共同助力中国以太坊技术深度交流和社区发展。

作为本届大会的受邀嘉宾,Hashed合伙人 & CTO Ethan Kyuntae Kim 发表主题演讲《Potentials of the Blockchain Technology and Current Limitations》(小编注:区块链技术的潜力与当下的制约)

这里写图片描述

Hashed,原名叫BPK(Blockchain Partners Korea),是韩国最大的数字货币基金会,规模最大的区块链投资基金,也是不少知名区块链项目的最大投资者,其投资项目包括ETH、OMG,EOS、Qtum等。

在演讲中,Ethan Kyuntae Kim分享了区块链的各项优势,以及他眼中所看到的区块链世界的未来潜力。

以下为Ethan Kyuntae Kim的演讲实录:

2008年,中本聪发出了一篇文章,虽然只有9页,但是解释了如何建立一个端对端的网络,去实现电子商务交易,而不需要任何授信代理机制。

这里写图片描述

这样的去中介化的信任机制,是通过分布式的网络节点来起作用的。在这个去中心化的网络中,每个节点都能起作用,即便某些节点不在线,也不会影响到其他节点的使用。这要是在传统集中式的网络中,某个节点有故障,比如受到DDos攻击情况,就瘫痪了。但在区块链网络中,由于每个节点都以同样的方式去运行,而没有一个集团或个人去完全占有、拥有或执行,所以这个网络拥有更大的力量。

此外,区块链非常透明的。每个节点平等共享资源,开发者可以在上面进行数据撰写,并且共享记录,而这些数字都可以包含所有内容,比如文章等,只要你能够想象得到,它就可以覆盖。

同时,有了区块链之后,我们可以将数字价值和人连接在一起。正是因为有了智能合约,所有的这些应用都可以连接在一起,由律师或会计进行撰写。到底怎么利用区块链的特点呢?我们可以充分利用自己的想象力。

现在因为我们使用了很多大企业提供的服务,也在数字世界中留下了很多信息,比如我们看了什么信息、买了哪些产品、见了哪些人。这些巨头公司也通过使用我们的信息赚了很多钱。很多人觉得这是一个互利互惠的关系,我们用大公司免费的服务,大的互联网企业也可以用我们的数据赚钱。这从某种角度来说是对的,但他们从我们身上拿到的数据越来越多,信息的不对称性也就越强。

如果我们充分利用区块链的特性,就可以建立全新的生态系统,一个非常透明的、去中心化的生态系统,在这个系统中没有人能够说谎,每个人都可以得到激励,并参与到网络中。企业也可以建立一个庞大的经济体系。给大家解释一下这是怎样的一个体系。

首先,通过智能合约,所有个人和企业都可以发起各种各样的活动,所有的个人和参与者都会因为加入这个网络而获得激励。这时我们就需要使用到数字加密货币。
我们要为什么建立一个去中心化的网络?因为如果每个人都可以在这个网络上自律,并且通过这个网络去获取利益,那么这个网络会变得更强健、更安全。所以在这个去中心化的网络上,它不仅仅是一个计算的分布式网络,它也是一个分布式的监管网络。

在由区块链构建的生态系统中,人们可以在这里获得产品和服务,并支付一些货币给商户。这个时候用户可以选择是否允许在社区中分享隐私信息,包括年龄、买了什么产品、什么时候买的产品等等。如果愿意将把这些信息在网络上进行分享,就可以获得一些补偿。最关键的是,生态系统变得更安全,因为只有其中的每个个体都扩大自己利益边界时,才能实现这点。

这里写图片描述

北京、纽约、东京等大城市,在实现未来区块链网络化时,有很多便利条件。比如韩国,它有5000万人口,其中超过一半是在首尔和大都市地区,40%的白领购买过数字货币,很多地方公司很愿意进入这个领域。韩国人很理解数字资产的概念。基于此,如果未来推出一种分布式的吸引用户的各类服务,是很有吸引力的。即便现在用户量并没有那么大,但如果在实施中有一个协议和代币,就会发展得特别快。
当前最大挑战是如何让更多人在开源项目中进行贡献。韩国到目前为止还有大量的问题需要解决。

我们也希望能不断找到合适的团队,将区块链协同应用到当前的业务中。我们也希望帮助更多开发者社区不断成长。

谢谢大家!

注:为方便大家及时回顾大会嘉宾演讲信息,文章成稿速度较快,其中难免会有一些纰漏,欢迎您及时指出,相关建议请发送至邮箱:puge@youkuaiyun.com,非常感谢!后续我们还将在区块链大本营公众号(ID:blockchain_camp)陆续推出精编文章,敬请关注。

<think> 我们正在讨论的是一个MongoDB的分片命令。这个命令用于对一个集合进行分片,指定分片键和分片策略。 命令详解: db.runCommand({ shardCollection: "mydb.video_summary_index", // 指定要分片的集合,格式为"数据库名.集合名" key: {"device_id": "hashed", "channel": 1} // 指定分片键,这里使用了复合分片键,其中device_id字段使用哈希分片,channel字段使用范围分片 }) 接下来,我将详细解释这个命令的含义和分片策略。 ### 分片键解析 1. **复合分片键**:这个分片键由两个字段组成:`device_id`和`channel`。 2. **哈希分片**:`device_id`字段使用了`"hashed"`策略,这意味着MongoDB会对`device_id`的值进行哈希运算,然后根据哈希值分配数据到不同的分片上。哈希分片可以保证数据均匀分布,尤其适用于字段值分布不均(如单调递增或递减)的场景。 3. **范围分片**:`channel`字段使用了`1`(升序)的范围分片策略。范围分片会根据字段值的范围将数据分配到不同的分片。这种策略适合范围查询,因为相邻的值可能会存储在同一个分片上,可以提高范围查询的效率。 ### 分片规则 - 当插入或新文档时,MongoDB会使用分片键的值来决定该文档应该存储在哪个分片上。 - 对于复合分片键,MongoDB首先使用第一个字段(即`device_id`)的哈希值来确定数据的大致分布,然后再根据第二个字段(`channel`)的值进行微调,最终确定数据应该落在哪个分片上。 ### 为什么使用这种分片策略? 1. **数据均匀分布**:使用`device_id`的哈希分片能够确保不同的`device_id`均匀分布到各个分片,避免热点问题(即所有数据都集中在一个分片上)。 2. **查询优化**:如果查询条件中同时包含`device_id`和`channel`,那么这种分片策略可以高效地定位到具体分片。特别是对于等值查询(如`device_id=xxx`),哈希分片能够快速定位到分片;而对于范围查询(如`channel`的范围查询),由于哈希分片已经将数据打散,可能需要在多个分片上执行查询(但如果查询条件同时指定了`device_id`的精确值,则可以直接定位到某个分片)。 ### 示例说明 假设我们有以下文档: ```json { "device_id": "d1", "channel": "c1", ... } { "device_id": "d2", "channel": "c1", ... } { "device_id": "d3", "channel": "c2", ... } ``` - 对于文档1:MongoDB先计算`d1`的哈希值(假设为`h1`),然后结合`channel`的值`c1`,确定分片(假设分片A)。 - 对于文档2:计算`d2`的哈希值(假设为`h2`),结合`c1`,可能分配到分片B。 - 对于文档3:计算`d3`的哈希值(假设为`h3`),结合`c2`,可能分配到分片C。 ### 注意事项 1. **分片键选择**:分片键一旦确定就不能改,因此需要谨慎选择。复合分片键中字段的顺序非常重要,因为MongoDB使用字段的顺序来划分数据。 2. **索引要求**:分片键必须在集合上有一个索引(可以是复合索引),且该索引必须是前缀索引(即分片键字段的顺序和索引字段顺序一致)。在创建分片集合之前,需要先创建这个索引。 3. **哈希分片限制**:哈希分片不能用于地理空间索引,也不支持浮点数字段(会转换为整数)。另外,哈希分片键只能有一个字段,但可以与其他字段组合成复合分片键(如本例)。 ### 创建分片集合的步骤 1. 启用分片数据库(如果还未启用): ```javascript sh.enableSharding("mydb") ``` 2. 创建支持分片键的索引(如果不存在): ```javascript db.video_summary_index.createIndex({"device_id": "hashed", "channel": 1}) ``` 注意:在MongoDB中,哈希索引只能针对单个字段,所以实际创建的是一个复合索引,其中`device_id`字段是哈希索引,`channel`是升序索引。但MongoDB允许在分片键中混合使用哈希和范围字段,因此这个索引可以这样创建: ```javascript db.video_summary_index.createIndex({"device_id": 1, "channel": 1}) // 注意:这里不能直接创建哈希字段与其他字段的复合索引 ``` 然而,上面的写法是错误的,因为MongoDB不支持在一个复合索引中同时包含哈希索引和其他类型索引。实际上,在分片键中使用混合类型(哈希和范围)时,MongoDB会在后台处理索引,我们只需要创建分片键,MongoDB会自动管理索引。但是,根据官方文档,分片键必须是索引或索引的前缀。而且,对于哈希分片键,它必须是单个字段的哈希索引,或者复合分片键的第一个字段是哈希索引。 因此,正确的做法是先为`device_id`创建哈希索引,然后再创建复合索引(实际上,由于分片键包含了两个字段,我们需要创建一个复合索引,其中第一个字段是`device_id`(哈希),第二个字段是`channel`(升序))。但是,MongoDB不允许在一个索引中混合哈希和升序。所以,我们需要这样处理: 实际上,在分片键中混合哈希和范围分片时,MongoDB要求分片键是一个复合索引,并且第一个字段是哈希索引,其余字段是升序或降序索引。但是,在MongoDB中,我们不能创建一个同时包含哈希索引和其他类型的复合索引。 根据MongoDB官方文档:复合哈希索引是不允许的。也就是说,你只能在单个字段上创建哈希索引。那么,当分片键是复合字段(一个哈希字段和一个范围字段)时,我们该如何创建索引呢? 实际上,MongoDB在分片集合时,会自动创建必要的索引。所以,我们只需在分片命令中指定分片键,MongoDB会自动创建对应的索引(如果不存在)。因此,我们不需要提前手动创建索引。 但是,为了查询性能,我们可能还需要创建其他索引。 总结:执行分片命令时,如果分片键对应的索引不存在,MongoDB会自动创建。对于混合分片键(哈希+范围),MongoDB会创建一个特殊的索引来支持分片。 3. 执行分片命令: ```javascript db.runCommand({ shardCollection: "mydb.video_summary_index", key: {"device_id": "hashed", "channel": 1} }) ``` ### 总结 该分片命令的含义是:使用复合分片键对集合`mydb.video_summary_index`进行分片,其中`device_id`字段采用哈希分片策略,`channel`字段采用范围分片策略。这种分片策略既保证了数据分布的均匀性(通过`device_id`的哈希),又支持对`channel`的范围查询优化。 §§相关问题§§: 1. MongoDB哈希分片和范围分片各自适用的场景是什么? 2. 如何选择合适的分片键来避免数据热点? 3. MongoDB分片后,如何管理分片以实现集群的平衡? 4. 分片集合的查询操作与普通集合有哪些不同? </think> # MongoDB 分片命令详解:`db.runCommand({shardCollection:"mydb.video_summary_index",key:{"device_id":"hashed","channel":1}})` 这个 MongoDB 命令用于在分片集群环境中对一个集合进行分片设置。下面我将详细解析其含义、工作原理和实际应用场景。 ## 命令结构解析 ```javascript db.runCommand({ shardCollection: "mydb.video_summary_index", // 要分片的集合 key: {"device_id": "hashed", "channel": 1} // 分片键定义 }) ``` ### 关键参数说明 | 参数 | 说明 | |------|------| | `shardCollection` | 指定要分片的集合,格式为 `数据库名.集合名` | | `key` | 定义分片键 (Shard Key),控制数据如何分布到不同分片 | | `"device_id": "hashed"` | 对 device_id 字段使用哈希分片策略 | | `"channel": 1` | 对 channel 字段使用范围分片策略 (1 表示升序) | ## 分片策略详解 ### 1. 复合分片键 (Compound Shard Key) 这个配置定义了复合分片键,包含两个字段: - **device_id**:使用哈希分片策略 - **channel**:使用范围分片策略 ### 2. 哈希分片 (Hashed Sharding) ```javascript "device_id": "hashed" ``` - **工作原理**:MongoDB 对 `device_id` 字段值应用哈希函数,生成哈希值 - **数据分布**:基于哈希值将文档均匀分布到不同分片 - **优点**: - 数据分布均匀,避免热点问题 - 适合高写入负载 - 对离散值查询友好 - **缺点**:范围查询效率较低 ### 3. 范围分片 (Ranged Sharding) ```javascript "channel": 1 ``` - **工作原理**:基于 `channel` 字段的值范围划分数据 - **数据分布**:连续的值范围存储在相同分片 - **优点**: - 高效的范围查询(如 `channel: {$gt: 'A', $lt: 'M'}`) - 地理空间数据友好 - **缺点**:可能导致数据分布不均(热点问题) ## 分片键选择的实际含义 ### 数据分布逻辑 MongoDB 使用以下逻辑确定文档存储位置: 1. 计算 `device_id` 的哈希值 2. 组合 `哈希值 + channel` 创建复合键 3. 根据复合键值的范围划分数据段(chunks) 4. 将数据段分配到集群中的不同分片 ### 典型应用场景 这种分片策略非常适合: 1. 视频监控系统(基于设备ID和设备通道) 2. IoT 设备数据存储 3. 多租户应用(租户ID + 资源类型) 4. 需要平衡读写负载的场景 ## 分片操作完整流程 ### 1. 创建分片集合前准备 ```javascript // 启用数据库分片 sh.enableSharding("mydb") // 创建必要索引(MongoDB 自动处理分片键索引) db.video_summary_index.createIndex({"device_id": "hashed", "channel": 1}) ``` ### 2. 执行分片命令 ```javascript db.runCommand({ shardCollection: "mydb.video_summary_index", key: {"device_id": "hashed", "channel": 1} }) ``` ### 3. 验证分片状态 ```javascript // 检查分片状态 db.video_summary_index.getShardDistribution() // 查看数据分布情况 use config db.chunks.find({ns: "mydb.video_summary_index"}).sort({min: 1}) ``` ## 分片集群数据分布示例 假设有 4 个分片,数据可能这样分布: | 分片 | 数据范围示例 | |------|--------------| | shard1 | `{ device_id: hash(0-25), channel: A-D }` | | shard2 | `{ device_id: hash(25-50), channel: D-G }` | | shard3 | `{ device_id: hash(50-75), channel: G-K }` | | shard4 | `{ device_id: hash(75-100), channel: K-Z }` | ## 最佳实践与注意事项 1. **分片键选择原则** - 基数高(字段值多样化) - 写操作分布均匀 - 匹配常见查询模式 2. **热点问题解决方案** ```javascript // 启用自动分片平衡器 sh.startBalancer() // 手动拆分大块数据 sh.splitAt("mydb.video_summary_index", { "device_id": BinData(0, "E90D..."), "channel": "M" }) ``` 3. **查询优化建议** - 查询条件应包含分片键前缀(device_id) - 避免全分片扫描的查询 - 使用集群覆盖索引 ```javascript // 高效的查询(使用分片键前缀) db.video_summary_index.find({ "device_id": "device_123", "channel": "front_camera" }) // 低效的查询(缺少分片键前缀) db.video_summary_index.find({ "channel": "front_camera" // 需要扫描所有分片 }) ``` 4. **监控和维护** ```bash # 查看分片状态 mongosh> sh.status() # 监控块迁移 mongosh> db.currentOp({ "desc": /Balancer/ }) ``` ## 常见问题解决方案 **问题1:分片后性能下降** - 检查查询是否使用分片键 - 确保分片键索引存在 - 优化分片键选择 **问题2:数据分布不均** - 手动拆分大数据块 - 调整分片键策略 - 增加分片数量 **问题3:分片键修改** - MongoDB 不支持修改分片键 - 解决方案: 1. 创建新分片集合 2. 导出/导入数据 3. 新应用逻辑 ## 总结 该分片命令创建了一个复合分片键策略,结合了哈希分片和范围分片的优势: 1. `device_id` 的哈希分片确保数据均匀分布 2. `channel` 的范围分片优化相关数据的查询效率 3. 特别适合设备+通道的多维数据模型 4. 为大规模视频监控数据提供水平扩展能力 这种分片策略在 IoT、监控系统和多租户应用中表现出色,平衡了写入性能和查询效率的需求。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值