2010-08-27 14 views
5

Zacząłem zaglądać do NoSql i zastanawiałem się, co inni sądzą o przydatności takich rozwiązań do przechowywania i wyszukiwania danych finansowych szeregów czasowych?NoSql (na przykład RavenDB) dla finansowych szeregów czasowych danych?

Na przykład w prostym scenariuszu zapisałbym symbol giełdowy, otwarty, wysoki, niski, zamknięty, wolumen i znacznik czasu. Chciałbym następnie zapytać o te dane na podstawie zakresu symboli i datownika.

Jak myślisz, jaka byłaby dobra struktura dokumentu dla tego scenariusza?

Dzięki,

Tom

Edit: Martwię głównie o wydajności zapytań odczytu danych na podstawie szeregów czasowych w roztworze NoSQL vs tradycyjnego rozwiązania RMDBS

Odpowiedz

3

Tom, dane finansowe zwykle mają ścisłą spójność i wymagania dotyczące trwałości. Na pierwszy rzut oka i bez znajomości Twojego zastosowania oczekiwałbym, że będziesz potrzebował właściwości RDBMS w porównaniu z właściwościami ACID, które zazwyczaj definiują rozwiązania NoSQL. Może, jeśli opiszecie swój wzorzec użytkowania i dlaczego myślicie, że potrzebujecie modelu nierelacyjnego, będę w stanie znaleźć dla was bardziej odpowiednie rozwiązanie.

W obecnej formie dane są łatwo uporządkowane według modelu relacyjnego i mają dość sztywny schemat, więc nie widzę potrzeby bazy danych Schemaless (MongoDB, CouchDB, Riak ...). Zwykle notowania giełdowe muszą mieć silną konsystencję (zawsze być aktualne), więc nie widzę żadnego punktu w klonie dynamo (Cassandra, Voldemort ...). Jeśli nie masz już ogromnej ilości danych i nie uderzysz w ścianę, jeśli chodzi o szybkość przetwarzania i wykorzystanie zasobów, nie wybrałbym bazy danych opartej na kolumnach (HBase, Hypertable).

+0

Właściwości ACID nie są dla mnie wymagane. Dane, które są przechowywane, są aktualizowane tylko na noc w zadaniu wsadowym i będą otrzymywać zapytania tylko do odczytu w ciągu dnia. To, co mnie interesuje, to czy rozwiązanie NoSQL będzie lepiej radzić sobie z zapytaniami opartymi na "szeregach czasowych" (wybierając dane w zakresie czasu) niż tradycyjne rozwiązania RMDBS. – TJF

+0

Nie brzmi to tak, jak masz tutaj wymaganie dostępności, po prostu chcę szybkich zapytań w bazie danych tylko do odczytu. To brzmi jak coś, co każda przyzwoita baza danych może zapewnić wszystko, czego naprawdę potrzebujesz, to indeks na znaczniku czasu. Nie sądzę, że rozwiązanie NoSQL byłoby lepsze, ale zależy to od skali.Szczerze mówiąc, użyłbym wyszukiwarki takiej jak Solr (lub Lucene) i po prostu podkasowałem pamięć podręczną, ponieważ twoje dane są tylko do odczytu, mogą być bardzo szybkie. – Asaf

3

Take a look at ESENT.

Dla twojego scenariusza rozważałbym użycie głównego indeksu powyżej 2 kolumn: symbolu + znacznika czasu (jeśli zamierzasz wyszukiwać poszczególne symbole w pewnym przedziale) lub znacznika czasu + symbolu (jeśli chcesz pobrać wszystkie symbole w pewnym przedziale).

3

Tom. Co dokładnie próbujesz osiągnąć? RavenDB z pewnością poradzi sobie z tym scenariuszem, ale należy pamiętać, że indeksy RavenDB są aktualizowane w tle. Twój scenariusz wydaje się być odpowiedni dla RDBMS, więc muszę zapytać, dlaczego szukasz rozwiązania NoSQL.

+0

Aktualizowanie indeksów w tle nie stanowi problemu ten przypadek użycia. Moje pytanie dotyczy głównie wydajności odczytu. Czy rozwiązanie NoSql będzie lepsze w zapytaniu o szereg czasowy (zakres czasowy) niż tradycyjne rozwiązanie RMDBS? – TJF

+0

Prawdopodobnie z RavenDB prawdopodobnie większość pracy można wykonać bezpośrednio nad zbudowanym indeksem, który będzie _very_ fast –

Powiązane problemy