.:: strefa ::.

Systemy informatyczne przetwarzają coraz większe ilości danych, w naturalny sposób pojawia się więc coraz większa potrzeba ich automatycznej analizy i obróbki. Deweloperzy związani z bazami danych muszą tworzyć specyficzne, dedykowane rozwiązania, a wybór odpowiedniej technologii to praktycznie klucz do sukcesu. Chciałbym porównać dwie wybrane platformy - .NET i Perl - w hipotetycznym scenariuszu automatycznego przetwarzania danych.

Wspomniany scenariusz zakłada potrzebę wyznaczenia rekordów podobnych w bazie klientów, a dokładniej - w tabeli, która zawiera 10000 wierszy z danymi teleadresowymi (przykładowe kolumny: nazwa, miejscowość, adres, kod, nip). Dane w bazie są zwielokrotnione, tzn. kilka rekordów w rzeczywistości opisuje jednego i tego samego klienta (zapisanego oczywiście w różny sposób, np. "FIRMA HERKULES", "HERKULES S.C.", "HERKULES - SKLEP"; analogicznie z danymi adresowymi: "WIEJSKA 15", "ULICA WIEJSKA" itd.). Aby zrealizować cel, do tabeli zostanie dodana kolumna unikalnego identyfikatora, a algorytm zapełni ją odpowiednimi wartościami, przydzielając rekordom dostatecznie podobnym taki sam identyfikator. Zakładamy ponadto warunek brzegowy (minimalizacja ryzyka błędu): rekordy oznaczone jako podobne muszą posiadać identyczny NIP.

Zadanie opisane wyżej to klasyczna deduplikacja danych. Od prawie 2 lat zajmuję się m.in. procesami inteligentnej analizy, przetwarzania danych i obserwuję w ostatnim czasie znaczący, dynamiczny wzrost popularności tej tematyki. Złoty wiek różnorodnych automatów właśnie się rozpoczął.

Wracając do naszego scenariusza, można sobie wyobrazić co najmniej kilka koncepcji algorytmu deduplikacji, oczywiście każdy z nich ma swoje mocne i słabe strony. Skupiamy się na technologii, a nie na funkcjonalnościach - więc dodam tylko, że do oceny zgodności poszczególnych pól użyłem metody Levenshtein-Distance (google zaprasza zainteresowanych).

Środowisko testowe wyglądało następująco: serwer Windows Server 2003 SE 32bit, baza danych SQL Server 2005 SP1, wszystko postawione na jednej maszynie (na której uruchamiane były również testowe implementacje). Jak widać środowisko zostało dobrane tak, żeby lekko faworyzować platformę .NET. Implementacja algorytmu w CLR (język C#) to klasyczna aplikacja obiektowa z providerem OLE DB (natywne rozwiązanie względem SQL Servera).

Algorytm został również zaimplementowany w Perlu (wersja 5.8.8), dostępem do danych zajmował się moduł DBI działający na providerze ODBC.

Mamy więc pojedynek technologii, za którą stoją miliardy dolarów w jej naturalnym środowisku - i - technologii open source, która dzięki wieloletniej pracy rzeszy ludzi została wysoce zoptymalizowana do przetwarzania danych, a wyrażenia regularne traktuje tak samo natywnie jak choćby instrukcję warunkową IF. Poniżej przedstawiam wyniki:

(średni czas dla 3 prób)

PERL:
81 s

.NET:
127 s

Wyraźnie zwyciężył więc Perl, który zadanie wykonał o 55% szybciej niż konkurent (jakość była jednakowa w obydwu przypadkach, zgodnie z założeniem). Nie pierwszy raz przekonałem się, że Practical Extraction and Report Language nie ma sobie równych wśród technologii do przetwarzania danych. Warto też dodać, że obydwie implementacje powstały w tak samo krótkim czasie, mimo że do stworzenia kodu w Perlu wykorzystałem zwykły edytor tekstowy, a do .NET - potężne Visual Studio 2005 z pełnym intellisense i innymi programistycznymi udogodnieniami.