Bardzo duże bazy danych

Konkurencja na rynku zmusza firmy do posługiwania się coraz bardziej wyrafinowanymi metodami analizy z coraz większych baz danych. Czy istnieje granica rozmiaru bazy i jak ją określić?

Konkurencja na rynku zmusza firmy do posługiwania się coraz bardziej wyrafinowanymi metodami analizy z coraz większych baz danych. Czy istnieje granica rozmiaru bazy i jak ją określić?

Zgodnie z prawem Moore'a (był taki programista) wydajność procesorów podwaja się co ok. 18 mies., zaś pojemność układów scalonych - co 24 mies. Zapewne to samo prawo da się zastosować do innych elementów komputerów. Trzeba będzie je trochę zmienić w przypadku elementów mechanicznych, takich jak konstrukcje samych dysków i głowic do nich. Ale i tu postęp jest widoczny. Jeszcze na początku 1993 r. przebojem dla komputerów PC był dysk 220 MB. Obecnie przyjmuje się, że podstawowy model komputera do pracy ma mieć dysk 340 lub 420 MB. W ciągu roku zalecana pojemność dysku wzrosła więc o ok. 50% a cena (za MB) zmalała o ok. 30%. (Gdyż obecnie dysk 340 MB kosztuje tyle samo co na początku 1993 r. dysk 220 MB.)

Coraz więcej danych

Jednakże nie ma żadnego prawa określającego przyrost ilości informacji, którą trzeba zmagazynować na tych dyskach. I nie mówię tu w tej chwili o wielkości programów na biurko, które rozrastają się w zdumiewającym tempie. Mam raczej na myśli wielkości baz danych, potrzebnych do działania każdemu przedsiębiorstwu. Gdy w roku 1991 opracowywano poważną aplikację, wydawało się, że pojemność dysków 12 GB w serwerze aplikacji baz danych wystarczy w zupełności. Nikogo jednak nie dziwi, że gdy opracowanie aplikacji zbliża się do końca, sama objętość kodu i aplikacji przekracza 3 GB, zaś przewidywana pojemność bazy danych przekroczy 50 GB!

Potrzebujemy coraz więcej danych. Nawet zwykły supermarket obecnie już nie zadowala się podsumowaniem dziennych obrotów, co kiedyś oznaczało, że potrzebuje zapisać kilkaset kB dziennie. Obecnie zapisuje się każdą transakcję w kasie rejestrującej, łącznie z zestawieniem "koszyka" zakupów klienta. I to wcale nie jakiegoś "średniego" czy "statystycznego" koszyka. Nic takiego już nie istnieje. I nikogo nie interesuje.

Potrzebne są informacje o zawartości koszyka konkretnego klienta. Wyrafinowane metody analizy tych danych pozwolą określić, że pewne zestawy towarów się powtarzają. (Jest bowiem prawdopodobne, że kupując parówki, kupimy także musztardę.) Należy więc odpowiednio do tego ustawić towary w sklepie. Należy także określić strategię zamawiania towarów, aby jak najmniej leżało w sklepie, ale aby nigdy niczego nie zabrakło.

Można sobie wyobrazić, że wspomniany sklep zapisuje dzisiaj kilkadziesiąt, a może nawet kilkaset MB dziennie. A będzie zapisywał jeszcze więcej, gdy nareszcie uda nam się przejść na obrót bezgotówkowy i będziemy mogli płacić czekiem lub kartą kredytową. Każdy z takich środków płatniczych zawiera nasze dane osobowe. Łatwo już da się dotrzeć do naszego wykształcenia, może nawet określić profil naszych indywidualnych zakupów. Cóż więc trudnego, aby na półce sklepu spożywczego pojawiło się nasze ulubione pismo (mam nadzieję, że będzie to Computerworld), beletrystyka dopasowana do upodobań przeważającej części klienteli itp.

Jak ocenić rozmiar bazy danych?

Projektujemy obecnie aplikacje, które powinny służyć klientowi przynajmniej przez 10 lat, jeśli nie więcej. Przypomnę, że na dużych komputerach IBM czy DEC nadal znakomicie działa wiele programów opracowanych ponad 20 lat temu. Można się więc spodziewać, że nasze obecne aplikacje na pewno będą działać w 2005 r.

Jest oczywiste, że będą one rozbudowywane o nowe moduły, ulepszane i dostosowywane do nowych wymagań w biznesie, ale będą to te same aplikacje. Powstaje dość trudny problem jaka będzie pojemność bazy danych, które te aplikacje powinny obsługiwać. Nie da się tego rozstrzygnąć już teraz. Można jednak dość dobrze ocenić rozmiar bazy potrzebnej w najbliższym czasie.

Śmiejemy się wszyscy z praw Murphy'ego. A tymczasem, podobnie jak w mądrościach ludowych, powiedzeniach i przysłowiach, tkwi w nich pewne racjonalne jądro. Otóż jedno z praw Murphy'ego głosi, że informacja rozrasta się w takim tempie, aby zapełnić każdy dysk. Czy da się to wykorzystać do oceny pojemności bazy danych? Ano spróbujmy!

Przyjmę dla uproszczenia, że nasz klient potrzebuje obecnie bazy 1000 GB. (Taka jednostka nosi nazwę terabajta). Obecna cena dysków dla dużych komputerów i serwerów sieciowych wynosi 2 USD za 1 MB (dyski dla PC są tańsze). Tak więc dyski o pojemności 1 TB kosztują obecnie 2 mln USD. Jeżeli go stać, to robimy mu tę aplikację.

Cena dysków maleje rocznie 20-35%, zależnie od tego, których producentów bierze się pod uwagę, przy uwzględnianiu cen ich produktów. Oznacza to, że np. w 2000 r. za te same 2 mln USD będziemy w stanie kupić 3-8,6 TB dysków, zaś w 2005 r. będzie to 9-74 TB dysków. Wartość rzeczywista leży zapewne gdzieś pośrodku. Można więc przyjąć, że w 2000 r. ok. 5 TB dysków a w 2005 r. 26 TB dysków będzie kosztowało 2 mln USD.

I teraz właśnie przydaje nam się prawo Murphy'ego. Całość zostanie zapełniona danymi naszego klienta. Albo innego klienta prowadzącego taki sam rodzaj działalności. Jeżeli więc obecnie projektujemy aplikację korzystającą z 1 GB danych, to za 5 lat będzie ona potrzebowała przynajmniej 5 GB a za 10 co najmniej 26 GB. Tak więc opracowując aplikację z dziedziny baz danych pamiętajmy o rynku i prawach Murphy'ego i dopasujmy jej rozmiar do zmieniających się wymagań. Na dodatek wydaje się, że sposób oceny tempa rozwoju bazy przy użyciu prawa Murphy'ego jest równie dobry, jak patrzenie w sufit.

Obecnie projektowane aplikacje korzystają z 1 GB danych, za 5 lat będą one potrzebowały przynajmniej 5 GB - a za 10 co najmniej 26 GB.


TOP 200