agacera

I use and recommend metabase and redash. Metabase is more polished and easier for business folks. But redash supports more data sources (hive for instance).

Both are open source and in my opinion can fill about 80% of dashboards and ad hoc analysis for a small to medium company. The other 20 % your company must be rich enough to buy Tableau or rich enough to build its own solution.

https://www.metabase.com https://redash.io

hey, Kile. Thanks for the awesome work you do.

completely off-topic: have you ever thought about giving your training (https://jepsen.io/training) in an online way (mooc, udemy, whatever)? I would love to learn about distributed systems from you, but today I think it would be almost impossible since you only seems to give in organization trainings.

Confluent only officially supports the Java client (and now has a Python, Go and .Net clients as well that I didn't know) and it is really recommended to use the client with the same version of broker due to protocol incompatibilities.

Most Kafka client implementations are open-source projects of their own, this is also true for most redis clients implementations, but again: Kafka protocol is much more complicated than Redis.

I haven't used Kafka with other languages besides Java or Scala, so I can't really say how mature are the other clients.

But my point about how easy is to implement a client for Redis if needed is still valid. =)

I can think in some circumtances: 1 - You already have a Redis infrastructure and don't wanna or don't have resources to deploy a full Kafka infrastructure (3 kafka brokers + 3 zookeeper nodes)

2 - Kafka clients are not available (or are poorly available) for every programming language. Redis has a simpler protocol, so it has more/and better clients available and even if you use an exotic language, it is easy to write a client to it (well... easier than Kafka)

3 - Kafka AFAIK does not have any internal cache implementation, so every read is served from disk (+ page cache). This means that Redis Streams will (probably) perform much better for use cases when the consumers need to fetch data from old offsets.

edit: added reason number 3.

Probably it is needed to check if the row is still visible to that transaction.

in the beginning of September a chinese guy was arrested for selling VPN software. you can try ways to bypass the great firewall, but it is against the law to do that, and in China it is a good idea to follow the law.

http://thehackernews.com/2017/09/china-vpn-great-firewall.ht...

If you are already invested in Redshift this is a really nice feature to have.

I used to work in an environment where only data for the last few months was stored in Redshift (to save costs since storage is expensive). Whenever someone need old data, we need to make room for it unloading tables to S3. Now this is not needed anymore, and is is awesome.

Another nice reason is that some BI tools doenst work with Athena (and PrestoDB) yet (Metabase and Pentaho for instance), so it is now viable to use Redshift to expose data inside S3 to these tools.

If you are already invested in aws I suggest you to use the firehose + s3 to store data and use the Athena to query it.

Postgresql is awesome, best open-source RDBMS by far, but MSSQL is more advanced. This is expected since hundreds of developers are being paid by Microsoft to work full-time on it.

For OLAP use cases it is years ahead of Postgres.