这种简单结构的超大量数据如何选择、优化数据库?

2018-03-27 10:06:41 +08:00
 sphawkcn
想做这么一个东西,用户在网页上批量提交 [文题] 或者 [ 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:*************
1963 次点击
所在节点    数据库
8 条回复
Immortal
2018-03-27 10:11:45 +08:00
上集群 es
feverzsj
2018-03-27 10:24:06 +08:00
分表
polymerdg
2018-03-27 10:33:26 +08:00
学术搜索?
FiveDDD
2018-03-27 10:41:28 +08:00
这种用 es 似乎会更方便使用吧
polymerdg
2018-03-27 10:48:02 +08:00
100 亿 1bit 都是 快 10G 了
Tyris
2018-03-27 11:11:18 +08:00
scihub ?
ZSeptember
2018-03-27 11:11:23 +08:00
这个不就是一个简单的爬虫,加数据展示吗。
现在主流的开源搜索方案就是 ES,这个量级肯定是没问题的。
爬虫可以用 kafka 做异步写入
owenliang
2018-03-27 11:19:33 +08:00
ES 检索,这种 文献类 - 全量 - 全文检索需要吃大量的内存和 CPU,做好心理准备。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/441686

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX