是否可以接受有许多基于"WHERE"的听众

Question

我正在研究一个实现，我需要有效地侦听以下伪查询：

SELECT * FROM 'trips' WHERE 'travelers' IS ONE OF [ x,y,z ]

由于 firebase 不允许 OR 查询，我目前的解决方案是创建旅行 x 旅行者的所有可能排列并聆听所有这些排列。

// Returns an array of {}
const permutations = ( locs, uids ) => {
    let perms = locs.map( location => {
        return uids.map( uid => ( { location: location, uid: uid } ) )
    } )
    return [].concat( ...perms )
}
// Trip destinations
let destinations = [ 'Amsterdam', 'Berlin' ]
// UIDs of travelers (in reality unique hashes)
let uids = [ 'John', 'Mary' ]

// Listeners
return Promise.all( permutations( locations, friends ).map( ( { location, uid } ) => {
        this.db.collection( 'trips' )
        .where( 'destination', '==', location )
        .where( 'traveler.uid', '==', uid )
        .onSnapshot( snapshot => {
            Promise.resolve( snapshot.docs )
            // Filter out empties
            .then( docs => docs.map( doc => doc.exists ? doc : false ) )
            .then( docs => docs.filter( doc => doc != false ) )
            // Grab data from docs
            .then( docs => docs.map( doc => ( { ...doc.data(), id: doc.id } ) ) )
            // Call a callback (used int he bigger scheme of a redux listener)
            .then( callback )
        } )
    } ) )
} )

现在这会导致一些侦听器，但如果目标/uids 数组变大，这可能会导致大量侦听器。

我也可以运行手动搜索触发器，但我喜欢使用实时更新。

在Firebase中拥有潜在的大量听众是一个问题吗？无论是性能还是成本？

Answer 1

你必须更具体地了解"bazillion"。 一般来说，听众很便宜，你不应该太担心它。 但一切都有实际限制，我想当你接近你假设的"bazillion"时，你会发现那是什么。

1 个侦听器调用的计费与 10 个、100

个或 1000 个侦听器没有任何不同。 可以预期单个侦听器的计费会线性扩展。 对于每个文档，每个文档的成本都与通常自己的成本完全相同，而每个文档在其所有查询之间都不同。

每个列表器还共享一个连接，因此您不必担心打开的文件描述符或类似的东西用完。 实际上，您的限制将是内存和带宽。