Jak mogę zagwarantować, że wstawki do SQL Server 2008 R2 są najpierw buforowane w pamięci RAM?

17

Wyobraź sobie strumień danych, który jest „wybuchowy”, tzn. Że może szybko nadejść 10 000 zdarzeń, a następnie przez minutę nic.

wprowadź opis zdjęcia tutaj

Twoja rada eksperta: Jak mogę napisać kod wstawiania C # dla SQL Server, tak aby istniała gwarancja, że SQL buforuje wszystko natychmiast w swojej własnej pamięci RAM, bez blokowania mojej aplikacji na więcej niż potrzeba, aby przesłać dane do tej pamięci RAM? Aby to osiągnąć, czy znasz jakieś wzorce konfiguracji samego serwera SQL lub wzorce konfiguracji poszczególnych tabel SQL, do których piszę?

Oczywiście mógłbym stworzyć własną wersję, która polega na zbudowaniu własnej kolejki w pamięci RAM - ale nie chcę na nowo wymyślać kamiennego paleolitu, że tak powiem.

c# sql-server visual-studio-2010 sql-server-2008

— Contango
źródło

1

Czy mówisz o kodzie klienta C #? Więc interesuje Cię kod SQL, który zapewnia, że zapisy są buforowane?

— Richard

6

Będę skłonny do wstawiania się w kolejce NAWET, jeśli RDBMS obsługuje to, ponieważ (a) nie jest trudne, (b) jest całkowicie pod twoją kontrolą i (c) nie jest zależne od dostawcy.

Interesuje mnie kod klienta C #, który zawiera kod SQL, aby zapewnić zapisywanie w pamięci podręcznej. Jestem jednak pewien, że mógłbym pracować z prostym T-SQL i napisać własne opakowanie C #.

11

Czy próbowałeś tylko pisać i zobaczyć, co się stanie? Czy masz znane wąskie gardło?

Jeśli chcesz zapobiec blokowaniu aplikacji, jednym ze sposobów byłoby umieszczenie w kolejce zapisów w celu odroczenia wywołania bazy danych. Spodziewałbym się jednak, że kolejka zniknie za sekundę lub 2: więc czy potrzebujesz kolejki, jeśli jest to w porządku?

Czy możesz buforować do stołu pomostowego, a następnie spłukać później? Używamy tej techniki do radzenia sobie z ciągłymi zapisami milionów nowych wierszy na minutę (faktycznie używamy pomostowego DB z prostym odzyskiwaniem): ale nie wdrożyliśmy go, dopóki nie mieliśmy doświadczenia z pisaniem wierszy.

Uwaga: Każdy zapis w SQL Server będzie iść zrobić dysk jako część protokołu Write Ahead Logging (WAL). Dotyczy to wpisu dziennika t dla tego zapisu.

Strona danych z wierszem w pewnym momencie przejdzie na dysk (na podstawie czasu, użycia, presji pamięci itp.), Ale ogólnie twoje dane i tak będą w pamięci. Nazywa się to „Checkpointing” i nie usuwa danych z pamięci, po prostu usuwa zmiany (edytowano 24 listopada 2011 r.)

Edytować:

Ze względu na wszystkie rozważania, w oparciu o ostatni akapit powyżej, przenieś swój LDF dla tej bazy danych na dedykowany zestaw dysków w celu zwiększenia wydajności. To samo dotyczy bazy danych pomostowych (po jednej dla MDF / LDF). Dość często jest tuzin lub 3 różne woluminy (normalnie przez SAN) dla serwera bazy danych

— gbn
źródło

1

Buforowanie do stołu pomostowego jest prawdopodobnie najlepszym sposobem. Otrzymałem również potwierdzenie od jednego z moich przyjaciół, który pracuje w środowisku z miliardami tabel wierszy, powiedział, że używa tabel tymczasowych do szybszej analizy.

7

Chyba, że coś mi brakuje, naruszyłoby to wymaganie ACID dotyczące trwałości ( http://en.wikipedia.org/wiki/ACID ). Oznacza to, że jeśli aplikacja „zapisuje” dane do pamięci RAM, a serwer ulegnie awarii, dane zostaną utracone.

Zatem szukasz systemu innego niż baza danych, który służy jako kolejka do ewentualnego przechowywania w bazie danych, lub systemu bazy danych, który jest wystarczająco szybki do tego, co robisz. Sugerowałbym wypróbowanie tego drugiego w pierwszej kolejności i sprawdzenie, czy to wystarczy; nie pożyczaj kłopotów.

— Ben Thul
źródło

+1 Powinienem o tym wspomnieć. WAL jest wymagany dla ACID

— gbn

2

Kiedyś użyłem do tego zestawu danych. Wstawiałem wiersze do zestawu danych, gdy tylko dotarły, i istniał inny wątek, który co 2 sekundy czyścił wiersze do bazy danych. Możesz także użyć dokumentu xml do wykonania cachina, a następnie przekazać xml do bazy danych w jednym wywołaniu, może to być jeszcze lepsze.

pozdrowienia

Piotr

— Piotr Rodak
źródło