Well, I mean you could use an adze or a froe. Axes are really common in green woodworking (chair making) and they’re great for getting wood to split along the grain.
167 karma · joined December 29, 2009
blog at http://facility9.com
However, it is a bit too large for a bike commuter and I'll be selling it on eBay shortly.
By "empirical proof", I mean that I have never seen anyone conclusively prove that switching data access from stored procedures to ad hoc SQL through an application was the cause of performance improvement. I've seen proof that removing complex application logic from the database fixed a problem, or that better indexing improved performance, but I've never seen anyone prove that removing stored procedures alone fixed the problem.
Further, there's nothing in your proposed solution of scaling out with readable replicas that precludes the use of stored procedures for data access. As a huge fan of both databases and separation of concerns, stored procedures make tremendous sense. They let a domain expert tune the database as needed. Even going so far as allowing that expert to re-write queries, provide optimizer hints, or even change the physical data model for better performance without ever changing application code.
Although I may or may not be competent, I have scaled "stuff" in a database. But I do appreciate you getting a vague ad hominem into the first sentence. Bravo.
The typical bottlenecks that I found were almost always IO - either through crappy storage, crappy indexing, or some combination of the two. Modern databases typically aren't bottlenecked by the lock manager.
I'd also agree that moving work out to a NoSQL database is particularly tricky. For three years I maintained the .NET Riak client and helped developers make better decisions when they were considering moving away from an RDMBS.
It turned out that their client was enumerating folders and files looking for changed data rather than hooking into the OS X file system notifications. We really liked it for the corporate account since it's possible to selectively grant outside parties access to files/folders.
So, when your data volume exceeds what will fit in RAM, I'm guessing that your plan is to shard to multiple MongoDB servers. Is your plan to continue to add multiple replicas to each shard to handle DR?
So, thanks already for taking a look at our code and poking at it.
Thanks for reading it all.
Build your database tier using everything they taught you in the classroom. Normalization is your friend here. Why? When you've effectively normalized your database, you can monitor the results of queries and eventually introduce the optimizations that you need to make things run faster.
The problems that sites like highscalability.com deal with are far beyond the scale of most endeavors. If you run into massive scale problems, be very happy because it means you're building something that people want and you can afford to throw some money at the problem ;)
I know people who have production databases with 30+ terabytes that is sitting in a relational database. If you design well, you shouldn't have any problems reaching those goals.
At the end of the day, every communication with your employer is an opportunity. If you can't communicate well, you will be less likely to get what you want out of those interactions. On the other hand, if you're able to write well and communicate clearly, you're going to get what you want far more often.