NLTK 确实是一个很好的学习平台,但并非旨在为数百万客户提供强大的服务。
您可以通过两种不同的方式解决可伸缩性问题:
- 第一种“大数据”方法:使您的算法适应 MapReduce 并在 MongoDB/Hadoop/Google MapReduce/上运行它们...有不同的地方可以托管此类解决方案(Amazon、Google、Rackspace...)
- 第二种,“自行开发”方法:使用通用托管解决方案或您自己的数据中心。
“大数据”方法
这意味着重新思考你的算法。需要良好的数学背景和对算法的良好理解。也许你甚至会替换算法,因为执行时间与工作量的关系不大。
因此,就实施您的想法而言,这可能是最困难(甚至可能是不可能)的解决方案,具体取决于您的技能。对于部署和未来的好处,这是迄今为止最简单的解决方案。
“自己动手”的方法
您可以通过可扩展性来表示不同的含义:
- 更大的训练集
- 更多客户
- 更多算法和应用
- 增加你的训练集可能意味着重新训练或适应
- ...
关于可扩展性有不同的数量级:您要扩展 10 倍、100 倍、1000 倍……?
有不同的方法来克服可扩展性问题:
- 并行化:添加服务器的精确副本并进行负载平衡
- 流水线:可以在不同服务器上进行的不同步骤中的拆分处理
- 更昂贵的硬件、更快的 CPU、RAM、磁盘、总线、ASIC……
- 客户端处理
- 缓存请求
- 软件性能调优,在 C/C++ 中实现瓶颈
- 使用更好的算法
- 更智能地分离离线发生的事情(例如,使用 cron 作业)和每个请求完成的事情。
- ...
无论可扩展性的类型是什么,以及您使用什么方法来克服它,都请进行负载测试,看看您可以处理什么。由于您无法立即购买所有硬件,因此有多种方法可以对扩展的基础架构进行负载测试:
- 租用处理器、内存、磁盘空间……每小时,刚好够做负载测试和纾困。这样,您无需购买设备。
- 风险更大:在比生产中更少和更便宜的设备上进行负载测试并推断结果。也许你有一个关于你的算法如何扩展的理论模型,但要注意副作用。布丁的证据在吃。
接近 VC(就可扩展性而言)
- 创建一个可以清楚地自我解释您的想法的原型(不一定可扩展)
- 向自己证明,在未来的某个时候一切都会好起来的,代价是什么(最小/预期/最大一次性/连续成本)
- 从私人测试版开始,这样可扩展性从一开始就不是问题。退出测试版没有最后期限。估计可以,但没有截止日期。不要为此妥协!
祝你好运!