这是一个创建于 1890 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们代码是 python + sqlalchemy，数据库是 postgresql
单个表里头差不多 7、8 千万数据，因为数据有一些逻辑，有些数据是 3 天唯一，有些是 7 天唯一，有些是 30 天唯一，
现在逻辑是每次写入的时候先查下，3 天内有没有，或是 7 天有没有，或是 30 天或是。。。，比较费
是否有好的建议，或是唯一索引里头可以做时间等逻辑么，前面有尝试过加日期字段，做成联合唯一索引，但是只能做到天，比如 3 天，7 天、30 天，或是 90 天的逻辑好像就没办法了
大神没有什么建议，提示下么，谢谢了，或是其他等什么数据库可以实现这样等逻辑么？
单个表里头差不多 7、8 千万数据，因为数据有一些逻辑，有些数据是 3 天唯一，有些是 7 天唯一，有些是 30 天唯一，
现在逻辑是每次写入的时候先查下，3 天内有没有，或是 7 天有没有，或是 30 天或是。。。，比较费
是否有好的建议，或是唯一索引里头可以做时间等逻辑么，前面有尝试过加日期字段，做成联合唯一索引，但是只能做到天，比如 3 天，7 天、30 天，或是 90 天的逻辑好像就没办法了
大神没有什么建议，提示下么，谢谢了，或是其他等什么数据库可以实现这样等逻辑么？
 |
1
psx2019 2019-09-21 16:28:46 +08:00
一次性查出来,然后在内存里面按照业务逻辑判重.
|
 |
3
jugelizi 2019-09-21 16:30:16 +08:00
我怎么觉得 redis 很满足这种需求
|
 |
5
jianzhiyao020 2019-09-21 17:32:53 +08:00
pgsql 估计不行了，redis 辅助一下还可以，存一个过期时间为：1,3,5,7 天的键，去辅助快速检查
|
|
6
jianzhiyao020 2019-09-21 17:37:30 +08:00
你这个数据是近 N 天唯一，
假设解决办法 A 是获取一个近 N 天唯一的 hash， 先假设 A 可行， 那么每次获取的时候都能获取到近 N 天的唯一值， 随着时间推移， 那么这个 hash 将一直保持不变， 那么也就是说：近 N 天“唯一”这个需求就不成立了， 自己推翻了自己。 证毕。 |
 |
7
amxku OP @jianzhiyao020 呵呵呵呵。。。。
|
Select Language