我在一家公司工作过，我可以这么说，FusionIO拯救了这家公司。我们有一个单一的Postgres数据库，支撑了应用程序的很大一部分。我们尝试启动一个横向扩展项目，但成效甚微——结果发现，在一个复杂且老旧的代码库上进行分片非常困难。不知怎么的，我们最终安装了一块FusionIO卡。我们从每秒大约5000次读取请求，提升到了使用最便宜的2TB卡时的每秒30万次读取请求。从那以后，我一直认为垂直扩展比最初我认为的更容易实现。事实证明，硬件能做的事情比我们想象的要多得多。
源讨论将QLC SSD转换为SLC SSD原帖 153 条评论 · 导入时统计大约十年前，我得到了一些最后生产的FusionIO SLC卡用于基准测试。当时软件是一个内存数据库，客户想要用它来扩展容量。我 literally 只是把Fusion卡当作了交换空间。 在加载数据几分钟后，内核平静下来，它就像一个冠军一样工作。在一台500美元的电脑上，每秒处理数百万次事务，跨越数十亿条记录...还有一张比我的车还贵的卡。 当然，现在不会这么做了，但那确实是一套令人印象深刻的产品。
完整原文把你的经验，加入这段讨论。
在这种情况下，稍微更好的解决方案是设置一个反向代理，将所有GET请求发送到只读副本，而实际数据库的服务器则处理所有写入流量。 但其中的难点在于，你可能需要设置响应以包含由成功写入触发的读取结果。否则，你必须解决副本的延迟问题。
完整原文你可以在单个服务器中获得大约五百个核心，以及多个TB的RAM。你可以在一台服务器上将维基百科或Stack Overflow或Hacker News的业务逻辑全部运行在RAM中，尽管你仍然需要副本以进行带宽扩展和故障转移。垂直扩展肯定应该重新流行起来。 更不用说，不管多贵的单个服务器，其成本只是同等云服务的一小部分。 还记得LMAX Disruptor的炒作吗？他们的模式基本上是将整个业务逻辑的数据集中到一个核心上，并确保该核心不会受到任何干扰——编写最快的L1缓存可访问的非阻塞串行代码，输入和输出都使用环形缓冲区。流水线业务流程可以使用每个流水线阶段的一个核心。他们用这种模式在2011年实现了每秒2000万次交易的基准测试——他们运行了一个股票交易所…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。