我需要一个架构意见和方法来解决以下问题：
简介：
我们有一张table ~4M 调用的行 Purchases .
我们还有一张table ~5k 调用的行 Categories .
另外，我们还有一张table
~4k SubCategories .
我们使用t-sql来存储数据。
在用户请求时（在运行时），服务器接收大约10-15n个参数的请求。根据这些参数，我们进行采购，按类别和子类别进行排序，并进行一些计算。
一些“计算”的过程包括过滤、排序、重新排列购买字段、相互减去购买、相互添加一些其他购买、查找储蓄等。。。
这个过程是特定于用户的，因此每个用户将根据其角色获得不同的数据。
问题：
这个过程大约需要3-5分钟，我们想减少它。
以前，这个过程是在内存中通过webworkers（js）在浏览器上完成的。随着内存开始变得非常大，大多数浏览器开始在加载时出现故障，我们已经不再使用它了。然后我们将服务移动到服务器（nodejs），后者通过子进程动态处理请求。子进程的原因：计算进程经过大约5000x次for循环（对于每个类别），并执行上述“计算”。
通过子进程，我们能够将工作分配到#个子进程中，如果我们至少运行16个核心（16个子进程），结果会更好一些。
目前的处理时间减少到大约1.5-2分钟，但我们想看看是否有更好的选择。
我明白，不看任何代码就很难完全理解我们的目标，只能具体地问问题。在运行时对半大数据进行计算的一些方法是什么？
我们有一些想法：
在内存表中使用sql并在sql中进行计算
使用azure批处理服务
使用更大的机器（~32-64核），如果我们没有其他想法，这可能是我们最好的选择。当然，成本会急剧增加，但我们接受成本会增加的事实）
踏入hadoop生态系统（或其他大数据生态系统）
其他一些有用的事实：
我们的购买量约为1gb（对于内存计算来说，有点太大了）
我们正在考虑在redis上进行预计算和缓存，以便为客户端准备一些数据（我们将每天使用他们在帐户中设置的参数进行预计算，但是客户端往往会频繁更改这些参数，因此我们必须有一些有效的方法来处理未缓存和预计算的数据）
如果有更多的信息，我们可以提供更好地理解我们的困境，请评论，我会提供尽可能多的信息。有太多的代码粘贴在这里，一个人完全理解算法，因此我想尝试用文字传递我们的问题，如果可能的话。
2条答案
按热度按时间eh57zj3b1#
这个主题并不新鲜，只是以防万一。。。根据我的经验，我想说您的t-sqldb可能会成为您的瓶颈。
您是否衡量了sql查询的性能？您在sql server端计算什么？在node.js端？
一个好的开始是测量sql查询的响应时间，修改查询，处理索引，并在需要时深入研究db查询引擎的工作方式。有时在db设置中进行一个小的调整就可以了！
wrrgggsh2#
在确定工作流的关键路径之前，不要决定技术
这永远不会帮助你实现（一个未知的）目标。
由于不知道流程的关键路径，没有人能够从任何架构中计算出任何加速，无论你可能会积极地“推销”你，或者只是“推荐”你作为“怪胎/书呆子/性感/流行”来跟随-无论你喜欢听什么。
你会从这样一个未成熟的决定中得到什么？
通常是预算（co$t$）和项目管理（滑动时间尺度）噩梦的混合体：
额外成本（新技术还意味着需要学习的新技能、新的培训成本、团队重新塑造和调整的新延迟，以及在绩效水平上更好地成熟使用新技术，比当前使用的工具等）
选择“受欢迎”品牌的风险，另一方面，它不会表现出营销文本承诺的任何肤浅的力量（但一旦支付了最初的进入成本，除了承担永远无法实现预期目标的风险之外，别无选择，可能是由于高估了性能效益和低估了改造成本以及严重低估了运营和维护成本）
如果您可以使用“更好的选择”仍然是您的选择的解决方案，您会怎么说：
现在就可以开始使用当前正在使用的代码，而无需更改一行代码
你现在可以从一个基于你的自由意志的渐进的性能扩展路径开始
您可以避免（mis）的所有风险—投资于任何额外的溢价成本“超级盒子”，而是出于安全考虑—重新使用廉价且经过大量服务测试/微调/部署验证的cots硬件单元（一个普通的双cpu+几gb的机器，通常在数据中心大量使用）
您可以扩展到所需的任何性能级别，从一开始就逐渐提高cpu限制的处理性能，无需任何麻烦，可以根据需要扩展到约1k~2k~4k~8k cpu—是的，可以扩展到数千个cpu，您当前的工作人员代码可以立即用于提供这种提高的性能带来的直接好处，从而使您的团队有更多的时间进行彻底的设计改进和代码重新分解，以获得更好的性能，如果当前工作流，曾经是“被动”的智能分配，比如说~1000，后来~2000或~5000个cpu核（仍然没有改变一个sloc）单靠自己还不够吗？
您可以根据需要逐步扩展到（几乎）任何大小的内存容量，无论是在第1天~8tb、~16tb、~32tb、~64tb，明年都可以跳到~72tb或~128tb，如果需要的话——所有这些都会让你的预算总是（几乎）线性的，并且完全由你的绩效计划和实际客户产生的流量来调整
您可以将您的研发工作隔离并集中于（重新）学习“新”平台，而不是纯粹的流程（重新）设计，以进一步提高流程性能（在可行的情况下，可以使用预计算策略，也可以在ram布局中使用更智能的全功能，以实现更快的临时计算，而不是静态预计算）
对于这种与投资回报率一致的战略，企业主会怎么说？
如果一个人让ceo+cfo“买”任何新玩具，那么，这对今天、明天的黑客攻击来说都是很酷的，但这样的做法永远不会让股东们比把钱投进尼罗河更高兴。
如果你能展示出最终有效的项目计划，其中大部分的知识和技能都集中在与业务一致的目标上，同时保护投资回报率，那将使你的首席执行官+首席财务官和我保证你的所有股东都非常高兴，不是吗？
那么，你决定走哪条路？