NoSQL: Co to są dane nieustrukturyzowane?

obecnie działamy na granicy zasobów dzięki naszemu rozwiązaniu opartemu na serwerze mssql.

Mamy teraz wiele tradycyjnych opcji dotyczących następnego ruchu, aby poradzić sobie z obciążeniem:

• kupuj szybsze procesory i IO
• podzielić niektórych klientów na oddzielny serwer
• przenieś db do klastra

Wszystkie są albo drogie pod względem licencjonowania i sprzętu, albo czasu. Chcę więc dodać kolejną opcję, przenosząc cały system do skalowalnego rozwiązania, które obiecuje silnik nosql Cassandra.

Nie jestem jednak pewien i nie mam doświadczenia z bazami danych noSQL, dlatego muszę zrozumieć strukturę „nieustrukturyzowanych” danych.

W naszej aplikacji przechowujemy dane wprowadzane przez użytkowników na różne sposoby jako listy „klucz-wartość”. Istnieje tabela nadrzędna, która zawiera element head (jak Order), oraz tabela podrzędna z parami klucz-wartość zawierającymi zawartość zamówienia (jak Order_Lines).

Pod względem biznesowym Zamówienia i Linie Zamówienia są jednostką. Ale ze względu na RDBMS są one przechowywane w tabelach i muszą być przez cały czas łączone.

Podczas operacji czasami wybieramy ładowanie tylko górnej części, ale przez większość czasu ładujemy wiersz główny + niektóre KVP, aby wyświetlić przydatne informacje.

Na przykład na liście przeglądowej pokazujemy identyfikator nagłówka + niektóre wartości w kolumnach dla każdego wiersza.

AKTUALIZACJA: Przechowujemy wszelkiego rodzaju formularze. Zasadniczo przechowujemy „dokumenty”. Niemniej jednak musimy przygotować i przeszukiwać te formularze według dowolnej wartości, sortować itp. Kontrola dostępu do danych dodaje kolejną warstwę współzależności do bazy danych.

Jak można się domyślić, ilość i dostępność niektórych KVP różni się w zależności od obiektu. Nie ma uzasadnionej możliwości utworzenia pojedynczych tabel dla każdego rodzaju obiektu, ponieważ musielibyśmy utworzyć tysiące tabel dla różnych kombinacji danych.

Czy tego rodzaju „słownikowe” zbiory danych lepiej przechowywać w bazie danych noSQL? Czy z tego skorzystamy na wydajności? Czy Cassandra modelowałaby te głowy i KVP jako jeden zestaw danych? Patrząc na stronę Cassandra i niektóre samouczki, mam wrażenie, że nie ma tak dużej różnicy między naszym RDBMS a Cassandrą pod względem organizacji danych - pozostawiając nam tyle samo złączeń, jeśli chcesz wybrać 5 KVP dla listy dla każdego wiersza.

Oświecenie jest mile widziane, również wskaźniki do dokumentów wyjaśniających problemy są w porządku.

Istnieje kilka pojęć, które należy rozróżnić. Jedna dotyczy struktury, a druga schematu.

Dane strukturalne to takie, w których aplikacja z góry zna znaczenie każdego otrzymanego bajtu. Dobrym przykładem są pomiary z czujnika. W przeciwieństwie do tego strumień na Twitterze jest nieustrukturyzowany. Schemat dotyczy tego, jaka część struktury jest przekazywana do DBMS, jak ma się to wymusić. Kontroluje, ile DBMS analizuje przechowywane dane. DBMS wymagany na podstawie schematu, taki jak SQL Server, może przechowywać nieprzetworzone dane (varbinary) lub opcjonalnie przeanalizowane dane (xml) i w pełni przeanalizowane dane (kolumny).

Bazy danych NoSQL DBMS leżą w spektrum od braku analizowania (sklepy kluczy i wartości) w górę. Cassandra oferuje pod tym względem stosunkowo bogatą funkcjonalność. Różnice między sklepami relacyjnymi polegają na jednorodności danych. Po zdefiniowaniu tabeli mogą być tam przechowywane tylko dane pasujące do tej definicji. Jednak w Cassandrze, nawet jeśli kolumny i rodziny są zdefiniowane, nie ma wymogu, aby dwa wiersze w tej samej tabeli wyglądały podobnie do siebie. Do projektanta aplikacji należy decyzja, ile idzie w jednym rzędzie (zwanym także dokumentem) i co jest przechowywane osobno, połączone wskaźnikami. W efekcie, ile chcesz denormalizacji.

Zaletą jest to, że można pobrać pełny zestaw danych za pomocą jednego odczytu sekwencyjnego. To jest szybkie. Jedną wadą jest to, że Ty, programista aplikacji, jesteś teraz całkowicie odpowiedzialny za wszystkie kwestie związane z integralnością danych i kompatybilnością wsteczną, na zawsze, za każdy fragment kodu, który kiedykolwiek dotyka tego magazynu danych. Trudno to naprawić. Ponadto jesteś zamknięty w jednym punkcie widzenia danych. Jeśli wpiszesz wiersze według numeru zamówienia, w jaki sposób zgłaszasz sprzedaż dotyczącą jednego konkretnego produktu, regionu lub klienta?

Pomimo głównego nurtu baz danych noSQL IMHO decyzja o przyjęciu takiej technologii powinna być podejmowana zgodnie z osiągnięciami potrzebnymi na podstawie przechowywanych informacji, nie tylko uwzględniając wydajność, którą obecnie posiadasz. Oznacza to, że być może najlepszą opcją jest trzymanie się bazy danych SQL i poprawianie swojego sprzętu.

Ale dodatkowo przeczytałem w twoim pytaniu coś, co skłoniło mnie do myślenia. Nie ma wiele na temat obecnego stanu bazy danych, ale zdanie „zasadniczo przechowujemy dane wprowadzane przez użytkowników na różne sposoby, ponieważ listy„ klucz-wartość ” sprawiają, że zastanawiam się, czy problemem nie byłby zły model danych, a nie brak zasobów fizycznych. Zarządzałem naprawdę dużymi tabelami (+10 miliardów wierszy) z niewiarygodną wydajnością w „tradycyjnych” bazach danych SQL.

Nie twierdzę, że to źle, po prostu, ponieważ oczywiście nie mogę ocenić cię we właściwym modelu danych z tak małą ilością informacji o twoim obecnym rozwiązaniu, ale po prostu pomyśl o ponownym przejrzeniu twojego modelu danych jako dodatkowej opcji wraz z resztą, ponieważ może tam znaleźć jakieś wskazówki.

Zazwyczaj listy klucz-wartość są przydatne jako kompromis, gdy nie można wdrożyć modelu w jego ostatecznym stanie, ponieważ nie znasz różnych kluczy, z którymi musisz się zmierzyć, lub gdy potrzebujesz wartości jednego z możliwych klucze do określonego elementu. Ale po wdrożeniu zazwyczaj lubię ponownie zastanawiać się nad takimi decyzjami po chwili, gdy zebrałeś wystarczającą ilość informacji, aby zidentyfikować typowy przypadek użycia i zdecydować, czy decyzja dotycząca modelu danych jest najlepsza. Jeśli wiesz, że będziesz mieć pewną liczbę kluczy, spróbuj wykonać test porównawczy z projektem zwykłego stołu w tradycyjny sposób

CREATE TABLE benchmarkTable (
  element INTEGER,
  key1 VARCHAR(xx),
  key2 INTEGER,
  key3 DECIMAL(5,2),
...
);

... i dodając odpowiednie indeksy. Wypróbuj i zmierz plany wykonania przy użyciu obu podejść. Możesz być szczególnie zaskoczony, jeśli zbierzesz więcej niż jeden klucz na raz, ponieważ między innymi zaletami należy zmniejszyć rozmiar bloku danych, a tym samym poprawić wydajność.

Mam nadzieję, że to pomaga, a przynajmniej poszerza możliwości i otwiera nową linię do dochodzenia.