ah-

I can confirm this. Consul is much easier to run in production without issues. Zookeeper is rather picky around disk responsiveness etc.

And the Consul API is rather nice.

Lots of ARM64 changes! Has anyone here tried running OpenBSD on one of the supported boards? How was your experience?

It would be amazing to be able to play with the commands in addition to pressing exactly the keys that the tutorial tells you to press.

Get a demonstration, then try on your own.

Or maybe even include a vim golf game as an exercise? E.g. get to some word in less than four key presses.

What motivated you to start building your own language? Did you use much kdb/q before?

How did you manage to get this open sourced?

How much of it is open source? Can I run my own?

Out of interest, what kind of tooling did you build for Kafka?

Would Prime95 be likely to damage hardware if ran for a prolonged period on aws/gce/azure?

Do they have anything in their contracts telling you not to do that?

No Kafka Streams for Go yet.

And the pine64 is one of the arm64 boards supported by OpenBSD: https://www.openbsd.org/arm64.html

Exciting times in database land! It certainly seems like the good systems are converging on very similar storage architectures. This design is so similar to how Kafka and Kudu work internally.

As the raw storage seems pretty optimal now, I suspect next we'll see a comeback of indices for more precise queries to get another jump in performance.

I think this means that there are e.g. 10 million different time series, that each get a new sample appended every 10 seconds.

From looking at their examples and interfaces, it's clearly for simple, small scale processing.

I wonder where the bottleneck was. Right below that result they have the performance plot that shows how it used up almost no CPU or network bandwidth. I'd expect S3 to be faster than this?

FWIW, I've been playing with parquet and Kudu lately and on a reasonably sized single machine you can run similar queries on similar scale data in <5 seconds.

Please someone port this to Kubernetes.

Thanks!

I'd love to see a bit more of monocular without having to install it. Do you know if there are any screenshots, blog posts or even a demo instance?

Can you elaborate a bit on what this actually means?

How would I use it? How does a query look like?

I like it a lot!

Does the duration include travel time? I'm in London and it suggests flying to India and Peru for a 3 day weekend trip. I'd be nice to see how much time you'd actually have at the destination, given a certain amount of days off, especially for short trips.

I had the same happen to me while using a cheap ebay charger. Never happened with a genuine one.

There's an interesting post about the internals: http://www.righto.com/2015/11/macbook-charger-teardown-surpr...

Even better, you can build shady counterfeit circuits yourself that happen to pass the test cases but don't really do what the customer requested.

This needs a vim mode.

I'm not sure if it was the case when the article was written, but the REST proxy is open sourced now: https://github.com/confluentinc/kafka-rest

Kafka gives you vastly better delivery guarantees than the common ActiveMQ brokers.

If you put a message into Kafka and have it configured correctly, it will come out on the other end at least once. This is not the case for most of the competitors.

This needs a [2015]. Back then there wasn't a single usable client for .net.

Since then the non-Java clients have massively improved. In particular https://github.com/edenhill/librdkafka is fantastic. There's also https://github.com/dpkp/kafka-python/, with support for consumer groups and all the other modern features.

The basic criticism of requiring a complex client is valid, however you cannot achieve the delivery guarantees that Kafka gives you without one. The alternative would be to have a local agent process like consul, but that wouldn't give you the throughput that Kafka gets.

Disclaimer: I've built a C# client for Kafka based on librdkafa (https://github.com/ah-/rdkafka-dotnet), so I'm biased.

You can use event logs and eventual consistency to solve this problem.

Basically you make the transfer of money an event that is then atomically committed to an event log. The two bank accounts then eventually incorporate that state.

See http://www.grahamlea.com/2016/08/distributed-transactions-mi...

But I agree that often life is easier if you just keep things simpler. If you require strong consistency like with the user/profile don't make that state distributed. If you do make it distributed you need to live with less consistency.

It would be nice to include installation instructions.

Thanks. So it's building a hash tree with deterministic chunking and that means you can cheaply update the hash after updating parts of the tree as you only have to rehash certain bits?

Does that mean that your chunk sizes are kind of fixed? Do you think there's a way to retain that advantage and be able to coalesce smaller chunks into larger ones?

Say your smallest nodes are 4KB but for more efficient storage you might want to go up to 4MB chunks. Could that be done while retaining the same hash for the same underlying data?

Can you elaborate a bit on how the hashing and chunking works? There's a rolling hash for determining chunk boundaries, and also SHA-512/256 somewhere.

Does the same data chunked differently have a different hash?

It'd be fantastic to combine something like noms with https://arrow.apache.org/ and then use Spark/Drill/Impala to query it.