觉得什么东西实现起来困难的时候，大概率是需求有问题。
你想想真的有需求要画一万个散点吗？绘图区域足够大吗？一万个点挤到一起能看出来吗？用户真正想看到的是什么？
如果用户想看的是分布状态，可以 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 去限制，其它的没什么好办法。

@okampfer 后端管这个叫做编译

@darksword21 就是你在后端编译打包项目做的那些活。编译器把一种语言翻译成另一种，分析项目依赖把它们都打包到一起。

其实主要就是因为从一开始设计就只是个简单的脚本语言，根本就没想做完备的工程化解决方案。后面再加起来就很头疼。
不仅仅是前端有这问题，Python 也是一样。

你都减脂了。。中午还吃啥？
早上有空做饭就吃点好的，中午的话水果沙拉，牛奶麦片加蛋白粉都行。
晚上早点吃，好好吃一顿。
热量缺口这不就有了吗。
而且中午不吃高碳水就不怎么会困，午休也省了可以再去健身房练一下。

@marchDu 其他内存消耗大的 Java 程序有问题吗？重装一下 IDEA 或者给它换个 JVM 试试？