7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 1/28

HOW TO MIGRATE FROM POSTGRESQL TO HDF5AND LIVE HAPPILY EVER AFTER

 @ 

legacy code warrior

The story of a successful software rewriting

Michele Simionato GEM Foundation

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 2/28

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 3/28

WHERE I COME FROM

Ph. D. in Theoretical Physics (yep, I understand gravitational waves)contributed to Python with article/docs, author of the decorator moduleworked a couple of years as consultant (Zope/Plone + other stuff)worked 7 years in a Finance firm (mostly database and webprogramming)arrived at GEM in October 2012in charge of the earthquake simulation engine from September 2014

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 4/28

I spent 15 years doing Physics and 14 years programmingI am still more interested in solving the scientific problems than thetechnological problemslots of experience with programming in the largeknow all about code maintenance, dependencies management, productdocumentation, automatic tests, continuous integration, code reviews, ...SQL lover and generally old school boystill using Emacs in the 21th centuryI don't throw away old code just because it is old

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 5/28

WHAT I AM GOING TO TALK ABOUT

"big" numerical simulations for earthquakeslots of floating point outputs with geospatial datawhy storing them in Postgres/PostGIS did not workwhat to do when you have a huge architecturalproblemtechnical and political issues facedhow the migration PostGIS ­> HDF5 was donelessons learned

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 6/28

NUMBER CHRUNCHING WITH A RELATIONALDATABASE??

yep, serioslyafter a few weeks on the new job I had already realized that thearchitecture was completely wrongeverything was structured like a Django application without being a webapplicationthere was an insane mix of Django objects and arrayslarge numpy arrays were stored in the database as pickled objects

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 7/28

there were absurd things like doing the aggregation on the database withlocksthere were hundreds of workers writing concurrently on the same tablethe database logic was hopelessly coupled with the scientific logicstrangely enough, the architecture was totally wrong but the code basepretty good

Then rewrite everything?

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 8/28

THE FIRST LAW OF SOFTWARE REWRITING

Rewriting a project takes always longer than writing it in the first place

(as we seasoned developers know)

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 9/28

I did not want to embark myself in such an adventure

but sometimes there is no choice :­(

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 10/28

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 11/28

WHAT FIVE ORDERS OF MAGNITUDE MEAN

1 day ­> less than 1 second1 year ­> 5 minutes

I measured a speedup exceeding 200,000x

(+ memory gain of 1­2 orders of magnitude)

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 12/28

BLOCKED BY POLITICAL ISSUES

the architecture of the application had been just rewritten (more than anyear of effort, it was ported from Redis to PostgreSQL)a younger collegue of mine had already written a criticizing mail went inthe wrong handsthe official release of version 1.0 had to be ready in six monthsthere was a team friction between Zurich and Paviathere was an artificial division between hazard code and risk codemaking it impossible to fix the risk code

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 13/28

DOING NOTHING FOR 8 MONTHS

sometimes doing nothing is the best choicestudy the codebase, maintain the old codelet the frustration grow(a good thing, if limited in time)getting new case studies and adding new testsimprove where you can (monitoring, XML parsing, concurrency, ...)

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 14/28

WAITING PAYS OFF

the Zurich team evaporatedwe took change of both hazard and risk in Paviawe started removing old cruft (10,000+ lines of code)we decided on a conservative strategy: keep Postgres, rewrite therelational schema and the slow queries

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 15/28

13 MORE MONTHS FIGHTING POSTGRESQL

implemented a migration mechanismchanged most of the tableschanged the critical queries several timesimprovements by several orders of magnitudestill, it was not enough, as realized in the summer of 2014but we kept the users and scientists happy

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 16/28

THE DECISION TO DROP POSTGRESQL

started the oq­lite project with the excuse of the Windows porting,September 2014ported the simplest calculators to the new architectureremoved gradually the geospatial querieskept in parallel both versions, with the same functional testsremoved a lot of annoying unittestsbuilt expertise with HDF5

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 17/28

OTHER ARCHITECTURAL CHANGES

all the concurrency is managed by a pure map­reducemade the concurrency layer independent from the low levelparallelization technologychanged from everybody read/write on the database to only thecontroller node can read/writeall scientific data are now in the datastore (one .hdf5 file per calculation)all the metadata (i.e. start/stop time of the calculation, description, logs,performance information, output information) are in SQLite

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 18/28

the workers do not write anything on the filesystem and they do notcommunicate at all with the master, except via the map­reduce (sharednothing)totally decoupled the database from the calculation logicadded a DbServer in Python serializing the access to the database(needed for the WebUI)removed the ORM layer (thanks to Martin Blais dbapiext)

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 19/28

EVEN MORE CHANGES

removed completely the need for XMLSchema, doing the validationentirely at the Python levelimplemented a generic serializer Python <­> XML instead of dozens ofdifferent serializers, one per classadded CSV exports with the final goals of removing XML exportsimplemented a serialization protocol Python <­> hdf5 with methods__toh5__ and __fromh5__supported both single user mode and multiple user modeported the engine to Windows and Mac OS Xmodernized the code to Python 3

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 20/28

ALL WENT SURPRISINGLY WELL!?

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 21/28

THINGS THAT I ALREADY KNEW, REINFORCED

monitoring the running system for speed and memory allocation isessentialif testing is difficult, the architecture is badunittests are bad, functional tests are goodif you want performance, replace Python objects and dictionaries withnumpy.arraysno ORM please

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 22/28

MY TECHNICAL ADVICE

follow a principle of simplicity/cleanness: 95 % of the speedups andmemory saving came for free after removing codeinvest your time in solving the real problem, not in complicating yourtechnological stack (so I did not spend time on numbas, GPUs, Intelcompiler, etc etc)always challenge the underlying assumptionstake the most difficult problem that you can solve and solve it firstmost of all, be patient

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 23/28

POLITICAL ADVICE

don't be confrontational with your bossit is his job to be conservativetake the slow way and make sure that at every little step you have ameasureable improvement to show offperformance is a good excuse for changeyou can raise your voice once or two in four yearsit takes time to build trust

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 24/28

THINGS I DISCOVERED ALONG

using a database + ORM requires a LOT more memory than you thinkit is sometimes best to use all of the available memorysometimes it is better to run out of memory earlythe data transfer is really importanta story about parsing XML: lxml ­> ElementTree ­> expatthe migration to Python 3 had several surprises

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 25/28

LESSONS ABOUT TECHNOLOGIES

concurrent.futures is just fineTravis is goodwheels are greath5py is ultra­fast but can bite you

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 26/28

REGRETS

nearly two years "lost" (from October 2012 to August 2014)I was too conservative and I should have cut more stuff/testsI should have investigated better what features were really important

(but removing 50,000+ lines of code feels really great!)

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 27/28

3/28

7/31/2016 reveal-md

http://localhost:1948/talk.md#/1 28/28

THE END: SECOND LAW OF SOFTWARE REWRITING

Software rewriting takes always longer than you think

But sometimes it is worth it :­)

https://github.com/gem/oq­engine

3/28