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 )
        } )
    } ) )
} )

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

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

Firebase是否有潜在的庞大读者群？是性能还是成本？

Answer 1

您必须更具体地说明“兆兆”。通常，听众很便宜，您不必为此担心太多。但是，一切都有实际的局限性，我认为当您接近假设的“惊人”时，您会发现那是什么。

1个侦听器不会调用与10个或100个或1000个侦听器不同的计费方式。您可以期望单个侦听器的计费能够线性扩展。每个文档的成本都与正常情况下的成本完全相同，因为每个文档的查询之间都不同。

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

有很多基于“ WHERE”的监听器是可以接受的

1 个答案: