Pilosa 最初是为分析用户属性数据（稀疏并且高基数）而准备的。所以当我们准备围绕 Pilosa 创建一家公司时，第一步就是评估在其他类型数据上的效果。

虽然用户细分的属性数量非常多，但数据却非常稀疏，这是因为很多属性只与少数人相关联，大部分人只有几百个或几千个属性。 Pilosa 可以非常优雅地处理这种场景，它能够在几毫秒内筛选数百万个属性的任意组合，从而找到满足该条件的用户。

图片由 Umbel 提供

对于用户细分数据，我们可以使用 Pilosa 处理这类问题。然而，如果我们希望 Pilosa 成为通用索引，那么它将不仅能支持分段查询而且不仅再稀疏而高基数的数据上工作。

为了测试 Pilosa，我们需要一个具有密集的，较低基数的数据集，并最好是能通过其他解决方案进行探讨，以便评估我们如何处理该问题。

纽约市政府开放的十亿出租车搭乘数据集（下载请参阅文末链接 4）完美符合以上条件，有很多分析该数据的文章，下面列出的仅仅是少数几个链接：

（译者注：数据集中包含上下车时间、地点、距离、车费、支付方式、乘客人数等字段）

• Analyzing 1.1 Billion NYC Taxi and Uber Trips, with a Vengeance [1]
• Kx 1.1 billion taxi ride benchmark highlights advantages of kdb+ architecture [2]
• Should I Stay or Should I Go? NYC Taxis at the Airport [3]

对我们特别有用的是 Mark Litwintschik 和他编制的性能比较表的系列文章，这是结果表格供参考，其中分别使用了 Spark, PostgreSQL, Elasticsearch 等数据库来查询。

我们对 Pilosa 执行了相同的四个查询，以便我们可以同其他解决方案的性能进行比较。

以下是每个查询的描述：

1. 每个司机搭乘了多少位乘客？
2. 对于每位乘客来说，打车平均花多少钱？
3. 每一年，每位乘客会打几次车？
4. 对于不同乘客人数，年份，旅行距离的组合，乘客数量有多少，结果按年度乘客数量降序排列。

现在我们有一个数据集和一组查询，都远远超出了 Pilosa 的最适合做的领域，以及对不同硬件/软件组合的长期性能对比。

如果您想了解如何在 Pilosa 中建模数据集并构建查询，请参阅我们的运输用例文章 [6]。

现在我们并非只有数千万的 boolean 属性，其中一些属性具有更复杂的类型：整数，浮点，时间戳等等。总而言之，相比之下这个数据集更适合用关系型数据库。

我们在 AWS c4.8xlarge 实例上架起了一个 3 节点的 Pilosa 集群，并附加了一个 c4.8xlarge 实例来加载数据。我们使用 pdk 工具将数据加载到 Pilosa 中，使用以下行参数：

pdk taxi -b 2000000 -c 50 -p <pilosa-host-ip>:10101 -f
<pdk_repo_location>/usecase/taxi/greenAndYellowUrls.txt

这个过程需要大约 2 小时 50 分钟，其中包括从 S3 下载所有的 csv 文件，解析它们，并将数据加载到 Pilosa 中。

如果我们将结果添加到 Mark 表中，它将如下所示：

请注意，每个组合的软硬件都不同，所以直接比较是很困难的。

我们应该注意到，Pilosa 在“查询1”上有一些“作弊”（由于其存储数据的方式，Pilosa 已经预先计算了此结果），因此查询时间大部分是网络延迟。

然而，对于其余的查询，Pilosa 表现非常出色 – 在某些情况下，可以胜过异构硬件，如多 GPU 配置。查询3 的 0.177s 时间特别令人吃惊，与 Nvidia Pascal Titan Xs 的表现相似。看起来 kdb+/q 也很好，但是请记住，Xeon Phi 7210 每个芯片有 256 个硬件线程，以及 16GB 的内存。这使它们的性能和内存带宽更接近于 GPU。当然价格也很贵，约 2400 美元。

对于我们来说，这些结果足以让我们花费更多的时间优化 Pilosa 用于其他方面。由于 Pilosa 的内部位图压缩格式没有针对密集数据进行优化，我们在这方面进行了更多的研究，并获得了令人振奋的结果，所以我们有理由认为这些数字还有很大的改进空间。

原文来自：

本文地址：//lrxjmw.cn/dba-pilosa.html编辑员：姜显赫，审核员：逄增宝

本文原创地址：//lrxjmw.cn/dba-pilosa.html编辑：圆蛋，审核员：暂无