C'è una ragione per cui Cassandra non ha il supporto geospaziale?

Question

Dal momento che Cassandra si basa sulla carta Dynamo (tabella hash distribuita, autoequilibrante) + BigTable e ci sono indici spaziali che si adattano bene a quel paradigma (quadkey o geohash). C'è una ragione per cui il supporto di Geospatial non è stato implementato?

È possibile aggiungere un tipo di dati GeoPoint come tupla con geohash interno e specificare un CF come contenente dati geografici. Da lì puoi scegliere il comportamento in base al fatto che i dati geografici sono un indice secondario o un SCF denormalizzato. Ciò potrebbe gettare le basi per lo sviluppo geospaziale e si potrebbe iniziare implementando alcuni frutti a basso impatto come .nearby() che potrebbero semplicemente restituire colonne che condividono lo stesso geohash. (So ​​che non ti darebbe il "più vicino", dovresti fare una passeggiata di geohashes circostanti o usare una forma e una curva di riempimento dello spazio per quella che potrebbe essere implementata in seguito, ma è un'operazione generale per trovarne alcuni colonne vicine)

So che SimpleGeo/Urban Airship ha costruito il supporto geografico in Cassandra, ma non sembra che sia mai stato aperto. Inoltre, fammi sapere se c'è un posto migliore per chiedere questo (quora, mailing list, ecc ...)

Answer 1

Penso che ci siano due parti per la risposta.

Il motivo per cui non è lì, è perché nessuno che ha commesso il codice in Cassandra ha pensato a questa funzione, o ha pensato che questa capacità abbia una priorità sufficientemente alta da passare molto tempo su di essa. La maggior parte dello sviluppo in Cassandra è fatto da Datastax e, essendo un'entità commerciale, sono al corrente delle richieste e dei suggerimenti degli utenti e sono anche piuttosto pragmatici su ciò che può dare loro il ROI in termini di nuove funzionalità.

Se ci fosse abbastanza sviluppatore di terze parti (o una squadra) con abbastanza tempo a disposizione, ciò potrebbe essere fatto, e concettualmente i commissari C * probabilmente non avrebbero problemi ad aggiungere una caratteristica importante come questa.

Il secondo aspetto è che Cassandra supporta BLOB (array di byte), il che significa che ciò che stai descrivendo può essere implementato nell'app/driver del client in modo relativamente semplice. In tal caso, l'unità sarà responsabile della traduzione delle chiamate geografiche in operazioni di byte raw appropriate. Sospetto anche che sarebbe meno lavoro che supportare una nuova primitiva di dati con un gruppo rilevante di operatori nel motore di archiviazione di base.