[不懂就问] 这样子的数据采集方案需要设计

[Saurichthys]

数量在消息队列 mq 上，大概一天产生有 1000 万左右，需要读取入库，插入时差不能大于 20 分钟 1.数据库可以用 mysql 或者 postgresql 吗，单库能不能支撑 2.如果开发语言使用的是 java 或者 php，请问需要什么样子的部署结构 3.另外数据只存留三天，能否使用类似 mysql 的 event 事件机制，2 秒执行一次删除动作这样子，会不会影响数据性能

[opengps]

数据库结构性能，硬盘性能，这俩跟得上，就没问题，至于删除，建议使用查询时间过滤，闲时再执行物理删除

[Saurichthys]

@opengps 单线程采集估计会很慢吧

[saulshao]

每天 1000 万，这是指行吗？ 1000 万行数据，大概会有多少个 iDoc，每个 iDoc 包含多少行数据？
理论上一天插入 1000 万行数据，对于任何数据库都不是什么很大的负载。一天有 3600X24 = 86400 秒，平均算下来每秒才写入 116 行.......
从 MQ 采集数据，一般也就是单线程，除非你有很多个可以并发访问的 MQ 服务器。又或者你的数据被放在多个 Queue 队列里。
至于保留数据，3 天清除一次一般建议选择负载比较小的时间段，集中删除，不要搞 2 秒删除一次这种动作，这会带来比较大的负担。

[Saurichthys]

@saulshao 谢谢大佬，这个 mq 是这样子的，只提供一个接口让我们订阅数据，但是这个数量比较大，这个用单线程，订阅在进行同步数据库处理这样子的方式可行吗，或者有其他的流程方式！

[saulshao]

这个大体上是可行的，虽然实操可能还会有一些问题，但是应该都可以遵循基本的逻辑来处理。如果不是让你直接访问队列，而是提供一个类似于 Rest API 的方式，那么从 MQ 读取数据的方式你自己并不能决定是多 /单线程。
通常这个 Rest API 还会给你弄个多久调用一次，以防止自己挂掉......
总而言之，数量不是问题，一个标准的数据库，就算只有最基本能运行的硬件配置，一天插入个 1000 万行都没什么问题。
按照最普通的 Web 应用程序架构来做就行。只是你这个东西没有 UI 层就好。