articles
Once you’ve learned the basics of using Lua in HAProxy, you start to see a lot of places the scripting language could be useful. At Cloudant, one of the places we saw that we could make use of Lua was when selecting from the various backends to which our frontend load balancers direct traffic. We wrote a simple proof of concept, which I wanted to document here along with some of the problems we hit along the way.
It’s a long weekend this week in the UK. I wanted to learn a bit more Ruby, so I decided to use the time to start writing a client library for CouchDB. Basically my day job at Cloudant, but in Ruby.
I first used Ruby back in about 2005, and this site was powered by a couple of Ruby incarnations: first a Ruby on Rails app for a time; then a fairly hokey static site generator. I think that lasted until around 2009 when I learned Python and switched to Google AppEngine. Even with this experience, I don’t know Ruby particularly well – I have never used it full time – but I think the library has come out okay so far.
If you use Cloudant’s dashboard to generate API keys and assign permissions, you’d be forgiven for thinking that an API key can only be used for one database. However, that’s just an unfortunate implication of the UI. In fact, you can give an API key permission to read or write any number of databases – even ones on different Cloudant accounts.
The key to doing this is to use Cloudant’s HTTP API rather than the dashboard. Here’s how.
One feature I value in an editor is allowing different languages to have different settings. Like the way the Javascript community has settled on using two spaces for indenting, whereas Python uses four. This feature is built-in to Sublime Text. The lack of the feature is one reason I gave up on the Atom editor.
While less convoluted than the read and write behaviour in a cluster, the behaviour of indexing in a clustered CouchDB or Cloudant environment merits a discussion. Understanding how indexing and querying works in a cluster will help avoid confusing situations where queries to a view index on Cloudant will produce different results because the indexes contain different data.
tl;dr: Writing indexing functions (map
/reduce
in views, index
for search indexes and so on) which can return different values for the same input document will cause the indexes on shard replicas to differ, meaning they could return different values for the same query even when data doesn’t change. It’s the developer’s responsibility to write their indexing functions such that they always emit the same values for indexing for the same JSON input.