Tag

improvements Archives - AWS Managed Services by Anchor

Extending PostgreSQL with high level languages (and cats)

By | Technical | No Comments

In a recent post we extolled the virtues of creating your own brand new operators in PostgreSQL. SELECT =^_^= FROM happycats; That’s well and good, but the output was a little lacklustre, returning “meow” for every tuple. We’d like to make it more interesting, and one way to add interesting functionality to Postgres is to embed a procedural language. This lets you juggle data with a little more finesse when it comes to certain operations, compared to the usual relational algebra. We’re going to use Perl because it’s easy to integrate with Postgres, and is generally a quick and dirty way to Get Stuff Done. When embedded in Postgres it’s referred to as PL/Perl. Let’s get started. We begin by “installing” the language into the database in which we wish…

Read More

Extending PostgreSQL for fun: with cats

By | Technical | 2 Comments

Perhaps you’ve thought I wish I had more cats in my Postgres database before. We certainly have. Just the other day we were lamenting some of the differences between MySQL and PostgreSQL, particularly the way that MySQL has case-insensitive matching using the LIKE operator, while Postgres has LIKE and ILIKE. This got us thinking, it’d be amusing to have more vague (and hilariously unwieldy) operators, such as: SELECT * FROM foo WHERE a VAGUELY RESEMBLES b; Something like this isn’t too implausible. It’s similar to what a full-text search entails, but it’s far from trivial. This got us thinking: if we can’t easily do that, can we at least have some amusing query syntax? Yes we can!

Read More

Second strike with Lightning!

By | Technical | 2 Comments

We put Kyoto Cabinet under the gun recently as a means to improve Redis. The Anchor Propulsion/Internet Laboratory validated Kyoto Cabinet as “fresh”, but extended live testing has revealed sub-optimal behaviour in some situations. To recap, we used Kyoto Cabinet to give Redis near-realtime disk persistence with a greatly reduced memory footprint; we called this “NDS” and published the code. Dirty keys are flushed from memory periodically into Kyoto Cabinet’s backing store. This works fantastically most of the time, but we’ve discovered that some operations cause a massive blowout in the on-disk files. Kyoto Cabinet is a key-value store. When you update a value in Kyoto Cabinet it can be rewritten in-place, unless the new value is longer than the old one. In this case, Kyoto Cabinet makes a new…

Read More

Redis Rethought: Exciting Extremes with Larger-Than-Memory Datasets

By | Technical | 2 Comments

In a recent post we talked about Redeye, a way to manage a cluster of Redis shards. Sharding is important for pure storage capacity, but also to manage availability and performance, seeing as Redis can be CPU bound in a suffuciently large environment. This time we’re tackling the other side of the equation, simply being able to hold all your data without dropping it. You’ll recall that Redis is purely an in-memory datastore. This makes it amazingly fast, but volatile. To get around this you can have persistence across restarts using RDB and AOF files. The catch is that you’re ultimately limited by the amount of RAM you have available – if you have 500gb of data to store then you need 500gb of RAM, either in a single server…

Read More

Extending Redis to scratch an itch

By | Technical | No Comments

Redis has become one of the most popular “noSQL” datastores in recent times, and for good reason. Customers love it because it’s fast and fills a niche, and we love it because it’s well behaved and easy to manage. In case you’re not familiar with Redis, it’s a key-value datastore (not a database in the classic sense). The entire dataset is always kept in memory, so it’s stupendously fast. Durability (saving the data to disk) is optional. Data in Redis is minimally structured; there’s a small set of data types, but there’s no schema as in a traditional relational database. Thanks to some peculiarities in the way Redis is implemented, it can offer atomic transactions that are difficult to achieve in normal database products. That’s not to say it’s perfect…

Read More

PostgreSQL 8.4

By | Technical | 2 Comments

Good news, everyone! PostgreSQL 8.4 is out, as of several weeks ago. Okay, this isn’t “new” news, but it’s not at all ungood, delay or otherwise. You can catch the feature list here, there’s some good stuff: http://www.postgresql.org/about/press/features84.html Of course the real trick is getting more of our customers to use the superior alternative, *le sigh* As if you *needed* any further convincing to choose Postgres over Mysql, we’ve put together a little comparison for you that highlights some of the most obvious differences for you. 🙂 http://www.anchor.com.au/hosting/dedicated/mysql_vs_postgres Oh yeah, using a Redhat OS? You’re short outta luck, you don’t get anything newer than 8.1.11 in the stock release – go use Debian, it’s better anyway. What are you missing out on? Plenty.

Read More

Improving your quality of life with Oracle

By | Technical | No Comments

Not content to take Oracle lying down, we’ve made a couple of small changes on our systems to make life a little saner. The first is a substantial improvement to the default initscript, the second is some shell/environment hacks that should really be done by default. I alluded to these a few posts ago, but hadn’t gotten to publishing them yet. If you’re a poor sod that has to use Oracle, head over and have a look at the improvements, feedback is always welcome (it might not be perfect, but it’s a lot better). In the interests of not being acquired by Oracle Corp, we’re publishing a diff to the initscript, rather than the full file.

Read More