Projektujesz globalnie rozproszoną aplikację społecznościową, która przechowuje osie czasu użytkowników i komentarze jako dokumenty JSON. Użytkownicy muszą natychmiast widzieć swoje własne zapisy, a opóźnienia między regionami muszą pozostać niskie. Zapisy są równomiernie rozłożone według użytkownika. Jaki projekt Cosmos DB należy wybrać?

Prawidłowa odpowiedź to Azure Cosmos DB SQL (Core) API z Session consistency i partition key userId. Wyjaśnienie: Azure Cosmos DB SQL (Core) API jest idealny do przechowywania dokumentów JSON, takich jak osie czasu i komentarze. Session consistency zapewnia, że użytkownik zawsze widzi swoje własne zapisy w kolejności, w jakiej je utworzył lub zaktualizował (read-your-own-writes), co jest kluczowe dla aplikacji społecznościowych. Jednocześnie oferuje niższe opóźnienia niż Strong consistency. partition key userId równomiernie rozkłada dane użytkowników, zapobiegając gorącym partycjom i zapewniając niskie opóźnienia, ponieważ zapisy są równomiernie rozłożone według użytkownika. Inne opcje są mniej odpowiednie: Strong consistency (w opcji MongoDB i SQL API) zapewnia najwyższą spójność, ale kosztem wyższych opóźnień, co jest niepożądane w globalnie rozproszonej aplikacji społecznościowej. partition key region lub timestamp (w opcjach MongoDB i SQL API) mogą prowadzić do gorących partycji, ponieważ dane z jednego regionu lub z jednego okresu czasu mogą być intensywnie zapisywane, co zwiększy opóźnienia. Azure Table Storage nie jest optymalnym wyborem dla dokumentów JSON i oferuje tylko Eventual consistency, która nie gwarantuje widoczności własnych zapisów. Gremlin API jest przeznaczone do baz danych grafowych, a nie do przechowywania dokumentów JSON.