Сховище Table

Розробка для Azure Storage

Shahzad Mian

Content developer, DataCamp

Table storage

Піктограма сховища

Table storage vs CosmosDB

CRUD

Таблиця даних

Діаграма реляційної схеми з підписом "Complex joins = Not needed here

Для швидкого й економного доступу до структурованих даних через прості пошуки за ключем.
Типові сценарії:
- Збереження показників IoT‑сенсорів.
- Конфігураційні дані.
Найкраще, коли важливі простота і масштабованість, а не складні запити.

Коли використовувати Table storage

Cosmos DB = розширені запити, глобальна дистрибуція або кілька API.
- Підтримує глобальну реплікацію з малою затримкою та гнучкою індексацією.
- Ідеально для застосунків з великим масштабом і високою продуктивністю.
- Краще, коли потрібні API на кшталт MongoDB чи Cassandra.
Компроміс: більше можливостей — вища вартість.

Azure Table vs Cosmos DB

Приклад Table storage

Дані в Table Storage групуються в tables.
Кожна таблиця містить entities — подібні до рядків.
Кожна сутність має properties — подібні до стовпців.
Кожна сутність мусить мати PartitionKey і RowKey для унікальної ідентифікації.
Ці ключі забезпечують швидкі та ефективні запити навіть у масштабі.

Ви можете виконувати CRUD через:
- Azure Portal.
- SDK або REST API.
- Azure Storage Explorer.
Керуйте даними без турбот про індекси чи зміни схеми.

CRUD operations

      "PartitionKey": "CustomerA",
      "RowKey": "1001",
      "Name": "Ava",
      "Points": 120

Скріншот 2025-12-29 о 10.39.44 pm.png


table_client.update_entity(entity)
table_client.delete_entity("CustomerA","1001")

Використовуйте Table Storage для простих, масштабованих і економних структурованих даних.
Кожен запис потребує PartitionKey і RowKey.
Обирайте Cosmos DB, коли потрібні багатші запити, глобальна реплікація чи кілька моделей даних.
Обидва сервіси можуть доповнювати одне одного в гібридних архітектурах даних.

Підсумок Table storage

Таблиця з partition key та row keys

Розробка для Azure Storage