Rethinking the relational database

TalkBack 8 of 15:: Next »; « Previous

Thread View
Flat View

some calulations: say phone number is stored as a bcd character string, say 15
digits to add some future expansion. that's 8 bytes per phone
number.
Call data per call: num_called num_caller datetime start, long
integer duration in seconds.

This is, say, 32 bytes max per phone call.
Say a user makes 100 calls per day, or about 40,000 per year.
Say your phone company has 100 million customers with the
above usage pattern.

This makes a total annual storage capacity of 128 terabytes of
information.
Say the government wanted you to keep that for 10 years, this
now makes 1280 terabytes of storage in total.

note: we are only storing call records here, not content of call or
text.

However, compared with media, the actual disk IO rate (for the
100 million people) is pretty low:
10 years is 315 million seconds, which is 4 megabytes per
second. I'm sure that striped over a bunch of disks would be
easy to do.
I'm also sure that if you split this into multiple databases based
on subsections of the phone numbers, it would be really really
fast to find an individuals' records.

With hashing and indexes to improve performance, I really can't
see what the problem is here.
Either the person behind this story is mathematically illiterate
(very very common these days), or she's talking about the
government running covert call mapping software trying to find
terrorists from phone call patterns.

As i don't know the first thing about covert stuff, I can't
comment of the practicality of using a RDBMS, although with
their budget, they could probably put the whole database in
RAM!; Posted by: hipparchus2000 Posted on: 05/23/05 You are currently: a Guest | Members login | Terms of Use