Przechowywanie ~ 3,5 TB danych i wstawianie około 1 K / s 24x7, a także wykonywanie zapytań z nieokreśloną szybkością, jest to możliwe z SQL Server, ale jest więcej pytań:
- jakie masz wymagania dotyczące dostępności? 99,999% czasu pracy, czy wystarczy 95%?
- jakie masz wymagania dotyczące niezawodności? Czy brak wkładki kosztuje 1 milion dolarów?
- jakie masz wymagania dotyczące możliwości odzyskania? Jeśli stracisz jeden dzień danych, czy to ma znaczenie?
- jakie masz wymagania dotyczące spójności? Czy należy zagwarantować, że zapis będzie widoczny przy następnym czytaniu?
Jeśli potrzebujesz wszystkich tych wymagań, które podkreśliłem, obciążenie, które proponujesz, będzie kosztować miliony w sprzęcie i licencjonowaniu w systemie relacyjnym, dowolnym systemie, bez względu na to, jakie sztuczki spróbujesz (sharding, partycjonowanie itp.). System nosql z definicji nie spełniałby wszystkich tych wymagań.
Więc oczywiście złagodziłeś już niektóre z tych wymagań. Istnieje przyjemny przewodnik wizualny porównujący oferty nosql w oparciu o paradygmat „wybierz 2 z 3” w Visual Guide to NoSQL Systems :
Po aktualizacji komentarza OP
W przypadku SQL Server byłaby to prosta implementacja:
- jeden klucz klastrowy z pojedynczą tabelą (identyfikator GUID, czas). Tak, ulegnie fragmentacji , ale czy fragmentacja wpłynie na odczyty z wyprzedzeniem, a odczyty z wyprzedzeniem są potrzebne tylko w przypadku skanowania znacznego zasięgu. Ponieważ wyszukujesz tylko określony identyfikator GUID i zakres dat, fragmentacja nie będzie miała większego znaczenia. Tak, jest to klucz szeroki, więc strony nieskładkowe będą miały słabą gęstość klucza. Tak, doprowadzi to do słabego współczynnika wypełnienia. I tak, mogą wystąpić podziały stron. Pomimo tych problemów, biorąc pod uwagę wymagania, nadal najlepszym wyborem jest klaster.
- podziel tabelę według czasu, aby móc efektywnie usuwać wygasłe rekordy za pomocą automatycznego przesuwanego okna . Uzupełnij to o przebudowę partycji indeksu online z ostatniego miesiąca, aby wyeliminować słaby współczynnik wypełnienia i fragmentację wprowadzoną przez klastrowanie GUID.
- włącz kompresję strony. Ponieważ najpierw klastrowane są grupy kluczy według identyfikatora GUID, wszystkie rekordy identyfikatora GUID będą znajdować się obok siebie, co daje kompresji strony dużą szansę na wdrożenie kompresji słownika.
- będziesz potrzebować szybkiej ścieżki we / wy dla pliku dziennika. Interesuje Cię wysoka przepustowość, a nie małe opóźnienia, aby dziennik mógł nadążyć z szybkością 1 tys. Wstawień na sekundę, więc usuwanie elementów jest koniecznością.
Partycjonowanie i kompresja stron wymagają SQL Server Enterprise Edition, nie będą działać w wersji Standard Edition i oba są bardzo ważne, aby spełnić wymagania.
Na marginesie, jeśli rekordy pochodzą z farmy serwerów WWW frontonu, umieściłbym Express na każdym serwerze sieciowym i zamiast INSERT na zapleczu, SEND
przekazałbym informacje do zaplecza, używając lokalnego połączenia / transakcji na urządzeniu Express znajdującym się razem z serwerem WWW. Daje to znacznie lepszą historię dostępności rozwiązania.
Więc tak bym to zrobił w SQL Server. Dobra wiadomość jest taka, że problemy, z którymi się spotkasz, są dobrze rozumiane, a rozwiązania znane. to niekoniecznie oznacza, że jest to lepsze niż to, co można osiągnąć dzięki Cassandrze, BigTable lub Dynamo. Pozwolę komuś, kto jest bardziej kompetentny w sprawach nie-sql-ish, do argumentowania ich racji.
Zauważ, że nigdy nie wspomniałem o modelu programowania, obsłudze .Net i tym podobnych. Szczerze myślę, że nie mają one znaczenia w dużych wdrożeniach. Robią ogromną różnicę w procesie rozwoju, ale po wdrożeniu nie ma znaczenia, jak szybki był rozwój, czy narzut ORM zabija wydajność :)