diff --git a/NOTES.md b/NOTES.md deleted file mode 100644 index ef30e3c..0000000 --- a/NOTES.md +++ /dev/null @@ -1,510 +0,0 @@ -# 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连接 - ---- - -# 并行策略- 线程控制模块 - -不宜使用并行框架，可使用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选项 - -目前B+树本身还无法并行，哪怕只有查询，也可能因为内外存交换导致并行出错。 -可以让陈语嫣先做预加载，并进行两表分块并行的处理，之后再使B+树支持多线程 -目前vstree没有内外存交换，只读时完全可以支持多线程 -但实际应用中必然存在着读写可能和写写可能，后期必须要引入事务 -对于读写问题，应该使用读写锁，采用强读者的模式，即优先将锁分配给读者 -另一种方式是不用锁，为索引建立溢出页，这是一种比较好的处理并行的方式 - - -# TODO - -删光了，树叶应该在，包括kv和vs等 -清空后，LRUcache::flush 没法打开文件 - -join缓存 -彭鹏数据集的两个bug -成组插删还没完全支持和测试，需要修改KVstore.cpp - -要在单机支持到10亿triple，最坏情况下最多有20亿entity和20亿literal，目前的编号方式是不行的 -可考虑将entity和literal彻底分开，也可以将int扩展为unsigned，但这样不好判断无效ID - -gstore后续需要开发的地方： -事务操作 -多领域多库解决方案。 - -任务分配： ---- -JSON格式传输(陈佳棋) -数据库连接池 保持连接而不是每次都用socket(http?) -分页查询(先将整个查询结果缓存，需要考虑内外存交换) -陈佳棋的任务：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=, <=, a时不直接取字符串，而是转换为数值并编码 -难点：约束条件转换为析取范式， 同一变量的约束，不同变量间的约束 - -#### 如何用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可以不按照树序，考虑评估每两个表的连接代价 -1. 用机器学习（对查询分类寻找最优，梯度下降，调参）评估深搜顺序的好坏 -2. 压缩字符串：整体控制是否启动（比如安装时），同时/不同时用于内存和硬盘。对单个string根据结构判断是否压缩？（一个标志位）关键词映射？string相关操作主要是比较，相关压缩算法必须有效且不能太复杂！ -3. 实现对谓词的查询（再看论文） -4. 将查询里的常量加入变量集，否则可能不连通而无法查询，也可能影响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语言的输入输出操作 - ---- - -## DataSet - -http://www.hprd.org/download/ -