Storage is relatively inexpensive — thus it is better to âerr on the sideâ of more storage than you are likely to need.
Fixed Overhead Storage
For obvious reasons, there is significant overhead for the computer operating systems, the database, the web server, and other system software. In addition, there is an amount of fixed overhead for storage of the ExtraView programs, the ExtraView HTML, the application log files, the storage temporary files, and other scripts and libraries. ExtraView recommends that you allow a minimum of 40 GB for this fixed overhead. This is a generous allowance and will give a reasonable amount of spare capacity.
Database Storage
The only real limit to the size of database is the size of database supported by Oracle, MSSQL, MySQL or other database you are using. ExtraView has virtually no constraints beyond the overall limitations of these databases; indeed, ExtraViewâs patent pending database techniques remove several key constraints of how fields and data consume resources within databases using traditional storage mechanisms. As an example, the administrator can add an unlimited number of fields (columns) to an ExtraView database. ExtraView is not bound by the constraints that are especially severe in MSSQL with the number of columns in a table and the total width of a table. ExtraView stores all of your data within the database. If you are planning an installation with more than 250 users, ExtraView highly recommends that you utilize a knowledgeable database administrator for the maintenance of the Oracle or MSSQL database. There are several key areas that affect ExtraView storage requirements:
- Issues stored. This is the main requirement for storage. There are some variables involved. For example, how many User Defined Fields (UDFâs) exist in your installation? ExtraView takes an entire copy of each record as part of its audit trail each time you update a record. On average, how many times will a record be updated, from its creation to its closure? In a typical installation, the size of an individual problem record, including data and index storage is usually 25 KB to 200 KB. The main variable is the creation and usage of a significant number of additional UDFâs of type TEXTAREA, LOGAREA and PRINTTEXT, and how much data is stored within these. Over many customer installations, ExtraView has noted that the average number of updates to an individual issue, from creation to closure, is approximately five. Therefore, it is a reasonable estimate that through its life, each record will require between 125 KB and 1,000 KB of storage including the main and history records. However, these numbers are totally dependent upon your system design and usage pattern, and may vary with your specific circumstances. As an example, if you believe you will create 1,000 new issues per month the likely requirement for storage after a two-year per period will be between 3.0 GB and 24.0 GB.
- User data. Each user requires storage of his personal data, plus personal reports that he or she creates. Overall this is not usually a significant amount of storage. Approximately 50 KB of data per user is a reasonable assumption. As an example, if you have 5,000 users in your community, the storage requirement is approximately 250 MB.
- Metadata. This is all of the configuration data within your system, such as products, modules, customer names, status names, priorities, etc. In most installations this is a modest amount of data amounting to less than 5 MB. However, in large installations, with perhaps thousands of modules and components spread across hundreds of products and with thousands of users, this data may require more space. Large installations may have 100 MB or more supporting metadata.
File Attachments
ExtraView has the capacity to store extremely large file attachments against each and every issue in the system. If your system is to make significant use of file attachments, you must make an allowance for these in your calculations. File attachments are stored in BLOBS in the database or with optional configuration, these may be stored in a location on your file system. There is also a mixed mode where attachments of different types may be stored on the file system or within the database. Oracle has a limit of 4GB for a single file attachment; MSSQL has a limit of 2 GB for the size of a file attachment. Note that file attachments are not copied to the audit trail each time you update a record. This is to prevent the âexplosionâ of storage requirements and to prevent a significant performance penalty if multiple large file attachments were to be copied each time a record was updated. However, accesses to file attachments by users are part of the audit trail. File attachments have a small amount of overhead (less than 1 KB of data), for each one stored in ExtraView.
Text Search Indexes
ExtraView contains a technology we have named Quickfind. This optional feature indexes all the text within the database for extremely fast retrieval. As opposed to performing queries and pattern matching to determine whether records are included or excluded from the results of a keyword search, Quickfind will have pre-indexed all the text including text within file attachments. Searching is extremely quick but at the expense of additional storage. If you are enabling this feature, allow approximately XX% of the database to store these indexes. If you are storing an unusually high number of attachments with issues, or have very large attachments, you might want to allow an extra margin.