When you are making over a billion transactions a day, you seriously think ORM is the way to go? Don't take my word for it, go ask Peter Zaitsev yourself </thread>
I give up
- Thread starter Rage9
- Start date
When you are making over a billion transactions a day, you seriously think ORM is the way to go? Don't take my word for it, go ask Peter Zaitsev yourself </thread>
where's the specifics brah? where the fuck are the numbers and data? what specifically is the slow down with ORMs? what does ORM even mean? Prove to me you even fucking understand what an ORM is and what it does and then I might take you seriously. Until then I'll clump you together with all the other chump "coders" here
I know where you are coming from, but any ORM, as you know, uses SQL internally for DB manipulations.
ORM overhead = Time to execute raw SQL + time to execute the wrappers/libraries/mapping classes on top of that.
Raw SQL overhead = Time to execute raw SQL.
So, you see.
Edit: A good ORM framework will minimize its overhead so that for the most frequently executed operations, the overhead caused by the framework will be minimal.
What do I gain from proving anything to you on an internet forum? Oh wait, nothing :thumbsup:
Someone who specializes in "mysql performance" has chosen to make a career of an oxymoron.
The logical conclusion of what you're espousing is that all applications be written in SQL to avoid the overhead of the database library required by any general purpose language. A good ORM layer reduces db touch and doesn't introduce second-class implementation requirements. If mysql requires native sql or worse mysql-optimized sql for a given application, that's basically an indication of mysql being a shitty solution for that application.
Read it again. I mostly agree with dchuk. The only point I made was that ORM will never be as fast as raw SQL. It doesn't imply that I advocate writing raw SQL for everything.
In fact, here is why I would use an ORM solution:
- Less time required for development and maintenance
- Less chances/opportunities for the developer to mess up the data access and resource management logic
- Less repetition of boilerplate code
Scenarios which justify use of native/raw SQL, according to me:
- If you are building a quick prototype or application, and the ORM takes a while to set up and configure
- If your data access and manipulation needs involve complex queries and update statements
That is all I can think of, off the top of my head.
@Insomniac:
I don't know anything about you, so I am not assuming anything. You did make a statement.
You could have backed it up with real data/numbers, as dchuk said.
I'll give you a few situations, just for the fuck of it (since you seem less of a douche than dchuk).
First up, the typical SQL based ORM will basically just do a select *. The goal here is to minimize re-use of requests for individual columns. For any major high traffic site (we're not talking a single server in your moms basement here) you introduce network issues to bandwidth requirements. Oh wait, I hear you say, but MySQL can't push 1gbit of traffic out of it - though this is a valid assumption, when you have a rack of database servers, you can easily saturate a 1gbit or even 10gbit link between switches.
Next up, we have the situation of update efficiency of counters. The average ORM will do something like select *, then update blah set column = 50. The problem here, is what if another server was also working on this column? Is 50 the correct value? Or was the intended result column = column + 1? Are you going to use transactions to lock the database now, or are you going to lock with memcache? If you use MySQL, you're now introducing the possibility of deadlocks due, ever increased by even 1ms of network latency. But I hear you say, why not just use memcache in the first place? What if the row is something that actually matters, such as impressions, clicks or conversions... you're going to leave those stats in volatile memory?
Next we have query efficiency. Lets say we have a database with 20 million rows. We're doing a select on something like surname, and want to page through. What is your ORM going to do? First 100 results or so, sure limit 100 is fine. What about when it's limit 10000, 100? Oh shit, your code now needs to switch to using a where statement otherwise your queries start taking 10x longer to process. What if that limit is complex?
What about if I want to grab stats from the database in natural order, without fucking around with reordering the rows in memory? select * from (select somedata from table group by 1 order by 1 desc limit 24) as data order by date asc; Is your ORM doing to do that shit for you efficiently?
What happens when you're a django fag using south to manage your database? Seriously doesn't take much for some dipshit to fuck up foreign keys and truncate a table when doing what should have been a single row delete, or have his n00b ass want to clean up his code, and start dropping columns on insanely huge tables in production, causing minutes or even hours of server downtime while the change is committed.
My point is since hibernate2 ORM solutions like it are generally transactionally "faster" because they allow developers to optimize db read/write inefficiencies by eliminating them with store-agnostic caching mechanisms and batching expensive transactions, and because ORM frameworks tend to offer transparent bindings for multiple backends the solution for mysql sucking doesn't have to be "write raw sql," the solution can be use a backend that doesn't suck.
Even assuming ORM-generated queries are as poor as you think they are, blaming ORM for mysql's shitty query optimizer is putting the blame squarely in the wrong place.
Caching only solves problems up to a certain point, eventually you need access to a fuck ton of persistent or consistent data, and storing it all in memory gets extremely cost prohibitive (not to mention you can even start to run into cache layer locking/bandwidth issues).
Also, sometimes different backends really doesn't solve the problem. The service might need a combination of neo4j, Solr, MySQL, MongoDB and HDFS, all depending on what kinda of queries or data retention policies a piece of the project needs. Seriously not going to say "oh lets just switch MySQL to PostgreSQL" just because one coder wants to be lazy and not understand what his code does.
I thought we were discussing/comparing ORM vs raw SQL.
If you are talking about in-memory data, it is scalable, and the cost to do so is coming down every year.
If you are using a NoSQL solution like MongoDB or HDFS, that is a whole different scenario. It is obvious O-to-Relational-M is not applicable in a non-relational context. If you brought that up as a case where switching databases is useless, you contradicted yourself by posting the link where switching to MySQL apparently solved the scalability issues faced by Google.
About dchuk: I don't know him personally, except here at the forums. This is what I have observed: he is very helpful to newbies. He doesn't pitch his product where it is not useful.
Some weird assertions in this thread.
* ORM vs raw SQL, framework vs raw code, MVC vs glue libraries are all silly arguments. There's too much information and implementation detail missing to draw a conclusion.
A Rails app can be as performant as a static html website with page caching that turn it into a static html website that Nginx can serve without even hitting Rack.
Active Record can be just as performant as raw SQL when it's tokenizing your query into a postgres stored policy. On the other hand, if you're relying on raw SQL, you'll either be coupling your SQL with your database implementation or writing your own adapter glue (ORMlol).
Most of these absolutist assertions come off as nothing but someone justifying what amounts to intellectual stagnation. The OP conflating MVC frameworks and Twitter Bootstrap pretty much exhibits the sentiment. Quit hating on stuff and find enjoyment in learning new things.
* ORM vs raw SQL, framework vs raw code, MVC vs glue libraries are all silly arguments. There's too much information and implementation detail missing to draw a conclusion.
A Rails app can be as performant as a static html website with page caching that turn it into a static html website that Nginx can serve without even hitting Rack.
Active Record can be just as performant as raw SQL when it's tokenizing your query into a postgres stored policy. On the other hand, if you're relying on raw SQL, you'll either be coupling your SQL with your database implementation or writing your own adapter glue (ORMlol).
Most of these absolutist assertions come off as nothing but someone justifying what amounts to intellectual stagnation. The OP conflating MVC frameworks and Twitter Bootstrap pretty much exhibits the sentiment. Quit hating on stuff and find enjoyment in learning new things.
No one is saying ORM is faster then raw SQL, also.. if you were making a billion transactions a day, there would be no need for you to be on WF making posts about ORM or SQL. Look at the real world and code accordingly.
Its faster for me to rob a bank and get $25k then to flip burgers at McDonalds, but that doesn't mean its better for me to actually rob the bank at this time.
Also, there are tons of ways to speed up and secure SQL rather then changing ORM to raw code. Some coders spend hours rewriting their code to get fractional % increase, when they could have just updated their config settings , server, or code base ( non ORM changes ).
my point is, I highly doubt your coding anything that requires a level of a billion transactions a day or something that handles massive amounts of queries a day for any platform that you would then have time to come to WF to argue about SQL.