krenoten

11 ms·

61.
by krenoten 11y ago
This is one of the most exciting DB's coming into the world, and I've had a lot of fun watching progress from the sidelines! Keep kicking ass!
62.
by krenoten 11y ago
this is rarely a concern for things that are ephemeral in nature to begin with. it's also a 20 line code change to add a similar ttl buffer into memcached.
63.
by krenoten 11y ago
redis is single threaded, so 32 cores doesn't mean much without sharding. I generally prefer memcache unless you have a super locked-down infrastructure (no engineers to deploy a KEYS operation that destroys a shard and all the systems
64.
by krenoten 11y ago
> Generally any program that can handle a suspend and resume can handle being persisted across reboots. This is not the case for very many of my processes. Are you suggesting DMTCP or something? That won't work with most of the st
65.
by krenoten 11y ago
Badass! This would have saved me about a week of my life if it had come a few years ago!
66.
by krenoten 11y ago
Prometheus is for smaller problems. You have to manage your own sharding with prometheus, so it doesn't work for handling large volumes of data unless you are willing to do complex automation for a large number of disparate replicatio
67.
by krenoten 11y ago
The price performance curve is bad at low traffic, but pretty good compared to most other things out there at the higher end of things.
68.
by krenoten 11y ago
I love OpenTSDB, but I think it's highly unusual for people to have "absulutely no issues at all". I ran OpenTSDB at the hundreds of thousands to low millions of ops per second range for several years. OpenTSDB has historic
69.
by krenoten 11y ago
It depends how much time you have to burn, and how much traffic you handle. If you have trivial scaling needs or want to spend 10x the human time managing that setup, then go ahead. You use something like opentsdb when you have hundreds o
70.
by krenoten 11y ago
They have mostly moved away from it.
71.
by krenoten 11y ago
http://unix.stackexchange.com/questions/127001/linux-lxc-vs-...
72.
by krenoten 11y ago
That's pretty hand-wavey. All databases can be made to lose all guarantees under failure conditions.
73.
by krenoten 11y ago
Redis is single-threaded, so everything it does on a per-node basis is implicitly atomic. You can also force the single thread to handle a block of commands from a single socket at once by using MULTI (otherwise commands can be interleaved
74.
Hierarchical Delta Debugging(blog.acolyer.org)
1 points by krenoten 11y ago|0 comments
75.
Simplifying and Isolating Failure-Inducing Input(blog.acolyer.org)
1 points by krenoten 11y ago|0 comments
76.
Hardening Kubernetes on the DCOS with etcd-mesos – Mesosphere(mesosphere.com)
1 points by krenoten 11y ago|0 comments
77.
by krenoten 11y ago
This is a pretty balanced article. Absent is Nomad, which claims the world but when you dig into the code pretty large advertised chunks are simply not there yet. Nomad seems like a much more straightforward implementation of the Borg paper
78.
by krenoten 11y ago
That link isn't working for me, unfortunately. I'm assuming that the HOL you're referring to stems from the assumption of the default DRF allocator of fast decisions, which can cause issues for mixed workloads if there'
79.
by krenoten 11y ago
Mesos is a two-level scheduler, where the elected master is more of a broker for offers from agents to external schedulers that decide to act on the offer or not. By default it's pessimistic, but this is pluggable and there's no
80.
by krenoten 11y ago
Modern operating systems are better at handling many threads.
81.
by krenoten 11y ago
It was a terrible idea with old OS's and engineers never learned about their schedulers. Many of your favorite systems run at high frequencies on Varnish using one thread per session.
82.
by krenoten 11y ago
It's like many things that are declarative - you can only do what has been explicitly enabled in the declaration handling logic. This is good and bad. It's good because it restricts what is possible (protecting you slightly more
83.
by krenoten 11y ago
Kubernetes is very much still under development. Most of the work up to 1.0 has gone into refinement of the API, rather than stability. For instance, HA is only now being seriously worked on - and if your API server goes down and you need
84.
by krenoten 11y ago
https://syslab.cs.washington.edu/research/specpaxos/
85.
by krenoten 11y ago
TLA+ model checking and an implementation that follows the spec as closely as possible.
86.
by krenoten 11y ago
Raft has a dirty little secret: your cluster breaks when two nodes become partitioned from each other (but not the rest of the cluster) and one of them is the leader. Script: nodes {1, 2, 3*} where 2 and 3 are partitioned, and 3 is the curr
87.
Satellite – monitoring, alerting, and self-healing for Mesos(github.com)
1 points by krenoten 11y ago|0 comments
88.
by krenoten 11y ago
Have any of the popular Haskell libraries for building distributed systems seen high-scale production use for more than 5 years?
89.
by krenoten 11y ago
No system can achieve 100% consistency and 100% availability in the presence of partitions. It's kind of wacky that Aphyr compared those replicated consensus tools and eventually consistent stores with HBase. HBase does not use a con
90.
by krenoten 12y ago
Yes, please do look at them, because Google, Facebook, Twitter, Yahoo, and eBay use MySQL pretty heavily for many of their core storage needs (look at the contributor list for WebScaleSQL). Spotify uses Postgres for the same. All of them

More ›