只是想知道Parquet谓词下推是否也适用于S3，而不仅限于HDFS。具体来说，如果我们使用Spark（非EMR）。
进一步的解释可能会有所帮助，因为它可能涉及对分布式文件系统的理解。
我有一个mongodb碎片,有2个碎片(比方说A和B),每个碎片有17GB的可用空间.我将包含对象ID的_id设置为分片键.
以下是用于设置db和collection的命令.
sh.enableSharding("testShard");
sh.shardCollection("testShard.shardedCollection", {_id:1});
然后我尝试向mongos服务器发出4,000,000次插入查询.我执行脚本4次以下.
for(var i=0; i<1000000; i++){
db.shardedCollection.insert({x:i});
}
使用_id作为分片键,根据我的理解,所提到的4000000文档将适合1个分片,所有插入仅在分片中发生.
然而,结果并不像我预期的那样,在一个碎片中插入了大约1,300万个文件,在B碎片中插入了另外~270万个文件.
为什么会这样？是否在分片设置命令中缺少某些内容？或者我的理解是错误的,也许在mongodb中有类似默认范围的分片键？
如果有人可以共享默认范围分片键的行为(没有标记识别),将会非常有帮助.
下面是sh.status()结果
shard key: { "_id" : 1 }
chunks:
B 5
A 5
{ "_id" : { "$minKey" : 1 } } -->> { "_id" : ObjectId("540c703398c7efdea6037cbc") } on : B Timestamp(6, 0)
{ "_id" : ObjectId("540c703398c7efdea6037cbc") } -->> { "_id" : ObjectId("540c703498c7efdea603bfe3") } on : A Timestamp(6, 1)
{ "_id" : ObjectId("540c703498c7efdea603bfe3") } -->> { "_id" : ObjectId("540c704398c7efdea605d818") } on : A Timestamp(3, …假设我有交易数据和访问数据
visit
| userId | Visit source | Timestamp |
| A | google ads | 1 |
| A | facebook ads | 2 |
transaction
| userId | total price | timestamp |
| A | 100 | 248384 |
| B | 200 | 43298739 |
我想加入交易数据和访问数据来做销售归因。我想在交易发生时实时进行（流式传输）。
使用 Spark 中的 join 函数在一个数据和非常大的历史数据之间进行连接是否具有可扩展性？历史数据是访问，因为访问可以是任何时间（例如访问是交易发生前一年）
我有一些分片收藏.它们的大小在MongoDB 2.4.11中介于50-90MiB之间.根据文档的默认块大小为64MB.
当我使用下面的命令检查块分配时,
db.getCollection(collName).getShardDistribution()
它表明了这一点
一些大小低于64MB的集合已被分成几个块.
data : 58.13MiB docs : 148540 chunks : 2
estimated data per chunk : 29.06MiB
estimated docs per chunk : 74270
一些大小为x且64MB <x <128 MB的集合具有2个以上的块.
data : 98.24MiB docs : 277520 chunks : 4
estimated data per chunk : 24.56MiB
estimated docs per chunk : 69380
这种行为有望吗？这是怎么发生的？
需要对维度建模或星型模式有所了解.
通常,当我们设计数据仓库时,我们将有事实表和维度表.
但是,在事实表中嵌入维度确实有意义.特别是对于没有其他属性且很少改变其价值的简单维度.
事实表中的维度将使查询运行得非常快,无需单独维护维度表,在执行ETL时无需查找维度表.
有没有考虑将尺寸与事实分开？