Plusy i minusy używania MongoDB zamiast MS SQL Server [zamknięty]

Aby stwierdzić, czy MongoDB jest dobry do przechowywania takich danych, które ostatecznie zostaną zapytane o przedziały czasowe (np. konkretnej kamery między określoną godziną)?

Także:

Jaka powinna być Specyfikacja serwera (CPU, RAM, dysku)? dowolne sugestia?

Zależy od zbyt wielu zmiennych, które tylko Ty znasz, jednak mały klaster sprzętu towarowego działa całkiem dobrze. Naprawdę nie mogę udzielić rzeczowej odpowiedzi na to pytanie i sprowadzi się to do Twoich testów.

Jeśli chodzi o schemat to ja bym wybrał dokument struktury:

{
    _id: {},
    camera_name: "my awesome camera",
    images: [
        { 
            url: "http://I_like_S3_here.amazons3.com/my_image.png" ,
            // All your other fields per image
        }
    ]
}

Nie tylko to, ale to powinno być dobre dla shardingu, ponieważ masz wszystkie potrzebne dane w jednym dokumencie, gdybyś miał shard na _id prawdopodobnie możesz uzyskać idealną konfigurację tutaj.

Czy powinienem rozważyć Sharding / replikację w tym scenariuszu(biorąc pod uwagę wydajność na piśmie do synchronizacji zestawów replik)?

Możliwe, że wiele osób zakłada, że muszą odłamać, kiedy w rzeczywistości po prostu muszą być bardziej inteligentni w tym, jak projektują baza danych. MongoDB jest bardzo darmową formą, więc istnieje wiele sposobów na zrobienie tego źle, ale biorąc to pod uwagę, Istnieje również wiele sposobów na zrobienie tego dobrze. Ja osobiście bym pamiętał o shardingu. Replikacja może być również bardzo przydatna.

Czy są jakieś korzyści z używania wielu baz danych na tej samej maszynie, tak że jedna baza danych będzie przechowywać obrazy z bieżącego dnia dla wszystkich kamer, a druga będzie używana do archiwizacji zdjęć z poprzedniego dnia?

Mimo że MongoDBs write lock jest na poziomie DB (obecnie) powiedziałbym: nie. Właściwa struktura dokumentu i właściwe odłamywanie / replikacja(w razie potrzeby) powinny być w stanie obsłużyć to w jednym zbiorze (- ach) opartym na dokumencie w ramach jednego DB. Nie tylko to, ale możesz kierować zapisy i odczyty w klastrze na określone serwery, aby stworzyć sytuację współbieżności między niektórymi maszynami w klastrze. Promowałbym poprawne wykorzystanie funkcji współbieżności MongoDBs nad separacją DB.

Edit

Po czytając pytanie ponownie pominąłem moje rozwiązanie, że wstawiasz 80K + zdjęć dla każdego aparatu dziennie. Jako taki zamiast osadzonej opcji chciałbym rzeczywiście zrobić wiersz na obraz w kolekcji o nazwie images, a następnie camera kolekcja i odpytywać dwa tak jak w SQL.

Podzielenie kolekcji images powinno być równie łatwe na camera_id.

Upewnij się również, że bierzesz pod uwagę swój zestaw roboczy z serwerem.

Aby stwierdzić, czy MongoDB jest dobry do przechowywania takich danych, które ostatecznie zostaną zapytane o przedziały czasowe (np. konkretnej kamery między określoną godziną)? Wszelkie sugestie dotyczące Schemat oparty na dokumentach dla mojej sprawy?

Jaka powinna być Specyfikacja serwera (CPU, RAM, dysku)? jakieś sugestie?

Myślę, że RAM i Dysk byłby ważny.

• Jeśli nie chcesz robić sharding do scale out, powinieneś rozważyć większy rozmiar dysku, aby móc przechowywać w nim wszystkie swoje dane.
• twoje gorące dane powinny zmieścić się w pamięci RAM. Jeśli nie, powinieneś rozważyć większą pamięć RAM, ponieważ wydajność MongoDB zależy głównie od PAMIĘCI RAM.

Czy powinienem rozważyć Sharding/replikację dla tego scenariusza (podczas biorąc pod uwagę wydajność na piśmie, aby zsynchronizować replikę zestawy)?

Nie wiem ile macie aparatów, nawet 1000 wstawek / sekundę przy sumie 1000 kamer powinno być łatwe do zmontowania. Jeśli chodzi o wydajność insert, nie sądzę, że musisz robić sharding (z tym, że rozmiar danych jest zbyt duży, aby rozdzielić je na kilka maszyn).

Kolejnym problemem jest częstotliwość odczytu aplikacji. To jest bardzo wysoki, to można rozważyć sharding lub replikacji tutaj. I można użyć (timestamp + camera_id) jako klucz sharding, jeśli zapytanie dotyczy tylko jednej kamery w zakresie czasu.

Czy są jakieś korzyści z używania wielu baz danych na tej samej maszynie, więc ta jedna baza danych będzie zawierała zdjęcia z dnia bieżącego dla wszystkich kamer, a drugi będzie używany do archiwizacji zdjęć z poprzedniego dnia?

Tabelę można rozdzielić na dwie kolekcje (archive i current). I ustaw indeks tylko na archive, jeśli zapytasz o datę tylko na archive. Bez nakładów na tworzenie indeksu, zbiór current powinien korzystać z insert.

I możesz napisać codzienny program do zrzutu danych current do archive.