0

I am building a small webapp that will initially be hosted on a EC2 Micro instance (which is severely memory-limited, 613Mb RAM). When I set it up it asks for a RAM component into which it will load all the database data that it can hold.

This won't be a problem at first, since I estimate that my launch customers' data won't need more than 20Mb in total.

However, if things go well I might upgrade to a bigger instance and later I might want to cluster dedicated membase VMs.

My question is this: How do I set it up now so that I don't paint myself into a corner when I want to migrate to:

  1. A bigger machine
  2. A cluster of machines?

What will the upgrade paths look like when I arrive at these junctures?

Pieter Breed
  • 101
  • 4

1 Answers1

1

It's actually much easier to add nodes (and nodes that are similar to existing nodes) than to change nodes once you are in production, though you can do both. Additionally, the benefit of spreading the data out across nodes is that you are going to get distribution of the data AND I/O. Because Membase is very fast, it typically gets network bound first. Additionally, more nodes allows replication of data and thus better chance of riding out any sort of node failure in the cluster without application downtime. So I'd recommend you start with a small-ish node (perhaps micro...but maybe small) and grow by adding nodes. Rebalancing the new nodes into the cluster is a no-brainer.

user57165
  • 11
  • 1
  • My worry is that I have to set the memory allocation per node up front. How will I scale this up when I get more capable machines? – Pieter Breed Oct 15 '10 at 05:51