2012-03-27 15 views
7

Buduję stronę internetową, która ma listę życzeń. Chcę przechowywać listy życzeń w pamięci podręcznej, ale chcę, aby użytkownik mógł sortować listę życzeń podczas przeglądania na wiele różnych sposobów - dodania daty, daty dodania odwróconej, nazwy pozycji itp. Chcę również zaimplementować stronicowanie, które, jak sądzę, mogę wprowadzić za pomocą tokena kontynuacji.Przechowywanie tabeli Azure: Zamówienie przez

Jak rozumiem, "zamówienie według" nie zostało zaimplementowane, a kolejność, w jakiej wyniki są zwracane z pamięci tabeli, zależy od klucza partycji i klucza wiersza. Dlatego jeśli chcę zaimplementować stronicowanie i sortowanie, które opisuję, jest to najlepszy sposób na wdrożenie tego poprzez wielokrotne przechowywanie listy życzeń za pomocą innego klucza/klucza partycji?

W tym prostym przypadku jest prawdopodobne, że lista życzeń nie będzie tak duża, a ja w rzeczywistości mogę ograniczyć maksymalną liczbę pozycji, które mogą pojawić się na liście, a następnie pozbyć się stronicowania i posortować je w pamięci. Jednak mam bardziej złożone przypadki, które muszę również wdrożyć do stronicowania i sortowania.

Odpowiedz

8

Na dzisiejszym sprzęcie, który ma 1000 wierszy do przechowywania, na liście, w pamięci i sortowaniu jest łatwo obsługiwany. Jaki jest prawdziwy problem, jak to możliwe, aby uzyskać dostęp do wierszy w pamięci tabeli za pomocą klawiszy i bez konieczności skanowania tabeli. Duplikowanie wierszy w wielu tabelach może być dość kłopotliwe w utrzymaniu.

Alternatywnym rozwiązaniem byłoby tymczasowe rozmieszczenie wierszy w SQL Azure i zastosowanie zamówienia tam. Może to być skuteczne, jeśli zestaw wyników jest zbyt duży, aby mógł pracować w pamięci. Aby uzyskać najlepsze wyniki, tabela tymczasowa musiałaby mieć niezbędne indeksy.

+0

Jestem skłonny do zrobienia tego w pamięci i martwienie się o to później, jeśli stanie się wąskim gardłem. – s1mm0t

+0

... Twoja druga sugestia jest jednak interesująca. Czy kiedykolwiek zrobiłeś coś takiego? Przesyłanie danych między różnymi pamięciami samo w sobie wydaje się czymś, co byłoby powolne. – s1mm0t

+0

Nie zrobiłem tego ostatnio. Biorąc pod uwagę, że prawdopodobnie działa to w rozłączonym świecie i mając na uwadze skalowalność w wielu instancjach, ładowanie zestawu wyników z pamięci tabeli do pamięci lokalnej dla każdego żądania może być nieefektywne. Zamiast tego umieszczanie w SQL Azure umożliwi dostęp do danych z wielu instancji po pojedynczym obciążeniu. Z drugiej strony, jeśli implementacja jest oparta na pojedynczej instancji z ograniczonym zestawem danych, ładowanie w pamięci może wystarczyć. Najpierw wypróbuję opcję pamięci, a następnie przejdę do opcji SQL, jeśli nie spełnia ona oczekiwań. – hocho

2

Dlaczego nie zrobić tego wszystkiego w .net przy użyciu listy.

Dla tego typu aplikacji uważałbym, że SQL Azure byłby bardziej odpowiedni.

+0

W przypadku listy życzeń może być lista/IEnumerable odpowiednie, ale mam inne podobne ekrany, na których może być 1000 wyników.Nie chcę tego wszystkiego robić w pamięci. Używam Table Storage na rzecz SQL Azure w tym przypadku ze względu na korzyści finansowe. – s1mm0t

+0

Pamięć do 1000 rzędów to niewiele. Również przy ustalaniu korzyści kosztowych trzeba myśleć o swoim czasie. Jeśli zamierzasz zaoszczędzić godzinę lub więcej miesięcznie od korzystania z SQL Azure, korzystanie z SQL Azure jest znacznie tańsze. O ile nie masz do czynienia z dużymi danymi, a mam na myśli ogromną, korzyści kosztowe wynikające z przechowywania tabel przez SQL Azure nie są równe. –

+0

Dałem ci plus +1. Nie zawsze chodzi o koszt lub rozmiar. Dla aplikacji z wieloma dzierżawcami, w której chcesz rozdzielenie danych tworzących tabelę pamięci jest łatwiejsze i szybsze niż tworzenie bazy danych. – Paparazzi

-1

Coś jak to działało w porządku dla mnie:

List<TableEntityType> rawData = 
    (from c in ctx.CreateQuery<TableEntityType>("insysdata") 
    where ((c.PartitionKey == "PartitionKey") && (c.Field == fieldvalue)) 
    select c).AsTableServiceQuery().ToList(); 
List<TableEntityType> sortedData = rawData.OrderBy(c => c.DateTime).ToList(); 
+5

To będzie sortować wiersze w pamięci – BritishDeveloper

+0

To ignoruje oryginalne pytanie, w tym stronicowanie w zakresie, a nie tylko sortowanie. –

0

Azure Storage utrzymuje podmiotów w porządku leksykograficznym, indeksowane przez klucz podziału jako indeks podstawowy i klucz wiersz jako indeksu wtórnego. Ogólnie biorąc, dla twojego scenariusza brzmi to tak, jakby UserId byłby odpowiedni dla klucza partycji, więc masz klucz wiersza do optymalizacji dla każdego zapytania.

Jeśli chcesz, aby użytkownik zobaczył listę życzeń od góry, możesz użyć wzorca logowania, w którym kluczem wiersza będzie odwrócony klawisz daty i godziny w polu DataTime, gdy użytkownik wprowadził listę życzeń.

Jeśli chcesz, aby użytkownik zobaczył listę życzeń uporządkowaną według nazwy przedmiotu, możesz podać nazwę przedmiotu jako klucz wiersza, dzięki czemu obiekty będą naturalnie sortowane według lazuru.

Podczas zapisywania danych może zajść potrzeba denormalizowania danych i wykonywania wielu zapisów za pomocą tych różnych schematów klawiszy rzędu. Ponieważ będziesz mieć ten sam klucz partycji co identyfikator użytkownika, możesz na tym etapie wykonać operację wstawiania wsadowego i nie martwić się o spójność, ponieważ operacje wsadowe w lazurowym stole są atomowe.

Aby rozróżnić różne schematy w wierszu, można poprzedzić każdą stałą ciągiem znaków. Tak jak w przypadku odwróconego tyknięcia wartość klucza rzędu, na przykład woul dbe coś w rodzaju "InvertedTicks_ [InvertedDateTimeTicksOfTheWishList]", a wartość klucza pozycji w wierszu przedmiotu będzie "Nazwa elementu [nazwa elementuOfTheWishList]"

Powiązane problemy