高内存/性能临界计算.建筑方法意见

Question

我需要一个解决以下问题的架构意见和方法：

简介：

我们有一个~4M行表，名为Purchases。 我们还有一个~5k行表，名为Categories。 此外，我们还有一个~4k SubCategories表。我们使用T来存储data.At用户的请求(在运行时)，服务器接收到大约10-15 N的参数可能性的请求。根据这些参数，对采购进行分类和subCategories排序，并对“计算”过程中的“计算”过程进行computing.Some，包括过滤、排序、重新排列采购字段、互相减法、互相添加一些其他采购，找到节省，etc...This过程是特定于用户的，因此每个用户都会根据各自的角色获得不同的数据。

问题：

这个过程大约需要3-5分钟，我们想要削减它的down.Previously，这个过程是在内存中，通过网络工人(JS)浏览器上完成的。随着内存开始变得非常大，并且大多数浏览器开始在加载时出现故障，我们已经不再使用它了。然后，我们将服务移动到服务器(NodeJS)，它通过子进程动态地处理请求。子进程的原因:计算过程经过一个关于5,000倍次数的for循环(对于每个类别)，并执行上面提到的“计算”.Via子进程，我们能够将工作分配到子进程的#中，如果我们运行至少16核(16个子进程)，这会给我们带来更好的结果。目前的处理时间已经降到了的1.5到2分钟，，但是我们想看看我们是否有更好的选择。

我理解在不看到任何代码的情况下，很难完全理解我们的目标，而是特别地提出问题。在运行时对半大数据进行计算的一些方法是什么？

我们有一些想法：

1. 使用内存中的SQL表并在sql中进行计算
2. 使用蔚蓝批处理服务
3. 使用更大的机器(~ 32-64核)，这可能是我们最好的机会，如果我们不能得到任何其他想法。当然，成本会大幅增加，但我们接受成本会增加的事实)
4. 踏入hadoop生态系统(或其他大数据生态系统)

其他一些有用的事实：

1. 我们购买的~1GB (对于内存中的计算来说有点太大了)。
2. 我们正在考虑在redis上进行预计算和缓存，以便为客户端准备一些数据(我们将每天使用他们在帐户中设置的参数进行预计算，但是客户往往会频繁地更改这些参数，因此我们必须有一些有效的方法来处理非缓存和预计算的数据)。

如果有更多的信息，我们可以提供更好地理解我们的困境，请评论，我会提供尽可能多的信息。有太多的代码粘贴在这里，一个人要完全理解算法，因此，我想尝试把我们的问题，如果可能的话。

Answer 1

决不要在确定工作流的关键路径之前决定技术

这将永远不会帮助你达到(一个未知的)目标。

不知道过程的关键-路径，没有人能计算出任何加速从任何一个人可以积极-“销售”你或just-"recommend“你跟随”怪人/书呆子/性感/流行“-任何一个人喜欢听到。

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

通常情况下，预算($t$)和项目管理(滑动时间尺度)都是噩梦的混合体：

• 额外成本(新技术也意味着新技能的学习，新的培训成本，团队重新调整和成长的新延迟，在性能水平上比目前使用的工具更好，等等)。
• 选择一个“受欢迎的”-brand的风险，它在另一方面并没有表现出市场营销文本所承诺的任何表面力量(但一旦支付了最初的进入成本，就只能承担永远达不到预定目标的风险，这可能是由于过高的性能效益和被低估的转换成本以及严重低估的运营和维护成本)。

如果你能用一个解决方案，你会怎么说，

如果“更好的选择”仍然是你的选择：

• 您可以立即启动，使用当前正在使用的代码，而不需要更改一行代码。
• 您可以使用now启动，这仍然是您基于自由意志的渐进路径的性能扩展。
• 您可以避免(Mi)-investing的所有风险进入任何额外的额外成本“超级盒”，但是宁愿留在安全的一边，重新使用一个廉价的、大规模的服务测试/微调/部署经过验证的COTS硬件单元(一个普通的双CPU+几台GB计算机，通常用于成千上万的数据中心)。
• 您可以扩展到所需的任何性能级别，从一开始就逐步提高CPU绑定的处理性能，从一开始就没有麻烦，可扩展到大约1k ~2k ~4k ~8k的CPU，根据需要--是的，多达数千个CPU，您的当前工作人员的代码可以立即用于交付这样提高的性能的直接好处，从而使您的团队可以自由地进行彻底的设计改进工作，并在可能的设计改进和代码重新包装上花费更多的时间，如果当前的工作流程是“被动的”，只分发到1000，晚些时候~2000或~5000-CPU核心(仍然没有一个SLOC改变)本身是不够的吗？
• 你可以在需要的基础上逐步地扩大到(几乎)任何大小的内存容量，无论是在第1~8 to，~16 to，~32 to，~64 to，明年跳转到~72 to或128 to(如果需要的话) --所有这些都会使你的预算始终(几乎)线性，并根据你的性能计划和实际客户产生的流量完全调整。
• 您可以隔离和您的研发工作，而不是(re)-learning“新的”-platform(S)，而是纯粹的，用于进一步提高流程性能(无论在可行的情况下使用预计算策略，也可以使用更智能的、完全在内存中的布局来进行更快的临时计算，而不能静态地预先计算)。

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

如果你让首席执行官+首席财务官“买”任何新的玩具，那么，这对今天的黑客来说是很酷的，明天也是如此，但这种方式绝不会比把钱投入尼罗河更让股东们开心。

如果你能展示最终有效的项目计划，其中大部分知识和技能都集中在与业务一致的目标上，同时保护投资回报率，这将使你的首席执行官+首席财务官和我都保证，你的所有股东也非常高兴，不是吗？

那么，你决定走哪条路？

Answer 2

这个话题并不新鲜，只是以防万一.就我的经验而言，我认为您的tell可能是您的瓶颈。

您测量了SQL查询的性能吗？在SQL服务器端计算什么？在Node.js那边？

一个好的开端是度量SQL查询的响应时间，修改查询，编写索引，并在需要时深入了解DB查询引擎是如何工作的。有时候，在DB设置中进行一个小的调优就能做到这一点！