Czy SQL Server i Mongo mogą być używane razem?

Mamy dużą witrynę z wiadomościami, która ma duży ruch w sieci. Architektura to często spotykana baza danych - warstwa repo - warstwa usług - Asp.Net MVC. Problem, który widzieliśmy, dotyczy wydajności odczytu. Okazuje się, że te wszystkie obiekty w domenie DDD są świetne teoretycznie dla reguł biznesowych, ale utrudniają życie, jeśli chodzi o optymalizację wydajności odczytu.

Jako rozwiązanie rozważam coś zupełnie nowego (dla nas): użycie noSQL. Chciałbym użyć bazy danych noSQL do prezentacji danych na naszej stronie internetowej. Nie możemy pozbyć się naszego SQL Servera (przynajmniej nie w najbliższym czasie), ale wydaje mi się, że praktycznym krokiem byłoby użycie Mongo jako bazy danych zapytań dla wszystkich nowych rozwiązań.

Moje pytanie brzmi, czy można używać programu SQL Server jako bazy danych rekordów i Mongo jako bazy danych zapytań razem ?

Kiedy więc jeden z naszych redaktorów zaktualizuje rekord, dane będą przechowywane w SQL Server. Jest to konieczne, ponieważ istnieje zbyt wiele starszego kodu, którego nie można ponownie napisać z dnia na dzień.

Ale kiedy przeglądający w witrynie przegląda artykuł lub listę artykułów, chciałbym skorzystać z wydajności Mongo kontra SQL Server. Aby dane były nieco aktualne, powiedzmy 15 minut lub mniej, dane programu SQL Server musiałyby odświeżyć Mongo. RDBMS ma narzędzia do replikacji do takich operacji i zastanawiam się, czy istnieje coś takiego do zrobienia od SQL Server do Mongo. Może serwer Lync?

— Jan
źródło

Możliwy? Oczywiście jest to możliwe, ponieważ dwa osobne magazyny danych. O co dokładnie pytasz?

— Oded,

Ale czy możesz ich używać razem? Czy baza danych Mongo DB działa jako pamięć podręczna tylko do odczytu danych?

— John,

Ponownie oczywiście możesz „używać ich razem”. Ale nie jest jasne, co to oznacza. Tak długo, jak masz jakiś mechanizm aktualizacji dla mongo, możesz iść. Zobacz posty Udi Dahana - ale to od Ciebie zależy określenie mechanizmu.

— Oded,

Nigdy nie przeprowadziliśmy się do MongoDB, ale wygląda na to, że w przyszłym roku będziemy mogli. Jednym z przejściowych sposobów, które zrobiliśmy, jest przechowywanie JSON w polach varchar. Ze wszystkiego, co przeczytałem, nie ma dobrego sposobu na przenoszenie danych w obie strony między NoSQL a SQL - wszystko będzie musiało być niestandardowe, zwłaszcza, że dostępne tam bazy danych NoSQL różnią się znacznie w zależności od tego, jak to robią .

— Jan

@John, jeśli chcesz pozostać przy relacjach i chcesz odejść od SQL Server, możesz przyjrzeć się Postgresql i jego integracji z jsonem . W ten sposób przechowuje dane w kolumnie Json, którymi można następnie manipulować w bazie danych.

Odpowiedzi:

Wystąpił problem, który wielu ma przed sobą ... baza danych zoptymalizowana pod kątem odczytu rzadko jest dobra pod względem wydajności zapisu i odwrotnie. Jednym z podejść, które ewoluowało z tego ograniczenia odczytu i zapisu, jest CQRS (Segregacja Odpowiedzialności za Polecenia). Mimo że Wikipedia łączy oba systemy, CQRS i CQS są technicznie różne. CQS wymaga po prostu, aby metoda albo dokonała zmiany (polecenia), albo zapytała informacji (zapytania), nigdy nie obu.

CQRS idzie o krok dalej i określa, że masz osobny model dla zapytań i poleceń. Ten pojedynczy krok umożliwia między innymi oddzielenie bazy danych do odczytu i zapisu. Właśnie to chcesz zrobić.

Nie mogę powiedzieć, że jestem ekspertem od Mongo lub konfiguruję go do pracy z SQL Server. Ale z mojego zrozumienia, ludzie używają Mongo jako zdormalizowanego widoku ich transakcyjnej bazy danych. Aktualizowanie Mongo z transakcyjnej bazy danych może sprowadzać się do uruchomienia agenta SQL. Lub posiadanie oddzielnej usługi do sondowania bazy danych.

Jeszcze lepszą alternatywą byłoby, aby twoja usługa Dowodzenia wyzwoliła zdarzenie za każdym razem, gdy wykonywana jest aktualizacja. Miałbyś wtedy usługę, która nasłuchiwała tego zdarzenia i aktualizowała MongoDB o te informacje. Jest to podstawowe podejście do pozyskiwania zdarzeń (poszukiwanie źródła zdarzeń na stronie).

Greg Young, jeden z liderów myśli w świecie DDD, pisze obecnie książkę z serii Fowler Signature na CQRS pod tytułem Event-Centric (kiedyś CQRS). Fowler napisał post na swoim blogu opisujący podejście

— Michael Brown
źródło

+1 CQRS dobrze tutaj pasuje. Użyj zdarzeń, aby wypełnić i zaktualizować bazę danych dokumentów używaną do budowania twoich widoków, i pozostaw bazę danych sql taką, jaka jest.

— quentin-starin

Nie przyjęliśmy systemu CQRS, ale zwróciłem uwagę na to, co napisali Greg, Udi i inni. Duża część CQRS nie jest konkretną platformą, ale jedynie rozmyślając o komendach i zapytaniach osobno. Nie sądzę, żeby Greg kiedykolwiek napisał książkę, chociaż Microsoft Patterns and Practices opublikowało ją.

— Jan

Jedyną rzeczą, którą dodałbym do tej odpowiedzi jest: Jeśli twój przypadek użycia dotyczy tego w przypadku MS SQL i MVC, czy rozważałeś BrightstarDB zamiast MongoDB w części NoSQL? Ma zgodność z Entity Framework i LINQ, co może ułatwić ci przejście.

— CrazyPyro,

Tak. W moim obecnym projekcie pobieramy dane i przechowujemy je w SQL Server, a następnie budujemy indeksy wyszukiwania za pomocą Lucene / Solr i przechowujemy je w MongoDB. Jednak wypełnianie MongoDB odbywa się za pomocą niestandardowego modułu ładującego - bez replikacji programu SQL Server lub automatycznego odświeżania.

— TMN
źródło

Okej, jestem ciekawy, dlaczego nie zaludnić bezpośrednio mongo? Czy jesteś pod takim samym ograniczeniem, że musisz korzystać z obu?

— yati sagade,

Nasz istniejący SQL Server nie może zostać przepisany z dnia na dzień. Myślę, że to mały, ale użyteczny krok dla dziecka.

— John,

@yatisagade: Right. Mamy raporty, które muszą działać z programem SQL Server, ale mamy globalną aplikację do wyszukiwania, która korzysta z indeksów Lucene.

— TMN,