- Kolejki do zarządzania aktualizacjami zasobów reklamowych dla każdego kanału.
Niekoniecznie jest to problem z bazą danych. Lepiej przyjrzeć się systemowi przesyłania wiadomości (np. RabbitMQ)
- Tabela zasobów, która zawiera poprawną migawkę alokacji na każdym kanale.
- Przechowywanie identyfikatorów sesji i innych danych szybkiego dostępu w pamięci podręcznej.
dane sesji prawdopodobnie powinny być umieszczone w oddzielnej bazie danych, bardziej odpowiedniej do zadania (np. memcached, redis, itp.) Nie ma uniwersalnej bazy danych
- Udostępnienie pulpitu nawigacyjnego podobnego do Facebooka (XMPP), aby jak najszybciej aktualizować sprzedawcę.
Moje ograniczenia to:1. Aktualizacje inwentarza nie mogą zostać utracone.
Na to pytanie można odpowiedzieć na 3 sposoby:
-
Tę funkcję musi zapewnić Twoja aplikacja. Baza danych może zagwarantować, że zły rekord zostanie odrzucony i wycofany, ale nie gwarantuje, że każde zapytanie zostanie wprowadzone.Aplikacja będzie musiała być wystarczająco inteligentna, aby rozpoznać, kiedy wystąpi błąd i spróbować ponownie.
-
niektóre bazy danych przechowują rekordy w pamięci, a następnie okresowo opróżniają pamięć na dysk, co może prowadzić do utraty danych w przypadku awarii zasilania. (np. Mongo działa w ten sposób domyślnie, chyba że włączysz kronikowanie. CouchDB zawsze dołącza do rekordów (nawet usunięcie jest flagą dołączoną do rekordu, więc utrata danych jest niezwykle trudna))
-
Niektóre DB są zaprojektowane tak, aby były wyjątkowo niezawodne, nawet w przypadku trzęsienia ziemi, huraganu lub innej klęski żywiołowej, pozostają trwałe. należą do nich Cassandra, Hbase, Riak, Hadoop itp.
Jaki rodzaj trwałości masz na myśli?
- Kolejki zadań powinny być wykonywane w kolejności i najlepiej, aby nigdy nie zostały utracone.
Większość rozwiązań noSQL woli działać równolegle. więc masz tutaj dwie opcje.1. użyj bazy danych, która blokuje całą tabelę dla każdego zapytania (wolniej)2. zbuduj swoją aplikację, aby była inteligentniejsza lub bardziej urozmaicona (kolejkowanie po stronie klienta)
- Łatwy/szybki rozwój i przyszła konserwacja.
ogólnie rzecz biorąc, początkowo programowanie SQL jest szybsze, ale wprowadzanie zmian może być trudniejsze.NoSQL może wymagać nieco więcej planowania, ale łatwiej jest wykonywać zapytania ad hoc lub zmiany schematu.
Pytania, które prawdopodobnie musisz sobie zadać, są bardziej podobne do:
-
„Czy będę potrzebować intensywnych zapytań lub głębokiej analizy, do których lepiej nadaje się mapa/redukcja?”
-
"czy będę musiał często zmieniać schemat?
-
„czy moje dane są wysoce relacyjne? w jaki sposób?”
-
„czy dostawca mojego wybranego DB ma wystarczające doświadczenie, aby mi pomóc, gdy tego potrzebuję?”
-
„czy będę potrzebować specjalnych funkcji, takich jak indeksowanie GeoSpatial, wyszukiwanie pełnotekstowe itp.”
-
„Jak blisko czasu rzeczywistego będę potrzebować moich danych? Czy zaszkodzi, jeśli najnowsze rekordy pojawią się w moich zapytaniach dopiero po 1 sekundzie? Jaki poziom opóźnienia jest akceptowalny?”
-
"czego naprawdę potrzebuję, jeśli chodzi o przełączanie awaryjne"
-
„Jak duże są moje dane? Czy zmieszczą się w pamięci? Czy zmieszczą się na jednym komputerze? Czy każdy pojedynczy rekord jest duży czy mały?
-
„jak często moje dane będą się zmieniać? czy to archiwum?”
Jeśli zamierzasz mieć wielu klientów (kanały?), każdy z własnymi schematami zapasów, baza danych oparta na dokumencie może mieć swoje zalety. Pamiętam, jak kiedyś spojrzałem na system e-commerce z inwentarzem i miał prawie 235 tabel! Z drugiej strony, jeśli masz pewne dane relacyjne, rozwiązanie SQL może również mieć pewne zalety.
Z pewnością widzę, jak mógłbym zbudować rozwiązanie za pomocą mongo, couch, riaka lub orientdb przy podanych ograniczeniach. Ale co jest najlepsze? Spróbowałbym porozmawiać bezpośrednio z dostawcami DB i może obejrzeć taśmy nosql
