Cơ sở dữ liệu NoSQLNoSQL Databases

Thuộc bộ kiến thức Backend Roadmap.

Tổng quan

NoSQL (“Not Only SQL”) là thuật ngữ chung cho các database không dùng mô hình relational truyền thống gồm bảng, hàng, và schema cứng nhắc liên kết qua foreign key và join. Thay vào đó, mỗi họ NoSQL được tối ưu cho một hình dạng dữ liệu và pattern truy cập cụ thể: tra cứu đơn giản theo key, document lồng nhau, hàng thưa (wide row), hay đồ thị các thực thể liên kết.

Các database NoSQL xuất hiện vào giữa đến cuối những năm 2000, xuất phát từ nhu cầu của các công ty vận hành ở quy mô mà một server relational đơn lẻ khó đáp ứng. Google (Bigtable, 2006), Amazon (bài báo Dynamo, 2007) và Facebook (Cassandra, 2008) đều công bố hoặc open-source các hệ thống được xây để xử lý workload phân tán khổng lồ với throughput cao, nơi horizontal scaling (thêm nhiều máy commodity) quan trọng hơn khả năng truy vấn phong phú và các đảm bảo mạnh của một relational database (RDBMS).

Đánh đổi cốt lõi của NoSQL: nó nới lỏng một số thứ mà relational database đảm bảo — schema cố định, join nhiều bảng, và thường là ACID transaction mạnh — để đổi lấy sự linh hoạt, horizontal scalability, và hiệu năng trên các pattern truy cập cụ thể. NoSQL không phải là thứ thay thế SQL; nó là một bộ công cụ chuyên biệt mà bạn dùng khi mô hình relational không phù hợp.

Ghi chú này giả định bạn đã quen với Relational Databases và liên kết tới Database Design & Scaling cùng Caching.

Kiến thức nền tảng

Vì sao NoSQL xuất hiện

Relational database là kho lưu trữ đa dụng tuyệt vời, nhưng nhiều yếu tố đã bộc lộ giới hạn của chúng ở quy mô lớn:

• Khối lượng và tốc độ ở quy mô web — mạng xã hội, IoT, log, và clickstream tạo ra hàng tỷ lượt write khó phục vụ từ một node primary duy nhất.
• Horizontal scaling — RDBMS truyền thống scale lên (máy lớn hơn). Sharding một relational database với join và transaction xuyên shard rất khó. Các hệ NoSQL được thiết kế để scale ra trên nhiều node ngay từ đầu.
• Sự linh hoạt về schema — phát triển agile thay đổi hình dạng dữ liệu liên tục. Schema cứng và migration làm chậm team; dữ liệu bán cấu trúc (JSON) phù hợp tự nhiên với nhiều tính năng sản phẩm.
• Pattern truy cập chuyên biệt — một cache cần tra cứu key trong microsecond; một recommendation engine cần duyệt graph; một feed cần đọc timeline của một user thật nhanh. Lưu trữ relational “một cỡ cho tất cả” không phải lúc nào cũng tối ưu.
• Chi phí — scale ra trên phần cứng commodity hoặc dịch vụ cloud managed có thể rẻ hơn so với việc mua server relational ngày càng lớn.

Đánh đổi giữa SQL và NoSQL

Khía cạnh	Relational (SQL)	NoSQL
Data model	Bảng, hàng, cột; đã normalize	Key-value, document, wide-column, graph
Schema	Cố định, bắt buộc (schema-on-write)	Linh hoạt / động (thường schema-on-read)
Ngôn ngữ truy vấn	SQL (chuẩn hóa)	API/DSL riêng theo sản phẩm (một số giống SQL)
Join	Hạng nhất, mạnh mẽ	Hạn chế hoặc không có; ưu tiên denormalization
Transaction	ACID mạnh xuyên hàng/bảng	Thường hạn chế; tùy sản phẩm
Scaling	Chủ yếu vertical; sharding khó	Horizontal scaling là mục tiêu thiết kế hạng nhất
Consistency	Mạnh theo mặc định	Điều chỉnh được; thường eventual consistency
Phù hợp nhất cho	Truy vấn phức tạp, quan hệ, tính toàn vẹn	Throughput cao, big data, hình dạng linh hoạt/chuyên biệt

Khi nào chọn cái nào

Chọn relational database khi:

• Dữ liệu có cấu trúc chặt và quan hệ quan trọng (đơn hàng, hóa đơn, kế toán).
• Bạn cần ACID transaction xuyên nhiều hàng/nhiều bảng (chuyển tiền, tồn kho).
• Truy vấn của bạn tùy biến và đa dạng — bạn chưa biết trước tất cả pattern truy cập.
• Tính toàn vẹn dữ liệu và constraint là tối quan trọng.

Chọn NoSQL khi:

• Bạn cần scale write/read theo chiều ngang vượt quá khả năng của một node.
• Pattern truy cập đã biết trước và đơn giản (tra cứu theo key, đọc một document).
• Dữ liệu bán cấu trúc, phân cấp, hoặc schema thay đổi thường xuyên.
• Bạn có hình dạng chuyên biệt: caching (key-value), catalog (document), time-series/event log (wide-column), dữ liệu nặng về quan hệ (graph).

Hầu hết hệ thống thực tế đều polyglot: PostgreSQL cho dữ liệu transactional cốt lõi, Redis cho caching/session, Elasticsearch cho search, và có thể thêm một graph hoặc document store cho một tính năng cụ thể.

CAP theorem và các mô hình consistency

CAP theorem phát biểu rằng một kho dữ liệu phân tán chỉ có thể đảm bảo tối đa hai trong ba thuộc tính sau khi xảy ra network partition:

• Consistency (C) — mọi lượt read nhận được kết quả write mới nhất (hoặc lỗi).
• Availability (A) — mọi request nhận được phản hồi (không lỗi), nhưng không đảm bảo đó là dữ liệu mới nhất.
• Partition tolerance (P) — hệ thống vẫn hoạt động dù mạng bị chia cắt giữa các node.

Vì network partition là không thể tránh trong mọi hệ phân tán, P không phải lựa chọn tùy ý — bạn buộc phải chịu được partition. Lựa chọn thực sự khi partition xảy ra là C hay A:

• Hệ CP (ví dụ HBase, MongoDB ở cấu hình mặc định, Zookeeper) ưu tiên consistency: có thể từ chối request để tránh trả về dữ liệu cũ.
• Hệ AP (ví dụ Cassandra, DynamoDB, Riak) ưu tiên availability: vẫn cho write và hòa giải (reconcile) sau, chấp nhận inconsistency tạm thời.

Các database hiện đại thường cho phép điều chỉnh theo từng operation (xem quorum read/write bên dưới), nên “CP vs AP” là một dải liên tục chứ không phải nhãn cố định.

Các mô hình consistency:

• Strong consistency — sau khi một write hoàn tất, mọi read tiếp theo đều thấy nó. Dễ suy luận nhất; đánh đổi bằng latency/availability.
• Eventual consistency — các replica sẽ hội tụ “cuối cùng” nếu ngừng write; một read có thể tạm thời trả về dữ liệu cũ. Tuyệt cho availability và throughput.
• Read-your-writes / causal / monotonic — các mô hình trung gian cho các đảm bảo hữu ích mà không cần strong consistency đầy đủ.

ACID vs BASE

	ACID (RDBMS điển hình)	BASE (NoSQL điển hình)
Viết tắt của	Atomicity, Consistency, Isolation, Durability	Basically Available, Soft state, Eventual consistency
Mục tiêu	Tính đúng đắn và an toàn	Availability và scale
Consistency	Mạnh, tức thì	Eventual (hội tụ theo thời gian)
Transaction	Nhiều lệnh, tất-cả-hoặc-không	Thường single-item; hạn chế multi-item
Trạng thái	Luôn hợp lệ sau mỗi transaction	Có thể inconsistent tạm thời
Đánh đổi	Latency/availability lấy tính đúng đắn	Tính đúng đắn (ngắn hạn) lấy availability

Lưu ý: ranh giới đang mờ dần. MongoDB hỗ trợ ACID transaction đa document; DynamoDB hỗ trợ transaction; Google Spanner và CockroachDB cung cấp strong consistency phân tán. Hãy chọn dựa trên đảm bảo thực tế mà sản phẩm cung cấp, không phải dựa trên cái nhãn.

Khái niệm chính

Bốn họ NoSQL nhìn nhanh

Họ	Data model	Truy vấn theo	Sản phẩm tiêu biểu	Use case điển hình
Key-value	Value dạng “hộp đen” dưới một key duy nhất	Chỉ theo key	Redis, Memcached, DynamoDB, Riak	Cache, session, feature flag, counter
Document	Document JSON/BSON tự mô tả	Key + truy vấn theo field	MongoDB, CouchDB, Firestore	Catalog, user profile, CMS, dữ liệu app
Wide-column	Hàng với cột động, gom theo column family	Partition key + clustering	Cassandra, ScyllaDB, HBase, Bigtable	Time-series, event log, feed ở quy mô lớn
Graph	Node + edge kèm property	Traversal / pattern match	Neo4j, Dgraph, Amazon Neptune	Social graph, fraud, recommendation

Key-value store

Mô hình đơn giản nhất: một hash map khổng lồ, phân tán. Bạn lưu một value (database coi như bytes “hộp đen”) dưới một key duy nhất, và lấy lại theo key đó. Cực nhanh và dễ scale, nhưng thường bạn không thể truy vấn theo nội dung của value.

Sản phẩm: Redis (in-memory, nhiều cấu trúc dữ liệu phong phú, tùy chọn persistence), Memcached (cache in-memory, không persistence), DynamoDB (managed, bền, scale được), Riak (phân tán, AP, kiểu Dynamo).

Ví dụ (Redis):

# Lưu session kèm thời gian hết hạn
SET session:abc123 '{"userId":42,"role":"admin"}' EX 3600
GET session:abc123

# Counter atomic cho rate limiting
INCR api:calls:user:42
EXPIRE api:calls:user:42 60

# Bảng xếp hạng dùng sorted set
ZADD leaderboard 1500 "player:alice"
ZADD leaderboard 2300 "player:bob"
ZREVRANGE leaderboard 0 9 WITHSCORES   # top 10

Ngoài string thuần, Redis còn cung cấp list, set, sorted set, hash, stream, và pub/sub — đó là lý do nó được dùng vượt xa caching đơn thuần. Xem Caching.

Document store

Lưu các document — bản ghi tự mô tả, lồng nhau ở dạng JSON hoặc BSON. Document được gom vào các collection. Không có schema cố định, nên các document khác nhau trong cùng collection có thể có field khác nhau. Bạn có thể truy vấn trên bất kỳ field nào, tạo index, và cập nhật từng phần lồng nhau của document.

Sản phẩm: MongoDB (phổ biến nhất; truy vấn phong phú, aggregation pipeline, transaction), CouchDB (API HTTP/JSON, đồng thời đa phiên bản, đồng bộ offline), Firebase/Firestore (managed, listener real-time, ưu tiên mobile).

Ví dụ (MongoDB):

// Một document sản phẩm — dữ liệu liên quan được embed, không join
db.products.insertOne({
  _id: "SKU-1001",
  name: "Mechanical Keyboard",
  price: 89.99,
  tags: ["electronics", "peripherals"],
  specs: { switches: "brown", layout: "TKL", backlight: true },
  reviews: [
    { user: "alice", rating: 5, text: "Great feel" },
    { user: "bob",   rating: 4, text: "A bit loud" }
  ]
});

// Truy vấn theo field lồng nhau + phần tử trong array
db.products.find({
  "specs.switches": "brown",
  tags: "peripherals",
  price: { $lt: 100 }
});

// Aggregation: rating trung bình mỗi sản phẩm
db.products.aggregate([
  { $unwind: "$reviews" },
  { $group: { _id: "$_id", avgRating: { $avg: "$reviews.rating" } } }
]);

Việc embed dữ liệu liên quan (reviews nằm trong product) tránh được join và cho phép đọc trọn sản phẩm trong một truy vấn — một ý tưởng modeling cốt lõi của NoSQL.

Wide-column store

Còn gọi là column-family store. Dữ liệu được tổ chức thành các hàng định danh bởi partition key, và mỗi hàng có thể có tập cột động, lớn. Các hàng được phân bố qua các node theo partition key; trong một partition, hàng được sắp xếp theo clustering column. Mô hình này được xây cho throughput write khổng lồ và read dự đoán được trên các partition đã biết — nhưng bạn phải thiết kế bảng quanh các truy vấn của mình, vì nó không hỗ trợ truy vấn tùy biến và join.

Sản phẩm: Cassandra (AP, consistency điều chỉnh được, không có single point of failure), ScyllaDB (tương thích Cassandra, viết bằng C++, hiệu năng cao hơn), HBase (chạy trên HDFS, CP, kiểu Bigtable), Google Bigtable (managed, vận hành Search/Maps/Analytics).

Ví dụ (Cassandra CQL):

-- Thiết kế bảng cho truy vấn: "các event gần đây của một device, mới nhất trước"
CREATE TABLE events_by_device (
  device_id   text,
  event_time  timestamp,
  event_type  text,
  payload     text,
  PRIMARY KEY (device_id, event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

-- Write
INSERT INTO events_by_device (device_id, event_time, event_type, payload)
VALUES ('dev-42', '2026-07-19T10:00:00Z', 'temp', '{"c":21.5}');

-- Read: hiệu quả, chỉ chạm một partition, đã được sắp xếp sẵn
SELECT * FROM events_by_device
WHERE device_id = 'dev-42'
LIMIT 100;

Partition key (device_id) quyết định node nào giữ dữ liệu; clustering column (event_time) quyết định thứ tự sắp xếp bên trong. Chọn partition key tốt (để tránh “hot partition” và partition phình vô hạn) là kỹ năng trung tâm.

Graph database

Mô hình hóa dữ liệu thành các node (thực thể) nối với nhau bởi các edge (quan hệ), cả hai đều có thể mang property. Chúng vượt trội khi quan hệ là trọng tâm — duyệt “bạn của bạn”, tìm đường ngắn nhất, hoặc phát hiện các vòng tài khoản fraud liên kết — những truy vấn sẽ cần rất nhiều join tốn kém trong SQL.

Sản phẩm: Neo4j (phổ biến nhất; ngôn ngữ truy vấn Cypher), Dgraph (phân tán, GraphQL-native), Amazon Neptune (managed; hỗ trợ Gremlin và SPARQL).

Ví dụ (Neo4j Cypher):

// Tạo người và một mối quan hệ bạn bè
CREATE (alice:Person {name: 'Alice'})
CREATE (bob:Person {name: 'Bob'})
CREATE (carol:Person {name: 'Carol'})
CREATE (alice)-[:FRIENDS_WITH]->(bob)
CREATE (bob)-[:FRIENDS_WITH]->(carol);

// Bạn-của-bạn của Alice mà cô ấy chưa là bạn
MATCH (alice:Person {name: 'Alice'})-[:FRIENDS_WITH]->(:Person)
      -[:FRIENDS_WITH]->(fof:Person)
WHERE NOT (alice)-[:FRIENDS_WITH]->(fof) AND fof <> alice
RETURN DISTINCT fof.name;

Chi phí traversal phụ thuộc vào số quan hệ đi qua, không phải tổng kích thước dataset — nên truy vấn quan hệ sâu vẫn nhanh dù dữ liệu tăng lên.

Các kho dữ liệu chuyên biệt

Ngoài bốn họ kinh điển, một số kho được xây cho mục đích riêng cũng rất phổ biến trong backend:

• Search engine — Elasticsearch, OpenSearch, Apache Solr. Xây trên inverted index cho full-text search, chấm điểm relevance, faceting, và analytics. Thường ghép với một database chính (search trên một bản sao của dữ liệu).
• Time-series database (TSDB) — InfluxDB, TimescaleDB (một extension của PostgreSQL), Prometheus. Tối ưu cho metric có timestamp: ingest cao, downsampling, retention policy, truy vấn theo cửa sổ thời gian.
• Kho analytics / OLAP dạng columnar — ClickHouse, Apache Druid, Apache Pinot. Lưu dữ liệu theo cột để aggregation nhanh trên hàng tỷ dòng; phục vụ dashboard và analytics, không phải write transactional.
• Vector database — Pinecone, Milvus, Weaviate, Qdrant, pgvector. Lưu embedding chiều cao và hỗ trợ tìm kiếm tương đồng (nearest-neighbor) — xương sống của semantic search và Retrieval-Augmented Generation (RAG). Xem AI for Backend.

Data modeling cho NoSQL

Modeling cho NoSQL khác biệt về bản chất so với modeling relational. Trong SQL bạn normalize trước rồi để join ghép lại dữ liệu. Trong NoSQL bạn mô hình quanh các pattern truy cập và thường denormalize mạnh tay.

• Thiết kế hướng access-pattern — liệt kê mọi truy vấn ứng dụng cần trước khi thiết kế bảng/collection. Cấu trúc dữ liệu sao cho mỗi truy vấn chạm một partition/document/key. Bạn tối ưu cho read, không phải cho cấu trúc gọn gàng.
• Denormalization — nhân bản dữ liệu để một lần read trả về mọi thứ cần thiết (ví dụ lưu tên tác giả trong mỗi bài post, không chỉ author ID). Đánh đổi storage và độ phức tạp khi write để lấy tốc độ read. Giữ các bản sao đồng bộ trở thành việc của ứng dụng.
• Embedding vs referencing (document) — embed dữ liệu được đọc cùng nhau và thuộc sở hữu của cha (line item của đơn hàng nằm trong đơn hàng); reference dữ liệu lớn, dùng chung, hoặc cập nhật độc lập (một user được nhiều post tham chiếu).
• Aggregate — mô hình quanh đơn vị bạn đọc và ghi như một khối. Một document/hàng lý tưởng nên khớp với một thao tác nghiệp vụ.

Single-table design (DynamoDB): Một pattern nâng cao nổi tiếng, trong đó nhiều loại entity nằm trong một bảng, phân biệt bằng partition key (PK) và sort key (SK) được ghép khéo léo. Điều này cho phép một truy vấn lấy về các item liên quan (ví dụ một user và tất cả đơn hàng của họ) mà không cần join.

PK	SK	Attributes
USER#42	PROFILE#42	name, email
USER#42	ORDER#1001	total, status, date
USER#42	ORDER#1002	total, status, date

# Một truy vấn trả về profile CỦA user VÀ tất cả đơn hàng của họ:
Query where PK = "USER#42"
# Lọc chỉ lấy đơn hàng:
Query where PK = "USER#42" AND begins_with(SK, "ORDER#")

Nguyên tắc thiết kế: vì DynamoDB không có join và tính phí theo từng request, bạn đặt các item liên quan cùng một partition key để đọc chúng trong một truy vấn hiệu quả.

So sánh giữa các họ

	Key-value	Document	Wide-column	Graph
Data model	Key → value hộp đen	Collection các document JSON	Hàng có partition, cột động	Node + edge + property
Khả năng truy vấn	Chỉ theo key	Truy vấn phong phú trên mọi field	Partition/clustering key; ad hoc hạn chế	Traversal, pattern matching
Consistency	Điều chỉnh được (thường eventual)	Điều chỉnh; MongoDB mặc định mạnh trên primary	Điều chỉnh (Cassandra quorum)	Thường mạnh (Neo4j ACID)
Scaling	Horizontal xuất sắc	Tốt (sharding)	Horizontal xuất sắc	Khó phân tán hơn
Use case tốt nhất	Cache, session, counter	Dữ liệu app, catalog, profile	Time-series, log, feed quy mô lớn	Quan hệ, social, fraud
Điểm yếu	Truy vấn theo value	Join xuyên document	Truy vấn ad hoc, join	Write cực lớn, sharding

Best Practices

• Mô hình quanh pattern truy cập, không quanh entity. Liệt kê các truy vấn read/write trước, rồi thiết kế storage sao cho mỗi cái là một operation hiệu quả duy nhất. Đây là điều ngược với normalization relational.
• Đừng ép mọi thứ vào một database. Dùng polyglot persistence: relational cho dữ liệu transactional cốt lõi, key-value cho caching, search engine cho text, và một kho chuyên biệt chỉ khi nó thắng rõ rệt.
• Hiểu nhu cầu consistency theo từng operation. Dùng strong consistency ở nơi tính đúng đắn quan trọng (thanh toán), eventual consistency ở nơi availability/latency quan trọng (feed, đếm view). Nhiều sản phẩm cho phép điều chỉnh theo từng truy vấn (ví dụ Cassandra QUORUM, DynamoDB read strongly-consistent).
• Chọn partition/shard key cẩn thận. Key kém tạo ra hot partition (tải không đều) hoặc partition không giới hạn (phình vô hạn). Nhắm tới key có cardinality cao, phân bố đều.
• Denormalize có chủ đích, và tự chịu trách nhiệm về consistency. Nhân bản dữ liệu tăng tốc read nhưng bạn phải giữ các bản sao đồng bộ khi write — thường qua logic ứng dụng, job nền, hoặc luồng change-data-capture.
• Đặt TTL và retention. Với cache, session, và time-series, dùng expiry/retention policy để dữ liệu không phình vô hạn.
• Index cho truy vấn của bạn, nhưng đừng mù quáng. Index tăng tốc read nhưng làm chậm write và tốn storage. Chỉ index các field bạn thực sự filter/sort.
• Nắm rõ giới hạn transaction. Nếu cần atomicity đa item, hãy xác minh sản phẩm hỗ trợ (MongoDB multi-doc transaction, DynamoDB TransactWriteItems) và hiểu chi phí.
• Lên kế hoạch cho lỗi và hội tụ eventual. Trong hệ AP, thiết kế write idempotent và cơ chế resolve xung đột (last-write-wins, vector clock, CRDT) để các replica reconcile đúng.
• Benchmark với dữ liệu và pattern truy cập thực tế. Hiệu năng NoSQL phụ thuộc rất nhiều vào key và hình dạng truy vấn; hãy test ở quy mô đại diện trước khi cam kết.

Tài liệu tham khảo

• MongoDB — What Is NoSQL?
• AWS — What Is NoSQL?
• Amazon Dynamo Paper (2007)
• Google Bigtable Paper (2006)
• Martin Kleppmann — Designing Data-Intensive Applications
• Cassandra — Data Modeling Documentation
• The DynamoDB Book — Single-Table Design
• Neo4j — Graph Database Concepts

# Session store with expiry
SET session:abc123 '{"userId":42,"role":"admin"}' EX 3600
GET session:abc123

# Atomic counter for rate limiting
INCR api:calls:user:42
EXPIRE api:calls:user:42 60

# Leaderboard using a sorted set
ZADD leaderboard 1500 "player:alice"
ZADD leaderboard 2300 "player:bob"
ZREVRANGE leaderboard 0 9 WITHSCORES   # top 10

// A product document — related data embedded, not joined
db.products.insertOne({
  _id: "SKU-1001",
  name: "Mechanical Keyboard",
  price: 89.99,
  tags: ["electronics", "peripherals"],
  specs: { switches: "brown", layout: "TKL", backlight: true },
  reviews: [
    { user: "alice", rating: 5, text: "Great feel" },
    { user: "bob",   rating: 4, text: "A bit loud" }
  ]
});

// Query by nested field + array membership
db.products.find({
  "specs.switches": "brown",
  tags: "peripherals",
  price: { $lt: 100 }
});

// Aggregation: average rating per product
db.products.aggregate([
  { $unwind: "$reviews" },
  { $group: { _id: "$_id", avgRating: { $avg: "$reviews.rating" } } }
]);

-- Model the table for the query: "recent events for a device, newest first"
CREATE TABLE events_by_device (
  device_id   text,
  event_time  timestamp,
  event_type  text,
  payload     text,
  PRIMARY KEY (device_id, event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

-- Write
INSERT INTO events_by_device (device_id, event_time, event_type, payload)
VALUES ('dev-42', '2026-07-19T10:00:00Z', 'temp', '{"c":21.5}');

-- Read: efficient, hits one partition, already sorted
SELECT * FROM events_by_device
WHERE device_id = 'dev-42'
LIMIT 100;

// Create people and a friendship
CREATE (alice:Person {name: 'Alice'})
CREATE (bob:Person {name: 'Bob'})
CREATE (carol:Person {name: 'Carol'})
CREATE (alice)-[:FRIENDS_WITH]->(bob)
CREATE (bob)-[:FRIENDS_WITH]->(carol);

// Friends-of-friends of Alice she isn't already friends with
MATCH (alice:Person {name: 'Alice'})-[:FRIENDS_WITH]->(:Person)
      -[:FRIENDS_WITH]->(fof:Person)
WHERE NOT (alice)-[:FRIENDS_WITH]->(fof) AND fof <> alice
RETURN DISTINCT fof.name;

# One query returns the user profile AND all their orders:
Query where PK = "USER#42"
# Filter to just orders:
Query where PK = "USER#42" AND begins_with(SK, "ORDER#")