Ruby

Location

The Open Data movement is picking up steam in a big way. Some government or NGO seems to announce plans for full transparency every week. Then you've got a guy like Rob McEwen creating billions of dollars of wealth when he decided to open source his gold mining company's geological data. Still, data today is like the web was in 1995... all over the place. We need a data commons: a place for people to discover, consume, contribute, discuss and purchase data. This talk discusses how such an infrastructure could work, and how we must bring tools for working with data to non-technical individuals.

Location

This session will cover lessons learned about Ruby on Rails development using PostgreSQL. From the database-centric view the session will explain Rails best practices, taking advantage of RoR strong points, dealing with its weak points, PostgreSQL strong and weak points, and using advanced SQL features in web applications. The session will demonstrate how PostgreSQL is used to speedup Rails code, making slow things in your web application fast and impossible things - possible. The session will also discuss the peculiarities of complex enterprise apps and show that PostgreSQL is an ideal open source match for their development.

Topics covered will include:

Our experience with Ruby on Rails and PostgreSQL combo:

    * performance characteristics of Ruby applications
    * Rails advantages
    * PostgreSQL advantages

How to optimize Rails with PostgreSQL:

    * doing as much as possible in SQL
    * preloading attributes and associations
    * using Postgres' arrays for even faster preloading
    * generating and executing SQL queries instead of manipulating data with ORM

How to optimize Rails application by moving logic to the PostgreSQL database:

    * efficient trees
    * efficient pagination
    * efficient access control system with roles and privileges
    * efficient data analysis and aggregation

How to deal with PostgreSQL limitations:

    * optimizer forcing subselects for the whole result set despite limit/offset
    * optimizer not being able to estimate the resulting set size of the generate_series() function call
    * "in" in where conditions forcing joins
    * need for pushing down conditions in certain cases
    * avoiding on-disk sorts
    * selecting records holding group-wise maximum without windowing functions (pre 8.4)
    * using "not exists" as a cure to bad performance of "not in" conditions

How to make your database faster:

    * improving shared database performance under severe memory restrictions
    * realistic explain analyze
    * Postgres-specific performance tips

How to keep your database and application robust:

    * getting the right compromise between ORM and the database
    * best practices for database schema development and maintaining data integrity
    * performance testing and benchmarking
    * performance monitoring