月黑风高，我发布个囧物吧：Scorates 动态数据存储工具
2 views
Skip to first unread message
刘鑫
Dec 31, 2009, 1:41:51 PM12/31/09
to Python.cn@google, edb-china, perlchina, proj_idea_t, Idea-Torrent, guangzhou-tech-party
http://bitbucket.org/March/socrates/
基于语义模型的动态数据存储工具
真不该在豆瓣发布一个强大数据库产品的同时做这样一件事，时势吖，时势吖……
在互联网英雄们设计出一个比一个快的架构，将数据吞入存储的时候，我在思考另一个问题，就是如何Lazy和Smart的使用数据。
之前有一期《程序员》，有一篇很有意思的文章《屹立在关系型数据库上的语义网模型》，对我很有启发，但是文中只是给出了一个非常简单的数据库表结构的介绍。所以我有了一个想法，基于三元语义逻辑从头设计了完整的工具，一次性解决动态数据结构以及复杂数据关系的存储和表达。
很感谢SQLAlchemy，为我提供了这样的一个强大的起点。这是我用过最好的关系数据库编程工具。基于它，我开发了Socrates，一个用于存储动态结构数据的工具。
Socrates 的思路是，每一个主谓宾形式，描述一个数据内容，这个三元结构称为Segment，是语义逻辑的原子。主语（subject）表示了数据的分组，可以看作是“分子”。subject 的唯一标识是它的subject id，而它不必要有一个可读的uri——这一点很重要，Socrates的语义模型并不是语义网，我们可以在每一个主语条目上附加一个uri以存储语义网数据，但是也可以灵活的用于其它用途。Socrates的谓词是它的核心机制，逻辑上它表达了Subject的内部结构，实现上，它为多样化的数据类型高效存储于常见的关系型数据库提供了可能，因为它直接描述 Subject 的语义，所以 predicate 必需是可读的，name是它的必要属性。
如上，Socrates的语义模型是自描述的，一个Socrates存储初始化完毕后，会有两个基础表：描述 Subject 间关系的 segment_subject 和 文本数据表 segment_string。里面存储了10条元语，这10条元语表达了Socrates模型的逻辑内核。这样，任一数据，都可以最终展开成可读的形式。
Socrates的一个特色是高度的可移植性，它基于SQLAlchemy，至今为止所有的功能，以前未来设计的所有核心的功能，都可以适用于SQLAlchemy支持的所有数据库平台，这包括了SQLite、PostgreSQL、MySQL、Oracle等等。另一方面，由于SQLALchemy对数据库特化功能的广泛支持，用户可以在具体建立Scorates结构的数据库中大量的使用该数据库平台特有的数据类型。例如默认的 string 存储表，Socrates会在Postgres和SQLite中自动使用无限文本类型。在我实际使用的一个日志系统中，就使用了Postgres的 Interval。
Socrates的原子单位是 Segment ，Subject可以看作是同一 Subject id 的Segments集合，所以给一个Subject添加或删除若干Segments，改变其结构，是没什么问题的。而且一个 Segments 的 object 完全可以是一个 subject 。事实上 Subject 存储表（宾语字段存储 subject id）是Socrates的两个基础表之一。所以Socrates非常适合描述关系复杂的网状模型。由于 subject 和 predicate 在存储表中都是加索引的整数字段，根据 segment 查询 subject 并不是一个很慢的操作。
Socrates 目前还处于探索和研究阶段，除了我自己在一些项目中小规模使用，还没有更多的实践。作为作者，我也不主张你现在将它用在关键性的应用：）。除了功能不完整，例如缺少文档和稳定、完整的DSL规范，它还有一些我已经发现的问题：例如，它还不够快。
未来除了DSL，Socrates还会在三个方向上发展，一个是合理的缓存，目前的实践经验证明Segment级别的重复访问非常多，有效的缓存会大大提升性能。
另一方面是分布，Socrates的基础——SQLAlchemy提供了宝贵的通用性，在目前的存储类上加一个集群抽象层并不是很困难的事，我想的比这个更为有趣：一个是P2P，去中心化，采用类似友邻、互信分发的网状机制，一个是异构，只要应用允许，就完全可以跨多种数据存储服务建立Socrates集群。
第三方面的设想更为激进，那就是涉足到非关系数据库存储，例如建立在KV结构上——使用KV建立表达Socrates这种三段式的模型会复杂一些，但是可以在一些特定应用发挥KV数据库结构简单，性能好的优势——甚至直接写入文件，这很适合在集群上建立一个非实时，但高性能的写入节点，至于直接开发专有的存储结构，这超出我目前的精力和能力所及，但是如果未来项目发展良好，谁知道呢？：）
以上都是比较远期的设想，当然能够实现它们的话，性能问题相信就大大的消解了。
Socrates在数据库层表现为结构非常简单的存储表，每表三个字段，一个subject id、一个predicate id，一个obj，除了存储信息内容的obj字段，其它都是整数索引。除了完整功能的Python版本，我相信开发其它语言的轻量级使用包并不困难，尤其像Java、C#、Perl这一类有丰富数据库访问工具的编程语言。
欢迎所有对数据库技术或Python、SQLAlchemy等相关技术有兴趣的所有朋友参与。您可以参与设计的讨论，提出自己的见解；也可以贡献代码；或者在实践中使用它，向我反馈您宝贵的使用体验。
您看，我从下班吃完饭写这封邮件，等我中途哄孩子洗澡睡觉出来，都2010年了。做一个开源项目，对于我来说，时间和人力真的很紧缺。也因此，更要对豆瓣的同行们将他们的成果分享出来表示敬意。更要表达一下我的羡慕：）。
--
每一行代码都应该出自我手，工具可以帮我写，但不能替我写，更不能替我思考。
……
劉鑫
March.Liu
基于语义模型的动态数据存储工具
真不该在豆瓣发布一个强大数据库产品的同时做这样一件事，时势吖，时势吖……
在互联网英雄们设计出一个比一个快的架构，将数据吞入存储的时候，我在思考另一个问题，就是如何Lazy和Smart的使用数据。
之前有一期《程序员》，有一篇很有意思的文章《屹立在关系型数据库上的语义网模型》，对我很有启发，但是文中只是给出了一个非常简单的数据库表结构的介绍。所以我有了一个想法，基于三元语义逻辑从头设计了完整的工具，一次性解决动态数据结构以及复杂数据关系的存储和表达。
很感谢SQLAlchemy，为我提供了这样的一个强大的起点。这是我用过最好的关系数据库编程工具。基于它，我开发了Socrates，一个用于存储动态结构数据的工具。
Socrates 的思路是，每一个主谓宾形式，描述一个数据内容，这个三元结构称为Segment，是语义逻辑的原子。主语（subject）表示了数据的分组，可以看作是“分子”。subject 的唯一标识是它的subject id，而它不必要有一个可读的uri——这一点很重要，Socrates的语义模型并不是语义网，我们可以在每一个主语条目上附加一个uri以存储语义网数据，但是也可以灵活的用于其它用途。Socrates的谓词是它的核心机制，逻辑上它表达了Subject的内部结构，实现上，它为多样化的数据类型高效存储于常见的关系型数据库提供了可能，因为它直接描述 Subject 的语义，所以 predicate 必需是可读的，name是它的必要属性。
如上，Socrates的语义模型是自描述的，一个Socrates存储初始化完毕后，会有两个基础表：描述 Subject 间关系的 segment_subject 和 文本数据表 segment_string。里面存储了10条元语，这10条元语表达了Socrates模型的逻辑内核。这样，任一数据，都可以最终展开成可读的形式。
Socrates的一个特色是高度的可移植性，它基于SQLAlchemy，至今为止所有的功能，以前未来设计的所有核心的功能，都可以适用于SQLAlchemy支持的所有数据库平台，这包括了SQLite、PostgreSQL、MySQL、Oracle等等。另一方面，由于SQLALchemy对数据库特化功能的广泛支持，用户可以在具体建立Scorates结构的数据库中大量的使用该数据库平台特有的数据类型。例如默认的 string 存储表，Socrates会在Postgres和SQLite中自动使用无限文本类型。在我实际使用的一个日志系统中，就使用了Postgres的 Interval。
Socrates的原子单位是 Segment ，Subject可以看作是同一 Subject id 的Segments集合，所以给一个Subject添加或删除若干Segments，改变其结构，是没什么问题的。而且一个 Segments 的 object 完全可以是一个 subject 。事实上 Subject 存储表（宾语字段存储 subject id）是Socrates的两个基础表之一。所以Socrates非常适合描述关系复杂的网状模型。由于 subject 和 predicate 在存储表中都是加索引的整数字段，根据 segment 查询 subject 并不是一个很慢的操作。
Socrates 目前还处于探索和研究阶段，除了我自己在一些项目中小规模使用，还没有更多的实践。作为作者，我也不主张你现在将它用在关键性的应用：）。除了功能不完整，例如缺少文档和稳定、完整的DSL规范，它还有一些我已经发现的问题：例如，它还不够快。
未来除了DSL，Socrates还会在三个方向上发展，一个是合理的缓存，目前的实践经验证明Segment级别的重复访问非常多，有效的缓存会大大提升性能。
另一方面是分布，Socrates的基础——SQLAlchemy提供了宝贵的通用性，在目前的存储类上加一个集群抽象层并不是很困难的事，我想的比这个更为有趣：一个是P2P，去中心化，采用类似友邻、互信分发的网状机制，一个是异构，只要应用允许，就完全可以跨多种数据存储服务建立Socrates集群。
第三方面的设想更为激进，那就是涉足到非关系数据库存储，例如建立在KV结构上——使用KV建立表达Socrates这种三段式的模型会复杂一些，但是可以在一些特定应用发挥KV数据库结构简单，性能好的优势——甚至直接写入文件，这很适合在集群上建立一个非实时，但高性能的写入节点，至于直接开发专有的存储结构，这超出我目前的精力和能力所及，但是如果未来项目发展良好，谁知道呢？：）
以上都是比较远期的设想，当然能够实现它们的话，性能问题相信就大大的消解了。
Socrates在数据库层表现为结构非常简单的存储表，每表三个字段，一个subject id、一个predicate id，一个obj，除了存储信息内容的obj字段，其它都是整数索引。除了完整功能的Python版本，我相信开发其它语言的轻量级使用包并不困难，尤其像Java、C#、Perl这一类有丰富数据库访问工具的编程语言。
欢迎所有对数据库技术或Python、SQLAlchemy等相关技术有兴趣的所有朋友参与。您可以参与设计的讨论，提出自己的见解；也可以贡献代码；或者在实践中使用它，向我反馈您宝贵的使用体验。
您看，我从下班吃完饭写这封邮件，等我中途哄孩子洗澡睡觉出来，都2010年了。做一个开源项目，对于我来说，时间和人力真的很紧缺。也因此，更要对豆瓣的同行们将他们的成果分享出来表示敬意。更要表达一下我的羡慕：）。
--
每一行代码都应该出自我手，工具可以帮我写，但不能替我写，更不能替我思考。
……
劉鑫
March.Liu
Reply all
Reply to author
Forward
0 new messages