2013-09-16 16 views
6

Przez długi czas korzystałem z projektowania baz danych zorientowanych na rzędy, a poza projektami datawarehouse i Big data sample, nie korzystałem z projektu bazy danych z kolumną dla aplikacji OLTP.Baza zorientowana na kolumnę a baza zorientowana na wiersz

Moja zorientowane wiersz tabeli wygląda

ID, Make, Model, Month, Miles, Cost 
1 BMW Z3  12  12000 100 

Niektórzy ludzie w naszym zespole opowiada kolumny zorientowane bazy danych projektu. Sugerują one, że wszystkie nazwy kolumn powinny być nazwami właściwości w tabeli Właściwość. Następnie inna tabela Cytat będzie miał dwie kolumny Nazwa właściwości i Wartość właściwości.

W kodzie .net czytamy każdy klucz i porównujemy i konwertujemy na obiekt silnie wpisany. Kod jest naprawdę brudny.

if (qwi.DomainCode == typeof(CoreBO.Base.iQQConstants.MBPCollateralInfo).Name) 
    { 
     if (qwi.RefCode == iQQConstants.MBPCollateralInfo.ENGINETYPE) 
     { 
      Aspiration = qwi.Value; 
     } 
     else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.FUELTYPE) 
     { 
      FuelType = qwi.Value; 
     } 
     else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.MAKE) 
     { 
      Make = qwi.Value; 
     } 
     else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.MILEAGE) 
     { 
      int reading = 0; 
      bool success = int.TryParse(qwi.Value, out reading); 
      if (success) 
      { 
       OdometerReading = reading; 
      } 
} 
} 

arguement dla tej kolumny zorientowanych projektu jest to, że nie będzie musiał zmienić schemat tabeli i przechowywanej proc (nadal jesteśmy przy użyciu przechowywanej proc zamiast Entity Framework).

Wygląda na to, że zmierzamy do prawdziwego problemu. Czy projektowanie zorientowane na kolumnę jest dobrze akceptowane w branży.

+1

Wygląda na to, że pytanie nie ma nic wspólnego z DBMS zorientowanymi na kolumny (magazyn kolumnowy). Pytanie dotyczy właśnie wzoru projektu EAV. – sqlvogel

+0

"wciąż używamy zapisanego proca zamiast Entity Framework" Grałem z EF w wielu mniejszych i średnich projektach i nie myślę już, że EF jest drogą do zrobienia. Z tego, co przetestowałem i rozumiem, EF musi mieć dane w pamięci, aby móc nimi manipulować (tzn. Aktualizować), które często blokują drzwi, gdy rozważana jest poważna praca. – Mariusz

+0

„my nadal używa przechowywanej proc zamiast Entity Framework” EF wydaje się potrzebne dane w pamięci, aby móc je modyfikować, więc coś tak prostego jak: UPDATE dbo.MyTable SET Aktywny = 1, gdzie aktywny = 0 za dużą ilość danych może nie być trywialnie za pomocą EF (ale uwielbiam to również, gdy kopie tyłek na duży czas) – Mariusz

Odpowiedz

10

Mam problem z Twoją terminologią. Opisujesz strukturę EAV (stojącą dla Entity-Attribute-Value).

Pomiń: Baza danych "zorientowana na kolumnę" zwykle odnosi się do bazy danych, która przechowuje każdą kolumnę oddzielnie od innych (kiedy dowiedziałem się o bazach danych, było to nazywane "partycjonowaniem pionowym", ale nie sądzę, że został złapany) . Przykłady obejmują Paracel i Vertica.

Baza danych wartości atrybut-podmiot przechowuje każdy atrybut jednostki jako osobny wiersz.

Pierwszy problem z twoją strukturą polega na pisaniu. Niektóre z atrybutów są łańcuchami, a niektóre liczbami. Staje się to koszmarem zarządzania w świecie EAV.Albo przechowujesz wszystko jako łańcuchy (tracisz zdolność do wpisywania wartości kontrolnych i do zagwarantowania, że ​​słowa arytmetyczne) lub dodajesz wiele kolumn dla różnych typów z kolumną typu (czyniąc zapytania bardziej skomplikowanymi).

Podobnie, ograniczenia i odniesienia do kluczy obcych są znacznie trudniejsze do wdrożenia. Ponadto, ponieważ powtarzacie identyfikator podmiotu i atrybut w każdym wierszu, dane często zajmują więcej miejsca. Wartości NULL są zwykle dość wydajne.

Po stronie OLTP masz inny problem. Gdy chcesz wstawić encję, zazwyczaj chcesz wstawić również kilka atrybutów. Jedna wstawka zmieniła się teraz w wiele wstawek, a będziesz chciał zacząć je zawijać w transakcjach, wpływając na wydajność.

Biorąc pod uwagę wszystkie te niedociągnięcia, można pomyśleć, że nigdy nie używać modeli EAV. Jest dla nich miejsce. Są szczególnie przydatne, gdy atrybuty zmieniają się w czasie. Załóżmy, że masz aplikację, w której użytkownicy mogą umieszczać własne informacje za pomocą tagów. W takich przypadkach najlepszym rozwiązaniem jest podejście hybrydowe. Użyj zwykłej tabeli relacyjnej z wieloma kolumnami dla wspólnych informacji. Użyj tabeli EAV dla opcjonalnych informacji dla każdej jednostki.

4

Źródło: WIKI

  1. organizacje Kolumna zorientowane są bardziej efektywne, gdy agregat musi być obliczony na wiele wierszy, ale tylko dla szczególnie mniejszych podzbioru wszystkich kolumn danych, bo czytając, że mniejszy podzbiór danych może być szybszy niż czytanie wszystkich danych.
  2. Organizacje zorientowane na kolumnę są bardziej wydajne, gdy nowe wartości kolumny są dostarczane dla wszystkich wierszy jednocześnie, ponieważ dane z tej kolumny można zapisać wydajnie i zastąpić stare dane kolumny bez dotykania innych kolumn dla wierszy.
  3. Organizacje ukierunkowane na wiersze są bardziej wydajne, gdy wiele kolumn pojedynczego wiersza jest wymaganych w tym samym czasie, a rozmiar wiersza jest względnie mały, ponieważ cały wiersz można pobrać za pomocą pojedynczego wyszukiwania dysku.
  4. Organizacje ukierunkowane na wiersze są bardziej wydajne podczas pisania nowego wiersza, jeśli wszystkie dane kolumn są dostarczane w tym samym czasie, ponieważ cały wiersz można zapisać za pomocą pojedynczego wyszukiwania dysku.

W praktyce zorientowane na rzędy układy pamięci są odpowiednie dla obciążeń podobnych do OLTP, które są bardziej obciążone transakcjami interaktywnymi. Układy pamięci zorientowane na kolumny są dobrze dostosowane do obciążeń podobnych do OLAP (np. Hurtowni danych), które zazwyczaj obejmują mniejszą liczbę wysoce złożonych zapytań dotyczących wszystkich danych (prawdopodobnie terabajtów).

+1

Oczywiście, że masz rację, ale pytanie nie wymagało przechowywania kolumnowego :-) – dnoeth

3

Oprócz problemów Gordon Linoff wymienia modele danych EAV są również piekielnie trudne do zapytania - znaleźć wszystkie samochody, gdzie zrobić to BMW i miesiące od 12 do 24, a koszt < 10000 staje się ogromny galimatias paskudny SQL , zwłaszcza jeśli robisz porównania ciąg na liczbach ...

0

Ogólnie wiersz i kolumna zorientowane zorientowane jest mechanizm przechowywania na niskim poziomie (na dysku). Dobroć każdego magazynu zależy od twoich wymagań. W niektórych scenariuszach pamięć zorientowana na kolumnę przyniesie lepsze wyniki, aw niektórych scenariuszach zorientuje się na wiersz.

W bazie HBA są z wykorzystaniem koncepcji kolumnie rodziny, która jest grupą kolumn.

Różnica pomiędzy rząd zorientowany jest logicznym tabeli składające się z rzędów są przechowywane w rzędzie jeden wiersz, podczas gdy kolumna bloku zorientowane sklepach jednej kolumny na blok kolumny.

Zorientowane na wynik w wierszu wyniki są słabe, gdy odpalamy zapytania, które są analityczne (takie jak suma pensji, średnia pensji), ale działają prawidłowo, gdy potrzebujemy uzyskać dostęp do poszczególnych szczegółów wiersza lub wstawić nowy rekord. Podczas gdy kolumny zorientowane na kolumny działają dobrze na zapytania analityczne, ale powodują słabą wydajność do wstawiania pojedynczych rekordów lub uzyskiwania dostępu do wszystkich szczegółów rzędu.

Możesz odwiedzić ten link, które mają opisywać różne scenariusze swoje plusy i minusy z przykładu i ich różnicy podsumowania.

kliknij tutaj: http://geekrandomstuff.blogspot.tw/2014/04/row-oriented-database-vs-column.html

0

Z mojego doświadczenia EAV jest idealne do przechowywania aplikacji ustawienia IE. stosunkowo statyczne dane bez potrzeby dalszego łączenia i przekształcania danych, nic ponadto.