Czy powinienem zainstalować 32-bitową bazę danych czy 64-bitową bazę danych?

(Dużo czytałem o 64-bitowym kontra 32-bitowym systemie operacyjnym / aplikacjach, ale to pytanie dotyczy w szczególności baz danych).

Próbuję zrozumieć zalety i wady 32-bitowych i 64-bitowych baz danych, a mianowicie, w jakich warunkach zacznie mieć sens używanie instalacji 64-bitowych.

Systemy baz danych, którymi jestem zainteresowany, to: SQL Server 2008, MySQL i PostgreSQL 9.0.

Przeczytałem, że wersje PostgreSQL w wersji wcześniejszej niż 9.0 są dostępne tylko w wersji 32-bitowej dla systemu Windows, a ten artykuł na temat uruchamiania 32-bitowej wersji PostgreSQL w 64-bitowym systemie Windows rozwiązuje niektóre moje problemy, ale szukam więcej informacji.

Kiedy skorzystam z korzystania z 64-bitowych baz danych (tj. Rozmiar bazy danych / miejsce na dysku, dostępna pamięć systemowa, typy sernariów danych, o których wiadomo, że z niej korzystają, jaki silnik bazy danych jest używany itp.)?

w jakich warunkach korzystanie z instalacji 64-bitowych ma sens.

W ogóle poza byciem idiotą. Przepraszamy - po co instalować 32-bitową bazę danych na 64-bitowym serwerze? I - wyobraź sobie - SERVER 2008R2 jest dostępny TYLKO w wersji 64-bitowej.

Nie ma - na dzień dzisiejszy - scenariusza, w którym sensowne byłoby zainstalowanie 32-bitowej wersji SQL Server, jeśli jest taka szansa.

Bazy danych są w tym specyficzne - ponieważ w razie potrzeby chcą użyć dużej ilości pamięci jako pamięci podręcznej. O wiele więcej niż skromne 2 gb / 3 gb 32-bitowy proces może im dać. PAE to nie to samo. Nawet ignorując limity, pamięć PAE nie jest równa pamięci rzeczywistej dla SQL Servera (jest używana tylko do JEDNEJ rzeczy - buforowania stron db).

32-bitowy system operacyjny - jest na tym samym poziomie. na nowoczesnym sprzęcie nie ma sensu instalowanie 32-bitowego systemu operacyjnego.

PostgreSQL korzysta z 64-bitowej wersji na dwa główne sposoby. Po pierwsze, typy danych, które mogą zmieścić się w 64-bitach (głównie większe liczby całkowite i typy znaczników czasu), mogą być bardziej efektywnie przekazywane bezpośrednio w rejestrach niż przy użyciu wskaźników. Po drugie, można przydzielić więcej pamięci na dedykowany bufor bufora bazy danych. Punkt malejących zwrotów z tego przestrajalnego (shared_buffers) wynosi zwykle około 8 GB, ale będzie ograniczony do <2 GB w systemie 32-bitowym.

Jednak w systemie Windows PostgreSQL nie obsługuje pamięci współużytkowanej tak skutecznie, jak na platformach UNIX. Punktem malejącego zwrotu jest zazwyczaj <= 512 MB pamięci dedykowanej dla bazy danych, niezależnie od tego, czy masz 32-bitową czy 64-bitową wersję PostgreSQL. Lepiej zostaw resztę pamięci podręcznej systemu operacyjnego niż dedykuj ją bazie danych. W związku z tym naprawdę nie ma tak dużego wzrostu wydajności z 32 do 64 bitów w przypadku PostgreSQL w systemie Windows; główny tuning, który normalnie skorzystałby z posiadania większej ilości pamięci RAM, w rzeczywistości nie wykorzystuje go zbyt dobrze.

Używam MySQL na architekturze 64-bitowej, ponieważ chcę, aby najbardziej efektywnie wykorzystywały ponad 4 GB pamięci na wątek. Ogólnie rzecz biorąc, powinno to dotyczyć wszystkich baz danych.

Jedną z podstawowych różnic między architekturami jest zwiększone adresowanie, które pozwala na lepszą obsługę pamięci. Chociaż rozszerzenie adresu fizycznego firmy Intel umożliwia adresowanie powyżej 4 GB, nadal jest ograniczone do 4 GB na wątek. PAE pozwala na maksymalnie 64 GB.

Wikipedia ma porównanie wersji 64-bitowej i 32-bitowej, która zawiera więcej szczegółów na niskim poziomie.

Pamiętaj, że jeśli masz tylko 64-bitowe biblioteki klienta MySQL, podczas próby połączenia ich z 32-bitowym kodem wystąpią błędy „niewłaściwej architektury”. Zdarzyło mi się to, gdy próbowałem zainstalować powiązania Pythona („pip install MySQL-python”).

Można używać 64-bitowego serwera MySQL z 32-bitowym klientem MySQL i szkoda, że ​​serwer społeczności MySQL nie zawiera 32-bitowej i 64-bitowej wersji biblioteki klienta. Poprawne rozwiązaniem jest zainstalowanie dodatkowych 32-bitowych bibliotek klienta MySQL. Ponieważ jednak najłatwiejszym sposobem zainstalowania MySQL jest pobieranie binarne MySQL Community Server , a biorąc pod uwagę, że 64-bitowy instalator jest wyposażony tylko w 64-bitowe biblioteki klienta, ścieżką najmniejszego oporu jest po prostu pobranie 32-bitowego instalatora .

(wszystko to przy założeniu, że zawsze będziesz używać bardzo małych zestawów danych)

W przypadku tak wielu rzeczy 32-bitowy wygrywa (pod warunkiem, że możesz żyć z przestrzenią adresową), ale DB to jedna rzecz, w której nawet małe bazy danych mogą uzyskać prawdziwy wzrost wydajności w 64-bitowym. To prawda, że ​​nie wiem nic o serwerze MS SQL, ale widziałem testy porównawcze (na przykład na Sun 5 (starszy 64-bitowy pulpit Sun), 32-bitowy był ogólnie nieco szybszy, z wyjątkiem mysql, który miał 30 % szybciej w 64 bitach.