Databases Reference
In-Depth Information
BirthDate
01-01-1968
02-02-1971
03-03-1970
04-04-1963
05-05-1967
…
…
…
09-09-1972
Address
4
th
Cross, Bangalore
Central Square, Ranchi
H. City, Hyderabad
Chembur, Mumbai
…
…
…
New Town, Kolkata
Name
S Vohra
S Choubey
S Raj
M Iyer
R Menon
…
…
…
S Mohanty
Gender
M
M
F
F
…
…
…
M
Person ID
1
2
3
…
…
…
5,00,000,000
…
…
…
…
…
…
Figure 6-10.
Column family: Census data example
The obvious problem is that analyzing this census data to answer a question
such as “How many men were born in each year?” also entails reading the name and
address of each person, together with whatever other data is present in each row.
Columnar databases were devised to solve this problem. These databases store
each column separately so that aggregate operations for one column of the entire table
are significantly quicker than the traditional row storage model. The problem with
this columnar approach is that getting all the data for a single person becomes very
expensive because the database must fetch data from numerous places on disk and
glue together all those columns to represent a single row.
In contrast, in a CFDB design, columns of related data are grouped together
within one table as shown in Figure
6-11
. The person table has now been subdivided
so that all personal name and address data is grouped together, as is statistical
demographic data for each person. Any other columns in the table would be grouped
accordingly as well.
