不谈复杂度的重构都是耍流氓。

好奇这种情况下，pg 也没办法提供其他查询和写入了吧？

过长和特殊符号本来就不是正常用户会输入的，完全可以干掉。

对于后端来讲，不限制输入长度的话，可以算作 flaw 了。

后端没义务让所有场景都能返回，但有义务保服务对绝大多数人是可用的。

限制 term 长度？或者过滤掉特殊字符？

MySQL 有类似的，压测的时候用过，不过误差有点大，也没仔细找原因。

mysql> SELECT count(*) AS TOTALNUMBEROFTABLES
   -> FROM INFORMATION_SCHEMA.TABLES
   -> WHERE TABLE_SCHEMA = 'business';

Oracle 有个 Zone Map 的优化，会单独记录 count 之类的。

ssh -R，把服务器端口代理到本地。

确实不太好，我删掉了。

应该是 Java 写的

Ruby 能玩的东西没有其他语言那么多。

微服务，稳定性，可扩展（scable），存储，并发这些社区似乎都不是很关注。

见过别人做架构，做扩展性/做可用性，确实厉害。但 DHH 的态度是，花这力气，还不如多买几台机器。

稳定性这块，GitHub 一个 Web 服务，动不动就挂。。。GitHub 是一个企业服务，大家强依赖，挂是很丢人的。。。

GitHub 比那些有体量了，就换语言花钱雇人重写的还是强了不少的。

技术呢，用不用得着是一方面，但有没有趣，又是另一方面。

打个不恰当的比方，比如拥塞控制这件事，不考虑性能，不考虑稳定性，那随便写写，又简单又好维护，多好。但不考虑这些，又怎么弄清楚这个事儿呢？

如果性能不重要，稳定性不重要，扩展性不重要，算法不重要，就快速露撸功能最重要，好玩的就不多了。

唠叨了这么多，最后还是希望 ruby 可以探索更多的领域和更多的问题。

ruby 在可读性，高效开发上，做了非常多的探索，非常值得尊敬。但还是希望 ruby 可以做更多的事情。

国内某云厂商的运维升级 redis，不做备份。。。他们升级脚本有问题，rollback 脚本还有问题。。。

即使是这样，要是我的话，还是会打一下马

（楼主是不是可以给这个人的信息打一下马赛克？

高产

惺惺相惜？

哪都有能人，哪都有混子。在大场 ppt 是必备技能，但我觉得写 ppt 挺重要的，但全靠 ppt 就不好了。

大厂能人多，水货也多。这个可能是基数问题。

小公司，相对简单些，工作搞好就行。大厂要会表现。

技术上，小半看工作内容，大半看自学。但大厂基数大，更容易遇到能人（可能是技术好，可能是混的好）。大厂相对来讲（有些事情没到一定体量是不需要的，比如微服务），工作场景一般会更有意思些。

一个共同点是，不少人的阅读量不大，多数以自己的理解或经验作为依据。

有 es bulk inser，写个脚本就可以搞。

每秒 2000，一个多小时就能写完一千万的数据。

数据库也还好，都是连续性的读。

要想稳妥点，开始可以慢点。

六六六

这个也是很重要的一点。

嗯，有的数据库是用了 OS 的 buffer，比如 PostgreSQL。

用了 OS 的 buffer 会有一个叫 double buffer 的问题，Architecture of Database System 里面有提到这个问题。

CMU 15-445 里面也是建议是 buffer 由数据库自己维护。

你这么一说，这个地方叫元数据好像也不太合适，我改一下。

恩 ，我写错了，感谢。

那个老师的讲法，我按照我的理解整理了一下。

微服务的话，一个一个升级，风险会小很多。 还可以部署两个版本什么的。

但升级几个服务也是挺麻烦的事。

唠叨一下。

设计数据密集型应用的作者，把开发开发分为这样几个方面

可维护性，可扩展性，可用性。

可扩展性，也分为横向和纵向。纵向是单机的性能能到多少。那么，语言性能影响的是纵向的扩展性。

设计应用，如果能横向扩展，几乎可以说是赢了。而横向扩展跟语言性能没什么关系。

再来看下我们的环境，首先是硬件越来越便宜，cpu 单核性能已经不那么容易增加了，得靠多核提升性能。

性能瓶颈多数是在存储这。我们拿 Facebook 的 memcache 集群为例，有篇论文是介绍他们怎么玩的。他们的优化都在处理横向扩展，如何应对突发流量，如何减少网络请求之类的。单机的优化很少。分布式里，似乎都不是很在意单机的能力。

再比如 discord 用 rust 替换了一个 erlang 的 orderedsort 实现，性能翻了多少多少。先不说没找到具体的测试用例、机器情况。他们的实现，erlang 的是遍历，rust 的是跳表。当数据量比较大的时候，算法的重要性远大于语言。顺便一提，erlang 有 ets，sort 是平衡树，c 实现，并发性非常好。

有的时候，看清楚问题是什么，当前的情况是什么，更重要。

问题到底是快速迭代还是极致性能（高性能，多数的时候大家还是用 c++，相对来说 java 差不少，外加加上 gc）。如何利用现有资源，比如分布式，大内存，算法。

语言不过是工具盒里的工具，性能不过是这些工具的一个属性。

服务不可用，有多种情况。

一种是临时性的，比如重启，这种只要加一下超时重试，就可以解决。

另一种是服务直接被打趴下了。这个时候，需要调用方放慢一点速度，比如限流、熔断。

还有用类似 tcp 的拥塞控制来做的，比如 网飞有个 java 库是 https://github.com/Netflix/concurrency-limits。

Facebook 的 memorycache 集群也有类似的机制，说是可以降低延迟 https://pdos.csail.mit.edu/6.824/papers/memcache-fb.pdf 3.1

限流需要预先知道服务能承受多大压力，如果服务比较少，依赖简单，还行。但复杂了，就没办法知道这个数值了，就需要靠拥塞控制的思路搞。

应该是浏览器用 http2 的话，必须要用 TLS

https://stackoverflow.com/a/54458547/2477886

用 TLS 的话，需要签发证书。

Rust 和 Ruby 应该是所有编程语言里面最类似的了

你这么一说，Ruby 一定和 R 有关系，R 一定和 System R 有关系，根据关系的传递性，Ruby 和 System R 也有关系。

我也是最近才知道

bpf 这个东西我就是知道个名字，不过直觉上和 tracing（dapper 就是做 tracing 的）是一类东西。

有人这么形容 bpf

以前的一些 linux 指标，像是蜡烛照亮了内核，bpf 像是给内核打开了个灯

系统复杂起来了，都不好理解。

Google 他们为了理解他们自己的系统，搞了一个叫 Dapper 的东西，用来理解分布式系统。

最近还有一是 BPF http://www.brendangregg.com/bpf-performance-tools-book.html，好像也可以当 understanding tool 用。

搞 Rust 的好像有不少人弄 BPF，Erlang 好像也搞过一点，不过后来似乎是废弃了。

不知道 RoR 有没有类似的。

（要有兴趣，有时间我们可以讨论呀（虽然这两个东西我也不咋懂

我有 acm 的邮箱，不过花钱就能买。

俗称大忽悠

确实讲了不少如何思考的东西，还真挺有用的。