HN user

moatra

28 karma
Posts0
Comments16
View on HN
No posts found.

Just in time! This will be nice reference. I recently started working on a new Scala driver that uses the v0_4 asynchronous protocol, built on top of Akka's IO module and Play's JSON module. I think I have the performance where I want it, but now I need to flesh out the DSL for proper ReQL support.

Exponential back off is a good idea, but to make it even better you'll want to add some random jitter to the delay period. Especially in the case of deadlocks this helps avoid another deadlock when two things would have retried at exactly the same time.

To Be Continuous 11 years ago

Do Continuous Views work with table-table joins, or must there always be at least one stream present? The documentation[1] doesn't specify.

If so, this could be an interesting alternative to RethinkDB's changefeeds, as RethinkDB doesn't support joins on the change stream.

[1] http://docs.pipelinedb.com/joins.html

KONG definitely looks interesting, and I'd love to know more about it. However, there's definitely not a lot written about it yet.

For example: I've gone searching through the blog posts, github readme, and KONG documentation, but I still have no idea _why_ it needs Cassandra. What does it store in there?

That sounds great if your messages in the logs are the complete state for that key, but I'm not seeing how to use that compaction system if the messages are change events.

Is there a system designed for snapshotting the aggregate and logging the delta?

  if you want to build a new derived datastore, you can just start a new consumer
  at the beginning of the log, and churn through the history of the log, applying
  all the writes to your datastore.
For high-throughput environments with lots of appends to the log, how do you get around the ever-increasing size of your log file? I know the traditional answer is to take a periodic snapshot and compact the previous data, but is that built in to tools like Kafka?

Google offers three geocoders:

The first[1] converts ip to location, and allows 100 free queries per day.

The second[2] converts physical addresses to location as part of it maps JavaScript api, and is part of its 25,000 free requests/day.

The third[3] is its http version of geocoding, which also converts physical addresses to locations or visa-versa. This api has the 2,500 req/day limit.

[1]https://developers.google.com/maps/documentation/business/ge...

[2]https://developers.google.com/maps/documentation/javascript/...

[3]https://developers.google.com/maps/documentation/geocoding/