推荐 | 云上 Index：看“简墨”如何为云原生打造全新索引 - PostgreSQLChina的个人空间 - OSCHINA

前

言

拓数派首款数据计算引擎 PieCloudDB 是一款全新的云原生虚拟数仓。为了提升用户使用体验，提高查询效率，在实现存算分离的同时，PieCloudDB 设计与打造了全新的存储引擎「简墨」等模块，并针对云场景和分析型场景设计了高效的「Data Skipping」索引。

本文将详细介绍 PieCloudDB 的存储和索引的设计与打造过程，并将通过示例来演示 PieCloudDB 如何使用 Data Skipping 索引加速查询的效率。

作者 | Junfeng Yang, 拓数派 PieCloudDB 技术专家

作为一款云原生虚拟数仓，PieCloudDB 依赖于云计算所提供的基础设施服务，包括大规模分布式集群、虚拟机、容器等。通过利用这些服务，PieCloudDB 可以更好地适应动态的和不断变化的工作负载需求，并将实现高可用、易扩展、异地多活和弹性伸缩等特性。

索引是数据库系统提升查询效率的关键技术，其设计与存储息息相关。为了更好地适应云原生和分析型场景的要求，PieCloudDB 必须使用合理的存储架构及技术，打造一款全新的存储引擎，并实现高效的云上索引技术，满足用户查询需求。PieCloudDB 的存储作为将应用程序和用户数据连接起来的关键桥梁，是云原生虚拟数仓应用的核心组成部分。PieCloudDB 全新存储引擎「简墨」是一款专为云原生和分析型场景设计的高效存储引擎，旨在提供优异的查询性能和灵活的索引技术，以满足用户在云上的数据查询需求。

「简墨」：命名源自「竹简墨书」

在介绍云上 Index 「Data Skipping」之前，我们先了解一下 PieCloudDB 存储的设计逻辑。

为了让 PieCloudDB 能够满足不同类型的应用程序要求，PieCloudDB 所打造的存储被分为持久层和数据层两个存储层次：

● 持久层：持久层是 PieCloudDB 中的底层存储，通常采用分布式文件系统或对象存储系统等云原生存储，如 AWS S3、Azure Blob Storage 等。持久层具有高可用性、持久性等特点，能够安全地保持数据并保证数据的长期存储。

● 数据层：数据层是 PieCloudDB 的上层抽象，提供面向应用程序的标准访问接口，包括半结构化数据、结构化数据和支持 SQL 的无结构化数据存储。

基于上述存储层设计，PieCloudDB 可以满足许多不同类型的应用程序需求。同时，在云计算基础设施的帮助下，PieCloudDB 已实现容器化部署、自动化运维、微服务架构等功能，这样的架构设计为企业用户提供更高效、更可靠、更灵活以及成本更低的解决方案。

01. PieCloudDB 数据的持久化设计

对于数据的持久化的设计，通常有如下三种形式：

● N 元存储模型（即通常所说的行存）

● 分解存储模型（即通常所说的列存）

● 混合存储模型

PieCloudDB 采用了第三种：混合存储模型。混合存储模型是将一组数据水平分组，然后将它们的属性垂直划分为列。通过这样的存储模型，PieCloudDB 得以获得列式存储高效处理和压缩友好等优势，同时保留行存储的空间局部性优势，降低数据重组的开销。这一存储模型的选择也影响了 PieCloudDB 中的索引设计，后文将详细介绍。

02. PieCloudDB 存储底座

PieCloudDB 使用对象存储技术作为云原生虚拟数仓存储底层。对象存储可以带来可伸缩性、弹性扩展和高度容错性等优点。然而，在实际的使用过程中往往也遇到一些限制，主要包括以下几个方面：

● 延迟： 与传统的块存储技术相比，对象存储技术往往具有较高的延迟，因此在某些应用场景下，可能会对数据库的性能产生一定影响。

● 大规模重写操作难以支持： 对象存储基于分布式系统实现，而复杂的存储操作（如大规模数据的重写）实现起来是比较困难的，但是，这类操作在关系型数据库中常常会遇到。

● 事务管理： 对象存储通常提供了乐观并发控制等简单的事务管理机制，但是它们在处理分布式事务时很复杂，并且由于分散在多处，难以跨所有节点维护一个全局锁或者其他的协调机制。

● 数据一致性：尽管对象存储具有高可靠性和冗余性，但其异步特性意味着分布式数据的一致性需要通过额外的手段来维护，远比其他的分布式数据库解决方案更为复杂，同时也存在较高的管理成本。

PieCloudDB 在存储的打造过程中进行了大量设计来弥补这些限制，保证用户的使用体验。例如针对其中第二个方面，PieCloudDB 的持久化文件在生成后无法进行原地修改。因此，PieCloudDB 在 update/delete 时，会生成新的文件，在新文件中将包含未修改的数据和新增的修改后的数据，并将保留旧的数据文件。相关细节将在未来的技术文章中进行说明，欢迎关注。

基于云的基础设施的特点和 PieCloudDB 的存储设计思路，PieCloudDB的存储具有以下两个重要的特性。

● 使用混合存储模型

● 持久化的文件不会被修改

这些特性也决定了 PieCloudDB 索引的打造思路。在详细介绍 PieCloudDB 的索引特性前，我们先了解一下索引的常见类型。

01. 索引的常见类型

在 OLTP 场景中，数据库通常处理大量的短期事务，需要高效地执行单个记录的读写操作。为了避免对数据进行全量扫描，采用基于树的索引结构（如 B+树）可以加速少量数据的查询。这些索引帮助数据库引擎快速定位到特定记录，从而提高读取和写入的性能。随着数据的增量更新，索引也需要随之更新以保持数据的一致性和性能。

而在 OLAP 场景中，数据库通常面对大量数据的分析查询，例如数据仓库和数据分析。在这种情况下，很少涉及单个记录的查找，而是涉及到对大量数据的聚合、过滤和分析。传统的索引结构可能不再适用，因为对大规模数据集的全量扫描可能会变得非常耗时。

为了加速 OLAP 查询的执行，PieCloudDB 采用数据跳跃（Data Skipping）技术。数据跳跃是一种先进的优化技术，用于尽可能减少扫描数据时的 I/O 开销。它的主要思想是在执行查询时，跳过对那些不符合查询条件的数据块或分区的扫描。这样可以有效地减少 I/O 操作，从而加速查询的执行速度。

02. PieCloudDB 中的 Data Skipping 索引

Zone Map 索引和 BRIN（Block Range INdex）索引是在 OLAP 场景中常见的数据跳跃（Data Skipping）技术的具体实现方式。它们都利用了预先计算的统计信息来跳过不符合查询条件的数据块，从而加速查询的执行。

「Data Skipping」演示

Zone Map 是通过存储每个数据块的选定列的预先计算统计信息，例如最小值和最大值，以及其他聚合信息。在查询期间，数据库可以使用这些统计信息来裁减要访问的数据块，从而减少不必要的 I/O 操作，提高查询性能。这在OLAP 场景中对大规模数据集的查询非常有用。

在 PieCloudDB 中，每个数据块即是一组记录的列存数据。在数据导入时，每个文件将会统计对应数据块所需列的统计信息，得益于数据存储的实现，每列的统计过程和存储也变得更为简单高效。

03. 示例

在 PieCloudDB 中，当用户进行查询时，对于每一个数据块，首先会通过查询条件对应列的统计信息判断是否满足条件，如果满足则访问该数据块，如果不满足则跳过该数据块。接下来我们将通过一个示例为大家详细演示 PieCloudDB 的 Data Skipping 功能。

首先，创建一张表，分次导入一些测试数据。

CREATE TABLE dataskip (a int, b int); 

INSERT INTO dataskip SELECT i, i*2 FROM generate_series(1, 1000)i; 

INSERT INTO dataskip SELECT i, i*2 FROM generate_series(1001, 2000)i; 

INSERT INTO dataskip SELECT i, i*2 FROM generate_series(2001, 3000)i; 

INSERT INTO dataskip SELECT i, i*2 FROM generate_series(3001, 4000)i; 

INSERT INTO dataskip SELECT i, i*2 FROM generate_series(4001, 5000)i; 

INSERT INTO dataskip SELECT i, i*2 FROM generate_series(5001, 6000)i; 

INSERT INTO dataskip SELECT i, i*2 FROM generate_series(6001, 7000)i; 

INSERT INTO dataskip SELECT i, i*2 FROM generate_series(7001, 8000)i; 

INSERT INTO dataskip SELECT i, i*2 FROM generate_series(8001, 9000)i; 

INSERT INTO dataskip SELECT i, i*2 FROM generate_series(9001, 10000)i;  

CREATE TABLE jtbl (a int, b int);

INSERT INTO jtbl SELECT i, i * random() FROM generate_series(1, 1000)i;

现在来执行查询：

demo=# EXPLAIN ANALYZE SELECT * FROM dataskip WHERE a < 10; 
                                  QUERY PLAN 
------------------------------------------------------------------------- 
Gather Motion 3:1 (slice1; segments: 3) (cost=2.00..10.21 rows=3 width=8) (actual time=34.361..36.928 rows=9 loops=1) 
-> Bitmap Heap Scan on dataskip (cost=2.00..10.17 rows=1 width=8) (actual time=16.189..31.790 rows=5 loops=1) 
    Recheck Cond: (a < 10) 
    Rows Removed by Index Recheck: 316 
    -> Bitmap Index Scan on dataskip (cost=0.00..2.00 rows=333 width=0) (actual time=2.908..2.910 rows=1 loops=1) 
        Index Cond: (a < 10)  
Planning Time: 4.259 ms 
  (slice0) Executor memory: 159K bytes. 
  (slice1) Executor memory: 32972K bytes avg x 3 workers, 32972K bytes max (seg0). 
Memory used: 128000kB 
Optimizer: Postgres query optimizer 
Execution Time: 55.895 ms 
(12 rows)

如果关闭 Data Skipping 查询：

demo=# SET enable_bitmapscan = off;
SET
demo=# EXPLAIN ANALYZE SELECT * FROM dataskip WHERE a < 10;
                                                             QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
Gather Motion 3:1  (slice1; segments: 3)  (cost=0.00..51.71 rows=3 width=8) (actual time=129.916..140.925 rows=9 loops=1)
    -> Seq Scan on dataskip  (cost=0.00..51.67 rows=1 width=8) (actual time=2.939..132.546 rows=5 loops=1)
         Filter: (a < 10)
         Rows Removed by Filter: 3292
Planning Time: 0.099 ms
   (slice0) Executor memory: 123K bytes.
   (slice1) Executor memory: 32825K bytes avg x 3 workers, 32825K bytes max (seg0).
Memory used:  128000kB
Optimizer: Postgres query optimizer
Execution Time: 154.416 ms
(10 rows)

可以看到，当关闭 Data Skipping 时，可以看到执行时间是使用时的三倍。

这里还面临查询优化器的一个挑战，在复杂的 join 查询条件下，需要尽可能的将 join 条件或 where 条件下推到扫描节点上来尽可能的利用 Data Skipping。在这一点上，PieCloudDB 远胜于其他的产品。

demo=# EXPLAIN ANALYZE SELECT * FROM dataskip JOIN jtbl ON dataskip.a = jtbl.a and jtbl.a < 10;
                                                                  QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------
Gather Motion 3:1  (slice1; segments: 3)  (cost=2.00..15.47 rows=3 width=16) (actual time=33.638..33.712 rows=9 loops=1)
  -> Nested Loop  (cost=2.00..15.43 rows=1 width=16) (actual time=33.300..33.405 rows=5 loops=1)
        Join Filter: (dataskip.a = jtbl.a)
        Rows Removed by Join Filter: 20
        -> Redistribute Motion 3:3  (slice2; segments: 3)  (cost=0.00..5.21 rows=2 width=8) (actual time=0.003..0.013 rows=5 loops=1)
              Hash Key: jtbl.a
              -> Seq Scan on jtbl  (cost=0.00..5.17 rows=2 width=8) (actual time=3.144..20.979 rows=3 loops=1)
                     Filter: (a < 10)
                     Rows Removed by Filter: 356
        -> Materialize  (cost=2.00..10.19 rows=1 width=8) (actual time=5.547..5.554 rows=4 loops=6)
              -> Redistribute Motion 3:3  (slice3; segments: 3)  (cost=2.00..10.19 rows=1 width=8) (actual time=33.130..33.269 rows=5 loops=1)
                     Hash Key: dataskip.a
                     -> Bitmap Heap Scan on dataskip  (cost=2.00..10.17 rows=1 width=8) (actual time=11.766..24.910 rows=5 loops=1)
                           Recheck Cond: (a < 10)
                           Rows Removed by Index Recheck: 316
                           -> Bitmap Index Scan on dataskip  (cost=0.00..2.00 rows=333 width=0) (actual time=2.783..2.784 rows=1 loops=1)
                                 Index Cond: (a < 10)
Planning Time: 6.522 ms
  (slice0) Executor memory: 220K bytes.
  (slice1) Executor memory: 79K bytes avg x 3 workers, 80K bytes max (seg0).  Work_mem: 17K bytes max.
  (slice2) Executor memory: 32826K bytes avg x 3 workers, 32826K bytes max (seg0).
  (slice3) Executor memory: 32975K bytes avg x 3 workers, 32975K bytes max (seg0).
Memory used:  128000kB
Optimizer: Postgres query optimizer
Execution Time: 68.989 ms
(25 rows)

对于相同的 Query，当我们关掉 Data Skipping 时，查询时间又变成了前者的3倍。

demo=# SET enable_bitmapscan = off;
SET
demo=# EXPLAIN ANALYZE SELECT * FROM dataskip JOIN jtbl ON dataskip.a = jtbl.a and jtbl.a < 10;
                                                                  QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------
Gather Motion 3:1  (slice1; segments: 3)  (cost=0.00..56.97 rows=3 width=16) (actual time=139.811..139.886 rows=9 loops=1)
  -> Nested Loop  (cost=0.00..56.92 rows=1 width=16) (actual time=139.587..139.691 rows=5 loops=1)
        Join Filter: (dataskip.a = jtbl.a)
        Rows Removed by Join Filter: 20
        -> Redistribute Motion 3:3  (slice2; segments: 3)  (cost=0.00..5.21 rows=2 width=8) (actual time=0.003..0.011 rows=5 loops=1)
              Hash Key: jtbl.a
              -> Seq Scan on jtbl  (cost=0.00..5.17 rows=2 width=8) (actual time=1.758..21.023 rows=3 loops=1)
                    Filter: (a < 10)
                    Rows Removed by Filter: 356
        -> Materialize  (cost=0.00..51.69 rows=1 width=8) (actual time=23.262..23.269 rows=4 loops=6)
              -> Redistribute Motion 3:3  (slice3; segments: 3)  (cost=0.00..51.69 rows=1 width=8) (actual time=136.260..139.557 rows=5 loops=1)
                    Hash Key: dataskip.a
                    -> Seq Scan on dataskip  (cost=0.00..51.67 rows=1 width=8) (actual time=1.730..134.913 rows=5 loops=1)
                          Filter: (a < 10)
                          Rows Removed by Filter: 3292
Planning Time: 0.248 ms
  (slice0) Executor memory: 185K bytes.
  (slice1) Executor memory: 79K bytes avg x 3 workers, 80K bytes max (seg0).  Work_mem: 17K bytes max.
  (slice2) Executor memory: 32826K bytes avg x 3 workers, 32826K bytes max (seg0).
  (slice3) Executor memory: 32827K bytes avg x 3 workers, 32827K bytes max (seg0).
Memory used:  128000kB
Optimizer: Postgres query optimizer
Execution Time: 155.026 ms
(23 rows)

03. Primary Key 的支持

对于一般的 OLTP 数据库中，Primary Key 的作用主要包含以下几个方面：

● 加速点查

● 确保唯一性约束

● 确保非空约束

然而，在 OLAP 数据库中，因为其主要面向分析查询，点查（Point Lookup）的需求较少，而全表扫描和大规模数据跳跃技术更为重要。因此，一些 OLAP 数据库在实现 Primary Key 时会做出相应的调整。

例如，在 ClickHouse 中，Primary Key 被用于数据加载时进行排序，排序之后的数据可大大提高 Data Skipping 的性能。在 Snowflake 中也有类似的 Cluster Key 来使数据块具有聚集性，再通过 Auto Cluster（自动聚集）来提高 Data Skipping 的性能（Databricks 也采用类似的方式）。

在 PieCloudDB 中 Primary Key 支持非空约束，但是对于查询的加速，一般使用 Data Skipping。对于唯一值约束，PieCloudDB 中暂不支持。

除了 Data Skipping，PieCloudDB 也在调研和实现多种多样的索引以提供不同场景的性能提升，包括基于 Data Skipping 思路的其他索引探索和 OLTP 场景下的索引探索。

01. 基于 Data Skipping 思路的其他索引探索

在上述的讨论中，PieCloudDB 中目前的索引按分类属于稀疏索引（Sparse Index），除了通常的 Zone Map 类型索引之外，常见的还有如下实现：

● 基于 bitmap 的索引

● bloom filter

● column sketchs

● column imprints

● ......

02. OLTP 场景下的索引

上文中，我们也提到了传统的基于树的索引例如 B+树等。类似这一类的索引也被称为密集索引（dense index）。在 PieCloudDB 中，也不能完全排除其对查询的实际意义，我们将持续对这一领域进行探索。

关于 PieCloudDB

拓数派（OpenPie）旗下的 PieCloudDB 是一款全新的云原生虚拟数仓产品。在 eMPP 分布式专利技术、服务器无感知（Serverless）及 TDE（透明数据加密）等多项核心技术加持下， PieCloudDB 为企业构建高安全，高可靠，高在线「坚如磐石」的云原生虚拟数仓，助力企业实现数据价值最大化，更好地赋能业务发展并走向绿色，成为新一代AI数据计算基础设施的一个典范。

本文分享自微信公众号 - 开源软件联盟PostgreSQL分会（kaiyuanlianmeng）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

有

有色白水 2023-11-30 21:51

对错先不谈，如果他是源码开源，文档收费，这个的确没有瑕疵，他文档没开源啊，不懂直接撸代码或者自己写文档也是可以的，毕竟维护一个项目只有义务，没有收获也的确很难，兴趣也不能成为饿肚子的理由

小xu中年 2023-11-30 21:52

layui很好

taomail 2023-11-30 18:59

商业化无可厚非，谁也不欠谁的。喜欢用就用不喜欢用就不用，大家都有选择的自由。这件事有点像前段时间 clash 系列删库事件，各位为爱发电的开源慈善家为了保护自己，删库隐退，反而遭到各种人肉网爆。这两件事都让人痛心。

百小僧 2023-11-30 20:05

没事，从我开始，以后会越来越多。😊

竹夜梦 2023-11-30 19:37

可以尝试全局gradle

陈钇蒙 2023-11-30 19:53

管你有什么大道理, 你确实违反了你用的开源协议mit协议, 说再多都没有用, 你搞的就不是开源这种东西

Francesca 2023-11-28 19:16

框架开源，文档闭源，真会玩，如果没有文档，是不是这个框架别人不会用啊，资料都查不到，还不如搞个plus版收费框架，文档开源

韦小仇 2023-11-28 14:31

“龙芯浏览器之所以在 2023 年还兼容 IE，是因为我国信息系统主要基于 IE 构建”😂

复二呆 2023-11-28 18:19

之前这么干的是那个啥io来着？记不住名字了…

安一老厨 2023-11-30 19:21

这不是公不公平的问题，其他项目转付费都是某个版本以后的文档。你这好，一杆子打死。你早说要付费别人开发前还可以做其他选择啊。我看有些文档就做得很好，就是某个版本后的收费。你这还好，来个竭泽而渔。

Francesca 2023-11-30 20:23

harmonyOS=joke

wzhsh90 2023-12-01 07:45

后端好助手

陈钇蒙 2023-11-29 09:12

他这个事情不一样, 等于是开源转闭源收费了, 你要收费从一开始就收费无所谓, 有人愿意付费有人就喜欢免费的, 你一开始免费, 我用上了, 然后你一转闭源, 我怎么办? 不付费我连bug都修不了? 绑架用户吗?

橙

橙子的锋哥 2023-11-30 20:51

看过你的项目，很不错；

魔力猫 2023-11-30 10:23

如果老版本照旧，新版本文档封闭，这没太大问题。遗留系统，各种烂事多了去了。升级框架要加钱不算啥。可如果把老文档也封了，就等同绑票！而且作者也别吹已经有多少肉票交了赎金。交钱的有多少心里咒你们没点数？如果不是沉默成本太大，谁愿意给这笔钱？！考虑过这个框架但没用的，那是真庆幸自己没被杀猪。以后不是真正大厂支持的项目，敢随便放到公司里面了。像这次的事情，风险没边了！今天封框架文档，明天就可以封部分API，不给钱不能用。MIT协议在眼里不如一张厕纸。如果程序员把框架推荐引入公司项目，结果出了这么一出，尴尬不？接下来怎么办？跟公司说现在要交赎金，遇到苛刻的老板，为这499就让你拍屁股走人，还不给补偿，罪名都是现成的，给公司造成重大损失，499不是钱的事情，而是项目风险不可控。

安一老厨 2023-11-30 20:37

而且有一些是其他开源作者提供的文档，更应该直接公开，你可以不改，只作为审核者。如果这都还要收费。那与知网有啥区别：我自己发表的论文还不能自己使用？？？而且又没给原作者费用，原作者使用还得缴费？？？？当然希望没这种做法

小xu中年 2023-11-30 21:59

内置分页以及超强的 sql 优化功能？这条就非常优秀了，可以细讲一下吗？

技术粉 2023-11-29 15:39

看了，确实吓人，而且还看到了小人得志后的嘴脸。太吓人了

我的ID是jmjoy 2023-11-27 11:31

原文：“但可能在某些情况下会比现有版本慢约 20%。”，标题：“Fish Shell 采用 Rust 重写会导致性能下降”

乌龟壳 2023-11-30 21:47

看了下 3.0 的 roadmap，确定不绑定一下 vue 或者 react 么，比如虚拟滚动，自定义组件怎么办？当然，你可以把虚拟滚动的生命周期一整套做出来，但是这不就又实现了一个小的 vue 或者小的 react 了么

游

游游酱 2023-11-30 22:24

为了 activeX 不择手段

平波 2023-11-30 23:03

我不是搞.net,说实话,没人会在意你付出多少,最好的办法,就是弄个开源版,再弄个商业版;开源版慢慢就不更新了,然后你懂的,学下QT,变通一下

phper08 2023-11-29 18:02

https://gitee.com/dotnetchina/Furion/blob/v4/LICENSE.zh “特此免费授予任何获得本软件副本和相关文档文件（下称“软件”）的人不受限制地处置该软件的权利”

司徒无涯 2023-11-29 10:42

什么叫明码标价的事情，这跟所谓的纯玩旅游团先把你骗上车，然后再把你拉到购物中心强行购物有啥区别？收费没问题，你一开始就说明就好了，人家项目都用了那么久了，现在你收费了，换不换框架都是麻烦，没有文档公司新人来了根本无法上手，贵司人均源码大神是吧，这也能洗是我没想到的

mylady 2023-11-30 13:14

这次让他做成了，后面还会有更多的开源钓鱼了。

百小僧 2023-11-29 14:37

去看看pr，我一个人写了340万字的文档，其他所有开发者提交pr贡献文档的字数总不超过1000字。99.99%都是修改错别字。

单一结构 2023-11-30 19:33

这个官司很多矛盾点，因为利用bug是对于开发者而言的，对于使用者而言，只存在次要责任。所以第一责任人是腾讯开发，而不是利用漏洞的人。当然，到了刑事的话，是可以追责，那又是另外一个回事

陈钇蒙 2023-11-29 10:50

文档一开始也是免费的, 现在突然转收费了, 我说的修bug是指修我自己的代码的bug, 我用到框架的地方去查文档发现突然查不了了, 得付费, 这算什么事?

太空中的小星星 2023-11-30 22:24

我其实好奇怎么个兼容法呢？我去龙芯下载了浏览器，并正常使用了，还未找到哪里有ie的兼容。看起来好像不是wine的样子。有谁知道如何使用这个兼容吗？

fywtat 2023-11-30 19:49

其实吧，搞技术商业化的经验不多，搞个文档收费确实非常尴尬。还不如商业版支持收费。

osc_96846813 2023-11-30 19:33

哥们，如果缺钱你可以发起水滴筹，相信大家都能理解的，何必弄的这样里外不是人呢。😂

小xu中年 2023-11-30 21:53

支持

易仙洞主 2023-11-30 19:50

支持收费！！

O龙猫O 2023-11-29 07:57

有的人思路很奇特，平时请朋友吃个饭也得花他个四五百。享受别人免费产品服务，收他几百块他就受不鸟了。明码标价的事，你觉得合适你就用，你觉得不合适就不用。只能说明你还不是别人的目标客户。因为一直在java阵营，一直无缘使用Furion，并不妨碍一直支持Furion，吐槽的，不爽的，你们可以去看看他的代码，文档，官网，还有作者数年如一日的坚持，对这么一个优质个人项目，也算首屈一指了。文档收费的利弊，相信作者想得清楚明白。做开源很难，我们PDManer开源五年了，这些年累计收入，恰好够阿里云服务器费用。坚持做免费很难，如果不是我们找到了一条目前看上去还可以的商业化路径，社区开源版我们才能有条件坚挺免费不动摇。文档收费这个事，虽然我也不是很理解，但是不妨碍我支持他。有钱捧个钱场，没钱捧个人场，加油吧。

在大规模使用中

phper08 2023-11-29 18:01

Francesca 2023-11-30 20:22

openHarmony=KaihongOS

zb94748325 2023-11-29 12:23

什么辣鸡行为啊，别又当又立。搞社区版和商业版的公司多了去了，没人会骂。先开源再搞部分收费就特么辣鸡，还怨别人带节奏？？？鄙视鄙视鄙视！👎👎👎

最后的夏天 2023-11-28 14:26

卡脖子的不是别人正是老古董银行

hxy-go 2023-11-30 20:06

应该搞个社区办和商业版。

百小僧 2023-11-28 23:41

截至2023年11月28日 23:30:00，Furion 开通 VIP 服务用户 383 个，Furion 注册用户 5144 个，其中付费购买文档的用户 2319 个。感谢大家的支持，Furion 将努力服务好那些认可和喜欢 Furion 的用户。成功需要建立在契约上的朋友，Furion 与您做朋友。

osc_73355549 2023-11-30 16:35

主要是收费之前的文章应该免费公开，收费后更新的文章可以加密，这坑人的玩意，之前还推荐同行用。

zb31761687 2023-11-28 17:42

那些用了Furion做底层的公司要哭了

小xu中年 2023-11-30 21:51

很不错的项目

哈库纳 2023-11-29 15:30

周鸿祎说的没错 360 的确是可以被卸载，但是周鸿祎没说 3721 会把它重新安装回来。

zb31761687 2023-11-29 14:02

偷换概念，把你自己违反MIT协议跟小程序混为一谈真的好意思吗？还有脸威胁人家私有化部署追究法律责任？你是知法犯法懂吗？看到你威胁别人的帖子，吓我一跳，大家都看看他怎么吓唬人的： https://github.com/Rwing/debian-benchmarks-game-visualization/issues/1

-SORA- 2023-12-01 00:03

不是所有时候都能自动推导。比如定义函数的时候，它的参数的数据类型需要显式指定

浪

浪尖的旋律 2023-12-01 06:51

“不再强制要求员工每周前往办公室工作三天”

小

小元元 2023-11-30 19:27

人家说的是反话，理解能力有待加强

TeaWeb 2023-11-29 10:04

所以，HTTPClient、日志记录、JSON序列化这些也是高级功能吗？（没有反对你的意思，只是防止你的发言误导一些新手）

sth4me 2023-12-01 00:46

thinkphp多年以前就文档收费了，当然，入门文档还是免费的。

百小僧 2023-11-30 20:30

👉👉👉 说句实话，有时候我还是想不通你们这些人的。我们认识吗？我们有那么大的仇恨吗？我是伤害了你的利益吗？你了解的事情经过吗？你听到的看到的都是真的吗？你怀疑过这一切吗？你有限的知识够评价别人无限的人生吗？互联网那些被网暴的人真的就是道德败坏的人吗？你看懂社会运行规则了吗？人性的弱点你读懂了吗？你躬身入局了吗？自然辩证法学过吗？王阳明的心学心外无物课外阅读过吗？捕风捉影、愤然怒喷，把自己放在上帝的视角藐视着这一切，彷佛是一切的主宰，道德的化身，法律的审判者，人间的正义使者。

我写代码像蔡徐坤 2023-11-28 13:10

别啊，让ie死彻底吧

zb31761687 2023-11-29 11:30

就是诈骗，先以开源免费的名义让很多公司用上，然后封锁文档，让产品没有说明书，不得不被收割。先告诉你免费上船，到得江心，且问你要吃板刀面还是馄饨面。有人说：没人逼着你用啊，你可以不用嘛。说得对，可是那些已经上船的公司和开发者怎么办？力荐公司使用该项目作为底层的同行怎么办？他的所作所为完全违反了MIT协议，并且很恶心的还威胁那些已经上车需要文档的人。事实上该文档属于以MIT开源的项目的一部分，他可以拆分出来且不再维护，但是过去的内容无权禁止，其本质是违反MIT协议。欺骗众多因为MIT协议而选择Furion的公司和个人。问题在于，我们懂，可是公司的老板、非技术的领导懂吗？人家看到的是风险！百小僧用自己没资格不合法的事威胁人，很搞笑，但又切实的破坏dotnet国内的形象，破坏选择dotnet技术栈的公司的信心，砸大家的饭碗。

phper08 2023-11-29 10:20

假开源，借开源名义养肥用户然后再宰，看他前期宣传就知道了，一股浓浓的洗脑的话术，狐狸尾巴终于露出来了

小保哥 2023-11-28 16:14

没啥奇怪的，商用系统很多只要能满足要求的，都还运行得好好的，上古神器都还大把大把的。毕竟那可是当年花大价钱开发的，足够满足需求。只要能满足需求，为什么要换，技术该为系统服务，而不是系统为了技术的升级换代而去更新自己。等到这个系统不满足需求了，自然就会组织人员来更新了。

技术粉 2023-11-30 16:34

https://oscimg.oschina.net/oscnet/up-b182b52fe56f56bb8308410992824b53134.webp

思北谢Special 2023-11-29 09:48

作者的作品确实属于高质量一流作品，不过吃相不雅，早起通过开源免费，圈起了一批忠实用户，然后文档开始闭源收费，等于把用户哄上贼船，其实收费也是可以的，你一开始就收费，或者新出个Plus版本收费，都没问题，现在这种就属于砸了自己的招牌，还有人觉得代码开源免费，文档收费没问题，没有文档的代码，一文不值，因为有时间去读懂全部代码，已经可以重新撸一个出来了

推荐 | 云上 Index：看“简墨”如何为云原生打造全新索引

热门评论

关于作者

作者的专辑

作者的其它热门文章

热门资讯

热门软件

OSCHINA 社区

在线工具

攻略

QQ群

公众号

视频号