这是一个创建于 2869 天前的主题，其中的信息可能已经有所发展或是发生改变。
想做这么一个东西，用户在网页上批量提交 [文题] 或者 [ DOI ] 码，后台将用户提交的 [文题] 或者 [ DOI ] 码通过爬虫提交给相关网站检索，获取完整文献信息，再返回给用户，同时把数据保存到数据库，当数据库增大到一定程度的时候，就可以优先进行数据库检索，如果检索不到再用爬虫去抓取。感觉这个东西，有点像搜索引擎，只不过搜索结果是极规则的，而且是精确匹配的。
这个数据库会随着使用时间越来越大（百亿级别也是有可能的），我总结了一下数据的特点如下：
数据特点
1、数据字段固定，分别为作者、文题、出版年份、卷数、期数、起止页码、DOI 码，7 个字段。
2、被检索字段固定，用户只提交 [文题] 或者 [ DOI 码] ，如果匹配到则返回整条数据。
3、每条数据存入数据库后基本不需要更新，但是会不断有新的数据加入。
4、数据读取要求尽可能快，要尽快给用户呈现检索结果。但是新数据写入允许几个小时甚至几十个小时的延迟，同时写入也不要求完全可靠，允许丢失数据。因为丢失了下次仍然可以用爬虫爬取到。
5、数据条数会随着使用时间累积逐步扩大，百亿级别也是有可能的。
针对以上数据特点，我想请教各位大神的问题如下：
1、如何选择、优化数据库才能保持最佳检索性能呢？
2、对于类似问题，不知业界有无现成的成熟方案？
3、对于这种简单数据，如果达到百亿级别，不知容量大概在什么级别？ 10G ？ 100G ？ 1T ？ 10T ？
谢谢各位的鼎力相助！
附一条包含 7 个字段的文献范例供参考：
Basta G. Receptor for advanced glycation endproducts and atherosclerosis: from basic mechanisms to clinical implications[J]. Atherosclerosis,2008,196(1):9-21.DOI：*************
这个数据库会随着使用时间越来越大（百亿级别也是有可能的），我总结了一下数据的特点如下：
数据特点
1、数据字段固定，分别为作者、文题、出版年份、卷数、期数、起止页码、DOI 码，7 个字段。
2、被检索字段固定，用户只提交 [文题] 或者 [ DOI 码] ，如果匹配到则返回整条数据。
3、每条数据存入数据库后基本不需要更新，但是会不断有新的数据加入。
4、数据读取要求尽可能快，要尽快给用户呈现检索结果。但是新数据写入允许几个小时甚至几十个小时的延迟，同时写入也不要求完全可靠，允许丢失数据。因为丢失了下次仍然可以用爬虫爬取到。
5、数据条数会随着使用时间累积逐步扩大，百亿级别也是有可能的。
针对以上数据特点，我想请教各位大神的问题如下：
1、如何选择、优化数据库才能保持最佳检索性能呢？
2、对于类似问题，不知业界有无现成的成熟方案？
3、对于这种简单数据，如果达到百亿级别，不知容量大概在什么级别？ 10G ？ 100G ？ 1T ？ 10T ？
谢谢各位的鼎力相助！
附一条包含 7 个字段的文献范例供参考：
Basta G. Receptor for advanced glycation endproducts and atherosclerosis: from basic mechanisms to clinical implications[J]. Atherosclerosis,2008,196(1):9-21.DOI：*************
第 1 条附言 · 2018 年 3 月 27 日
谢谢各位大神的指点，看来大家一致推荐用 ES。
 |
1
Immortal 2018 年 3 月 27 日
上集群 es
|
 |
2
feverzsj 2018 年 3 月 27 日
分表
|
 |
3
polymerdg 2018 年 3 月 27 日
学术搜索？
|
 |
4
FiveDDD 2018 年 3 月 27 日
这种用 es 似乎会更方便使用吧
|
|
5
polymerdg 2018 年 3 月 27 日
100 亿 1bit 都是 快 10G 了
|
 |
6
Tyris 2018 年 3 月 27 日 via Android
scihub ？
|
 |
7
looplj 2018 年 3 月 27 日
这个不就是一个简单的爬虫，加数据展示吗。
现在主流的开源搜索方案就是 ES，这个量级肯定是没问题的。 爬虫可以用 kafka 做异步写入 |
 |
8
owenliang 2018 年 3 月 27 日
ES 检索，这种 文献类 - 全量 - 全文检索需要吃大量的内存和 CPU，做好心理准备。
|
Select Language