Baza danych do superszybkiego wysyłania zapytań

Question

Mamy tablicę danych o wielkości 300 Gb +, którą chcielibyśmy zapytać tak szybko, jak to możliwe. Tradycyjne bazy danych SQL (w szczególności SQL Server) nie mogą obsłużyć tego woluminu tak skutecznie, jak potrzebujemy (np. Wykonujmy select z warunkami 10-20 w klauzuli where w czasie krótszym niż 10 sekund), dlatego badam inne rozwiązania tego problemu.

Czytałem o NoSQL i to wszystko wygląda obiecująco, ale wolałbym usłyszeć od tych, którzy używali go w prawdziwym życiu.

Co można zasugerować tutaj?

EDYTUJ, aby wyjaśnić, o co nam chodzi.

Jesteśmy firmą opracowującą aplikację, dzięki której użytkownicy mogą wyszukiwać wycieczki i wykonywać rezerwacje wspomnianych wycieczek, płacąc za nie za pomocą plastikowych kart. Cała ta rzecz może być specyficzna dla Rosji, więc nie bierzcie mnie.

Gdy użytkownik loguje się do serwisu, jest ona przedstawiona w formie podobnej do tej:

alt text http://queenbee.alponline.ru/searchform.png

Tutaj użytkownik wybiera gdzie zostawia i dokąd ona idzie, daty, czasu trwania i wszystko to.

Po naciśnięciu "Szukaj" zapytanie trafia do naszego serwera DB, który nie może obsłużyć takiego obciążenia: zapytania zawierają różne rodzaje parametrów. Sharding też nie działa dobrze.

To, czego szukam, to jakaś pseudo-baza danych, która potrafi błyskawicznie tworzyć zapytania.

Answer 1

Nie jestem pewien, czy zgodziłabym się, że tradycyjne bazy danych SQL nie mogą obsłużyć tych woluminów, mogę przesyłać zapytania przez znacznie większe zestawy danych w tych ramach czasowych, ale został zaprojektowany specjalnie do obsługi tego rodzaju pracy i umieszczany na odpowiednich sprzęt, w szczególności podsystem We/Wy, który został zaprojektowany do obsługi dużych żądań danych.

Answer 2

To naprawdę zależy od tego, jakie klauzule masz w swoim GDZIE i jakiego rodzaju projekcji potrzebujesz na swoich danych.

Może być wystarczająco dobrze, aby utworzyć odpowiedni indeks na stole.

Również posiadanie optymalnej struktury danych jest bezużyteczne, jeśli musisz przeczytać 100 GB na zapytanie, ponieważ to zajmie trochę czasu.

Answer 3

NoSQL, jak można przeczytać, nie jest relacyjną bazą danych.

Jest to baza danych, która przechowuje pary klucz-wartość, które można przemierzać za pomocą zastrzeżonego API.

Oznacza to, że należy samodzielnie zdefiniować fizyczny układ danych, a także zoptymalizować kod.

Jestem dość nieaktualny, ale kilka lat temu brałem udział w projekcie BerkeleyDB, który zajmuje się nieco mniejszymi, ale wciąż dużymi wolumenami danych (około 100Gb).

To było całkowicie w porządku dla naszych potrzeb.

Należy również pamiętać, że może się wydawać oczywiste, że zapytania można zoptymalizować. Czy możesz opublikować zapytanie, którego tutaj używasz?

Answer 4

Jeśli chcesz tworzyć zapytania ad-hoc do raportowania lub analizy, prawdopodobnie lepiej jest użyć czegoś, co będzie dobrze współpracować z gotowymi narzędziami do raportowania. W przeciwnym razie prawdopodobnie będziesz tracił cały czas na pisanie małych programów do raportowania danych. Jest to strajk przeciwko bazom danych typu NoSQL, ale może to być problem lub nie, w zależności od okoliczności.

300 GB nie powinno być poza możliwościami nowoczesnych platform RDBMS, nawet MS SQL Server. Niektóre inne opcje dla dużych zapytań do bazy danych tego typu są:

• Zobacz, jeśli można użyć kostki SSAS i agregacje złagodzić swoje problemy z wydajnością zapytań. Opty- mizowanie oparte na użyciu może zapewnić odpowiednią wydajność bez konieczności uzyskiwania innego systemu baz danych. Usług SSAS można również używać w konfiguracjach typu "nic nie współdzielonego", co pozwala rozbierać zapytania w klastrze stosunkowo tanich serwerów z dyskami dołączanymi bezpośrednio. Spójrz na ProClarity na front-end, jeśli pójdziesz tą drogą.

• Sybase IQ to platforma RDBMS, która wykorzystuje podstawową strukturę danych zoptymalizowaną do raportowania zapytań. Ma tę zaletę, że gra ładnie z rozsądną różnorodnością konwencjonalnych narzędzi do raportowania. Istnieje kilka innych systemów tego typu, takich jak Red Brick, Teradata lub Greenplum (który używa zmodyfikowanej wersji PostgreSQL). Główny strajk przeciwko tym systemom polega na tym, że nie są one dokładnie pozycjami masowego rynku i mogą być dość drogie.

• Firma Microsoft ma w przygotowywanej wersji wersję SQL Server, z której można korzystać. Jednak związali to z zewnętrznymi producentami sprzętu, więc można je zdobyć jedynie za pomocą dedykowanego (a przez to drogiego) sprzętu.

• Poszukaj okazji do tworzenia zbiorów danych z zagregowanymi danymi, aby zmniejszyć wolumeny niektórych zapytań.

• Sprawdź, jak dostroić sprzęt. Bezpośrednie dołączanie tablic SAS i kontrolerów macierzy RAID może dość szybko przejść przez strumieniowe operacje we/wy sortowania używanego w skanach tabel. Jeśli podzielisz swoje tabele na wiele par dublowanych, możesz uzyskać bardzo szybką transmisję strumieniową - z łatwością można nasycić kanały SAS.
  Praktycznie, chcesz uzyskać 10-20 GB/s z podsystemu We/Wy, jeśli chcesz opisywać cele wydajnościowe i jest to możliwe bez korzystania z naprawdę egzotycznego sprzętu.

Answer 5

Z tego, co niewiele rozumiem, tradycyjne RDBMS są wiersz oparty który optymalizuje prędkość wstawiania. Jednak optymalizacja prędkości pobierania jest najlepiej osiągalna przy użyciu systemu pamięci opartego na kolumnach.

Zobacz Column oriented DBMS dla dokładniejszego wyjaśnienia niż mogę dać

Answer 6

Prawidłowo skonfigurować serwer SQL powinien być w stanie obsługiwać dane w terrabytes bez problemów z wydajnością. Mam kilku przyjaciół, którzy zarządzają bazami danych serwera SQl, których rozmiar nie ma problemów z wydajnością.

Twój problem może być jeden lub więcej z nich:

• Niewystarczające specyfikacje serwera
• brak dobrej partycjonowanie
• Słabe indeksowanie
• Słaba baza projekt
• Słaby projekt kwerendy w tym przy użyciu narzędzia takie jak LINQ, które mogą zapisywać nieprawidłowy kod dla bazy danych o tym rozmiarze.

Z pewnością NIE jest to zdolność serwera SQL do obsługi tych obciążeń. Jeśli dysponujesz bazą danych o takim rozmiarze, musisz zatrudnić profesjonalną firmę dba z doświadczeniem w optymalizacji dużych systemów.

Answer 7

Spodziewam się, że "konwencjonalna" baza danych może zrobić to, co chcesz, pod warunkiem, że odpowiednio dopasujesz swoje dane do zapytań, które robisz.

Może się okazać, że w celu generowania raportów z szacunkiem, należy podsumować dane w stanie wygenerowanym (lub załadowane, przekształcone itp.) I zesłać dane podsumowania.

Prędkość SELECT nie jest powiązana (bezpośrednio, w większości przypadków) z liczbą warunków w klauzuli WHERE (zazwyczaj), ale ma to związek z planem wyjaśniającym i liczbą zbadanych wierszy. Są narzędzia, które przeanalizują to dla ciebie.

Ostatecznie, na poziomie 300G (co nie jest TAK duże) prawdopodobnie będziesz musiał zachować część danych na dysku (= wolna) przynajmniej przez pewien czas, dlatego chcesz zacząć zmniejszać liczbę wymaganych operacji we/wy. Zmniejszenie operacji we/wy może oznaczać tworzenie indeksów pokrycia, tabel podsumowań i kopii danych o różnych indeksach klastrowych. To sprawia, że ​​Twoje 300G jest większe, ale kogo to obchodzi.

ops IO są król :)

Oczywiście robienie tych rzeczy jest bardzo kosztowne pod względem czasu dewelopera, należy więc zacząć od rzucania dużo sprzętu na problem, a jedynie próbować go naprawić za pomocą oprogramowania, które raz staje się niewystarczające. Wiele pamięci RAM jest początkiem (ale nie będzie w stanie przechowywać> 10-20% zestawu danych jednocześnie na bieżących, opłacalnych poziomach). Nawet dyski SSD nie są obecnie tak drogie.