What do you mean exactly? It is designed to run across multiple nodes, preferably out of multiple datacenters that don't have common points of failure (network connectivity, power).
But it is designed to run on systems that you control, as opposed to some other peer-to-peer systems.
It's going to be P2P nodes I control. The idea is to do IOT logging of data and put it into a DB to query everything basically. That's the long and short of it at least.
I don't think CockroachDB will be a good fit for your application.
The nodes expect constant network connectivity, they're talking to each other every few milliseconds. You want a very fast and reliable network.
For logging, some sort of store and forward architecture may be better. I don't think the level of consistency provided by CockroachDB would be necessary.
Well, the basic design of Cockroach (assuming no bugs) prioritizes consistency over availability, which means that your data should be safe even if the network is misbehaves arbitrarily. So the really interesting question is, how much availability can you expect?
"Mesh network" implies that the network should reconfigure itself if individual nodes or links fail. That's fine, but it will necessarily take some time to detect a failed connection, which means temporary unavailability while the database performs a leader election. CockroachDB is sharded, so if any single shard loses a majority of its nodes or becomes too badly partitioned, that shard becomes unavailabile until the network is restored. There's a tradeoff here -- if you're willing to accept slower performance, you can increase the number of replicas per shard.
(It's also interesting to think about what happens under heavy load. If the Cockroach daemons are handling requests as fast as they can, then whatever daemon is responsible for the mesh routing decision-making could become starved for CPU, leading to high packet loss or intermittent network partitions.)
This ends up being a surprisingly helpful tutorial on caveats and workarounds with Golang and CGO. In addition to being curious about CockroachDB, I've also been curious about compiling from source with CGO based apps in Golang. Thanks!
This looks like a perfect addition to my home lab - I have a few PIs lying around doing nothing (I know, shame on me) and running a distributed DB would be great to attach to a container-based network.
14 comments
[ 2.2 ms ] story [ 36.7 ms ] threadBut it is designed to run on systems that you control, as opposed to some other peer-to-peer systems.
The nodes expect constant network connectivity, they're talking to each other every few milliseconds. You want a very fast and reliable network.
For logging, some sort of store and forward architecture may be better. I don't think the level of consistency provided by CockroachDB would be necessary.
"Mesh network" implies that the network should reconfigure itself if individual nodes or links fail. That's fine, but it will necessarily take some time to detect a failed connection, which means temporary unavailability while the database performs a leader election. CockroachDB is sharded, so if any single shard loses a majority of its nodes or becomes too badly partitioned, that shard becomes unavailabile until the network is restored. There's a tradeoff here -- if you're willing to accept slower performance, you can increase the number of replicas per shard.
(It's also interesting to think about what happens under heavy load. If the Cockroach daemons are handling requests as fast as they can, then whatever daemon is responsible for the mesh routing decision-making could become starved for CPU, leading to high packet loss or intermittent network partitions.)
Is it possible to get CDB to exfiltrate it's data into a single node or another cluster of nodes?
Poorly.