弱弱的问下大佬，是如何处理国内的社保 / 养老及人事档案的？先谢过。

经常需要随身携带，可能会磕碰，磕碰之后容易坏的买 AC ，其他的不买。
iPhone & Watch: 必买。不过国内 iPhone 只修不换挺闹心的。
Homepod: 不买，因为放在家里，除了进点灰没什么可以坏的。
MBP 16: 因为放在家里当作台式机使用，基本不会带出门，所以不买。
MBP 13: 工作电脑，用了半年多，A 面有个坑，充电口有磨损，大部分情况下不会有问题。但是如果经常需要带着跑的话，保不齐可能会吧屏幕磕了碰了，风险较高，建议购买。

Swift Playground 小朋友的第一门外语（滑稽

现象 /影响：这里讨论一下 OLTP 在线业务（ i.e. 一个对外提供服务接口的 server ），具体现象就是，响应时间持续提高，大量请求积压，最终导致无法服务。
理论：排队论（ Queuing Theory ） M/M/1 模型描述了这种 OLTP 的模型，即请求随机，服务时间随机。在此系统下，一个请求的响应时间为 T=1/mu * 1/(1-rho)，其中 mu 为结束的概率，rho 为服务利用率。如果将这个图画出来，可以看到，当利用率超过某区间时，响应时间便急剧加长。
启发：在在线服务中，应当尽量控制资源的利用率。

首先看下考勤数据量能不能减少吧。考勤数据本身是像 log 一样的东西，可以定期归档一些不用的老数据，这样能有效降低表的大小，提升查询效率。
另一方面，如果直接设定可以任意模糊查询的话，可能出现的查询条件的数量是所有条件的笛卡尔积，因此可以考虑从业务规则上入手，看看用户的具体查询场景是啥。
比如我能想到的可以做的是，创建一个关键词列，把公司名称 用户 姓名都写进去，这样可以有效减少索引数量。
（关键词列，地区，时间）
（地区，时间）
在查询条件不复杂的情况下，不是特别推荐上 es ，除非你司已有非常成熟的中间件做导数据 /数据检查 /数据修复，而且无需你们运维 es 集群。

马克一下，一月过去。