分布式内存中网格中的聚合

[本文由Ron Zavner撰写。]

今天，我们看到越来越多的应用程序不再构建在关系数据库上，而是建立在分布式环境上。发生这种情况是因为它们需要可扩展性和高可用性，而且还需要能够提供高吞吐量和低延迟，这是旧版关系数据库无法实现的。如今，分布式环境和内存数据网格比几年前更先进，但是实现起来也比关系数据库更加复杂。

由于分布式数据网格以分布式方式存储数据，创建分布式数据库，因此有一些操作不太直观，例如连接查询和聚合操作。假设我们想要将一个雇员对象和它的部门对象一起取出。 “在数据库中，这可以通过一个简单的查询轻松完成。然而，对于分布式内存数据网格，我们甚至不知道员工对象和部门对象是不是在同一个节点上（除非我们将它们路由到一起，这并不总是最佳实践）。

对于聚集操作来说，这更加困难 - 比方说，我们想要获取所有员工的平均工资，最低工资和最高工资。在SQLit中就像下面这样简单：

    Select avg(salary),min(salary),max(salary) from employees

我们可以尝试让它变得更加复杂，例如，查询每个部门的平均工资：

    Select avg(salary) from employees group by department_id

或者查询平均工资高于X的部门：

    Select avg(salary) from employees group by department_id having avg(salary) > X

我们如何在分布式数据网格中执行这些任务？当数据通过节点进行分区，可以通过map reduce这种方法去实现。 每个节点上都将运行map函数，并且只计算该节点上员工的平均工资，并将结果返回给reducer。 Reducer运行在客户端上，然后把不同节点获得的所有结果进行聚集。这种方法非常高效，因为实际的业务逻辑在服务器端运行（有助于减少延迟），这样我们只用将每个节点的聚合数据返回给客户端（这是少得多的数据）。map reduce方法的缺点是它不像SQL查询那么直观。我们需要创建具有业务逻辑的类来进行操作，这样我们才可以用简单的API或SQL查询来轻松地进行描述查询过程。

理想情况下，我们可以写一个类似于下面的代码：

    query = new SQLQuery(Person.class，"");
    groupByResult = groupBy(gigaSpace，query，new GroupByAggregator()
    .groupBy("department")
    .selectAverage("salary"));

或者更复杂的查询：

    groupByResult = groupBy(gigaSpace，query，new GroupByAggregator()
    .groupBy("department")
    .selectAverage("salary")
    .selectCount()
    .having(new GroupByFilter(){
        @Override
        public boolean process(GroupByValue groupByValue){
           return groupByValue.getDouble("avg(salary)")> 18000;
        }
     }));

总的来说，如果我们想要运行一个操作，比如聚合，我们需要克服使用分布式数据网格的非直观限制。