Posts about NoSQL databases and Polyglot persistence from Tuesday, 11 November 2014
Strong consistency in Riak 2.0
While we are in the era of specialized databases, tunable solutions are always preferable. As we all know by now, in the land of distributed system one of the most non-trivial decisions, and trade-offs, is between availability and consistency. It’s usually the first that is harder to achieve. But that doesn’t mean that strong consistency cannot be a mandatory requirement for some applications.
Many data needs are better served by data stores that are optimized for maximum availability and scalability — rather than optimized for consistency. For certain use cases, there are elements to the data that require strong consistency. With Riak 2.0, in addition to eventual consistency, there is now a way to enforce strong consistency when needed.
The rest of the post covers how strong consistency buckets work in Riak 2.0. It also lists the current trade-offs:
- read-before-writes
- secondary indexes are not yet supported
- multi-datacenter replication is not yet supported
Original title and link: Strong consistency in Riak 2.0 (©myNoSQL)
Give Me Bare-Metal
Great post by Subbu Allamaraju looking at the significant impact container solutions have on cloud platforms, by providing better resource utilization, improved handling of heterogenous workloads:
What is getting disrupted here is not the core building blocks that advanced cloud platforms provide, but how we’re putting together infrastructure building blocks for agility, efficiency, availability, heterogeneity etc.
Original title and link: Give Me Bare-Metal (©myNoSQL)
This post is a confession of my love for databases and distributed systems
For fear of not ruining it, I don’t want to add anything. Read it and read the top comment on HN.
Original title and link: This post is a confession of my love for databases and distributed systems (©myNoSQL)
via: https://medium.com/@jeeyoungk/why-i-love-databases-1d4cc433685f
ZooKeeper on Kubernetes
What I really like about using kubernetes with ZooKeeper, is that kubernetes will recreate the container, if it dies or the health check fails. For ZooKeeper this also means that if a container that hosts an ensemble server dies, it will get replaced by a new one. This guarantees that there will be constantly a quorum of ZooKeeper servers.
I’m slightly behind with Docker and kubernetes so this is a bookmark to try out later.
Original title and link: ZooKeeper on Kubernetes (©myNoSQL)
via: http://iocanel.blogspot.com/2014/10/zookeeper-on-kubernetes.html
Why Is Exactly-Once Messaging Not Possible In A Distributed Queue?
Marc Brooker and Kyle Kingsbury answer the question in the title. As you’d expect the main complexity resides in offering the only-once guarantee in a fault tolerant system.
Original title and link: Why Is Exactly-Once Messaging Not Possible In A Distributed Queue? (©myNoSQL)