Since I wrote this post, a lot has changed for BigchainDB and in the blockchain space broadly, so it seemed high time for a revisit and refresh of what effect blockchain can have on one of the more fundamental parts of the traditional computing space: data storage.
Originally built as a technology to replace the Bitcoin blockchain in the Ascribe digital artwork tracking project, BigchainDB expanded into a component of the abandoned IPDB and now as a storage layer for the bold Ocean protocol.
This change in use caused changes to the underpinnings and implementation of BigchainDB, as did the closure of RethinkDB, forcing the team to switch the storage engine to the stalwart MongoDB. The blockchain layer on top of the database that provides the transactional support that helps guarantee a database change has taken place and adds additional control and security remains, but has gained maturity, with BigchainDB set to hit 2.0 in 2018.
All these changes now mean that BigchainDB encourages you to use their public network instead of deploying your instances. This approach is somewhat counter to traditional distributed database practice, but is more in-fitting with the evolution of Blockchain-based projects over the past few years, helps BigchainDB monetize their platform (with an ICO or SaaS model) and is an interesting change. Time will tell if customers are comfortable with storing data in a public network, but with access tokens ensuring security and privacy, it’s conceptually not too dissimilar from using a cloud-hosted database.
If you want, you can still install your own BigchainDB instances, but I feel the company will increasingly encourage you not to.
Whichever option you take, you can then use the official Python, JavaScript or community drivers. For example, with JavaScript, install the package with npm install bigchaindb-driver, create a connection and write and read assets to the database using appropriate keys for the writer and reader.
The post BigchainDB: Blockchain and Data Storage appeared first on SitePoint.
by Chris Ward via SitePoint
