我即将开始一个应该有一个相当大的数据库的新项目.
表的数量不会很大(<15),大多数数据(99%)将包含在一个大表中,这几乎只是插入/读取(没有更新).
该表中的估计数据量将以每天500,000条记录的速度增长,我们应该保留至少1年的时间来进行各种报告.
需要(只读)复制数据库作为备份/故障转移,并且可能用于在高峰时间卸载报告.
我没有那些大型数据库的第一手经验,所以我问的是那些DB在这种情况下最好的选择.我知道Oracle是安全的赌注,但如果有人有类似设置的Postgresql或Mysql的经验,我会更感兴趣.
我正在寻找一种算法来确定实时数据捕获的百分位数.
例如,考虑开发服务器应用程序.
服务器的响应时间可能如下:17 ms 33 ms 52 ms 60 ms 55 ms等.
报告第90百分位响应时间,第80百分位响应时间等是有用的.
朴素算法是将每个响应时间插入列表中.请求统计信息时,对列表进行排序并将值放在适当的位置.
内存使用量与请求数量呈线性关系.
是否有一种算法可以在内存使用量有限的情况下产生"近似"百分位数统计量？例如,假设我想以一种处理数百万个请求的方式来解决这个问题,但只想使用一千字节的内存进行百分位跟踪(丢弃旧请求的跟踪不是一个选项,因为百分位数应该是满足所有要求).
还要求不存在分布的先验知识.例如,我不希望提前指定任何范围的存储桶.
您将如何解决以下存储和检索问题？
每天(365天/年)将添加大约2.000.000行,每行包含以下信息:
entity_id与date_id相结合是唯一的.因此,每个实体和日期最多只能有一行添加到表中.数据库必须能够保存10年的每日数据(7.300.000.000行(3.650*2.000.000)).
上面描述的是写模式.读取模式很简单:所有查询都将在特定的entity_id上进行.即检索描述entity_id = 12345的所有行.
不需要事务支持,但存储解决方案必须是开源的.理想情况下我想使用MySQL,但我愿意接受建议.
现在 - 您将如何解决所描述的问题？
更新:我被要求详细说明读写模式.写入表将每天一批完成,新的2M条目将一次性添加.读取将连续进行,每秒读取一次.