MongoDB日期存储与查询、@Query、嵌套字段查询实战总结_mongodb query北京时间

缘由

MongoDB数据库如下：

如上截图，使用MongoDB客户端工具DataGrip，在filter过滤框输入{ 'profiles.alias': '逆天子', 'profiles.channel': '' }，即可实现昵称和渠道多个嵌套字段过滤查询。

现有业务需求：用Java代码来查询指定渠道和创建日期在指定时间区间范围内的数据。

注意到creationDate是一个一级字段（方便理解），profiles字段和creationDate属于同一级，是一个数组，而profiles.channel是一个嵌套字段。

Java应用程序查询指定渠道（通过@Query注解profiles.channel）和指定日期的数据，Dao层（或叫Repository层）接口Interface代码如下：

import org.springframework.data.mongodb.repository.MongoRepository;
import org.springframework.data.mongodb.repository.Query;

@Repository
public interface AccountRepository extends MongoRepository<Account, String> {
	@Query("{ 'profiles.channel': ?0 }")
	List<Account> findByProfileChannelAndCreationDateBetween(String channel, Date start, Date end);
}
1
2
3
4
5
6
7
8

单元测试代码如下：

@Test
public void testFindByProfileChannelAndCreationDateBetween() {
    String time = "2024-01-21";
    String startTime = time + DateUtils.DAY_START;
    String endTime = time + DateUtils.DAY_END;
    Date start = new Date();
    Date end = new Date();
    try {
        start = DateUtils.parseThenUtc(startTime);
        end = DateUtils.parseThenUtc(endTime);
    } catch (ParseException e) {
        log.error("test failed: {}", e.getMessage());
    }
    List<Account> accountList = accountRepository.findByProfileChannelAndCreationDateBetween(ChannelEnum.DATONG_APP.getChannelCode(), start, end);
    log.info("size:{}", accountList.size());
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

输出如下：size:70829。

没有报错，但是并不能说明没有问题。根据自己对于业务的理解，数据量显然不对劲，此渠道的全量数据是这么多才差不多。

也就是说，上面的Interface接口查询方法，只有渠道条件生效，日期没有生效？？

至于为什么没有生效，请继续往下看。想看结论的直接翻到文末。

排查

不生效

MongoRepository是Spring Data MongoDB提供的，继承MongoRepository之后，就可以使用IDEA的智能提示快速编写查询方法。如下图所示：

但是：上面的这种方式只能对一级字段生效。如果想要过滤查询嵌套字段，则派不上用场。

此时，需要使用一个更强大的@Query注解。

但是，@Query和JPA方式不能一起使用。也就是上面的方法findByProfileChannelAndCreationDateBetween查询方法，经过简化后只保留一级字段，然后嵌套字段使用@Query方式：

@Query("{ 'profiles.channel': ?0 }")
List<Account> findByCreationDateBetween(String channel, Date s1, Date s2);
1
2

依旧是不生效的。

版本1

基于上面的结论，有一版新的写法：

@Query("{ 'profiles.channel': ?0, 'creationDate': {$gte: ?1, $lte: ?2} }")
List<Account> findByChannelAndCreationDate(String channel, Date start, Date end);
1
2

此时输出：size:28。这个数据看起来才比较正常（虽然后面的结论证明不是正确的）。

WARN告警

如果不过滤渠道呢？查询某个日期时间段内所有渠道的全量用户数据？

两种写法都可以：

long countByCreationDateBetween(Date start, Date end);

@Query("{ 'creationDate': {$gte: ?0, $lte: ?1} }")
long countByCreationDate(Date start, Date end);
1
2
3
4

等等。怎么第一种写法，IDEA给出一个WARN？？

MongoDB日期

上面IDEA给出的Warning显而易见。因为MongoDB数据库字段定义是Instant类型：

@Data
@Document
public class Account {
    @Id
    protected String key;
    private Instant creationDate = Instant.now();
	private List<Profile> profiles = new ArrayList<>();
    private boolean firstTimeUsage = true;
}
1
2
3
4
5
6
7
8
9

IDEA作为宇宙最强IDE，给出WARN自然是有道理的。

作为一个代码洁癖症患者，看到IDEA的shi黄色告警，无法忍受。假设IDEA告警没有问题（极端少数情况下，IDEA告警也有可能误报，参考记一次Kotlin Visibility Modifiers引发的问题），为了消除告警，有两种方式：

• 修改Account数据库实体类creationDate类型定义，Instant改成Date
• Repository层接口方法不使用Date类型传参，而使用Instant类型传参。

那到底应该怎么修改呢？才能屏蔽掉IDEA的shi黄色告警WARN呢？？

单元测试

数据库持久化实体PO类日期字段类型定义，到底该使用Date还是Instant类型呢？？

在Google搜索关键词MongoDB日期的同时，不妨写点单元测试来执行一下。（注：此时此处行文看起来思路挺清晰，但在遇到陌生的问题是真的是无头苍蝇）

在保持数据库PO实体类日期字段类型定义不变的前提下，有如下两个查询Interface方法：

long countByCreationDateBetween(Date start, Date end);

@Query("{ 'creationDate': {$gte: ?0, $lte: ?1} }")
long countByCreationDate(Instant start, Instant end);
1
2
3
4

单元测试：

@Resource
private MongoTemplate mongoTemplate;
@Resource
private IAccountRepository accountRepository;

@Test
public void testCompareDateAndInstant() {
    String time = "2024-01-21";
    String startTime = time + DateUtils.DAY_START;
    String endTime = time + DateUtils.DAY_END;
    Date start = new Date();
    Date end = new Date();
    try {
        start = DateUtils.parseThenUtc(startTime);
        end = DateUtils.parseThenUtc(endTime);
    } catch (ParseException e) {
        log.error("testCompareDateAndInstant failed: {}", e.getMessage());
    }
    Criteria criteria = Criteria.where("creationDate").gte(start).lte(end);
    long count1 = mongoTemplate.count(new Query(criteria), Account.class);
    // idea warn
    long count2 = accountRepository.countByCreationDateBetween(start, end);
    long count3 = accountRepository.countByCreationDate(DateUtils.getInstantFromDateTimeString(startTime), DateUtils.getInstantFromDateTimeString(endTime));
    long count4 = accountRepository.countByCreationDate(DateUtils.parse(startTime).toInstant(), DateUtils.parse(endTime).toInstant());
    log.info("date:{},count1:{},count2:{},count3:{},count4:{}", time, count1, count2, count3, count4);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

单元测试执行后打印输出：date:2024-01-21,count1:35,count2:35,count3:32,count4:29。

换几个不同的日期，count1和count2都是一致的。也就是说，不管是使用Template，还是Repository方式，使用Date类型日期查询MongoDB数据，结果是一样的。count3和count4使用Instant类型查询MongoDB数据，结果不一致，并且和Date类型不一致。

为啥呢？？

Instant vs Date

MongoDB中的日期使用Date类型表示，在其内部实现中采用一个64位长的整数，该整数代表的是自1970年1月1日零点时刻（UTC）以来所经过的毫秒数。Date类型的数值范围非常大，可以表示上下2.9亿年的时间范围，负值则表示1970年之前的时间。

MongoDB的日期类型使用UTC（Coordinated Universal Time）进行存储，也就是+0时区的时间。我们处于+8时区（北京标准时间），因此真实时间值比ISODate（MongoDB存储时间）多8个小时。也就是说，MongoDB存储的时间比ISODate早8小时。

验证8小时

通过DataGrip查看数据库集合字段类型是ISODate：

其格式是yyyy-MM-ddTHH:mm:ss.SSSZ：

然后再看看时区问题。

同一个用户产生的数据（用户唯一ID都是65af62bee13f080008816500），在MySQL和MongoDB里都有记录。

MySQL数据如下（因为涉及敏感信息，截图截得比较小，熟悉DataGrip的同学，看到Tx: Auto，应该不难猜到就是MySQL）：

而MongoDB记录的数据如下（同样也是出于截图敏感考虑，主流数据库里使用到ObjectId的应该不多吧，MongoDB是一个）：

不难发现。MySQL里记录的数据比MongoDB里记录的数据晚8小时，也是一个符合实际的数据。

PS：此处的所谓符合实际，指的是符合用户习惯，我们App是一款低频App，极少有用户在半夜或凌晨使用，而MongoDB里则记录着大量凌晨的数据，实际上应该是北京时间早上的用户使用记录和数据。

从上面两个截图来看，虽然有打码处理，但依稀可以看到确实（参考下面在线加解密工具网站）是同一个用户（手机号）产生的两个不同数据库（MySQL及MongoDB）数据。

证明：MongoDB里存储的数据确实比MySQL的数据早8小时。

解决方案

PO实体类保持Instant类型不变，Repository层Interface接口方法传参Instant。平常使用的Date如何转换成Instant呢？

直接toInstant()即可，也就是上面的单元测试里面的第四种方式。方法定义：

/**
 * 加不加Query注解都可以。
 * 加注解的话，方法名随意，见名知意即可。
 * 不加注解的话，则需要保证查询字段是MongoDB一级字段，并且满足JPA约定大于配置规范。
 */
@Query("{ 'creationDate': {$gte: ?0, $lte: ?1} }")
long countByCreationDate(Instant start, Instant end);
1
2
3
4
5
6
7

查询方法：

long count = accountRepository.countByCreationDate(DateUtils.parse(startTime).toInstant(), DateUtils.parse(endTime).toInstant());
1

源码分析

Date.toInstant()源码

private transient BaseCalendar.Date cdate;
private transient long fastTime;

public Instant toInstant() {
    return Instant.ofEpochMilli(getTime());
}

/**
 * Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT
 * represented by this Date object.
 */
public long getTime() {
    return getTimeImpl();
}

private final long getTimeImpl() {
    if (cdate != null && !cdate.isNormalized()) {
        normalize();
    }
    return fastTime;
}

private final BaseCalendar.Date normalize() {
    if (cdate == null) {
        BaseCalendar cal = getCalendarSystem(fastTime);
        cdate = (BaseCalendar.Date) cal.getCalendarDate(fastTime,
                                                        TimeZone.getDefaultRef());
        return cdate;
    }

    // Normalize cdate with the TimeZone in cdate first. This is
    // required for the compatible behavior.
    if (!cdate.isNormalized()) {
        cdate = normalize(cdate);
    }

    // If the default TimeZone has changed, then recalculate the
    // fields with the new TimeZone.
    TimeZone tz = TimeZone.getDefaultRef();
    if (tz != cdate.getZone()) {
        cdate.setZone(tz);
        CalendarSystem cal = getCalendarSystem(cdate);
        cal.getCalendarDate(fastTime, cdate);
    }
    return cdate;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

Instant.java源码：

/**
 * Constant for the 1970-01-01T00:00:00Z epoch instant.
 */
public static final Instant EPOCH = new Instant(0, 0);

public static Instant ofEpochMilli(long epochMilli) {
    long secs = Math.floorDiv(epochMilli, 1000);
    int mos = Math.floorMod(epochMilli, 1000);
    return create(secs, mos * 1000_000);
}
private static Instant create(long seconds, int nanoOfSecond) {
    if ((seconds | nanoOfSecond) == 0) {
        return EPOCH;
    }
    if (seconds < MIN_SECOND || seconds > MAX_SECOND) {
        throw new DateTimeException("Instant exceeds minimum or maximum instant");
    }
    return new Instant(seconds, nanoOfSecond);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

附

敏感数据加解密

上面截图，MySQL表里，对手机号没有加密处理，直接明文存储；而在MongoDB数据库里，则进行ECB加密。加密工具类略，

此处，附上一个好用的在线加密工具网站，可用于加密手机号等比较敏感的数据，编码一般选择Base64，位数、模式、填充、秘钥等信息和工具类保持一致（除密钥外，一般都是默认）：

工具类

DateUtils.java工具类源码如下

public static final String DAY_START = " 00:00:00";
public static final String DAY_END = " 23:59:59";
public static final String DATE_FULL_STR = "yyyy-MM-dd HH:mm:ss";

/**
 * 使用预设格式提取字符串日期
 *
 * @param date 日期字符串
 */
public static Date parse(String date) {
    return parse(date, DATE_FULL_STR);
}

/**
 * 不建议使用，1945-09-01 和 1945-09-02 with pattern = yyyy-MM-dd 得到不一样的时间数据，
 * 前者 CDT 后者 CST
 * 指定指定日期字符串
 */
public static Date parse(String date, String pattern) {
    SimpleDateFormat df = new SimpleDateFormat(pattern);
    try {
        return df.parse(date);
    } catch (ParseException e) {
        log.error("parse failed", e);
        return new Date();
    }
}

public static Date parseThenUtc(String date, String dateFormat) throws ParseException {
    SimpleDateFormat format = new SimpleDateFormat(dateFormat);
    Date start = format.parse(date);
    Calendar calendar = Calendar.getInstance();
    calendar.setTime(start);
    calendar.add(Calendar.HOUR, -8);
    return calendar.getTime();
}

/**
 * 减 8 小时
 */
public static Date parseThenUtc(String date) throws ParseException {
    return parseThenUtc(date, DATE_FULL_STR);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

中文解析

SimpleDateFormat，作为Java开发中最常用的API之一。

你真的熟悉吗？
线程安全问题？
是否支持中文日期解析呢？

具体来说，是否支持如yyyy年MM月dd日格式的日期解析？

测试程序：

public static void main(String[] args) {
    log.info(getNowTime("yyyy年MM月dd日"));
}

public static String getNowTime(String type) {
    SimpleDateFormat df = new SimpleDateFormat(type);
    return df.format(new Date());
}
1
2
3
4
5
6
7
8

打印输出如下：

2024年01月23日
1

结论：SimpleDateFormat支持对中文格式的日期进行解析。

看一下SimpleDateFormat的构造函数源码：

public SimpleDateFormat(String pattern) {
    this(pattern, Locale.getDefault(Locale.Category.FORMAT));
}
1
2
3

继续深入查看Locale.java源码：

private static Locale initDefault(Locale.Category category) {
    Properties props = GetPropertyAction.privilegedGetProperties();

    return getInstance(
        props.getProperty(category.languageKey,
                defaultLocale.getLanguage()),
        props.getProperty(category.scriptKey,
                defaultLocale.getScript()),
        props.getProperty(category.countryKey,
                defaultLocale.getCountry()),
        props.getProperty(category.variantKey,
                defaultLocale.getVariant()),
        getDefaultExtensions(props.getProperty(category.extensionsKey, ""))
            .orElse(defaultLocale.getLocaleExtensions()));
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

大概得知：SimpleDateFormat对于本地化语言的支持是通过Locale国际化实现的。

ISODate

另外在使用SimpleDateFormat解析这种时间时需要对T和Z加以转义。

public static final String FULL_UTC_STR = "yyyy-MM-dd'T'HH:mm:ss'Z'";
public static final String FULL_UTC_MIL_STR = "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'";

public static String getBirthFromUtc(String dateStr) {
    SimpleDateFormat df = new SimpleDateFormat(FULL_UTC_STR);
    try {
        Date date = df.parse(dateStr);
        Calendar calender = Calendar.getInstance();
        calender.setTime(date);
        calender.add(Calendar.HOUR, 8);
        return date2Str(calender.getTime(), DATE_SMALL_STR);
    } catch (ParseException e) {
        throw new RuntimeException(e);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

结论

几个结论：

• JPA写法对于单表查询非常简单，借助于IDEA智能提示，可以快速写出查询Interface方法
• JPA很强，但对于关系型数据库的多表Join查询，或MongoDB的嵌套字段查询，则几乎派不上用场
• @Query通过注解的方式可以大大简化API的使用
• @Query写法和JPA写法不能混为一谈
• @Query也不是万能的。必要时，还是得使用QBE，Query By Example，或Query Criteria

参考

• MongoDB进阶与实战：微服务整合、性能优化、架构管理