<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-785B2F0B-E7E6-5DAE-98F1-6C32BED25964" xml:lang="en"><title>Database
storage overhead</title><shortdesc>Database storage is very efficient. This document gives details
of the storage overhead.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>Space utilization is efficient</p>
<ul>
<li id="GUID-8AE05C00-0C7E-5D9C-AC2B-DC1D5432DF0D"><p>the underlying permanent
file store adds minimal overhead to maintain its structure: store imposes
a fixed 46 bytes + two bytes per additional 16K; each stream requires seven
bytes.</p> </li>
<li id="GUID-5BDB30B0-9140-55AA-A7BE-4C4B30355ADE"><p>the database has minimal
space requirements to store its schema and data structure.</p> </li>
<li id="GUID-3FCF5F99-767F-5526-B0AF-40F7F248CF26"><p>including the stream
overhead, row storage overhead can be less than two bytes per row in ideal
clustering conditions, even with lower clustering the overhead is usually
below 1% of the data volume.</p> </li>
</ul>
<p>The storage required for a row can be determined as follows:</p>
<ul>
<li id="GUID-41E7E40C-6E34-5C7A-BB82-A0AF92B5D455"><p>each non-null value
requires the storage for fixed width columns, and the raw storage plus one
byte for variable width columns.</p> </li>
<li id="GUID-845C1A45-8C1F-5EA0-A3A6-787359332505"><p>long columns are stored
embedded in the row data when they are small enough, and otherwise they are
stored in a separate stream: this makes more efficient use of the both space
and speed. When embedded they require just one bit more than the short columns,
when separated they require eight bytes in the row data plus any stream overhead.</p> </li>
<li id="GUID-CD64205E-894B-50D3-9AAA-ACA375D820EA"><p>each nullable column
requires one extra bit.</p> </li>
<li id="GUID-4FF233BB-3863-5869-9E6E-E56AC3B29924"><p>bits are packed into
bytes in the row storage.</p> </li>
</ul>
<section id="GUID-14305B1D-41AF-452E-9E44-131569F00FBC"><title>Indexes</title> <p>Indexes
are implemented using STORE B+trees. Note in particular that indexes use fixed
length keys, so that indexes on longer text fields can consume significant
space.</p> <p>If the key for the index is <i>k</i> bytes, the number of rows
to index is <i>n</i>, the index page size is <i>P</i>, and the B-tree packing
density is <i>r</i>:</p> <p><i>a = [(P-8)/(k+4)] * r</i> </p> <p>Where <i>[x]</i> is
the largest integer &lt;= <i>x</i>. Then the number of pages required, <i>N</i>,
is</p> <p><i>N = n * (1/a + 1/(a*a))</i> </p> <p>Each page requires <i>P+7</i> bytes
in the store, so the total indexing overhead, <i>S</i>, is</p> <p><i>S = N
* (P+7)</i> </p> <p>For DBMS <i>P=512</i> and <i>r=0.86</i>.</p> </section>
</conbody></concept>