问题 :https://leetcode-cn.com/problems/spiral-matrix/
解:https://gitee.com/footmanff/leetcode/blob/master/src/main/java/com/footmanff/leetcode/P54.java
直接模拟旋转,处理一些边界条件比较麻烦,wrong 了好几次。
问题:https://leetcode.com/problems/merge-k-sorted-lists/
解:https://gitee.com/footmanff/leetcode/blob/master/src/main/java/com/footmanff/leetcode/P23_2.java
Runtime: 6 ms, faster than 54.03% of Java online submissions for Merge k Sorted Lists.
Memory Usage: 41.4 MB, less than 59.41% of Java online submissions for Merge k Sorted Lists.
解法是对 ListNode array 头部数字排序,然后每次对第一个位置的 array 执行出队,出队以后,利用重新对所有 array 排序(冒泡),并重复执行上述过程。
要再找个更优解法。
1 | public abstract class AbstractBeanFactory extends FactoryBeanRegistrySupport implements ConfigurableBeanFactory { |
最近在优化 ES 的搜索性能,其中有一个优化点是避免对 nested 结果的使用,对 nested 结构内的字段查询时候,相对不非 nested 结构的字段,性能会有损耗。本文不去具体说这个损耗的原理,只说解决办法。感兴趣的可以看看这篇文章:https://www.jianshu.com/p/f0a15e21f61b。
2018 年刚过几天,是时候总结一波了。
最近在用 spock,但是搭环境时候碰到一个依赖问题,这里记录下解决过程:
为了使用最新版的特性,引入的 spock 的核心依赖是这样的:
1 | <dependency> |
本来想搭一下 Spring-Boot 组合 Spock 做单元测试,弄了一个很小的 demo 项目测试,结果等到运行的时候 @Resource 注释不生效,bean name 也没错。反而 @Autowired 是能成功注入的,这个真的是奇了怪了。项目大概是这样的:
1 |
|
分片不宜过大,在故障恢复的时候会更大的影响集群。
The shard is the unit at which Elasticsearch distributes data around the cluster. The speed at which Elasticsearch can move shards around when rebalancing data, e.g. following a failure, will depend on the size and number of shards as well as network and disk performance.
TIP: Avoid having very large shards as this can negatively affect the cluster’s ability to recover from failure. There is no fixed limit on how large shards can be, but a shard size of 50GB is often quoted as a limit that has been seen to work for a variety of use-cases.
ES 只新增数据,不更新数据。更新也只是把旧的数据标记删除,再新增新的数据。被删除的数据在段合并前,是会一直占用资源的。有一种思路是按时间区间将数据分成不同的索引存储,比如 2017 年一份索引、2018 年一份索引。这样索引会更小,每次进入下一个年份都有机会调整分片数量和索引结果,冷数据也可以按年进入归档状态,不会影响在热数据上的业务服务。