IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Interesting
Since all the logic in a proc has to happen somewhere, I would assume doing it outside the DB would take longer on head-to-head, no-load comparisons. As long as the logic happening in the proc has to be atomic, wouldn't that continue to get worse as things scale?

In fairness, I'm not a DBA so I'm assuming there's something in DB world that's like the multiple small compute instances you can do with app servers. I've never built out DB infrastructure at this scale though, so I'm coming from the standpoint that I can't be the only one trying to do this so someone must have solved this.
--

Drew
New I've looked at DB scale out, though not recently.
In a previous job, we ran into questions about how to tackle that kind of problem.

Read-scaling can be done with simple replication, if you don't need transactions. We did that, and that was reliable. It helped I was also one of the web programmers and could build the database abstraction layer to load-balance SQL Selects.

Another method is sharding, which seems to have matured in the last few decades. We would've had to do it ourselves when we looked at the concept and I wasn't sure I was up to doing that! The Wikipedia article has more information.

Wade.
New Eventually the amount of work exceeds the capacity of a single machine to do it
At which point you have a distributed system whether you want it or not, and a distributed database is one of the hardest things to get right.
Regards,
-scott
Welcome to Rivendell, Mr. Anderson.
     Are stored procs "hiding functionality"? - (drook) - (23)
         wag, the same as a shared library, you dont know where it came from -NT - (boxley)
         Interesting question. - (Another Scott) - (1)
             Better to manage that sort of problem through services - (malraux)
         Depends on how they're managed. - (malraux) - (10)
             And don't forget about sp's providing better performance on the database. -NT - (mmoffitt) - (9)
                 That depends - (malraux) - (8)
                     For OLTP applications, I disagree, with MS Sql Server anyway. - (mmoffitt) - (7)
                         Performance is the least of my concerns at this point - (drook) - (1)
                             Until it isn't any more. :-) - (malraux)
                         Performance != throughput - (malraux) - (4)
                             Interesting - (drook) - (2)
                                 I've looked at DB scale out, though not recently. - (static)
                                 Eventually the amount of work exceeds the capacity of a single machine to do it - (malraux)
                             sure, lets take the speed out of the cpu and replace it in multiple small connected units, :-) -NT - (boxley)
         Implementation detail, someone else's problem. - (pwhysall)
         Who is responsible for what? - (crazy) - (5)
             I'm coming down on the side of your data integrity comment - (drook) - (4)
                 Sounds like a management problem. - (static) - (2)
                     You think? - (drook) - (1)
                         Not surprised at all. - (static)
                 Someone's going to be writing something that deals with integrity. - (malraux)
         Re: Are stored procs "hiding functionality"? - (mvitale) - (1)
             I used utPLSQL in a former life. - (malraux)

Your Freak God[tm] was HERE!
89 ms