基础设施选型要匹配团队工程背景与运维能力，而非唯技术最优论

团队在存储选型时放弃了当时看起来更”主流”的HDFS/HBase组合，转而选择Cassandra+MongoDB，给出的理由并非纯技术对比出的”孰优孰劣”，而是结合了自身团队实际状况的综合判断：HDFS处理小文件效率差、当时的NameNode还不够稳定、多级目录管理导致检索费劲；HBase基于HDFS、性能一般、检索困难，且同样存在单点故障，而”当时创业公司的运维能力还不强、资源也没那么多”，团队判断自己维护不来这套体系；相比之下Cassandra去中心化、扩容和容灾能力更省心，MongoDB则从开发之初就支持团队实际使用的Ruby语言。这个案例给出一条常被低估的选型考量：一项基础设施技术选型的正确与否，不能脱离”这个团队当前的工程背景、运维能力和资源规模是否撑得起这套技术”这个前提单独评判——同样的技术在成熟大厂手里可能是最优解，换到运维能力有限的小团队手里，反而可能变成难以承受的负担，选型时理解并承认自身局限，比追逐”更先进”的技术更重要。