你需要一个 Linq 。。。

之前就有一例，你可以搜搜文书网。

主要是行为上表现得只读吧。跟 RAM 那种用起来还是不一样的，抹除数据并不是常规操作。
这东西进化了好几代，大部分时候都是只读的。
最开始就是 ROM，出厂烧完了就改不了。
后来 PROM，用户可以改一次。
再后来 EPROM，这东西得用紫外线照，基本上也就相当于只读。
只有最后的 EEPROM 不需要特定的东西去擦写。

觉得什么东西实现起来困难的时候，大概率是需求有问题。
你想想真的有需求要画一万个散点吗？绘图区域足够大吗？一万个点挤到一起能看出来吗？用户真正想看到的是什么？
如果用户想看的是分布状态，可以 xy 坐标划分成格子，然后每个格子用颜色表示点的数量。
实际上就是热力图。

只是备份的话，有专门的冷数据存储服务，比 S3 便宜。
审核需要规避的话，自己加密分卷。不要相信任何一家。

做过，没什么问题。文件存 OSS，属性挂 metadata 。非常轻量的读写问题不大。
适合以文件操作为主要流程的场景。

SQLite
你搞个正常的数据库，性能消耗不说，带来的复杂度成本太高。完全没必要。

电池小才能频繁充电。

最终会变成 Web 框架的测试。哪怕是同一种语言，用不一样的框架写法差距也很大。
而且这活早就有人做了，你可以看一下 TechEmpower 的测试代码库。

普通生物学

@xxfye Identity 可比 Spring Security 好多了。
它属于那种一看就知道做的很烂然后你就根本不会去用的。
不至于先把你骗到坑里然后一锅端。

喝酒可以让你更快入眠，但实际睡眠质量更差。
酒精不代谢完心率下不去，根本进入不了深度睡眠。虽然睡了一晚但第二天觉得跟没睡一样。
你自己买个可以监测心率睡眠的手表手环就知道了。
就算是少量饮酒，也不建议喝完了直接睡觉。

既然一般会基于时间查询，说明你这数据本身就是时序数据，可以考虑时序数据库。
如果要用 ES 的话需要考虑两点，一是你的字符串内容要做分词检索吗？二是你要做聚合统计吗？
如果都不要，只是把 ES 当成速度快一点的数据库的话，那么意义不大。因为你还要考虑 ES 本身的那些问题，得不偿失。
所以现在的首要问题是，你是真的需要用 ES 去加速检索，还是想办法优化你的 MySQL 。

至于其它的，你用 MySQL 和 Mongo 解决不了的问题，不要指望 Pg 和 Cassandra 能解决。时序型数据库的话，还是要考虑上面 ES 那段里提到的问题。你需要做聚合统计吗？还是只做数据检索。

会的，除非你刚好插了一个 block 大小的内容进去。但这个你也得特殊处理，没法直接用系统的文件操作 API 。
比如你可以先把这些数据写成一个小文件，然后 cat 到原始文件前面。
也可以直接 fallocate 或者 dd

还能有啥比 C#+WinForm 拖拖拖更快么。。。
都是 Windows 10 的话自带.NET Framework，build 一下复制过去就完了。

基本只能用 HIPS 去限制，其它的没什么好办法。