35 KiB
NOTICE
一般在实践应用中不是单机，而是CS模式，因为API也是基于CS模式的。 那么在CS模式中，可以禁用server端对query结果的输出，提升效率 方式是控制Util/Util.h中OUTPUT_QUERY_RESULT宏的开启
在使用gserver时，不能在数据库没有unload时再用gbuild或其他命令修改数据库，仅限于C/S模式 将IRC聊天放到gstore文档上，freenode #gStore
推广
必须建立一个官方网站，可以展示下团队、demo，需要建立社区/论坛并维护 另外要有桌面应用或者网页应用，以可视化的方式操作数据库，类似virtuoso和neo4j那种 server 118.89.115.42 gstore-pku.com
自己的网站可以用实验室的服务器，gstore网站最好用云服务，图个稳定 但用实验室主机，备案时是否更麻烦？得以企业为单位，而且解析是否更麻烦？ gstore网站中的demo应用的主体可以放在实验室主机上，至少是gstore数据库应抽离出来，但若实验室主机不开外网，应如何而配置代理？ demo应用全部外链，具体服务放在实验室公开的主机上，通过ip:port连接
方正 微生物所 社交网络（正在让北师那个学生在做） DBpeida数据集上SPARQL查询接口
并行策略- 线程控制模块
不宜使用并行框架，可使用C的pthread，boost的thread库，或者启用C++11，gcc编译器需要高于4.8.1才能完整支持C++11 但boost的安装更麻烦，而且没有C++11安全，所以综合考虑，还是选择C++11 而且现在C++14标准都已经出来，11标准也已经得到比较广的应用了，而像openmp这种高级并行框架也是不合适的，因为不方便统筹规划每一线程 但如果只在 Linux 下编程，不用考虑平台兼容性，那么 C++11 的 thread 的附加值几乎为零（我认为它过度设计了，同时损失了一些功能），你自己把 Pthreads 封装成一个简单好用的线程库只需要两三百行代码，用十几个 pthreads 函数实现 4 个 class：thread、mutex、lock_guard、condvar，而且 RAII 的好处也享受到了。 Linux上最好还是使用POSIX标准的pthread库，由glibc提供 编译时采用-pthread选项
fork时子进程获得父进程数据空间、堆和栈的复制 所以无论是server还是内部的并行，都应采用多线程，避免内存消耗 但开多少个用户线程，这是个很大的问题，在各个阶段用户线程的分配（一个线程不断复制）
目前B+树本身还无法并行，哪怕只有查询，也可能因为内外存交换导致并行出错。 可以让陈语嫣先做预加载，并进行两表分块并行的处理，之后再使B+树支持多线程 目前vstree没有内外存交换，只读时完全可以支持多线程 但实际应用中必然存在着读写可能和写写可能，后期必须要引入事务 对于读写问题，应该使用读写锁，采用强读者的模式，即优先将锁分配给读者 另一种方式是不用锁，为索引建立溢出页，这是一种比较好的处理并行的方式 注意：读写锁本身就比较适合读多写少的情况，另外内外存交换锁不能严重降低并发度
多用try_lock避免死锁，对于gStore系统，使用溢出页是一种思路，但多版本两阶段锁协议更全面 一个sparql语句（包括查询和更新）就是一个事务，要支持事务的并发，保证安全和可恢复
多个用户级线程对应一个内核级线程，对应同一内核线程的一个用户级线程发生了未被处理的异常，全组线程都要崩溃。 线程总数最佳应设为(线程等待时间+线程运行时间)/线程运行时间*cpu数量 (这里应该是逻辑cpu数量，一般一个物理cpu会被处理为两个逻辑cpu) 综合进程与线程的优势： http://blog.csdn.net/qq_16209077/article/details/52769609
线程池的实现： http://www.cnblogs.com/cpper-kaixuan/p/3640485.html http://blog.csdn.net/turkeyzhou/article/details/8755976 http://www.cnblogs.com/osyun/archive/2012/08/31/2664938.html http://blog.csdn.net/revv/article/details/3248424 http://blog.csdn.net/jcjc918/article/details/50395528 用户线程总数设为逻辑cpu的两倍即可，总线程数保持不变，但各个层次的线程分配是动态调整的。 如果query少，那么一个query内部就可以用更多的线程，反之反之 gstore的IO占用率已经极高，并行读取优化不大；同时IO等待也不太长(否则在SSD上应该表现较好)，所以流水线也不能开太多 但如何使得线程在处理完一个任务后不立即退出，而是可复用？(每个线程跑while循环) 当系统闲置时，应销毁多余的线程，回收系统资源。 如果是多用户，线程数可以开得很大，因为某用户的线程等待时间可能很长 设定线程数上限，指定线程种类，超出上限的任务应该等待 http://blog.csdn.net/infoworld/article/details/8670951
??server针对多用户的高并发线程应该和后面具体的查询响应线程分开，前者可建立百千(等待时间可能非常长)，然后detached? 每个user的请求被挂载到线程池的job队列中？处理完成后再将结果返还给对应用户？
暂时可以先支持只读事务的并行，以及一个事务内部的并行处理，这需要处理内外存交换导致的不一致问题 内外存交换除了换入换出外还可能有堆的更新问题，这需要加锁，但加锁会导致阻塞 是否需要一个专门的缓存管理模块 多线程中，各个kvtree最好和vstree保持一致，否则很容易出问题(比如一颗kvtree读了修改之前的value，随后在vstree上却又读了修改之后的value)
TODO
保证通过测试：shape和warp数据集，插删查操作都要测，bbug一系列特殊的查询也要跑 要在单机支持到10亿triple，最坏情况下最多有20亿entity和20亿literal，目前的编号方式是不行的(int扩展为unsigned) 最好在单机100G内存上支持起freebase(2.5B triples)这个规模的数据集，就像jena和virtuoso一样，慢不要紧
同时将ID的编码改为unsigned，无效标志-1改为最大值的宏, triple数目的类型也要改为unsigned 注意pre的ID还可以为-2，或者对于pre仍然用int，或者改函数的返回值为long long (还有一些没有用-1而是>=0)
将B+tree中叶节点的大的value分离出来，新建一套缓存，使用block机制，标记length为0表示未读取 类型bstr的length问题也需要解决 如果把类型直接改成long long，空间开销一下子就上升了一倍 解决方法：对于ID2string，仍然用char和unsigned，但对于s2xx p2xx o2xx，应该用unsigned long long和unsigned来表示，这样最高可支持到40亿triple
那么是否可以调整entity与literal的分界线，如果entity数目一般都比literal数目多的话 直接把literal从大到小编号，可在ID模块中指定顺序，这样每个Datbase模块应该有自己独特的分界线，其他模块用时也需要注意 编号完成之后可以取剩下的编号的中间值作为边界，这样entity跟literal都有一定的增长空间
加锁后就不必因为交换而调堆，写的时候要锁住整棵树，因为得从root节点锁住（整颗树用一把读写锁） 可以考虑不使用锁，而是在node中用一位来标志是否被锁住，锁住则不能交换出去或写入，但可以继续查看内容 在操作缓存数组的时候，也要考虑多线程冲突问题
B+树中的heap策略是否真的高效?? 交换时与其update heap权值，不如直接加锁，或者如果是堆顶元素不应换出，可以先移除后插入。update heap中查找太耗时 kvstore的heap可以通过沉底的方法保证多线程一致么？
kvstore变慢：s2o这种索引的性能不关键，关键在于压缩后sp2o和op2s的性能查了不少！是否应二分查找pre，好像s2po中不同的pre并不多，避免线性查找 但根据排查，sp2o不是慢在得到po list后找p的过程，而是慢在读叶节点的过程，按理说这是应该比找sp要快的 也可以考虑为B+树节点设计两套block，因为大block跳数少，小block更能有效利用空间。 在同一个文件中很难处理两套block，但可以用两套文件，分别对应一套block，设计高位来支持逻辑地址，判断属于哪个文件
缓存是先申请先得到足够的，设置安全上限，如总共100G，已用不能超过90G，因为还有很多零散的内存是没有统计的
缓存管理模块，负责主要模块的缓存申请和释放，包括各个数据库等，调度各棵树的内存，不负责树内部的管理 线程管理模块和缓存管理模块都应该掌控全局 全局只写内存(除非内存放不下而发生内外存交换)，空闲时或者定期刷到磁盘，但如果为了可恢复性就要记log，这是很耗时的。 BufferManager和ThreadManager在最底层，新建GstoreApplication统领全局，无论是main里面的应用还是server应用，都调用GA里的函数进行处理 NOTICE: BufferManager只支持大体的管理，最好是预申请一大片缓存或者总体申请报销，零零碎碎的new/malloc不用管，避免反复调用开销太大 GA里面可以管理多个数据库，第一件事就是启动GA，读取init.conf进行配置，包含当前数据库列表的set，新建时已存在则提示，加载时不存在则报错 注意保持API不变 每个数据库在一个时刻只能被一个GA使用，因为若是两个GA同时使用，内存独立，会有各种预料不到的问题。一般使用都是CS模式，所以一个GstoreApplication就足够了。 通过加锁，数据库被GA使用时则加锁，设置标记，不等待，避免server导入数据库后又用gbuild重建数据库
树索引的内外存可以和读写共用读写锁，即要换出外存或写入时都要获得读写锁中的写锁 (因为更新操作不多，所以锁等待时间不必过于在意，但树节点过多导致的锁开销可能很大) (树从上到下获得锁，走严格的树协议，原来的storage堆替换策略也可以继续用，不过要加上锁的保护) 一般来说，保证弱一致性就可以了。
开发专门对kvstore的性能测试工具，包括增删查等，默认是用dbpedia170M数据集，需要修改makefile和test/kvstore_test.cpp
join缓存 vstree交换(先把capacity设小)
成组插删还没完全支持和测试，需要修改KVstore.cpp
hulin添加join缓存，这样的话两表拼接就不适合多线程并行，本身中间表那种添加方式就很难并行化（要改表要加锁，不好） 后面实现全新的join，两表采用索引拼接的方式，就可用多线程并行，但递归调整得在此轮的所有两表拼接完成后（后面再考虑调整时如何并行） 索引拼接的坏处：当重复ID很少时空间开销可能比中间表还大；拼接完需要递归更新直到全局收敛，次数是中间表的行数乘上列数；编程复杂度高。 实际上大部分图都是稀疏图，基本不会出现重复ID，所以还是用中间表的方式比较好(中间表上的处理也已经非常完善) join_two里面可以分块并行，但不能用太多线程，在末尾添加新记录时要加锁
gstore后续需要开发的地方： 事务操作：最小粒度是一个sparql/BGP一个事务，要支持workload(多个查询)为一个事务 最终一致性加锁就行了，顺序一致性则要考虑各种先后关系回滚等等，多版本两阶段锁协议 多领域多库解决方案。
任务分配：
数据库连接池 保持连接而不是每次都用socket(http?，用boost库) 分页查询(先将整个查询结果缓存，需要考虑内外存交换) 陈佳棋的任务：s和p对应同一个实体，应该先重命名，再过滤。还有一种情况是两者只是名字相同，实则并无关系 高阶谓词逻辑
陈佳棋找人负责： 模仿海量图大作业，基于gStore开发一个社交应用，要求可以批量导入且实时查询 查询级别的缓存（测试时可将查询复制后再随机打乱） 多查询优化
王力博： 安全备份 数据库的多版本备份，动态删除 gserver for multiple users, not load db for each connection, but get the same db pointer assign the pointer to the user who require this db, and ensure that each db is just kept once in memory 有什么办法去检测一个db是否存在呢？(首先要支持导入多个数据库) 如果不存在 就新建一个 再进行查询 如果存在 就直接进行查询 gserver-gclient if gclient quit(without unload), then restart, there maybe exist too many gserver process(so 3305 is occupied) or the reason maybe gserver still dealing with the previous job, then a new connection and a new job comes 如何避免整个server崩溃或卡死，无论单个查询/建立等操作遇到任何问题
胡琳： 彭鹏师兄的数据集bug 优化谓词查询，谓词少而entity/literal多，所以先过滤得到谓词的解是一种可以考虑的策略 以谓词为节点，以s/o为信息，来过滤得到谓词的结果 需要一个查询计划进行选择，可能有些?p应该先做，有些?s/?o应该先做
陈语嫣： 网站设计以及和外包方的联系 之后用pthread将join_two函数内部的拼接并行化，先实现一个最基本的版本即可
张雨的任务：单起点单终点的正则表达式路径问题，如果是多起点多终点？
WARN：B+树删除时，向旁边兄弟借或者合并，要注意兄弟的定义，应该是同一父节点才对！ 考虑使用 sigmod2016 那篇图同构的论文方法，实现一套join 但那个是基于路径的，BFS和索引连接的思想值得借用，可作为另外一套join方法 @hulin 叶子节点是否也可以先过滤先join，或者说非核心节点，sparql查询图中算度数时是否不要考虑常量？ 新的方法：基于谓词的频率动态调整顺序，但中间结果的保留是另一个问题，是用中间表还是索引连接，是否需要multiJoin？ 另外超级点和超级边的概念也需要被提出
李荆的任务： 考虑出入度数，编码为1的个数？应该不用，在编码的邻居信息中能够得到体现。 第二步编码应该更长，点和边对应着放在一起。按出入边分区，一步点，二步边分区和二步点。 对一个节点保留其最长链信息没啥用，因为数据图基本是连通的，最长链就是图的最长链。 多步编码不应分开，而应在编码逐一扩展，第二步可以依旧保留详细信息，最好用更长编码，因为信息更多。 可能有相同的谓词对应多个邻居，同样的谓词只要保留一个即可，不同邻居可以重合。 第三步可以只记谓词，第四步可以只记边的出入向。 vstree并行过滤
实现其他的join思路，比如基于过滤效果
如何在preFilter和join的开销之间做平衡 preFilter中的限制条件是否过于严格
寻找查询图的特征，分类做查询计划： 先对于每个查询，确定各部分的开销比例
fix the full_test:how to sum the db size right? for virtuoso, better to reset each time and the given configure file(need to reserver the temp logs)
load过程先导入满足内存的内容，或者先来几轮搜索但不输出结果，避免开头的查询要读磁盘。vstree直接全导入内存？ 先完成合并测试，再测lubm500M和bsbm500M -- 90 server
jemalloc??
各版本对比的表格中应加一列几何平均数，现实中大多数查询是简单查询，最好还有一个平均数，对应着把数据做归一化后求和 dbpedia q6现在应该统计并对比结果了，包含在测试结果中
在改善kvstore后，build过程明显加快了很多，现在vstree的建立时间成了瓶颈 preFilter中不仅要看谓词，也要看表大小以及度数，有些节点最好过滤！！！
允许同时使用多个数据库，查询时指明数据库，这样的话可以支持from，但各个数据库是相互独立的； 添加scala API; git管理开发；
从下往上建立B+树和vstree树 加快更新操作，如insert和delete等，是否考虑增加修改的源操作 删除时数据全部删光会出大问题，保留空树？或者插入时考虑为空树的情况？
更新量太多可直接重建索引，少量更新可写到overflow page中，在系统闲置时合并 比如维护一个insert和delete记录索引，每次需要查多个，判断关系 同一triple在同一索引中最多出现一次：原来已有/没有，先删后插，先插后删时等价的？ 若原来已有，插入应该被放弃？若原来没有，删除应该被放弃？
常量triple怎么办，有些点比较重要必须精确过滤，不仅仅看谓词还要看度数等等
评估函数用机器学习的方式？学习参数？学习模型？ 但机器学习对新问题没有一个基本的界，不像数学化的评估函数，对任何情况都能保证一个上界 (目前数据库里面很少有人利用机器学习来估价)
URI是唯一的，RDF图中不存在相同标签的节点，无法合并相似节点，也没法利用自同构的预处理加快查询 DBpedia最新的数据集，原来的相对太小了 count函数的优化：深搜计数即可，不必生成中间表 B+树每个节点内部添加索引，对keys分段？
是否可以考虑把literal也作为vstree中的节点，加快过滤？ join过程中生成literal可能开销大，且可以考虑用周围边对literal进行过滤。。。 但sp2o生成的literal链应该不会很长？
join buffer:use array instead of map, an ID can be in several columns, id2string maybe error(different pre, different list)! use Bstr[2^16], only for entity, also as buffers(after intersecting with candidates) if in id range, then use, otherwise generate(not update?) (when merging with hulin, discuss if exists) Method:scan all linking point from left to right to find a node without literals(if not?), and buffer for this column scan the column and get the maxID and minID, set minID as offset and only need to build a maxID-minID array (the interval smaller, the better, how about using hash-conflict-list here)
set different buffer size for different trees in build/query, for example, sp2o and op2s with 16G, p2so with 16G set string2id and id2string as 1-2G
测试时最好也统计出最长的string，和string的总大小
方正智汇：调用gStore做后台数据库，需要定义范式，比如领域、模型等等 递归删除的效率问题：比如删除一整个模型(没有关系数据库删除整个表快) 可以考虑加一个域的约束，根据这种边来全部删除 domain可用前缀表表达，但x可属于多个domain
批量插入批量修改的规模很大 需要支持修改谓词，不会出现p p o的情况 加谓词比较好加 删类的谓词，那么实例有该谓词的都得删
模型/领域 每个entity一个领域id？ 只给class分配id？只给最上层class分配id？(这样查询太复杂，效率低) 划分多个数据库，同样考虑模式，如果领域和领域之间没有交集 如果领域之间不完全独立，不能直接划分为多个数据库！如果划分需要考虑连接，划分后可直接用于分布式数据库应用
bsbm300M q8.sql - new gstore worser it is because this query is linear, which means the dfs join order not optimized, and the time spent in preFilter maybe not change maybe using non-dfs order for join? we need to compare the time of each part in q8.sql
用vf2来对比？借鉴它的思路？不过vf2做的是标准的子图同构，而非子图包含，需要修改 vf2与gStore相互借鉴，另一种过滤方式？ 客观来说，多边时vstree还是比较好的
对B+树加锁，可以直接更新节点的rank值，使其rank值最大（最高位或次高位），解锁时清除相应位 (不过这样会引入比较大的开销，因为内存堆的修改过程是比较耗时的，需要线性的查找时间) 实际上B+树应侧重于读的性能而非读写的平衡，比如不用块结构，直接把一个节点存成一片。 也可以使得每个节点固定大小，顺序存储，所有value存成记录文件，只增不减。 query过程几乎没有修改，需要free的block几乎没有，可以直接存free块号和当前最大块号， 而无需存所有块的使用情况。也是由于这个原因，树的查询中几乎不对堆做修改，避开了耗时的堆指针查询操作。
修复：需要返回pre结果的谓词查询，首先要知道哪些谓词位于select中，这需要扫描查询
change to BestJoin using index lists and super edges: the memory cost of join will be cut down, so we can cache more for querying! define different cache size for build and query in makefile with -D ?how about BFS instead of DFS?
需要一个整体的并行模块： 并行的线程总数要根据cpu的线程总数来设置，不能超过太多 三种粒度，多个sparql query的并行，一个sparql内部多个basic query的并行，一个basic query内部的join流水线，两表拼接时的分块并行 并行时对kvstore部分的影响（vstree因为基本是全内存，所以没啥影响），换入换出问题，需要加锁（禁止换出） 树协议加锁？ 多query并行时join的内存开销可能超标，需要在vector申请失败时抛出异常，其他地方捕捉异常处理（比如等待内存空闲）
关注jena的更新，以及其是否修复bug 每个模块的时间和提升 gStore性能表格，前后对比
to support 10 billion in a single machine, the memory should > 100G change Bstr length to long long type (also update anywhere related to length or strlen, such as Signature::encodeStr2Entity) change entity/literal ID type to unsigned +++++++++++++++++++++ 新建一个ID管理模块，要求高效稳定，放在Util中 在storage, Database, VStree多个地方用到 better move StringIndex to KVstore In unit test, insert/delete should be tested to improve coverage!!! too many entities for lubm500M, so it is very slow
应统计并降低IO开销（主要是kvstore），尽量顺序连续、预读取 比如加载时除了索引结构外，可以先读入一批节点 另外如果可以把bstr和节点分离，确保每个节点都是相同大小（预先分配定量数组） 所有bstr串单独放到一个文件中，不删除不修改，只能附加 大小超过一个阈值后，进行整理，移除无效的字段 节点中只保留Bstr的文件偏移，用long long类型 可以考虑将id2string直接使用倒排表实现，不用B+树（因为插删是很少的） 但string2id很麻烦，不能直接用倒排表计算
get 不能全部返回去重的，因为插删也需要调用get 除了join模块，其他只和查询相关的模块，最好也改为去重的
watdiv5000 exit unexpectedly -- p2so index 541740149 549240150 entity 26060745 literal 23964574 pre 86
调试成组插删，提升效率 目前存在的问题在于small_aa small_ab q3.sql toStartJoin to add literals p2olist the olist is not right
精简索引，如p2s和p2o可借用p2so来完成，同样得比如s2po和o2ps 而且sp2o普遍比较大，也可以用s2po加二分查找来完成 最终只需要完成6+3棵kv树 (很多问题，实现s2o要排序，代价可能非常高) （可以考虑共用s2索引，同时存下o和po作为value，一个key对应两个Bstr）
implement so2p with s2p and o2p may cause error s p o1 s2 p o
test on real data of applications is needed when case is ?s p1 o ?o p2 o this will be viewed as two basic queries and answered separately is this good? or if considered as one BGP, how can we do 2-hop encoding on it?
join(preFilter根据p的num数量)和stream中的问题(判断失误或内存泄露) 将b树返回num改为直接用已有的实现(应该在底层实现么，如何保证效率) 在Query中建立p2num和sp2num等对应，避免反复搜索。 (o2p o2ps o2s是否应该划分为entity/literal来加速, id2string是否用倒排表)
考虑用内联汇编在大循环里做优化(测试对比效率提升) 最好把entity和literal彻底分开
Join::preFilter -- 某些时候先过滤，某些时候后过滤，视结果数目和边的过滤性能而定 不用似乎也不会出错 when using allFilterByPres, not always good, sometimes too costly!(dbpedia2014, self6.sql) use "well-designed" in GeneralEvaluation to enable not all selected query; 三个瓶颈：getFinalResult copyToResult allPreFilter join_basic的效率非常关键，是核心
另一种过滤：用sp2num预估数量，或者也预估vstree的结果数量，set triple dealed(以后避免重复处理) 可以考虑只在拼接时add literal(需要考虑常量约束，entity与literal分开考虑)，最多提前加一个保证join启动 在idlist中寻找entity和literal的临界点时，注意左小右大，不要单纯扫描 是否最后再考虑卫星边的约束更好？（卫星边一定是单度的） entity和literal没必要放在一起作交，另外交的顺序或许也很重要 （每次应选最小的两个，或者多路merge的形式）
+++++++++++++++++++++ 带标签的路径，而不是过滤加验证的方式 |图仿真避开无用的候选集和join 分析cas的结构和查询模式 ask转换为常量三元组的判断
统计数据库大小时使用du -h还是ls -lR是个问题，但一般也不会相差太多 gStore中的内存空洞问题，一方面是可能某个块没有写满，另一方面是可能预申请的块太多。
TEST
signature.binary in db file are not removed in program, but it should be delete to save space
单元测试： http://www.cnblogs.com/linux-sir/archive/2012/08/25/2654557.html http://www.ibm.com/developerworks/cn/linux/l-cn-cppunittest/ https://my.oschina.net/vaero/blog/214893
watdiv5000在建立p2?索引时出错(p2so索引太大？) jena在测试lubm5000的查询时，似乎答案有问题，如q0.sql
若将signature编码长度由800扩大到1200+1000，build时间大幅上升，查询时间有些不变甚至加长，有些减小一半。 for q6.txt in DBpedia, the latter signature length returns the time of 16366841ms, while teh size is the same as original, 457393467 (but the size of q6.sql in jena is 17852675, which one is right?)
建立日志系统方便调试？ 出错时如何回滚，直接进行版本管理？ (每次插删前，将原来的索引做一个备份？)
测试时每个查询除了时间外，还要记录一下结果数，备用 a whole test on dbpedia must be done before commited!!!(just check query answer size) dbpedia q0.sql gstore比virtuoso慢，因为过滤花了很久，而且候选集很大，之后又要反复判断 bsbm100000 self3.sql pre_filter too costly 3204145 for ?v0 1 for ?v1 total 3204145 maybe we should start from ?v1 or using p2s or p2o(maybe p2so first, then pre_filter, then generate) self5.sql 中也是preFilter时间太长 可以考虑视情况进行preFilter，或者研究下开销为何有时那么大 或许可以不用，或者仍然全用s2p或改判断条件，或者只过滤单度顶点的边约束
virtuoso: dbpedia2014 这个测试很慢，容易出问题，最好单列 100441525 ms to load and the size is 17672699904/1000-39846 KB 50ms for q0.sql 217ms for q1.sql 210ms for q2.sql 23797ms for q3.sql 5536ms for q4.sql 2736ms for q5.sql 9515231ms for q9.sql
virtuoso: bsbm_10000 40137ms to load ,the size is 635437056/1000-39846 KB
using multi-join and stream, compared with jena
gstore performs worser than jena in these cases: bsbm series: self1.sql, sellf3.sql, self8.sql (self4,5,6) dbpedia series: q3.sql, q4.sql, q5.sql (q9.sql) lubm series: q0.sql, q2.sql, q13.sql, q16.sql watdiv series: C1.sql, F3.sql
performance of vstree have great impact on join process, due to the candidate size
the build time is 3 orders...it seems not directly related with the length of signature (so we can extend to better length!)
BSBM: when query contains "^^"(self0.sql), gstore output nothing. and when the results contain "^^"(self3.sql, self8.sql), gstore will omit the thing linked by "^^".
(this causes miss match because the other three dbms support this symbol. Virtuoso, however, can deal with queries containing "^^" but will not output "^^..." in results)
sesame does not support lubm(invalid IRI), and unable to deal with too large datasets like dbpedia2014, watdiv_300M, bsbm_100000...
DEBUG
error when use query "...." > ans.txt in gconsole
lubm5000 q1 q2 delete/insert/query 1003243 none after vstree
dbpedia q6.sql
build db error if triple num > 500M
BETTER
在BasicQuery.cpp中的encodeBasicQuery函数中发现有pre_id==-1时就可以直接中止查询，返回空值！
将KVstore模块中在堆中寻找Node*的操作改为用treap实现(或多存指针避开搜索？)
无法查询谓词，因为VSTREE中只能过滤得到点的候选解，如果有对边的查询是否可以分离另加考虑(hard to join)。(或集成到vstree中, add 01/10 at the beginning to divide s/o and p. however, result is 11 after OR, predicates are not so many, so if jump into s/o branch, too costly. and ho wabout the information encoding?)
DOCS:
how about STL:
http://www.zhihu.com/question/38225973?sort=created http://www.zhihu.com/question/20201972 http://www.oschina.net/question/188977_58777
WARN
重定义问题绝对不能忍受，现已全部解决（否则会影响其他库的使用,vim的quickfix也会一直显示） (因为和QueryTree冲突，最终搁置) 类型不匹配问题也要注意，尽量不要有（SparqlLexer.c的多字节常量问题） 变量定义但未使用，对antlr3生成的解析部分可以不考虑（文件太大，自动生成，影响不大） 以后最好使用antlr最新版（支持C++的）来重新生成，基于面向对象，防止与Linux库中的定义冲突！ （目前是在重定义项前加前缀）
KEEP
大量循环内的语句必须尽可能地优化!!!
-
gStore also use subgraph homomorphism!
-
always use valgrind to test and improve
-
此版本用于开发，最终需要将整个项目转到gStore仓库中用于发布。转移时先删除gStore中除.git和LICENSE外的所有文件，然后复制即可（不要复制LICENSE，因为版本不同；也不用复制NOTES.md，因为仅用于记录开发事项）
-
build git-page for gStore
-
测试时应都在热启动的情况下比较才有意义！！！gStore应该开-O2优化，且注释掉-g以及代码中所有debug宏
-
新算法在冷启动时时间不理想，即便只是0轮join开销也很大，对比时采用热启动
-
如果select中某变量未出现在查询图中，应该对该变量返回空值还是直接认为该查询非法
ADVICE
数值型查询 实数域 [-bound, bound] 类型很难匹配，有必要单独编码么？ 数据集中不应有范围 Query中编码过滤后还需验证
x>a, x<b, >=, <=, a<x<b, x=c vstree中遇到"1237"^^<...integer>时不直接取字符串，而是转换为数值并编码 难点：约束条件转换为析取范式， 同一变量的约束，不同变量间的约束
如何用RDF表示社交网络，以及社交应用的并发问题
construct a paper, revisit gStore: join method, encoding way, query plan
阅读分析PG源代码
单元测试保证正确性和效率，valgrind分析性能瓶颈与内存泄露，重复越多的部分越应该深入优化(甚至是汇编级别)
we can try on watdiv_1000/watdiv_2000/watdiv_1000M/freebase/bio2rdf
limited depth recursive encoding strategy: build using topological ordering, how about updates? (append neighbor vertices encodings) (efficience and correctness?)
目前的vstree按B+树形式实现，其实没有必要将一个节点的标签存两次。可以父节点放child子节点放entry，也可以在父节点存entry数组，根节点的entry单独提出。
(这样需要从上到下考虑)
论文中的vs*tree结构其实更复杂，节点之间有很多边相连，每层做一次子图匹配，过滤效果应该会更好，之后join代价很可能也会更小。目前的vstree仿照B+树实现更简单，每次单独过滤出一个节点的候选集，之后再统一join，但效果差强人意。
在index_join中考虑所有判断情况、一次多边、交集/过滤等等，multi_join不动
在join时两个表时有太多策略和条件，对大的需要频繁使用的数据列可考虑建立BloomFilter进行过滤
not operate on the same db when connect to local server and native!
VStree部分的内存和时间开销都很大，测试gstore时应打印/分析各部分的时间。打印编码实例用于分析和测试，如何划分或运算空间(异或最大或夹角最大，立方体，只取决于方向而非长度)
full_test中捕捉stderr信息（重要信息如时间结果应该确保是标准输出？），结果第一行是变量名（有select *时应该和jena分列比）
Can not operate on the same db when connect to local server and native!
auto关键字和智能指针？
实现内存池来管理内存？
join可以不按照树序，考虑评估每两个表的连接代价
- 用机器学习（对查询分类寻找最优，梯度下降，调参）评估深搜顺序的好坏
- 压缩字符串：整体控制是否启动（比如安装时），同时/不同时用于内存和硬盘。对单个string根据结构判断是否压缩？（一个标志位）关键词映射？string相关操作主要是比较，相关压缩算法必须有效且不能太复杂！
- 实现对谓词的查询（再看论文）
- 将查询里的常量加入变量集，否则可能不连通而无法查询，也可能影响join效率。如A->c, B->c，本来应该是通过c相连的子图才对，但目前的gstore无法识别。
考虑使用并行优化：load过程能否并行？vstree过滤时可多个点并行进行，另外join时可用pipeline策略，每得到一个就传给后续去操作。
写清楚每个人的贡献
SSD
how to set /home/ssd r/w/x for everybody mkfs.ext4 -E stride=128,stripe-width=128 /dev/sdb tune2fs -O ^has_journal /dev/sdb modify /etc/fstab: /dev/sdb /home/ssd ext4 noatime,commit=600,errors=remount-ro 0 1 to check if valid: mount /home/ssd ensure that IO scheduler is noop(just ssd) or deadline(ssd+disk), otherwise: add in rc.local: echo deadline(noop,cfq) >(>>) /sys/block/sdb/queue/scheduler (open trim if ssd and system permitted)
考虑支持GPU (可作为企业版的扩展功能)
RAID
学习Orient DB的方式，可同时支持无模式、全模式和混合模式
ACID? neo4j GraphDB
单个文件的gStore？嵌入式，轻便，类似sqlite，方便移植，做成库的方式给python等调用
联邦数据库，避免数据重导入，上层查询分块
没必要关闭IO缓冲同步，因为用的基本都是C语言的输入输出操作
是否可以考虑用vf2算法来作子图同构？比较效率，相互结合？ 考虑按谓词频度划分，比如建立两棵sp2o树，两者的缓存大小应该不同
Consider the use of Bloom Filter and FM-sketches