毫无疑问,大数据的索引和查询是相当具有挑战性的。大数据的特点以高速、价值、多样和大量!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”;
这里是在与本地索引群集上执行查询的步骤:
- 没有一个节点知道答案!因此,分散是需要找出“前10名”在本地的每个节点上使用的本地索引。
- 收集获得“前10名”返回到协调节点。
- 最后一步是重新排序,找出真正的前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服务器上查看一些添加索引的选项。