有个梨UGlee
2019-11-29 00:00:00 发布
文件系统在表述hierarchy的时候毫不费力，它也能象数据库那样表述foreign key，就是建一个link。但是文件系统在“抓一把”属性的时候很吃亏，比如一个文件夹里有很多用文件名和文件内容构成的键值对时，没有一个操作完成。
数据库实际上也是有hierarchy的，表是一层，记录是另一层，换句话说它是扁平的；数据库有能力在表内实现hierarchy但是查询效率很差；数据库主力用外键表述关系。
但有趣的地方是数据库的外键类似文件系统的symbolic link，如果被引用的记录删除，引用的记录也要做处理否则会破坏referential integrity，这和C语言的野指针类似。
但是对于有GC的语言，对象回收是根据引用的，例如Java，在文件系统上对应的则是不太常用的hardlink；这种设计下引用是对称的，并无法区分哪个引用算是主引用，就设计而言这应该是更好的，但SQL没采用这样的设计。
Document DB，Restful资源，都允许“抓一把”的方式获得一个子树；DBus的ObjectManager Interface也有这样的能力；这个能力主要收益是可以让一些数据被“zoom in”，就像一个JSON里原本被设计成primitive type的类型，后来演化成了集合类或者对象。它符合设计上的open close原则，操作语义不变但数据的结构发生改变。这一点是SQL的弱项。
但是hierarchy或者说是recursion，它天生是unbounded结构，在“抓一大把”或者想蹲在根节点上观察变化时有很大的麻烦，反倒是扁平化的SQL最适合观察，数据归类之后加filter也更有逻辑。
但Plan9坚持认为一切皆文件就是够了的。
++++++
问题：
假如在一个中等规模，譬如几千个节点的网络里，每个设备可以看到其它设备作为一个数据服务节点，你觉得那个抽象是最佳的呢？
1 一切皆文件，任何其它设备看起来都像文件系统可以mount到本地，顶层访问接口就是文件夹和文件，打开文件流再协商结构化的数据协议
2 类似rest，顶层是文件夹的多层结构，然后开始有集合和单例，单例是一个小号的document，操作原语是HTTP那几个，好像重用能力也是不错的；
3 所有节点在其它节点看起来都是一个大号JSON，可以封装成一个类似rx的读写访问，海量数据列表可以使用iterator和filter。
4 全部以SQL实现。这个肯定是灵活性最高的，但老实说最不可能广为流行，它需要的性能对很多弱设备来说不可行。SQL本身假定了强计算能力。
++++
一切皆文件还有一个很重要的好处是，如果一个可执行的项目自包含，例如bash脚本，它在mount到本地后可以直接使用，类似浏览器加载页面，且可以按需载入数据，还可以根据命名参数确定文件存取位置，包括存回远端，存在本地，存到另一个远端去，以及tee。这是unix最成功的地方，在云时代也没过时。
2019-11-29 00:00:00 发布
文件系统在表述hierarchy的时候毫不费力，它也能象数据库那样表述foreign key，就是建一个link。但是文件系统在“抓一把”属性的时候很吃亏，比如一个文件夹里有很多用文件名和文件内容构成的键值对时，没有一个操作完成。
数据库实际上也是有hierarchy的，表是一层，记录是另一层，换句话说它是扁平的；数据库有能力在表内实现hierarchy但是查询效率很差；数据库主力用外键表述关系。
但有趣的地方是数据库的外键类似文件系统的symbolic link，如果被引用的记录删除，引用的记录也要做处理否则会破坏referential integrity，这和C语言的野指针类似。
但是对于有GC的语言，对象回收是根据引用的，例如Java，在文件系统上对应的则是不太常用的hardlink；这种设计下引用是对称的，并无法区分哪个引用算是主引用，就设计而言这应该是更好的，但SQL没采用这样的设计。
Document DB，Restful资源，都允许“抓一把”的方式获得一个子树；DBus的ObjectManager Interface也有这样的能力；这个能力主要收益是可以让一些数据被“zoom in”，就像一个JSON里原本被设计成primitive type的类型，后来演化成了集合类或者对象。它符合设计上的open close原则，操作语义不变但数据的结构发生改变。这一点是SQL的弱项。
但是hierarchy或者说是recursion，它天生是unbounded结构，在“抓一大把”或者想蹲在根节点上观察变化时有很大的麻烦，反倒是扁平化的SQL最适合观察，数据归类之后加filter也更有逻辑。
但Plan9坚持认为一切皆文件就是够了的。
++++++
问题：
假如在一个中等规模，譬如几千个节点的网络里，每个设备可以看到其它设备作为一个数据服务节点，你觉得那个抽象是最佳的呢？
1 一切皆文件，任何其它设备看起来都像文件系统可以mount到本地，顶层访问接口就是文件夹和文件，打开文件流再协商结构化的数据协议
2 类似rest，顶层是文件夹的多层结构，然后开始有集合和单例，单例是一个小号的document，操作原语是HTTP那几个，好像重用能力也是不错的；
3 所有节点在其它节点看起来都是一个大号JSON，可以封装成一个类似rx的读写访问，海量数据列表可以使用iterator和filter。
4 全部以SQL实现。这个肯定是灵活性最高的，但老实说最不可能广为流行，它需要的性能对很多弱设备来说不可行。SQL本身假定了强计算能力。
++++
一切皆文件还有一个很重要的好处是，如果一个可执行的项目自包含，例如bash脚本，它在mount到本地后可以直接使用，类似浏览器加载页面，且可以按需载入数据，还可以根据命名参数确定文件存取位置，包括存回远端，存在本地，存到另一个远端去，以及tee。这是unix最成功的地方，在云时代也没过时。