MongoDB
 sql >> Baza danych >  >> NoSQL >> MongoDB

Powody za i przeciw przejściu z serwera SQL do MongoDB

Moim zdaniem format Twoich danych powinien być głównym problemem przy wyborze backendu do przechowywania. Czy masz dane o charakterze relacyjnym? Jeśli tak, to czy i czy warto modelować dane w dokumentach? Modelowanie danych jest tak samo ważne w bazie danych dokumentów, jak w relacyjnej bazie danych, po prostu robi się to inaczej. Ile masz rodzajów przedmiotów i jak są one powiązane? Czy DBrefs w Mongodb może załatwić sprawę, czy też przegapisz klucze obce tak bardzo, że będzie to bolesne? Jakie są twoje wzorce dostępu do danych? Czy pobierasz tylko dane jednego typu przefiltrowane według wartości pola, czy masz skomplikowane tryby pobierania?

Czy potrzebujesz integralności transakcyjnej ACID? Czy domena wymusza wiele ograniczeń na danych? Czy potrzebujesz współczynnika skalowalności bazy danych dokumentów, czy jest to po prostu „fajna” rzecz, którą należy mieć?

Jakie są Twoje wymagania dotyczące spójności i integralności danych? Niektóre rozwiązania NoSQL, a w szczególności MongoDB, mają dość luźną spójność zapisu w celu uzyskania wydajności. NoSQL to brak jednolitego krajobrazu i innych produktów, m.in. CouchDB ma inne cechy w tym dziale. Niektóre też można przestrajać.

To są wszystkie pytania, które powinny przejść do wyboru miejsca do przechowywania.

Niektóre doświadczenia

  • Prowadzenie obszernych raportów na temat przechowywanych danych może być trudniejsze podczas korzystania z MongoDB lub dowolnej bazy danych dokumentów, a niektóre przypadki użycia łączą w tym celu RDBMS i bazę dokumentów.
  • (Bardzo) Inny model zapytania. MongoDB różni się również od innych baz dokumentów.
  • Elastyczny sposób zmiany formatu/schematu danych podczas opracowywania
  • Nieznane terytorium
  • różny stopień dojrzałości sterowników i frameworków
  • Szybko
  • Prostsze (pod wieloma względami) narzędzia do produktów i zarządzania (w porównaniu do wielu produktów RDBMS)
  • Koniec z niedopasowaniem impedancji. Pamięć pasuje do danych, a nie na odwrót.
  • Mniej problemów i bardziej bezpośredni dostęp do danych.
  • Domena bardziej związana z trwałością (w zależności od „poziomu” ORM w NoRM, od tego, jak bardzo odciąga backend. Nie korzystałem z NoRM, więc nie mogę na to odpowiedzieć.)


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Znajdź dokumenty, których pole tablicy zawiera co najmniej n elementów danej tablicy

  2. Przesyłanie i pobieranie plików za pomocą MongoDB i Spring Boot

  3. Jak zamienić ciąg we wszystkich dokumentach w Mongo

  4. Nazwa pola batchSize ignorowana w projekcji pola

  5. Skrobanie i indeksowanie stron internetowych za pomocą Scrapy i MongoDB