有个同事问我:"你开发的分布式数据库系统, 如何避免 scan 扫描操作返回了 pending 事务状态的数据?"
我说:"把数据扫描出来, 然后逐个判断过滤掉 pending 状态的数据."
我感到奇怪, 对于他的问题, 解决方案非常显然啊. 解决方案非常直观, 兵来将挡水来土掩, 我相信他也能想到, 不想要的数据当然要剔除掉, 否则呢? 那么, 他的问题的点在哪?
没错, 他接着问了:"我 scan 的时候只想返回 key, 但是, 要判断状态, 是不是还得去读取 value 解析出状态信息?"
我当时是黑人问号脸:"当然要知道状态信息才能根据状态过滤呀, 不然呢?"
他终于祭出了那个经典的让人哭笑不得的问题:"读取 value, 是不是性能会下降啊?"
且不说无缘无故在没有任何场景支撑的情况下就提出性能问题让人莫名其妙, 这有什么性能问题? 我当然知道, 一次内存拷贝当然比两次内存拷贝性能高, 一次 IO 当然比两次 IO 性能高, 所以呢?
这种凭空想出的所谓"性能问题"有什么可讨论的? 你觉得一次 IO 性能高, 那只能在写入的时候把需要的数据聚簇到一起, 以便将来能一次读取. 也就是在写入的时候多付出成本, 以换取读取的时候节省成本, 道理不是很简单吗?
所以我说:"那就把状态信息放一起, scan 的时候就一起读出来了. 或者把 pending 状态的数据放到别的地方, scan 时自然不返回."
他应该是悟了, 说:"哦...", 然后走了.
我直到现在还是黑人问号脸... 感觉就像经历了一次蜘蛛蚂蚁, 打雷下雨一样的显而易见的因果关系, 感觉他是在寻找银弹.
其实, 系统层面的方案, 并不像冒泡排序和快速排序的算法性能差异那么明显, 系统层面的算法(方案, 策略, 流程)都是跟着需求走的, 功能需求要求怎么做就怎么做, 一就是一, 一之后就是二, 按部就班照着做, 非常直白, 没有一丁点可以偷工减料的地方, 朝三暮四和朝四暮三的障眼法更不可取.
不想要就过滤掉, 需要的就找出来, 不想多次IO就聚簇存储, 硬盘慢就放内存中, 内存不够就加内存或者淘汰数据, 锁粒度太大了那就增加锁数量减小锁粒度, 临界区太长了那就减少临界区长度, 操作次数太多了那就合并操作, 串行化吞吐量不满足需求那就并发多线程, 如果认为多线程调度成本太大那就换多路复用接口... 软件系统工程的事, 一切都是那么地自然和直观.
Loading ...