Application upgrade in a high availability environment

[nuli...@gmail.com]

Hi. I am writing a NoSQL database engine and I want to provide features to help the developers to upgrade their application to a new version without stopping the operation of the website, i.e 0% downtime during upgrade. So my question is, what are the methods or general design of a web application when it is run 24/7 and is changing its database structure very often? Kind of like facebook. Any examples or success stories would be greatly appreciated.

[William la Forge]

Have you looked at OSGi?

On Sun, May 5, 2013 at 3:32 AM, <nuli...@gmail.com> wrote:

Hi. I am writing a NoSQL database engine and I want to provide features to help the developers to upgrade their application to a new version without stopping the operation of the website, i.e 0% downtime during upgrade. So my question is, what are the methods or general design of a web application when it is run 24/7 and is changing its database structure very often? Kind of like facebook. Any examples or success stories would be greatly appreciated.

--
You received this message because you are subscribed to the Google Groups "NOSQL" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nosql-discussi...@googlegroups.com.
To post to this group, send email to nosql-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/nosql-discussion/-/vHPC6Zvs7owJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Konstantin Osipov]

* nuli...@gmail.com <nuli...@gmail.com> [13/05/05 02:24]:

Modern web applications not just upgrade databases often, they
migrate between different vendors more easily than before.
Moreover, a more or less any large web shop has a way to enable
a feature only for a subset of its users.

The common technique for this is to do it in your application
code. I.e. say, you write PHP and you roll out a new database
schema, you begin with rolling out new PHP which is aware of both
the new and the old schema. This is the only safe way, since
otherwise you risk getting into a consistency race between
the application code and the database schema.

Then you actually upgrade your database.

This principle works on all levels: large web sites have not
3-tier architecture (web frontend, app server, database),
but 4-tier, n-tier architecture, with app server and database
proxies, middleware, queues, etc. You can apply this
technique on any level, not necessarily in the app.

But the morale is that if you require real 0% downtime, you begin
thinking about it in the application, and the database just can
make it easier for you, but not spare you of the headache
completely.

It may also be worth taking a look at capistrano (it's a
deployment tool for Ruby) and how changing database schema
works with Ruby on Rails.

The features of online schema change *within the database* depend
greatly on your data model. Here you need to think at least about
two problems: online change on a single node, and online change
within a cluster of nodes.

--
http://tarantool.org - an efficient, extensible in-memory data store