Where should I store GPS (or other frequently changing, content searchable data on Ethereum)? Blockchain is not the best place for this kind of data, because it is expensive, but swarm is not searchable (as I know). So, if I would like to write an Uber like service on Ethereum, where I have to find the nearest points near real time, what would the best storage option?
3 Answers
Hmm.. you should seriously research Ethereum alot more before proposing this. because it is expensive
does not begin to describe how expensive and slow this will be if you wrote all your GPS data to Ethereum.
Here's a simple string of 1 GPS location data
$GPGGA,053855.33,3756.9296,N,12737.8335,E,3,08,0.0,0.0,M,0.0,M,0.0,0000*74
Let's make a simple contract to store this: https://ethfiddle.com/rM9HRNhsF8
So storing that single string costs roughly $0.021 USD. And you wanted to do this frequently for thousands of users....?
Hate to be the guy to tell you no, but what you really need is an application-specific sidechain running on Ethereum and not running your DApp on Ethereum itself.
-
1
You'd want to use logs most likely. The costs for storing log information is much much cheaper.
-
Ty. Log is a better place like the blockchain, but is it a good place for highly changing data? For example 1000s of users, whose change GPS coordinates in every minutes. If every changes are stored, the log would be really big after some weeks or months.– FazOct 1, 2017 at 21:32
-
1I feel that using the Blockchain to store such huge amounts of data doesn't really make sense. The cost would be prohibitively expensive! Plus the blockchain isn't really meant to be used like a database. Hence it might be better to use IPFS/Swarm to store the data, and add the IPFS hash to the smart contract as a record-keeper. Here's a great guide github.com/kggp1995/IPFS-Ethereum-Storage to help you understand how to leverage IPFS to amplify the power of the blockchain for storage. Jul 10, 2018 at 16:11
With the little info I have, I'd say the best place to store such data would be off-chain. Why do you need to store every reading for each user on the blockchain?
Do you need to store all the historic data? You could possibly just store the latest reading for each user and log each reading through events for easier access.
You could possibly refrain from storing each and every reading on-chain. How about just storing, say one reading per hour on-chain and using a "regular db" for storing every reading.
In an Uber scenario, you could store the pick up and drop off coordinates on-chain and then the rest of the readings off-chain.