How to change a web application that now needs to become OLTP and OLAP application?

Question

Previously, I did a simple web application for an enterprise client using PHP and MySQL.

After some time, it has grown to a point where I realized after talking with people here that I need to treat it as two separate apps OLTP and OLAP.

I have tentatively decided that

1. the OLTP will still continue to run using the current PHP codebase and MySQL
2. the OLAP will use PostgreSQL
3. both should appear as a single app to the end user. This is to avoid inconsistencies and too many logins.
4. the OLAP should help with sending out scheduled reports via email

I want to avoid a "big bang" approach. At the same time, I don't want to do the OLAP as an isolated app.

I want to slowly evolve to the point where transaction processing and the analytic processing functions are modular and consistent.

How do I approach this and bearing in mind, I currently have only 1 physical server that acts as both database and application server at the moment?

I am most familiar with PHP and am okay to use Python.

The physical server is running ubuntu 14.04 and nginx as web server.

The normalized MySQL currently is at 20mb and growing at a rate of 1 mb every month or so.

EDIT

My server shows 8 when I run grep -c processor /proc/cpuinfo

Each processor (I think?) shows the following stats:

vendor_id   : GenuineIntel
cpu family  : 6
model       : 44
model name  : Intel(R) Xeon(R) CPU           L5630  @ 2.13GHz
stepping    : 2
microcode   : 0x13
cpu MHz     : 1600.000
cache size  : 12288 KB

When I type free -m

             total       used       free     shared    buffers     cached
Mem:          7972       3052       4920         46        226       2039
-/+ buffers/cache:        785       7186
Swap:            0          0          0

When I ssh in

System load:  0.28                Processes:          229
  Usage of /:   13.9% of 126.32GB   Users logged in:    1
  Memory usage: 10%                 
  Swap usage:   0%

Answer 1

OK - I'm going to slightly revise my advice in the previous thread.

If you have only 1 physical server, you're always going to have problems with OLTP conflicting with OLAP - i.e. disk bottleneck. It would be far easier to use PostgreSQL as the server for both than the other way round - see my previous comments on the richer PostgreSQL SQL functionality.

We also don't know what sort of activity your app has, nor do we know your CPU, RAM and disk config (RAID?).

In the light of what you have written above, my advice is to use PostgreSQL for both - maybe two separate schemas on the same instance of PostgreSQL - or possibly two instances of PostgreSQL on the same machine. This is more or less what @Mat and @CraigRinger said. The logic behind separating the schemas is that when and if you get a second server (which you should), parititioning the functionality between the two machines will be trivial.

If most of the functionality of your app to date is of a CRUD nature, then porting it to PostgreSQL should be relatively painless, but, again, YMMV.