Free Riak database acts like depressed teenager to assure data reliability
Version 1.3 constantly interrogates itself to make sure data is ok
Basho's NoSQL Riak database has been given an upgrade that makes it question its own integrity at all times – a tedious trait in people, but a handy one for assuring data preservation in massively distributed information stores.
The "active anti-entropy" feature in Riak 1.3, which was released on Thursday, means the open source database will constantly interrogate key-value data stored in multiple locations to repair divergent, missing, or corrupted replicas.
Previously, Riak checked up on the health of data during read requests. Administrators could also issue a repair command via the Riak Console, which would fix all data in a specific partition. But that depended on knowing that data in a certain partition was outdated – "not super-viable for large deployments," Basho director of product management Shanley Kane told The Register via email.
Active Anti-Entropy, by contrast, runs in the background.
"Having things running in the background also detects problems sooner, which not only repairs problems sooner but also allows repairs to happen incrementally over time versus, say, only verifying data once a week and repairing lots of data in bulk," Kane said.
By running in the background, anti-entropy can be particularly useful for maintaining cold data – that is, data that is not likely to be read for long periods of time, Kane said.
Anti-entropy works by determining the difference between bits of data via a hash tree exchange. This means the amount of information exchanged during Active Anti-Entropy interrogation is proportional to the differences between two replicas.
The hash trees are stored as persistent entities in LevelDB instances outside the standard Riak key-value data. Trees are expired and rebuilt once a week to protect against the hash diverging from the underlying data, and trees are updated whenever a write is sent to the Riak-stored data.
Along with the entropy feature, IPv6 support has been expanded to the protocol buffer interfaces and some parts of Riak's data transfer component. Also, the Riak Control management software has been given a polish to give developers that 'new iterative release feel'. The update to the database is available via Basho's Github page.
Swanky multi-data center replication for enterprises with cash
Riak Enterprise, a paid-for version of the Riak database that Basho develops for large businesses, has received an update as well, in the form of "Advanced Multi-Datacenter Replication Capabilities."
The technology makes it easier to replicate information between multiple data centers without suffering a huge latency hit.
This is one of the trendier features to implement in a database at the moment, and follows TransLattice adopting a similar technology for their cloud-based tech.
Riak 1.3 updates the paid-for Riak Enterprise product's "Advanced Multi-Datacenter Replication Capabilities."
This upgrade give administrators the option of streaming data from one cluster to another over multiple TCP connections – the number of which tops out at around one per physical node – where previously you could only use one TCP connection per cluster, which could create performance bottlenecks.
"The new replication improvements are already used in production by customers and yielding significant performance improvements," Riak said. "For now, the new replication technology is available in advanced mode: it’s optional to turn on."
However, the technology does not yet support SSL, NAT, or full-sync scheduling, so organizations with thorough security policies may have to do a bit of extra work to use the feature.
"Our expectation is that most enterprises will already have trusted transport layer security solutions in place, but adding SSL to the advanced mode is one of our top priorities," Kane said, and indicated SSL support should come along in May.
Riak Enterprise pricing starts at $6,000 per node, and discounts are available as the number of nodes increases. ®
"...database acts like depressed teenager..."
Just what we need. A database that replies to queries in monosyllables, uses the floor as a.storage area, refuses to operate before midday and is unable to carry out its own garbage collection.
Sometimes they do turn out OK in the end, though.
Re: Addressing the symptoms, but not the cause?
(Note: I work at Basho (makers of Riak), and was the lead developer on this new Active Anti-Entropy feature.)
Riak is a database. You put data in, you get data out. There are no inherent inconsistencies in Riak, nor any built-in symptom that needs to be repaired.
Yes, Riak is an eventually consistent database, rather than a strongly consistent database. The AP option rather than the CP option from CAP. But, this has nothing to do with durability or data safety. AP vs CP determine the types of applications that a given database can support. Certain applications can tolerate eventual consistency and can use Riak, others can't and should use another database. Or wait until Riak supports strong consistency in addition to eventual consistency later this year.
The new Active Anti-Entropy (AAE) feature has nothing to do with eventual vs strong consistency. It's a self-healing feature designed to address hardware failure and other scenarios outside the control of the database. It's similar to RAID, but built into your database.
Riak is a fault-tolerant, replicated database. When you write data, it's stored to multiple machines (3 by default). Thus, you can lose machines and still have readable replicas. If a machine fails, you're going to end up with missing data (replace failed hardware w/ new, empty hardware) or divergent data (replace + restore from recent, but not 100% current backup). When you read an object, the request will be sent to all replicas, returning the non-missing/non-divergent (ie. correct) data. Riak, however, notices that one of the replicas is missing or divergent and asynchronously repairs it from the data on the other replicas.
The issue with this approach is that data is only repaired on reads. The new AAE feature augments this approach to provide a lightweight background process that's constantly verifying replicas and repairing things as necessary. Thus, even cold data that is never read is verified and repaired. The aim is to make sure all data is repaired before any other nodes fail. Sure, multiple failures could happen before everything is repaired and you're toast. This is no different than any other database (log replay/recovery) / RAID. There's always a chance additional disks will fail while you're in the process of rebuilding your RAID array. It's just statistically rare enough that we can all still sleep at night.
In any case, AAE isn't designed to solve an inherent problem with Riak. It's designed to help regenerate your data when hard drives, nodes, etc fail. It's also designed to detect silent data corruption (faulty hard drive / controller), an issue that effects all databases.
In short, AAE is similar to the protection provided by triple-mirrored ZFS, but at the node rather than hard drive level. ZFS maintains a hash tree for all data stored in the filesystem. On every read, the replicas are verified against the hash stored elsewhere on disk. If there's a mismatch, the bad replica is repaired from replicas on the other disks. As was famously discussed around the time ZFS appeared on the scene, this helps protect against silent data corrupt / bit rot (eg. when your hard drive, disk controller, etc corrupt data w/o any indication). The problem is that this verification only happens when data is read, thus cold data is never checked. The solution: a cron job that runs 'zfs scrub' periodically to verify all data on disk. Riak has similarly always done a verify/repair check on every read. The new AAE feature adds a smart, lightweight 'zfs scrub' equivalent that continuously verifies all data all the time.
Riak is designed to be an operations-friendly, fault-tolerant database. A database designed to easily scale-out as needed, that can tolerate multiple node failures and network partitions (eg. switch failures / split brain scenarios). Adding built-in self-healing / protection against silent data corruption from faulty hardware was a logic next step. Of course, Riak is a harder database to develop for, requiring eventually-consistent tolerant algorithms/designs. But, that's the great part about the "new database" or so-called NoSQL (*cringe*) movement: there's different products for different use cases. As a co-worker of mine use to say, thesedays databases are like D&D classes: use the right one for the quest; sometimes you need a rogue, other times a mage is best.
(Big Brother, cause AAE is watching your data...)
Addressing the symptoms, but not the cause?
A database that needs an agent bolted on to fix "divergent, missing, or corrupted " data doesn't sounds like a database I'd want to rely on in the first place.
It implies the failures don't matter in the period before the agent gets round to fixing them.
And it implies the agent will have a 100% success rate in fixing things.
But maybe I'm more fussy about my data that their users?