大数据能否解决我大量数据快速查询的问题

[yikewl]

开始没设计好，我订单分为4个千万级数据表关联（oracle），当一个客户进来后，我要列出他所有的订单，这样4个大表关联，贼贼慢，我就在想前些年不是一直在喊大数据吗，大数据怎么来解决这个问题呢。

实时性很高，速度也要求很快

[LinkSe7en]

你这问得太笼统了。大数据意味着分布式，即分布式存储和计算。4个kw级表join，还要快速响应，那首先问题是准备好多少台什么配置的节点。。。然后才是数据如何分布式治理和采用什么计算框架的问题了。。。

[shiter]

大数据可能应该这么做，把四个关联好的做成一个宽表 放到hbase 或者什么的地方，索引放在es里面，这样应该也可以秒级响应

[野男孩]

4个千万级表做级联能满足你实时计算，实时查询？

楼上的答案是一般的大数据解决方案，hbase宽表存数据，es做索引。
查询如果比较单一的话，可以直接设计好hbase的表的rowkey，查询起来比ES快。

[cocoa2003]

建议考虑建立宽表，在kudu中，通过sparkJobServer发布rest接口，做实时查询。前提要求机器配置也比较高，最少8台256G内存的机器集群

[yikewl]

我继续补充下我的问题，开始没讲清楚，不好意思。

首先这个表是订单表，意味着插入很频繁。其次历史数据意义重大，我上面的需求是需要把符合条件的3年的数据查出来。

就想问大数据方面能否做到这么实时，有我直接从oracle查出来实时么。

[yikewl]

引用 5 楼 cocoa2003 的回复:

建议考虑建立宽表，在kudu中，通过sparkJobServer发布rest接口，做实时查询。前提要求机器配置也比较高，最少8台256G内存的机器集群

我的实时订单能进去么

[yikewl]

讲下我目前解决思路，感觉好low.

逻辑库中创建一个表，包含经常要查询的字段。通过触发器记录这4个表的新增和修改，每秒刷到这个大表中，通过这种方式来避免多表联合查询。但是带来了性能损失，看起来好low.就想了解下，如何利用大数据知识去解决这类问题。

[小大飞]

能把数据放到内存中查吗？

[LinkSe7en]

引用 8 楼 yikewl 的回复:

讲下我目前解决思路，感觉好low. 逻辑库中创建一个表，包含经常要查询的字段。通过触发器记录这4个表的新增和修改，每秒刷到这个大表中，通过这种方式来避免多表联合查询。但是带来了性能损失，看起来好low.就想了解下，如何利用大数据知识去解决这类问题。

没有完美的解决方案，所有听起来高大上的东西，原理都很low。 只有符合现阶段需求和拓展预期的最佳实践。 建议从分布式的几大原则入手学习。例如CAP理论，分布式一致性算法（Raft等），BASE理论。 多学习现有的分布式数据库（NoSQL的HBase，Mongo，OLTP的RDB集群，HTAP的如TiDB），以及数据的分治算法，MapReduce思想，一致性哈希等等。

[小大飞]

建个宽表，包含四个表的所有字段，不要主键。写个定时任务，把表中新增的数据，不断的刷到宽表中。然后查询时直接查宽表。 查宽表还慢，把宽表放到Mongo中，直接通过Mongo查询？

[以专业开发人员为伍]

大数据是两个方面的意思：1是非常“大”的离散数据，比如说几百亿记录分布在几千台机器上，如何把几千个表当作一个表来写查询语句。2是一堆数学统计软件包，用来做最基本的所谓神经病网络分类算法，用了大数据这个时髦词儿。对于1来说，从来也没有说它比单机处理的速度更快。人家是根本不可能单机，所以才分为几千台机器上进行存储的。 于是就回到了你的后边提出的问题。你在数据库中搞什么“触发器”来将数据写到缓存，这是本末倒置了。缓存数据应该是第一位的、不落地的。数据即使还没有保存到数据库中备份之前，就应该落在缓存里了。而且数据库操作可以是异步的，不需要阻塞真正的业务操作，特别是不应该去让许多线程收到什么数据库事务锁的垃圾限制，因此把缓存操作当作数据库表的触发器的结果是完全是本末倒置了。

[以专业开发人员为伍]

满脑子只有关系数据库增上改查的时候，才会什么技术都往数据库表、触发器上去联系。

[yikewl]

引用 12 楼 sp1234 的回复:

大数据是两个方面的意思：1是非常“大”的离散数据，比如说几百亿记录分布在几千台机器上，如何把几千个表当作一个表来写查询语句。2是一堆数学统计软件包，用来做最基本的所谓神经病网络分类算法，用了大数据这个时髦词儿。对于1来说，从来也没有说它比单机处理的速度更快。人家是根本不可能单机，所以才分为几千台机器上进行存储的。

于是就回到了你的后边提出的问题。你在数据库中搞什么“触发器”来将数据写到缓存，这是本末倒置了。缓存数据应该是第一位的、不落地的。数据即使还没有保存到数据库中备份之前，就应该落在缓存里了。而且数据库操作可以是异步的，不需要阻塞真正的业务操作，特别是不应该去让许多线程收到什么数据库事务锁的垃圾限制，因此把缓存操作当作数据库表的触发器的结果是完全是本末倒置了。

仔细看了您的回复，感觉很有道理，但是又想不出一个方案，请指导一下，帮我指个小一点的方向，谢谢

[lsignsjisfsf]

1.从业务角度考虑，实时调取历史订单，是不是可以区分 动态变化的订单 + 历史不变的订单。 2. 如果可以区分开，对于动态变化的订单 可以采用oracle 查询。对于 历史不变的订单 可以建立宽表，spark streaming 实时计算获得结果，存储到hbase，供前端查询。

[deepthinkers]

我虽然是个刚入门的，我也给点思路，我建议你使用solr加 hbase 加spark。把关联数据利用spark计算结果存入hbase，用solr做全字段索引，再访问solr去查。和1楼思路差不多。速度是比较快的，至于四表关联的优化有很多，spark这边可以做。对于增量更新的问题，可以放在solr里面做，如果有删除标志位和时间戳，可以自动实现增量更新的。一点点拙见

[BigBangBug]

需求要先搞清楚，通常列出“所有”订单并不是完全所有，因为一个屏幕也装不下啊，都是分页的。像普通电商公司一般采用mysql分下库，单个库中的每个表一般最多3kw~5kw，对查询都是毫秒级出结果的。4个表join这个优化一下关系型数据库完全没问题，你这点数据量其实是很少的，分下库就每个表只有几百万，没必要用spark、hadoop这些重武器，而且可以告诉你的这种应用一点也快不起来，成本还很高。