How to structure big data in a SharePoint portal

Question

We are using SharePoint 2013 on premise, and are building a portal for showing content and for document managemenet.

Originally we wanted to organize our portal in a hierarchial structure to mirror the organization, but this will get problematic when we will migrate 3 TB of data into this portal.

Any advice on how we should organize our strcture?

Answer 1

SharePoint Server can be extended to handle huge data (that means, you can add more resources / servers to the existing farm). Data can be organized using following entities

1. Site Collection
2. Sites
3. List and Libraries
4. Content Types
5. Managed Terms etc.

Content organization/structure entirely depends on the kind of data/process your organization is following.

Content structure is one of the key area that is included as part of planning SharePoint deployment.

Below are the list of points that can help you to start with

1. Analyze existing documents. Determine document types, properties;
2. Create a flexible and easily extendable Content Type structure;
3. Choose where and how to store documents in SharePoint;
4. Create fields, sites, libraries and lists. Add Content Types;
5. Plan for permissions;
6. Define and automate SharePoint document naming;
7. Unify document templates location;
8. Distribute content to smaller files;
9. SharePoint Document Automation;
10. Implement Workflows;
11. Optimize views and libraries;
12. Findability and Search;
13. Backup & Recovery;
14. Plan retention and SharePoint Content database growth;
15. Have a Migration plan;

General planning recommendations

It is useful to divide information analysis for Web site planning into the following stages:

• Survey existing content and Web site structure Your current Internet or intranet site reflects its current information architecture. Analyze and record how information and content are distributed across your current sites and subsites. Look at logs or other analysis tools to see what content is most frequently accessed and least frequently accessed.
• Survey user requirements Survey the current site users and intended site users, and record the kinds of information that they create or use. What information do they need in their daily work? Are they able to find that information easily? Does the current Web site structure help them understand the relationships among the different kinds of information that the site contains? Is there missing information? Note any problems the users have in finding or using information with the site's current architecture.
• Survey business requirements Survey the managers of the business unit or organization that the Web site is being designed for. What are the business needs of the site? Should the units or divisions of the business be reflected in the information architecture of the site? How will information be shared across business units, or will it be isolated within one unit? If the site is targeted at customers, what information should they first encounter? How will they explore information about products or services?

http://technet.microsoft.com/en-us/library/cc262873(v=office.14).aspx