高内存/性能关键计算 – 架构方法观点

我需要一个架构观点和方法来解决以下问题：

介绍：

我们有一个~4M行的表称为Purchases 。
我们也有一个~5k行的表，称为Categories 。
另外，我们有一个~4k SubCategories的表。

我们正在使用T-SQL来存储数据。

在用户请求（在运行期间），服务器接收到大约10-15个可能参数的请求。 根据参数，我们采购，按类别和子类别进行分类，并进行一些计算。

“计算”的一些过程包括过滤，分类，重新安排采购领域，相互减less采购，增加一些其他采购，find储蓄等等。

这个过程是用户特定的，因此每个用户将根据他们的angular色获得不同的数据。

问题：

这个过程大约需要3-5分钟，我们希望把它裁掉。

以前，这个过程是通过webworkers（JS）在浏览器中完成的。 随着内存开始变大，大多数浏览器开始加载失败，我们已经离开了它。 然后，我们将服务移动到服务器（NodeJS），通过subprocess即时处理请求。 subprocess的原因：计算进程经过for循环大约5000倍（对于每个类别）并执行上述“计算”。

通过subprocess，我们能够将工作分配到#ofsubprocess中，如果我们运行了至less16个内核（16个subprocess），则可以获得更好的结果。

目前的处理时间下降到大约1.5-2分钟，但我们想看看我们是否有更好的select。

我明白它很难完全理解我们的目标，而没有看到任何代码，而是专门提出问题。 在运行时对半大数据进行计算的方法有哪些？

我们有一些想法：

1. 使用SQL内存表，并在SQL中进行计算

2. 使用azure色批处理服务
3. 使用更大的机器（〜32-64内核，如果我们不能得到任何其他的想法，这可能是我们最好的select，但是当然，成本增加了很多，但是我们接受成本会增加的事实）
4. 步入hadoop生态系统（或其他大数据生态系统）

其他一些有用的事实：

1. 我们的购买量约为1GB （对于内存计算来说有点过大）
2. 我们正在考虑在redis上进行预计算和caching，以便为客户端准备好一些数据（我们将使用他们的帐户中的参数设置每天预先计算，但客户端往往会频繁更改这些参数，因此我们有有一些有效的方式来处理未caching和预先计算的数据）

如果我们可以提供更多的信息来更好地理解我们的困境，请发表评论，我将尽可能提供更多的信息。 如果可能的话，将会有太多的代码粘贴到这里来完全理解algorithm，因此我想尝试用单词来提供我们的问题。

Answer 1

在确定工作stream的关键path之前，千万不要决定技术

这永远不会帮助你实现（一个未知的）目标。

不知道过程的关键path，没有人能够计算任何加速，可以积极地“推销”你或只是 “推荐”你遵循“怪异/书呆子/性感/stream行” – 任何人喜欢听。

你会从这样的早熟决定中得到什么？

通常情况下，预算（co $ t $）和项目pipe理（滑动时间尺度）噩梦的混合：

• 额外的成本（新技术也意味着新的技能学习，新的培训成本，新的延迟，团队重新塑造和重新调整，并成长为成熟的使用新技术在性能水平比目前使用的工具，等等）
• select一个“stream行”品牌的风险，而另一方面却没有performance出任何表面上的权力，营销文本是有前途的（但是一旦支付了进入的初始成本，就没有别的方法可以承担永不实现的风险预期的目标，可能是由于高估了性能收益和低估了转型成本，严重低估了运营和维护成本）

你会怎么说，如果你可以使用一个解决scheme，
“更好的select”仍然是您的select：

• 现在就可以开始使用您正在使用的代码， 而不需要更改一行代码
• 您现在可以开始使用仍然基于自由意志的渐进式性能缩放path
• 您可以避免（错误）投入任何超额费用的“超级盒子”的风险， 而是保持安全的一面重新使用廉价且大规模的在役testing/微调/部署validation的COTS硬件单元（一个普通的双CPU +几GB的机器，通常在数以千计的数据中心中使用）
• 您可以扩展到任何您需要的性能级别， 逐渐增加CPU的处理性能，从一开始就无忧无虑，根据需要达到一些〜1k〜2k〜4k〜8k的CPU – 是的，高达数千CPU，您当前的工作代码可以立即使用这些提高的性能的直接好处，从而使您的团队可以放手，更多的时间进行彻底的工作，可能的devise改进和代码重新分解，以获得更好的性能信封目前的工作stream程已经“被动地”被巧妙地分配到约1000个，后来的2000个或5000个CPU核心（仍然没有单个SLOC改变），这是不足够的。
• 您可以逐渐扩大 – 在需要的基础上，无忧无虑 – 几乎可以达到任意大小的内存容量，无论是在第1天〜8TB，〜16TB，〜32TB， 〜64TB ，如果需要的话，明年可以跳到〜72TB或〜128TB ，这些都可以保证您的预算始终（几乎）线性，并根据您的性能计划和客户实际产生的stream量进行全面调整
• 你可以把你的研发工作分离出来，而不是（重新）学习“新”平台，而是纯粹的进行 （重新） devise，以进一步提高过程的性能 （使用预先计算的策略，在可行的情况下，可以使用更智能的全内存RAM布局来实现更快的临时计算，而这些计算不能静态预先计算）

企业主对这种与投资回报率相一致的战略会说些什么？

如果有人让首席执行官兼首席财务官“买”任何新的玩具，那么今天这种黑客行为是很酷的，但是这样的做法永远不会使股东们高兴，而不是把钱投进尼罗河。

如果能够展示最终有效的项目计划，那么大多数知识和技能都集中在与业务目标相关的目标上，同时保护投资回报率，这将使您的首席执行官+首席财务官，我保证所有的股东快乐，不是吗？

那么，你决定去哪个方向？