huang7230468 最近的时间轴更新 huang7230468 最近的时间轴更新 | huang7230468V2EX 第 283810 号会员，加入于 2018-01-17 22:38:40 +08:00 |
| 有木有比较不错的 mongo 最佳实践呢？ 问与答 huang7230468 2020 年 4 月 24 日 |
huang7230468 最近回复了
2021 年 2 月 10 日 回复了 zhoudaiyu 创建的主题 git 大家所在的公司有 commit message 规范吗？ |
<feature> ...
<hotifx> ...
<refactor> ...
<test> ...
<doc> ...
<hotifx> ...
<refactor> ...
<test> ...
<doc> ...
2021 年 2 月 10 日 回复了 XiLemon 创建的主题 Java JPA 为何如此难用，是我姿势不对吗 |
个人见解：
1. JPA （ Java Persistence API ）是外国定义的一套数据持久化规范的 API，像我们现在用的 Spring-Data-JPA 底层就是 JPA，但 Spring-Data-Mongo 就没有；而 Mybatis 是国人写过，是一套非常灵活的 ORM 框架；
2. JPA 是支持单表或者多表的，但多表是需要自己写 Native SQL ；而 JPA 其实推崇使用单表的，有点像国内现在推崇尽量减少 join 关键字，从减少数据库的压力（当然这里也是看业务场景，不是一味的盲从）；
3.JPA 是从面向对象的角度设计的，减少 SQL 的硬编码，以减少后期的更换数据库的迁移成本；
4.JpaSpecification 的写法复杂度，其实是可以容忍的，因为稍微花点的时间，你会爱上他；
对于 JPA 需要改变以往的从数据库从发的设计，学会从业务建模的角度开始，可能会有更好的思路。目前我们已经用了几年，只会感觉越来越好用，越来越简单。
1. JPA （ Java Persistence API ）是外国定义的一套数据持久化规范的 API，像我们现在用的 Spring-Data-JPA 底层就是 JPA，但 Spring-Data-Mongo 就没有；而 Mybatis 是国人写过，是一套非常灵活的 ORM 框架；
2. JPA 是支持单表或者多表的，但多表是需要自己写 Native SQL ；而 JPA 其实推崇使用单表的，有点像国内现在推崇尽量减少 join 关键字，从减少数据库的压力（当然这里也是看业务场景，不是一味的盲从）；
3.JPA 是从面向对象的角度设计的，减少 SQL 的硬编码，以减少后期的更换数据库的迁移成本；
4.JpaSpecification 的写法复杂度，其实是可以容忍的，因为稍微花点的时间，你会爱上他；
对于 JPA 需要改变以往的从数据库从发的设计，学会从业务建模的角度开始，可能会有更好的思路。目前我们已经用了几年，只会感觉越来越好用，越来越简单。
2020 年 4 月 29 日 回复了 ngzhio2ex 创建的主题 职场话题 明天准备提离职，今晚对未完的工作已经没有干劲了，随它吧 |
请值好最后一班岗，这是一种态度
2020 年 4 月 25 日 回复了 liubx 创建的主题 MySQL ## 各位，我有一个业务上的问题想请教下大家。 |
我觉得首先应该确认下在业务上，用户先下单然后再退单，那么该用户还是否是新用户了？
2020 年 4 月 24 日 回复了 Mobai497 创建的主题 职场话题 专科报计算机专业当个程序员怎么样?就业?薪资?前途? |
1
2020 年 4 月 24 日 回复了 Jihang 创建的主题 酷工作 [杭州][蚂蚁金服-芝麻信用] 组内急招前端开发(高级、专家) |
有 Java 上海岗位吗
2020 年 4 月 24 日 回复了 tctc4869 创建的主题 Javascript 防止 xss 和 sql 注入而进行非法字符过滤， js 前端有什么几乎一劳永逸的方式？ |
还是从后端考虑吧，
2020 年 4 月 11 日 回复了 fjhhz1997 创建的主题 酷工作 杭州涅普科技有限责任公司招募临时技术方案架构师,报酬三万 |
MVP
2020 年 3 月 1 日 回复了 a627795061 创建的主题 MongoDB mongo 分页优化问题求教 |
目前我们也是在用 mongo：
我们主要有以下措施：
1、条件，我们应该利用条件来尝试将尽可能的 documents 的数量减少；
2、如果是数据非常多，几百万、几千万，那么应该考虑集群分片；
3、重新审视目标 collection 的 Index，是否合理？
4、甚至可以考虑 SSD ；
最后，问下，你们目前大概是多少数据呀？如果说只有几万条，理论上讲应该不会有问题；
我们主要有以下措施：
1、条件，我们应该利用条件来尝试将尽可能的 documents 的数量减少；
2、如果是数据非常多，几百万、几千万，那么应该考虑集群分片；
3、重新审视目标 collection 的 Index，是否合理？
4、甚至可以考虑 SSD ；
最后，问下，你们目前大概是多少数据呀？如果说只有几万条，理论上讲应该不会有问题；
Select Language