Cloud Deployment: New Servoy AMI Available

There is a new public Amazon Machine Image (AMI) available.
This image features Servoy version 5.1.2.
Also in anticipation of Servoy’s open source offering, this image is built using Postgresql version 8.4, the most advanced open source database on the planet.

To launch an instance of the AMI, log into your AWS Console and select AMIs.
Search in public AMIs for AMI ID = ami-2fc82146
Right-click the image and launch it.

Thanks Sean.

So, If we deploy any Servoy Solution, It will use Postgresql version 8.4 database for the solution repository and data???

Thanks,
Sasmit

Hi Sasmit,

PostgreSQL is a database server so you can have multiple databases open in it. Just like you can with MSSQL, Oracle, MySQL, etc.
One benefit of these database servers over Sybase iAnywhere is that you don’t have to bring the database server down to create/load up a new database. Just create/restore the database you need and you can immediately connect to it.

ROCLASI:
Hi Sasmit,

PostgreSQL is a database server so you can have multiple databases open in it. Just like you can with MSSQL, Oracle, MySQL, etc.
One benefit of these database servers over Sybase iAnywhere is that you don’t have to bring the database server down to create/load up a new database. Just create/restore the database you need and you can immediately connect to it.

With Postgres can you do SQLDump and Execute the way you can with MySQL Robert?

What tools would be most appropriate to manage Postgres (we use Navicat and Toad for MySQL)?

Hi Ian,

PostgreSQL comes with a dump/dumpall and restore utility.
And just like MySQL you also have a commandline sql editor called psql.

As for tools to manage PostgreSQL you can use the Open Source PgAdmin3 but Navicat also has a PostgreSQL version so if you are used to Navicat you can buy that version.
Toad Data Modeler (as most other DBA/ERD apps) also works with PostgreSQL.

Excellent Robert - thanks.

Would you recommend Postgres over MySQL?

Oh yes!

Kahuna:
Would you recommend Postgres over MySQL?

Well, yes :D.
For one MySQL is not 100% ACID compliant out-of-the-box. You would have to enable Strict SQL mode and use InnoDB to make it 100% compliant.
PostgreSQL is more SQL standards compliant than MySQL.
And at this point in time if you need more advanced features like Common Table Expressions (CTE) or even something basic as well working triggers then PostgreSQL will be your best bet between the 2.
Performance-wise they don’t differ much although PostgreSQL, again at this point in time, tend to perform better than MySQL on multi-core servers (4 cores and up).
Also the documentation of PostgreSQL is excellent!

Of course another non-technical thing is that there is no confusion on the PostgreSQL license. It’s free, as in beer.
In fact it’s license is so permissive you could slap your own sticker on it and sell it.

ROCLASI:
It’s free, as in beer.

Hmmmm… Beeer :P

Thanks Guys - I’ll investigate!!!

It’ll be great if PostgreSQL is the default repository for Servoy, especially because it’s ACID compliant out-of-the-box and the other reasons explained above.

However, don’t dismiss MySQL too fast. I will keep PostgreSQL as the repository for my Servoy server, but I’ll use MySQL as the backend database for my solutions. A simple reason: replication.

Replication is really nice when you have a core database that has tables that can be shared among different applications. Forget about filtering data, it can all be done at replication. It is also good for load balancing in this regard.

It’s really cool if you need (or you want) the data for your website in the same box of your web server. The core database and all CRUD functions are in one box (the core box), but the site is connected to the slave database residing in web server box. You can also just replicate the databases and tables that you want the world to see in your website.

Replication is also good for backups – along with other traditional techniques - like the mysqldump nightly backups.

Setting up MySQL as ACID compliant it’s nothing. Configuring replication is easy too, but you have to be careful.

Still, I wouldn’t use MySQL as the embedded database of Servoy installation –until MySQL 5.5 becomes a GA release (this one will be ACID compliant out-of-the-box -having InnoDB as default). But then, there is the issue: is MySQL free as in free beer? I doubt it.

jcarlos

jcarlos:
I will keep PostgreSQL as the repository for my Servoy server, but I’ll use MySQL as the backend database for my solutions. A simple reason: replication.

Is this because you don’t want to use any of the replication options PostgreSQL offers ? :)

Do note that when it comes to replication there is no one-size-fits-all approach. What kind of replication (master-slave/multi-master) you want to use all depends on what your requirements are. Another factor is how this replication is implemented (trigger based vs log shipping vs connection proxies, supports DDL or not, etc) that might influence your choice in tools depending on your situation.

To name a few (free and commercial) tools you could use (some of them also work with MySQL):

Warm Standy - WAL schipping to standby instance for failover.
Hot Standy (in upcoming PostgreSQL 9.0, now in beta) - streaming WAL shipping to standby instance
SLONY - trigger-based master/slave
Londist (part of SkyTools from the Skype people) - trigger-based master/slave
Sequoia - middleware-based multi-master
Pg-Pool II - middleware-based multi-master
HA-JDBC - client-driver-based multi-master
Postgres R - certification-based multi-master
Bucardo - master-master replication
Mammoth Replicator - log-based master/slave
Tungsten Replicator - heterogeneous log-based master/slave

Although some of these tools make implementing replication pretty simply do realize that with using replication you are adding another layer of complexity to your database, be it PostgreSQL or MySQL.

ROCLASI:
Is this because you don’t want to use any of the replication options PostgreSQL offers ? :)

You are correct. I don’t want to use any of the replication options PostgreSQL offers. Don’t take me wrong, I like PostgreSQL, it is just that its strength is not replication.

The most common tool for replication in PostgreSQL, which you are listing here (Slony-I), is essentially inferior to MySQL’s built in replication for the following reason: It uses SQL triggers to replicate the data across servers. This is considerably slower than MySQL’s binary log approach. This makes the cost of connection/communication between serves a lot higher. This cost can grow immensely in relation to the number of servers in the replication pool. This however wouldn’t be an issue for me because I am not distributing data across clusters of servers (yet), but it’s well know that Slony-I is adequate for high availability with two servers only – no more than that.

In addition, tools, tools and more tools! Oh please, I am tired of that. Tools are more difficult to administer. With MySQL replication you don’t need to install any additional software. You just physically set up a slave server(s) and configure MySQL master and the slave server(s) to begin replication. BTW, I am very conservative when it comes to replication. I don’t consider master-master replication - well, there is a configuration where a master is also slave and the slave is also a master that I like, but I won’t discuss here today. I really need run to a meeting :(

BTW, with MySQL replication, the layer of complexity to database is nothing. I found more complex to filtered data at the application layer than just configuring replication (and yes, this is for my specific application –as I describe above: when you have a core database that has tables that can be shared among different applications residing XY box on XY part of the world)

JC

Yes, the upcoming PostgreSQL 9.0 will have a true replication built in, consisting of Hot Standby and Streaming Replication. I will take at look at that.

jcarlos:

ROCLASI:
Is this because you don’t want to use any of the replication options PostgreSQL offers ? :)

You are correct. I don’t want to use any of the replication options PostgreSQL offers. Don’t take me wrong, I like PostgreSQL, it is just that its strength is not replication.

Fair enough. Replication was never really a focus of the PostgreSQL Worldwide Development Group until 8.4 with warm standby and now upcoming 9.0 with hot standby and streaming replication.

jcarlos:
The most common tool for replication in PostgreSQL, which you are listing here (Slony-I), is essentially inferior to MySQL’s built in replication for the following reason: It uses SQL triggers to replicate the data across servers. This is considerably slower than MySQL’s binary log approach.

You mean it’s not the best solution for your requirements. ;)

jcarlos:
In addition, tools, tools and more tools! Oh please, I am tired of that. Tools are more difficult to administer. With MySQL replication you don’t need to install any additional software.

You know there is a reason why there are tools, tools and more tools.
Because there are always requirements where your built-in MySQL replication or any other tool doesn’t cut it. It’s not that people like to reinvent the wheel over and over again. Most of the tools I mentioned are in fact Open Source.

http://www.servoy.com/generic.jsp?mt=39 … omy_id=933

Is this AMI also work for Servoy 5.2.1?

sasmithota:
Is this AMI also work for Servoy 5.2.1?

Sure. Once launched you can upgrade it to 5.2.1. See
http://wiki.servoy.com/display/public/D … er+upgrade