Często zadawane pytania dotyczące usługi Azure Cosmos DB

Usługa Azure Cosmos DB jest odpowiednia dla przypadków użycia internetu, urządzeń przenośnych, gier i IoT. W tych przypadkach użycia; automatyczne skalowanie, przewidywalna wydajność, szybka kolejność milisekund odpowiedzi, a możliwość wykonywania zapytań dotyczących danych bez schematu jest ważna. Usługa Azure Cosmos DB nadaje się do szybkiego opracowywania i obsługi ciągłej iteracji modeli danych aplikacji. Aplikacje, które zarządzają zawartością i danymi generowanymi przez użytkownika, często mapowane na typowe przypadki użycia usługi Azure Cosmos DB.

Jednostka żądania (RU) to miara przepływności w usłudze Azure Cosmos DB. Przepływność pojedynczej GET jednostki żądania odpowiada przepływności akcji HTTP dla dokumentu 1-kilobitowego. Każda operacja w usłudze Azure Cosmos DB; w tym operacje odczytu, zapisu, zapytań i wykonywania procedury składowanej; ma deterministyczną wartość jednostkową żądania na podstawie przepływności wymaganej do ukończenia operacji. Zamiast wymuszać rozważenie użycia procesora CPU, operacji we/wy i pamięci w odniesieniu do przepływności aplikacji, można traktować jednostki żądań.

Każdy kontener usługi Azure Cosmos DB można skonfigurować z aprowizowaną przepływnością pod względem jednostek żądań na sekundę (RU/s). Poszczególne żądania można porównać do mierzenia w jednostkach żądań i utworzyć kontener, aby obsłużyć sumę jednostek żądań we wszystkich żądaniach dla tego kontenera w ciągu sekundy. Możesz również skalować przepływność kontenera w górę lub w dół w miarę rozwoju potrzeb aplikacji. Aby uzyskać więcej informacji na temat mierzenia jednostek żądań, zobacz kalkulator przepływności.

Modele danych klucz/wartość (tabela), kolumnowe, dokumentowe i grafowe są obsługiwane natywnie ze względu na projekt ARS (atomy, rekordy i sekwencje), na którym jest oparta usługa Azure Cosmos DB. Atomy, rekordy i sekwencje można łatwo mapować i projektować na różne modele danych. Interfejsy API dla podzestawu modeli są dostępne przy użyciu projektu usługi ARS (MongoDB, NoSQL, Table, Apache Cassandra i Apache Gremlin). Usługa Azure Cosmos DB obsługuje również inne interfejsy API.

Kontener to grupa elementów. Kontenery mogą obejmować co najmniej jedną partycję i mogą być skalowane w celu obsługi praktycznie nieograniczonych woluminów magazynu lub przepływności.

Kontener jest jednostką rozliczaną, w której przepływność i używany magazyn określają koszt. Każdy kontener jest rozliczany co godzinę na podstawie aprowizowanej przepływności i używanego miejsca do magazynowania. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Cosmos DB.

Azure Cosmos DB to rozproszona globalnie wielomodelowa usługa bazy danych firmy Microsoft. Model wielomodelowy odnosi się do obsługi wielu interfejsów API i modeli danych usługi Azure Cosmos DB. W tym modelu różne interfejsy API używają różnych formatów danych do przechowywania i protokołu przewodowego. Na przykład; Program NoSQL używa formatu JSON, baza MongoDB używa kodowanego binarnie kodu JSON (BSON), tabela używa modelu danych jednostki (EDM), usługa Cassandra używa języka Cassandra Query Language (CQL), język Gremlin używa formatu JSON. W związku z tym zalecamy używanie tego samego interfejsu API dla wszystkich dostępu do danych na danym koncie.

Tak. Interfejsy API usługi Azure Cosmos DB umożliwiają bezpośrednią integrację. Na przykład interfejsy API REST usługi Azure Cosmos DB można zintegrować z usługą Azure API Management dla operacji CRUD, eliminując konieczność korzystania z usług pośrednich, takich jak Azure Functions.

Tak, usługa Azure Cosmos DB jest zgodna ze standardem HIPAA. Ustawa HIPAA określa wymogi dotyczące wykorzystywania, ujawniania i ochrony informacji o zdrowiu umożliwiających indywidualną identyfikację osoby. Aby uzyskać więcej informacji, zobacz temat Microsoft Trust Center.

Nie ma limitu całkowitej ilości danych, które kontener może przechowywać w usłudze Azure Cosmos DB.

Nie ma limitu całkowitej przepływności, którą kontener może obsługiwać w usłudze Azure Cosmos DB. Kluczowym pomysłem jest rozłożenie obciążenia w przybliżeniu nawet między wystarczająco dużą liczbę kluczy partycji.

Tak oba tryby są zawsze w pełni szyfrowane.

Liczba aprowizowanych kontenerów, liczba godzin, przez które kontenery były w trybie online, a aprowizowana przepływność dla każdego kontenera określa opłaty za użycie usługi Azure Cosmos DB. Aby uzyskać więcej informacji o cenach, zapoznaj się z cennikiem usługi Azure Cosmos DB.

Aby zadać pytanie techniczne, możesz opublikować jedno z tych dwóch forów pytań i odpowiedzi:

• Pytania i odpowiedzi firmy Microsoft (pytania i odpowiedzi)
• Stack Overflow. Stack Overflow jest najlepszy w przypadku pytań programistycznych. Podaj jak najwięcej szczegółów, aby pytanie było jasne i odpowiadalne.

Aby rozwiązać problem z Twoim kontem, wyślij żądanie obsługi w portalu Azure Portal.

Najpierw musisz zarejestrować się w celu uzyskania subskrypcji platformy Azure. Po zarejestrowaniu się w celu uzyskania subskrypcji platformy Azure możesz dodać kontener API for NoSQL do subskrypcji platformy Azure.

Zestawy SDK (Software Development Kit) są dostępne dla platform .NET, Python, Node.js, JavaScript, Go i Java. Deweloperzy mogą również korzystać z interfejsu API REST do interakcji z zasobami usługi Azure Cosmos DB z większej liczby platform i języków.

Zapoznaj się z przykładami i szablonami kodu szybkiego startu dla interfejsu API dla noSQL:

• .NET
• Python
• Node.js/JavaScript
• Java/Spring
• Idź

Tak, interfejs API for NoSQL umożliwia aplikacjom przechowywanie dowolnych dokumentów JSON jako elementów bez definicji schematu lub wskazówek. Dane są natychmiast dostępne do wykonywania zapytań za pomocą języka zapytań usługi Azure Cosmos DB for NoSQL.

Tak, interfejs API dla noSQL obsługuje transakcje między dokumentami wyrażone przy użyciu partii w zestawach SDK lub jako procedury składowane i wyzwalacze języka JavaScript. Transakcje są ograniczone do jednej partycji w każdym kontenerze i wykonywane za pomocą semantyki ACID jako "wszystkie lub nic", odizolowane od innych współbieżnie wykonujących kod i żądania użytkownika. Jeśli wystąpią wyjątki, cała transakcja zostanie wycofana.

Bazy danych można tworzyć przy użyciu jednego z następujących narzędzi:

• Portal Azure
• Zestawy SDK klienta NoSQL (płaszczyzna danych) interfejsu API
  • .NET
  • Python
  • JavaScript
  • Java
  • Idź
• Zestawy SDK interfejsu API do zarządzania noSQL (płaszczyzną sterowania)
  • .NET
  • Python
  • JavaScript
  • Java
  • Idź
• Azure Resource Manager
  • Szablon JSON
  • Biceps
  • Terraform
• API REST

Yes! Usługa Azure Cosmos DB obsługuje uwierzytelnianie firmy Microsoft Entra w celu zarządzania usługą i jej zasobami (płaszczyzną sterowania) oraz wykonywania danych, operacji i zapytań (płaszczyzna danych). Uwierzytelnianie płaszczyzny sterowania odbywa się przy użyciu funkcji kontroli dostępu opartej na rolach platformy Azure. Możesz użyć wstępnie skonfigurowanej roli wbudowanej](.. /.. /role-based-access-control/built-in-roles.md) lub możesz utworzyć rolę niestandardową. Za pomocą kontroli dostępu opartej na rolach platformy Azure można zarządzać kontami, bazami danych, kontenerami i metadanymi. Płaszczyzna sterowania obejmuje między innymi operacje, ale nie tylko te przykłady.

• Tworzenie, zastępowanie lub usuwanie baz danych — tworzenie, zastępowanie lub usuwanie kontenerów — odczytywanie lub zastępowanie przepływności bazy danych — odczytywanie lub zastępowanie uwierzytelniania płaszczyzny danych kontenera używa niestandardowego interfejsu API dla implementacji kontroli dostępu opartej na rolach noSQL. Dzięki tej natywnej implementacji można również użyć wstępnie skonfigurowanych lub niestandardowych ról. Za pomocą natywnej kontroli dostępu opartej na rolach można wykonywać zapytania, zarządzać elementami lub wykonywać inne typowe operacje. Płaszczyzna danych obejmuje między innymi operacje, ale nie tylko te przykłady.
• Tworzenie, zastępowanie, aktualizowanie lub usuwanie elementów — elementy poprawiania — wykonywanie zapytań

Structured Query Language (SQL) to język, który jest zwykle używany do wykonywania zapytań dotyczących danych relacyjnych. Interfejs API dla NoSQL ma niestandardowy język zapytań NoSQL pochodzący z języka SQL. Język zapytań NoSQL zawiera podzestaw języka zapytań SQL zwykle skojarzony z programem SQL Server wraz z różnymi ulepszeniami specyficznymi dla programu NoSQL. Język zapytań NoSQL udostępnia rozbudowane operatory hierarchiczne i relacyjne oraz rozszerzalność za pomocą funkcji zdefiniowanych przez użytkownika (UDF) opartych na języku JavaScript. Gramatyka JSON umożliwia modelowanie dokumentów JSON jako drzew z węzłami oznaczonymi etykietami, które są używane zarówno przez techniki automatycznego indeksowania usługi Azure Cosmos DB, jak i dialekt zapytań SQL usługi Azure Cosmos DB. Aby uzyskać informacje na temat korzystania z tego języka zapytań, zobacz Zapytanie NoSQL.

Interfejs API dla noSQL obsługuje agregację za pomocą funkcji agregujących, takich jak: COUNT, MAX, AVGi SUM za pośrednictwem języka zapytań NoSQL.

Interfejs API dla noSQL obsługuje optymistyczną kontrolę współbieżności (OCC) za pomocą tagów jednostek HTTP lub elementów ETag. Każdy zasób interfejsu API dla noSQL ma element ETag, a element ETag jest ustawiany na serwerze za każdym razem, gdy dokument jest aktualizowany. Nagłówek ETag i bieżąca wartość są uwzględniane we wszystkich komunikatach odpowiedzi. Tagi ETag mogą być używane z nagłówkiem If-Match , aby umożliwić serwerowi podjęcie decyzji, czy zasób ma zostać zaktualizowany. Wartość If-Match jest wartością elementu ETag do sprawdzenia. Jeśli wartość elementu ETag jest zgodna z wartością ETag serwera, zasób zostanie zaktualizowany. Jeśli element ETag nie jest już aktualny, serwer odrzuca operację z kodem odpowiedzi "Błąd warunku wstępnego HTTP 412". Następnie klient pobiera zasób, aby uzyskać bieżącą wartość elementu ETag dla zasobu. Ponadto elementy ETag mogą być używane z nagłówkiem, If-None-Match aby określić, czy jest potrzebny do ponownego pobrania zasobu.

Większość zestawów SDK interfejsu API dla noSQL obejmuje klasy do zarządzania optymistyczną kontrolą współbieżności.

Użyj funkcji importowania zbiorczego w zestawie SDK platformy .NET lub zestawie SDK języka Java dla interfejsu API for NoSQL, aby zaimportować duże zestawy danych. Ta funkcja optymalizuje aprowizowaną przepływność w celu importowania dużych zestawów danych.

Możesz też użyć platformy Apache Spark do importowania danych na dużą skalę przy użyciu języka Python lub języka Scala.

Tak, ponieważ usługa Azure Cosmos DB for NoSQL jest usługą RESTful, łącza zasobów są niezmienne i mogą być buforowane. Interfejs API dla klientów NoSQL może określić nagłówek "If-None-Match" dla odczytów względem dowolnego dokumentu lub kontenera, a następnie zaktualizować swoje kopie lokalne po zmianie wersji serwera.

Tak. Emulator usługi Azure Cosmos DB zapewnia wysoką wierność emulacji usługi Azure Cosmos DB. Obsługuje ona funkcje identyczne z usługą Azure Cosmos DB w różnych interfejsach API. Ta funkcja obejmuje obsługę tworzenia elementów, wykonywania zapytań o elementy, aprowizowania kontenerów i skalowania kontenerów. Aplikacje można opracowywać i testować przy użyciu punktów końcowych emulatora. Następnie możesz wdrożyć aplikacje na platformie Azure w skali globalnej, zmieniając parametry połączenia z emulatora na usługę na żywo.

To ograniczenie eksploratora danych jest ograniczeniem języka JavaScript. Język JavaScript używa liczb zmiennoprzecinkowych o podwójnej precyzji, jak określono w Institute of Electrical and Electronics Engineers (IEEE) 754. Ten typ danych może bezpiecznie przechowywać liczby między -(2⁵³ -1) i 2^53-1 (czyli tylko 9007199254740991).

Kontrola dostępu oparta na rolach (RBAC) to metoda regulacji dostępu do komputerów lub zasobów sieciowych na podstawie ról poszczególnych użytkowników w przedsiębiorstwie. W usłudze Azure Cosmos DB kontrola dostępu oparta na rolach służy do udzielania dostępu płaszczyzny danych do użytkowników i aplikacji. Aby uzyskać więcej informacji na temat różnych terminów w kontroli dostępu opartej na rolach, zobacz słownik zabezpieczeń.

Użyj natywnej funkcji kontroli dostępu opartej na rolach (RBAC) usługi Azure Cosmos DB, aby udzielić dostępu do płaszczyzny danych użytkownikom i aplikacjom. Aby uzyskać więcej informacji, zobacz Udzielanie dostępu opartego na rolach płaszczyzny danych.

Od tej pory obsługiwany jest tylko interfejs API NoSQL.

Obsługa witryny Azure Portal na potrzeby zarządzania rolami nie jest jeszcze dostępna.

Obecnie obsługiwane są zestawy SDK .NET V3, Java V4, JavaScript V3 i Python V4.3+.

Tak.

Tak. Aby uzyskać więcej informacji, zobacz wyłączanie uwierzytelniania opartego na kluczach.

Ogólne wytyczne dotyczące migrowania konta usługi Cosmos DB do innej grupy zasobów lub subskrypcji opisano w artykule Dotyczącym przenoszenia zasobów platformy Azure do nowej grupy zasobów lub subskrypcji .

Po pomyślnym przeniesieniu konta usługi Azure Cosmos DB zgodnie z ogólnymi wytycznymi wszystkie tożsamości (System-Assigned lub User-Assigned) skojarzone z kontem muszą zostać ponownie przypisane. Ponowne przypisanie jest wymagane w celu zapewnienia, że te tożsamości nadal mają niezbędne uprawnienia dostępu do klucza Key Vault.

Jeśli twoje konto usługi Cosmos DB ma włączone klucze zarządzane przez klienta, możesz przeprowadzić migrację konta tylko wtedy, gdy jest to konto klucza zarządzanego przez klienta między domenami. Aby uzyskać więcej informacji, zapoznaj się z przewodnikiem konfigurowania międzydzierżawowych kluczy zarządzanych przez klienta dla konta usługi Azure Cosmos DB za pomocą usługi Azure Key Vault.

Podczas migracji z trybu okresowego do trybu ciągłego nie można uruchamiać żadnych operacji płaszczyzny sterowania, które wykonują aktualizacje lub usuwanie na poziomie konta. Na przykład operacji, takich jak dodawanie lub usuwanie regionów, przełączanie awaryjne konta, aktualizacja polityki kopii zapasowej, itp., nie można uruchamiać, gdy migracja jest w toku. Czas migracji zależy od rozmiaru danych i liczby regionów na twoim koncie. Akcja przywracania na zmigrowanych kontach kończy się powodzeniem tylko od momentu pomyślnego zakończenia migracji.

Konto można przywrócić po zakończeniu migracji. Jeśli migracja zakończy się o godzinie 13:00 PST, możesz rozpocząć przywracanie do punktu w czasie od godziny 13:00 PST.

Tak.

Interfejs API dla noSQL, interfejs API dla tabel, interfejs API języka Gremlin i interfejs API dla kont bazy danych MongoDB korzystających z udostępnionej, aprowizowanej lub automatycznej aprowizowanej przepływności obsługują migrację do ciągłej kopii zapasowej.

Konta z włączoną usługą Azure Synapse Link lub z wyłączoną usługą Azure Synapse Link dla co najmniej jednej kolekcji nie mogą migrować do ciągłej kopii zapasowej.

Migracja zajmuje różny czas, który w dużej mierze zależy od rozmiaru danych i liczby regionów na twoim koncie. Stan migracji można uzyskać przy użyciu interfejsu wiersza polecenia platformy Azure lub poleceń programu PowerShell. W przypadku dużych kont z dziesiątkami terabajtów danych migracja może potrwać do kilku dni.

Tak, ta migracja wymaga czasu, który w dużej mierze zależy od konieczności oczekiwania na wszystkie stare wstępne zapisy, aby zostały opróżnione podczas ciągłej migracji kopii zapasowej. Stan migracji można uzyskać przy użyciu interfejsu wiersza polecenia platformy Azure lub poleceń programu PowerShell. W przypadku dużych kont z dziesiątkami terabajtów danych migracja może potrwać do kilku dni.

Nie, operacja migracji odbywa się w tle. Żądania klientów nie są zatem dotknięte. Jednak musimy wykonać pewne operacje zaplecza podczas migracji i może upłynąć dodatkowy czas, jeśli konto jest obciążone dużym obciążeniem.

Po uruchomieniu procesu migracji konto jest włączone w trybie ciągłym. Jeśli migracja zakończy się niepowodzeniem, należy ponownie zainicjować migrację, dopóki nie zakończy się pomyślnie.

Załóżmy, że rozpocząłeś migrację o godzinie t1 i zakończyłeś o godzinie t5. Nie można użyć znacznika czasu przywracania między t1 a t5. Załóżmy również, że Twoje konto jest teraz w trybie ciągłym. Aby przywrócić do czasu po t5, wykonaj przywracanie przy użyciu witryny Azure Portal, interfejsu wiersza polecenia lub programu PowerShell, tak jak zwykle przy użyciu konta ciągłego. Żądanie samoobsługowego przywracania można wykonać tylko po zakończeniu migracji. Aby przywrócić system do czasu przed t1 godziną, możesz otworzyć zgłoszenie do pomocy technicznej, tak jak zwykle, korzystając z konta do okresowych kopii zapasowych. Po migracji można wykonać okresowe przywracanie w ciągu 30 dni. W ciągu tych 30 dni można przywrócić dane na podstawie okresu przechowywania/interwału kopii zapasowych konta przed migracją. Na przykład, jeśli kopia zapasowa została skonfigurowana do przechowywania 24 kopii w odstępach 1 godziny, możesz przywrócić kopię zapasową w dowolnym momencie między (t1 – 24 hours) a t1.

Operacje, takie jak dodawanie/usuwanie regionu, tryb failover, zmiana zasad tworzenia kopii zapasowych i wszelkie zmiany przepływności powodujące przenoszenie danych są blokowane podczas migracji.

Nieudana migracja nie powoduje zablokowania żadnych operacji płaszczyzny sterowania. Jeśli migracja zakończy się niepowodzeniem, powtarzaj próbę, dopóki się nie powiedzie, zanim wykonasz inne operacje na płaszczyźnie sterowania.

Nie można anulować migracji, ponieważ migracje nie są operacją odwracalną. Za pośrednictwem zespołu pomocy technicznej można tymczasowo anulować ograniczenia i pozwolić na kontynuowanie operacji w trybie offline. Nie można jednak wrócić do okresowego stanu kopii zapasowej.

Nie ma narzędzia do szacowania czasu. Nasze testy i przebiegi skalowania wskazują, że przetworzenie konta z 1 TB danych zajmuje około 90 minut. W przypadku kont z wieloma regionami oblicz łączny rozmiar danych jako Number_of_regions * Data_in_single_region.

Przetestuj funkcję trybu ciągłej kopii zapasowej, aby sprawdzić, czy działa zgodnie z oczekiwaniami przed migracją kont produkcyjnych. Migracja jest operacją jednokierunkową i nie można jej cofnąć.

Tak, możesz utworzyć bezpłatne konto bazy danych z 1000 RU/s i 25 GB bezpłatnie.

Jeśli dopiero zaczynasz korzystać z platformy Azure, możesz utworzyć bezpłatne konto platformy Azure, co daje 30 dni i środki na wypróbowanie wszystkich usług platformy Azure. Jeśli masz subskrypcję programu Visual Studio, możesz również skorzystać z bezpłatnych środków na korzystanie z platformy Azure w dowolnej usłudze platformy Azure.

Możesz również użyć emulatora usługi Azure Cosmos DB, aby utworzyć i przetestować aplikację lokalnie bezpłatnie bez tworzenia subskrypcji platformy Azure. Jeśli sposób działania aplikacji w emulatorze usługi Azure Cosmos DB jest zadowalający, możesz zacząć korzystać z konta usługi Azure Cosmos DB w chmurze.

Usługa Azure Cosmos DB jest dostępna w witrynie Azure Portal. Najpierw utwórz konto w celu uzyskania subskrypcji platformy Azure. Po zarejestrowaniu się dodaj konto usługi Azure Cosmos DB do subskrypcji platformy Azure.

Użyj identyfikatora Entra firmy Microsoft do uwierzytelniania w usłudze Azure Cosmos DB dla wszystkich interfejsów API obsługujących tę metodę uwierzytelniania. W przypadku interfejsów API, które nie obsługują uwierzytelniania identyfikatora Entra firmy Microsoft, należy używać kluczy z ostrożnością. Upewnij się, że klucze dla kont produkcyjnych są bezpiecznie przechowywane, na przykład w usłudze Azure Key Vault.

Aby uzyskać informacje o dostępności regionalnej dla usługi Azure Cosmos DB, zobacz Dostępność produktów platformy Azure według regionów. Bazę danych można uwzględnić w co najmniej jednym z tych regionów.

Zestawy SDK (software development kit) dla usługi Azure Cosmos DB umożliwiają konfigurację regionów używanych na potrzeby połączeń. W większości zestawów SDK wartość "PreferredLocations" jest ustawiona na dowolne regiony platformy Azure, w których jest dostępna usługa Azure Cosmos DB.

Usługa Azure Cosmos DB jest obecna we wszystkich regionach świadczenia usługi Azure, jak określono na stronie Regiony świadczenia usługi Azure. Ponieważ jest to podstawowa usługa platformy Azure, każde nowe centrum danych ma obecność usługi Azure Cosmos DB.

Podczas ustawiania regionu należy pamiętać, że usługa Azure Cosmos DB szanuje suwerenne i rządowe chmury. Na przykład nie można replikować danych z suwerennego regionu. Podobnie nie można włączyć replikacji do innych suwerennych lokalizacji z konta zewnętrznego.

Aprowizowanie przepływności na poziomie kontenera i bazy danych to oddzielne oferty i przełączanie się między jedną z tych ofert wymaga migracji danych ze źródła do miejsca docelowego. Musisz utworzyć nową bazę danych lub kontener, a następnie przeprowadzić migrację danych przy użyciu biblioteki funkcji wykonawczej zbiorczej lub usługi Azure Data Factory.

Tak, usługa Azure Cosmos DB obsługuje analizę szeregów czasowych. Za pomocą zestawienia zmian można tworzyć zagregowane widoki na danych szeregów czasowych. To podejście można rozszerzyć przy użyciu przesyłania strumieniowego platformy Apache Spark lub innego procesora danych strumienia.

Aby uzyskać informacje na temat limitów przydziałów usług i limitów przepływności, zobacz limity przydziału usługi i limity.

Powiązana zawartość

• Często zadawane pytania dotyczące usługi Azure Cosmos DB for NoSQL
• Często zadawane pytania dotyczące usługi Azure Cosmos DB dla bazy danych MongoDB
• Często zadawane pytania dotyczące usługi Azure Cosmos DB dla języka Apache Gremlin
• Często zadawane pytania dotyczące usługi Azure Cosmos DB dla bazy danych Apache Cassandra
• Często zadawane pytania dotyczące usługi Azure Cosmos DB dla tabel