Tell me more ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.
up vote 0 down vote favorite

Here is my situation:

We are working on a scan-to-SP solution for our remote locations. The scanning will take place throughout the day/night. Our current estimated Total Daily Scans will number around 7,500-10,000 with most scanned documents (PDF) around 1.5 - 2 KB in size (20G / day of documents at max). We will be using a third party back up solution to offload the documents after X weeks / months (TBD). My question is how should we go about storing these documents utilizing our SharePoint environment? Should the docs be stored within the content DB as usual or should we use RBS/BLOB storage?

Thank you

Jason

share|improve this question
What sort of storage are you using? Can you afford to drop 20 GB of data into this storage each day? How many days before you fill up this storage? Also, will you be indexing the PDFs? – shufler Apr 19 '12 at 16:52
We can and will be able to handle this kind of storage capacity, maintain document security and maintain a high standard of network / dB io performance. We are currently not looking at indexing the PDFs. – Jason D Apr 19 '12 at 21:44

2 Answers

up vote 2 down vote

While externalizing BLOBs may solve some of your performance concerns it doesn't sound like it is going to solve your core problem which is the amount of content and speed that you are throwing this content into SharePoint. Make sure you heavily review your architecture to ensure you are supporting the database IOPS required as well as understand the software boundaries of large databases.

Externalizing BLOBs is not a solution to get over the 200GB recommendation within SharePoint.

http://technet.microsoft.com/en-us/library/cc262787.aspx#ContentDB We strongly recommended limiting the size of content databases to 200 GB, except when the circumstances in the following rows in this table apply. If you are using Remote BLOB Storage (RBS), the total volume of remote BLOB storage and metadata in the content database must not exceed this limit.

Refer to this white paper to gain a better understanding regarding managing multi-terabyte content databases with SharePoint 2010. http://www.microsoft.com/downloads/details.aspx?FamilyID=37B1333C-A8D9-45F9-BE78-9212C2CD3641&displaylang=e&displaylang=en

share|improve this answer
Thank you, Cory, for the link. We will NOT be hitting this high of a capacity for at least a year to year and a half (if even that). We will be able to roll this out a little at a time so our infrastructure, testing and capacity management will be tweaked as we move along. – Jason D Apr 19 '12 at 21:42
Also forgot to mention that we will be creating a site collection and subsequent content db for each remote site. I'm working on some code to create the new content db when the site collection is created for the remote site. – Jason D Apr 19 '12 at 21:55
Re: the 200 GB recommendation -- this is performance-related (and is a good recommendation). Given that this would be exceeded in 10 days, it's worth pointing out that provided you have the infrastructure to support it you can go over this if you want. Microsoft will support a content database of up to 4 terabytes. – shufler Apr 20 '12 at 2:28
Yep @shufler, good point. I did include the multi-terabyte white paper in my response as it's true that Microsoft does support the larger databases (that didn't use to be the case). We commonly see clients under plan this level of capacity so I like to be safe. – Cory Peters Apr 20 '12 at 18:43
up vote 0 down vote

Go BLOB, thats a lot of documents to be contsantly going in and out of your database. Could cause a lot of performance issues. Also what is the time frame? Keep in mind SharePoint Thresholds of 30 million documents per document library. 60 million objects per content database. See here for thresholds. http://technet.microsoft.com/en-us/library/cc262787.aspx . Are you using a third party tool for scanning the documents in?

share|improve this answer
Thank you, Cory for your response. My assumption here is "time frame" meaning how long do we intend to keep the documents? Here is how our process is going to work: User Scans > Scan to Drop Off Library --> Content Org Rule processes doc and routes --> User is going to edit metadata assigned to documents --> document is routed to subfolder based on metadata --> document remains in subfolder for up to x Weeks --> Document is then archived via 3rd party (evault) My thoughts on this were to use RBS to keep from hammering SQL too hard. (gotta get used to hitting "shift return" - :) – Jason D Apr 19 '12 at 19:03
Sorry, yes time frame did mean how long to keep the documents. You may have already considered these but other things to think about are how large is your farm, are you intending to index these libraries. Those could all hurt your performance as well. Items still could be getting dropped in. 10000 items a day is a lot of documents for users to enter metadata, would it be more cost effective to have something like KnowledgeLake (which can use StoragPoint for BLOB storage) Granted maybe you have 10000 users and that point is moot. – Cory Apr 19 '12 at 19:13
(for clarity I rounded) we have 100 locations, each location has an average of 10 users and each user will scan an average of 10 documents a day. I've looked into StoragePoint and I'm currently looking at KnowledgeLake per your suggestion. Thank you – Jason D Apr 19 '12 at 19:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.