tags:

views:

438

answers:

6

Hi All! I ever developed several projects based on python framework Django. And it greatly improved my production. But when the project was released and there are more and more visitors the db becomes the bottleneck of the performance.

I try to address the issue, and find that it's ORM(django) to make it become so slow. Why? Because Django have to serve a uniform interface for the programmer no matter what db backend you are using. So it definitely sacrifice some db's performance(make one raw sql to several sqls and never use the db-specific operation).

I'm wondering the ORM is definitely useful and it can:

  1. Offer a uniform OO interface for the progarammers
  2. Make the db backend migration much easier (from mysql to sql server or others)
  3. Improve the robust of the code(using ORM means less code, and less code means less error)

But if I don't have the requirement of migration, What's the meaning of the ORM to me?

ps. Recently my friend told me that what he is doing now is just rewriting the ORM code to the raw sql to get a better performance. what a pity!

So what's the real meaning of ORM except what I mentioned above? (Please correct me if I made a mistake. Thanks.)

+2  A: 

A good ORM allows you to tune the data access if you discover that certain queries are a bottleneck.

But the fact that you might need to do this does not in any way remove the value of the ORM approach, because it rapidly gets you to the point where you can discover where the bottlenecks are. It is rarely the case that every line of code needs the same amount of careful hand-optimisation. Most of it won't. Only a few hotspots require attention.

If you write all the SQL by hand, you are "micro optimising" across the whole product, including the parts that don't need it. So you're mostly wasting effort.

Daniel Earwicker
What if you have developer DBAs managing the data with several different client teams accessing the database?
gbn
@gbn - not sure where you're going with that question, but in that case I'd roll out a single data layer (developed with an ORM) to all the other teams to share, and then enhance it in response to their feedback (whether on performance, usability or any other quality criteria).
Daniel Earwicker
My direction is: all my client teams code against my stored procedures. This allows me to deal with Java, c#, vb.net and VBA clients. The DAL is stored procedures. The client langauge and ORM is irrelevant.
gbn
i.e. hand-code the equivalent of the ORM's output in an RDBMS-specific language. Another group where I work tried that. The original requirement was specific RDBMS, but that soon changed (victims of their own success). Also, it was assumed SPs would be "faster", but it turned out that some parts of the app needed to dynamically generate their SQL because the users needed very flexible querying. Guess what, those dynamic queries turned out to be the most-used queries of the system. All that effort maintaining multiple set of SPs for queries that hardly ever run! Using ORM for the next version.
Daniel Earwicker
So if you never need the ability to switch RDBMS vendors (not sure why you'd want to rule that out) you should be okay... my attitude is summed up by this blog post: http://smellegantcode.wordpress.com/2009/05/11/when-to-use-stored-procedures/
Daniel Earwicker
We'll switch client before we switch RDBMS...
gbn
Ha! Well, that's a slightly different situation. One of your business requirements appears to be "Whatever happens, we must use this particular RDBMS as part of the solution". So naturally there is no rational argument against your decision.
Daniel Earwicker
Thanks, Earwicker. Your reply makes me feel better about ORM.
Tower Joo
We're a large corporate, not a software house. The main constant is the RDBMS...
gbn
+4  A: 

You have mostly answered your own question when you listed the benefits of an ORM. There are definitely some optimisation issues that you will encounter but the abstraction of the database interface probably over-rides these downsides.

You mention that the ORM sometimes uses many sql statements where it could use only one. You may want to look at "eager loading", if this is supported by your ORM. This tells the ORM to fetch the data from related models at the same time as it fetches data from another model. This should result in more performant sql.

I would suggest that you stick with your ORM and optimise the parts that need it, but, explore any methods within the ORM that allow you to increase performance before reverting to writing SQL to do the access.

Steve Weet
I mostly agree with you. Actually I can figure out which ORM operations slow the db query and optimize them after hacking the ORM internal. It means I should know sql very well on one side, and know the ORM internal very well on another side. It seems unworthy comparing with focusing on the raw sql.
Tower Joo
A: 

here is the definition from Wikipedia

Object-relational mapping is a programming technique for converting data between incompatible type systems in relational databases and object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language.

Yassir
A: 

a good ORM (like Django's) makes it much faster to develop and evolve your application; it lets you assume you have available all related data without having to factor every use in your hand-tuned queries.

but a simple one (like Django's) doesn't relieve you from good old DB design. if you're seeing DB bottleneck with less than several hundred simultaneous users, you have serious problems. Either your DB isn't well tuned (typically you're missing some indexes), or it doesn't appropriately represents the data design (if you need many different queries for every page this is your problem).

So, i wouldn't ditch the ORM unless you're twitter or flickr. First do all the usual DB analysis: You see a lot of full-table scans? add appropriate indexes. Lots of queries per page? rethink your tables. Every user needs lots of statistics? precalculate them in a batch job and serve from there.

Javier
Thanks. But after you tuned the DB, and you may face the same problem. Maybe the db can't be tuned any more, and you have to consider to rewrite the ORM operations to raw sql to get a better performance.
Tower Joo
of course. I just happen to believe that the ORM's performance ceiling is really high. most sites won't be anywhere near. Also it's not just 'tuning the DB'; it's also about using the right data structure and algorithms. If you do 50 queries per page, no amount of DB tuning will help, you have to bring it down to less than 10, less than 5 ideally.
Javier
A: 

ORM separates you from having to write that pesky SQL.

It's also helpful for when you (never) port your software to another database engine.

On the downside: you lose performance, which you fix by writing a custom flavor of SQL - that it tried to insulate from having to write in the first place.

Ian Boyd
Thanks. But I guess you didn't read my post.
Tower Joo
No, i read it. You have the two reasons for ORM.
Ian Boyd
A: 

ORM generates sql queries for you and then return as object to you. that's why it slower than if you access to database directly. But i think it slow a little bit ... i recommend you to tune your database. may be you need to check about index of table etc.

Oracle for example, need to be tuned if you need to get faster ( i don't know why, but my db admin did that and it works faster with queries that involved with lots of data).

I have recommendation, if you need to do complex query (eg: reports) other than (Create Update Delete/CRUD) and if your application won't use another database, you should use direct sql (I think Django has it feature)

nightingale2k1
Thanks. And your conclusion is nearly same with mine.
Tower Joo