如何做好大数据的实时复杂查询

在过去的几年里，我们生活中几乎每一个功能都依赖于实时应用。无论是通过社交媒体更新我们的朋友圈，在线购物，还是等待客户服务的立即回应，我们已经变得越来越依赖快速有效的得到我们想要的信息。

然而我们不知道的是，这其中存在几个挑战：

在这些系统中流动着的大量数据

·需要一个高度可用的应用程序和数据存储

·高性能的要求·支持复杂查询。

·事务支持

我们可以尝试把这些挑战转化为3个部分：大数据，实时性和复杂查询。

第一个挑战-大数据

从大数据开始，要解决这些问题，我们有很多可以利用的解决方案。 最流行的解决方案是NoSQL数据库和Hadoop。 它们属于分布式环境，其中存在多个包含数据的分区。 通过分区间的复制，以确保在某一台服务器宕机时，我们可以从另一台服务器获取数据（大多数是最终一致的，这意味着副本可能没有最新的数据更新，但是这属于另外的讨论范畴）。 那么，如果我们采用这些NoSQL数据库，我以很容易地克服数据量和高可用性问题所带来的挑战。 它也是一种可扩展的解决方案，可以添加更多的计算和存储资源，这些将能够支持更多的数据和吞吐量。

第二个挑战-实时

实时是面临的主要挑战。目前主流的解决方案主要是基于磁盘的，这意味着没有对实时部分的支持，面对复杂的查询可能需要几分钟，有时甚至更多。 这就是为什么我们需要内存数据网格，它在内存中存储了部分数据或全部数据。 当数据存储在内存中，计算是可以做到非常快速的使用RAM而不是I / O访问。

但这种解决方案也不是那么容易。 我们也许可以在RAM中存储几个TB数据，但如果我们有更多的数据，那怎么办？ 比如说50TB ......即使如今RAM变得便宜得多，但50TB也将是非常昂贵的。 此外，这也导致管理一个数据网格集群的机器数量过多。 一些内存数据网格解决方案提供了另一种方法，在磁盘中存储一些非活跃的数据。

固态硬盘可以为我们提供一个将二者合二为一的机会，前提是我们使用正确。虽然SSD并不像RAM一样快，但它比正常的磁盘快得多，而且比RAM便宜很多。 现在有2种方式，我们可以利用固态硬盘来实现非常大的集群和实时复杂查询：

*快速索引模式 - 我们将查询的字段存储在RAM中，将其余部分都存储在SSD上。 例如，如果我们有一个包含很多字段的大对象，我们只能在RAM中存储其中的一些索引，将一些次要字段存储在固态硬盘中，所以相比于常规磁盘，我们依然可以在它们之上进行非常快的查询。

*热数据---最近被使用的对象将被存储在RAM中，其他对象将被放入SSD。 这种方法还可能具有实时性的挑战，因为查询引擎在SSD上进行需要全部数据的复杂运算，而不是在RAM上。

第三个挑战-复杂查询

还剩下复杂查询这部分挑战，大多数应用在关系型数据库中有实时分析的需求，我们可以很容易地通过聚合查询实现 （avg， min， max， sum， group by）。而分布式环境中，这要复杂得多，因为数据在集群的分区中，聚和就意味着我们要么需要把所有的数据传输到客户端（这不是一种好的选择，因为它实在是太多了）或使用MapReduce逻辑模型，使用Map Reduce逻辑模型是一种不错解决方案，只不过没有简单SQL group by来的更直观而已。