索引大数据：分布式数据库中的全局索引与本地索引

毫无疑问，大数据的索引和查询是至关具备挑战性的。大数据的特色以高速、价值、多样和大量！100KS更新每秒的速度和TBs的数据扫描，让你不能这样作实时，除非你有坚实的索引！想象一下这些应用程序：

• 旅游应用程序，能让你看到全部航班和酒店的订价和记录！
• 在线游戏，能显示顶级球员的准确记分牌！
• 欺诈检测应用程序，须要看你最近的动态来决定进行信用卡交易是否合法！

这些都是使用状况的查询，须要处理高摄取数据，但不能妥协毫秒的响应时间！若是你不能提供旅游路线、记分牌，或应对实时的诈骗行为，全部的都会关闭！好吧，这听起来好像不太可能，而且你会问：“如何索引和查询这类型的实时数据呢？”

全局索引和本地索引

分布式系统提供两种类型的索引模型：

• 本地索引：在集群中，每一个节点索引的数据在本地上进行。这为快速索引进行了优化。然而随着数据摄取的增长，本地索引维护与传入的工做量，以及集群变大(节点)分散收集的点击查询延迟。想象一下这个查询：“找到8月份十大最活跃用户”

#SQL would look something like this

SELECT customer_name, total_logins.jan_2015 

FROM customer_bucket 

WHERE type=“customer_profile” 

ORDER BY total_logins.jan_2015 DESC 

LIMIT 10;

#index for the query would look something like this

INDEX ON Customer_bucket(customer_name, total_logins.jan_2015) 

WHERE type=“customer_profile”;

这里是在与本地索引群集上执行查询的步骤：

1. 没有一个节点知道答案！所以，分散是须要找出“前10名”在本地的每一个节点上使用的本地索引。
2. 收集得到“前10名”返回到协调节点。　　
3. 最后一步是从新排序，找出真正的前10的活跃用户，结合全部节点的结果，并将结果发送回客户端。

咱们假设这样作超过100节点，你添加了第101个节点！没有得到更快的执行此查询。每一个节点仍然作一样的工做，包括新节点。事实上，损害了101节点查询的延迟!

顺便说一下，许多NoSQL数据库像Couchbase服务器或MongoDB作本地索引。关于本地索引详细信息，可参见Couchbase服务器地图，点这里。

• 全局索引：该指数是独立分区，并放置在节点上的数据。它能够跟上突变的挑战，做为索引的数据须要一个网络访问，而且很是适合查询。想象一下上面相同的查询。该指数如今位于一个节点或两个。

#index for the query would look something like this

INDEX ON Customer_bucket(customer_name, total_logins.jan_2015) 

WHERE type=“customer_profile”

AND continent="Europe";

INDEX ON Customer_bucket(customer_name, total_logins.jan_2015) 

WHERE type=“customer_profile”

AND continent="America";

INDEX ON Customer_bucket(customer_name, total_logins.jan_2015) 

WHERE type=“customer_profile”

AND continent="Asia";

如下是在一个全局索引的群集上执行查询的步骤：　 
　　 
1. 如今咱们知道答案全局索引上的一个节点！因此，不须要分散在这里！咱们只需从索引中检索顶部登陆数 
2. 最后一步是将结果发送回客户端。　 
　　　 
不像前面的例子中的100个节点，你的第101节点如今能够作真正的工做！查询延迟快不少！

全局索引在分布式数据库中不多出现(NoSQL或其余)。MongoDB和Cassandra都没有全局索引。然而，能够在Couchbase服务器下的全局二级索引看到全局索引。Couchbase 服务器GSIS也能够独立部署到集群中的一个单独的区域使用索引服务。这意味着数据服务节点正在作的核心数据操做（插入/更新/删除）不须要在集群的其余部分进行索引。这个部署拓扑称为MDS，你能够在这里了解更多。

在分布式数据库的世界里，重要的是选择索引。不然，查询的延迟多是不可预测的，大数据能够实时查询到不可能的东西！你能够在Couchbase服务器上查看一些添加索引的选项。