I'm finally getting around to posting the slide deck that presented at SharePoint Saturday KC.  The topic was "Architecting for Scale in SharePoint 2010" It's a pretty juicy deck with lots of detail that will help you with storage architecture and SQL tuning.  It also provides good background on Remote BLOB Storage (RBS) and the improvements to the search subsystem in SP2010. You'll find the slides here: Architecting for Scale in SharePoint 2010

Binary Large Objects, or BLOBs as the SQL types like to call them, are the byte arrays that represent documents and other files in SharePoint.  Typicaly, they are stored in the SharePoint content database.  The reality is, the ECM industry has known for decades that RDBMS is not the best place to store BLOBs.  SQL database storage needs to be high IOPS and low latency... translated... EXPENSIVE storage.  It's much more efficient if we are able to store the BLOBs on lower cost, possibly even archival-class storage while we continue to invest in high performance storage for the structured content metadata. As...

So this has been a long time coming.  It's been over a year since I originally wrote the Storage Architecture whitepaper and it was in need of refreshing. While the original content was certainly accurate, there were a few things that I wanted to clarify, particularly after having attended the SharePoint Master training.  There were also a couple things for which conventional wisdom has shifted a bit like the fact that we are now allowed to split the SearchDB into 2 file groups. Also, I wanted to add in some additional guidance on a few more topics that I receive a LOT...

Ok. So after writing that last post on the 100GB database limitation I got some nice feedback from several people. Also, I'm finding that this is information that really needs to get "out there". Far to often, KL is brought in to implement a document imaging or file share conversion solution in SharePoint. The problem lies in the fact that often times the sandbox that everyone learns to play in becomes production! This ends up presenting a lot of challenges for us as consultants when tryi