@will800 这应该是个动态图吧，你鼠标卡住的时候，这个图会卡住不动吗？

你开着性能监视器，或者任务管理器切到磁盘。看看有没有突然增高，或者那个动态曲线在卡顿的时候动画会不会也卡住。

一般会突然卡顿一下，多数是你某个程序在做大量 IO 。但你如果卡顿的时候曲线还在跑，说明就是你的鼠标干扰了。

公司不允许对外开放端口，就是不想让你这么搞。

你这种真的出了问题，或者被查出来，开掉你都不用 N+1 。

云服务的好处就是你可以跨可用区啊。

你不花钱跨区做高可用，那和你租个机房托管有啥区别。。。

再怎么信任也免不了天灾人祸的。

你的 CICD 直连外网拉包么。。。
正常情况下 CICD 应该只用内网缓存过的二进制，这样才能保证你产品的安全，出了问题也可追溯。
特别是 NPM 这种一大把前科的东西。

只从缓存取的话，应该不会有问题的。

@Vegetable 我之前也是觉得电动剃不干净一直用手动，但试了一下湿剃也还挺干净的。虽然比不上手动，但远比干刮干净很多。主要是方便，不用来回蹭好几遍。比较适合用手动会动不动就把脸刮破的人。

@K8dcnPEZ6V8b8Z6 剃须膏或者剃须泡，反正就和你用手动是一样的，只是换成电动剃须刀。
实在没有你用水也不是不行，主要就是预先软化一下。

@xtx 其实你可以试试电动剃须刀湿剃也很爽。总体而言个人体感 手动湿>电动湿>>>电动干。

@SeaTac V2 上很多人都这样，只是我也没想到科技贴也能丰富黑名单，希望 V2 能出个查看点赞用户的功能，这样就能顺手全 B 了

@Mithril 主要是看你想做什么。
其实 SQLite 还是很强的，如果你只想弄个带数据库的单机程序，那它就是最好的选择。单独装个数据库就会有各种各样的问题。
而且你用 ORM ，简单项目的话，在几种关系型里切换也不是很难。

PostgreSQL 确实比 MySQL 好一些，但这俩玩意对你来说区别不大。。。

你既然用 C#，那你直接 EF Core + SQLite 就行了。等玩明白了再去搞 PostgreSQL 或者 MySQL

Windows 自带的磁盘管理就能做。你把 C 盘后面的那个分区清空删掉，就能把空间合并进去。

这俩就不是同一类东西。

以 AWS 为例，你以后服务端要做高可用吗？会有负载均衡到多个服务器实例里吗？有这需求那你必然要上 S3 ，不然你怎么把 EBS 同时挂到多个 EC2 里去。
而且 S3 是可以跨可用区的，EBS 不行。

如果你都不考虑这些，就一个单机跑。那么 S3 是按量付费的，EBS 是预付费，你开了 500G 那就是 500G 的钱，空着他也是 500G 。至于价格那就看厂商了，可能有不同的免费额度。

你用啥语言习惯就继续用它。没啥特别需求，或者什么都不会的建议 Java ，突出一个用的人多。集成这些乱七八糟的东西你总能找到对应的库来做。

AWS 方面没啥问题，但你这些东西配置不好的话安全性也一样没法保证，而且也不便宜。DynamoDB 和你自己开 EC2 装数据库的区别就是能省一些运维的工作，但该做的配置，该怎么提升安全性也一样得你自己考虑。不是说你开了服务就可以什么都不管的。

可以的，很容易。

但也有更方便的办法，比如 PNG 这种文件格式是由一堆 chunk 组成的，只有特定的一些数据块是大家公认的图像数据，但你也可以加一些自己定义的块。

你可以在这些块里直接把文件塞进去，它照样是个合法的 png 。

有的软件就是这么干的，比如以前的 Adobe Fireworks ，它虽然保存的是 PNG 文件，但用了自己定义的数据块保存额外的信息，所以你用 Fireworks 打开它自己生成的 PNG 时是可以编辑的，其他软件打开就只是个图。

要么你前端老大撕逼能力强，让后端根据你前端 ViewModel 写一堆聚合接口

要么你推后端去用 GraphQL ，虽说如果真的按照它去设计，很多时候这玩意很难用，但你用它包一下，一次请求调俩接口还是很容易的。

但对于后端来说，不去维护多个功能过于类似的接口是基本素养。

数据倒是不会丢，但是会炸。。。

MongoDB 即使在正确关闭的情况下，也会有很小的概率下次启动读不出来文件直接崩溃给你看。当然你要是真的不重启那也没啥问题，做好备份就是了。

这玩意最主要的问题是，你真的需要“无模式”的数据库吗？特别是你用 ORM 了，真的你会新老版本的代码连接到同一个数据库里去？很多时候你代码做了变更，还是要放 migration 上去修改已有数据，那还不如直接用关系型。

甚至你要的那一点附加的无模式功能，大部分现代的关系型数据库也都支持了。

主要还是看你的需求到底是什么，是要精确结果，还是一个近似估计。而且也要看数据分布是怎样的，平均查询覆盖的数据量有多少。

比如说你这几千万数据是好几年的，每天其实都没多少，那就先拆表，再限制查询范围不能跨边界，结果就能好不少。

OLAP 在这种大规模去重统计上，是用 HyperLogLog 去算近似值的。如果你一定要精确结果，那它也会非常慢的（还是要比你 mysql 快）。

所以如果你数据量比较集中，只要个有一定精度的近似值，而且以后还有这类统计分析的需求，那就上个 OLAP 数据库。但这不只是增加了系统复杂度，而且数据同步，OLAP 数据库的备份还原等等你都要考虑到。

如果一定要精确值，而且以后也没这类需求。想办法在现有数据库上改进也可以的。