#nosql

Firestore Data Modeling Guide: Embedded Documents vs Referencing (with a Blog Case Study)

Khi chuyển từ cơ sở dữ liệu quan hệ (MySQL, PostgreSQL) sang Firestore, nhà phát triển thường giữ thói quen cũ, cố gắng tái tạo cấu trúc bảng thay vì tận dụng ưu điểm của mô hình tài liệu NoSQL. Bài viết so sánh hai cách tiếp cận chính: nhúng tài liệu (embedded documents) và tham chiếu (referencing) thông qua nghiên cứu trường hợp về một blog.

Những lập trình viên chuyển từ cơ sở dữ liệu quan hệ sang Firestore sẽ tìm hiểu cách tối ưu hóa mô hình dữ liệu bằng cách phân biệt giữa các tài liệu được gộp và tham chiếu để tránh rắc rối về hiệu suất và quản lý dữ liệu.

Dumbo Phone Home

MongoDB and Git had a baby, and it's named Dumbo. DumboDB will occasionally phone home to DoltHub. Learn more!

Getting Started with MongoDB: A Complete Beginner’s Guide from SQL to NoSQL

Getting Started with MongoDB: A Complete Beginner’s Guide from SQL to NoSQL A practical introduction to MongoDB for beginners and intermediate developers transitioning from traditional SQL …

Distributed Databases: An Overview

Cơ sở dữ liệu phân tán lưu trữ dữ liệu trên nhiều máy chủ kết nối qua mạng, với các kiến trúc phổ biến như shared-nothing và primary/secondary.

Lập trình viên cần đọc bài này để hiểu cách thiết kế hệ thống phân tán hiệu quả, giúp tối ưu hóa khả năng mở rộng, độ tin cậy và quản lý dữ liệu trong ứng dụng lớn và phân tán.

Accelerating AI in Healthcare: Fix Data Infrastructure Before AI Fails Become a Board Priority

Hầu hết dự án AI trong y tế thất bại do hạ tầng dữ liệu cũ, phân mảnh, không phù hợp với workloads thời gian thực. FHIR trở thành tiêu chuẩn bắt buộc nhưng triển khai quy mô lớn rất phức tạp. Couchbase đề xuất giải pháp NoSQL phân tán lưu trữ tài nguyên FHIR dạng JSON, hỗ trợ tìm kiếm toàn văn, triển khai đa vùng và hợp nhất workloads vận hành, phân tích cùng AI vector trên một nền tảng duy nhất, đồng thời tuân thủ HIPAA và GDPR.

Lập trình viên AI trong y tế nên đọc bài này để hiểu cách chuyển đổi cơ sở dữ liệu legacy sang các giải pháp hiện đại như Couchbase FHIR, giúp tối ưu hóa hiệu suất mô hình AI và giảm thiểu rủi ro do dữ liệu không đồng nhất gây ra trong môi trường y tế.

Distributed Databases: An Overview

Distributed databases store data across multiple networked nodes managed as a single logical system. Two primary architectures exist: primary/secondary (master/slave), where one node handles all writes with secondaries as read replicas, and shared-nothing, where data is partitioned across all nodes for linear write and read scalability. Shared-nothing systems use sharding to split data into partitions distributed across nodes, with replicas maintained for high availability. Relational databases struggle with distribution due to tightly coupled table structures, making NoSQL a common choice for clustered deployments. Couchbase implements shared-nothing architecture using 1024 vBuckets per bucket, each assigned as active and replica copies across nodes, with a vBucket map enabling SDK clients to route requests directly to the correct node without a central proxy.

See our new Azure Cosmos DB Design Patterns

The Azure Cosmos DB Design Patterns GitHub repo has been significantly updated with five new runnable patterns: Vector Search (using a local embedding model for RAG), Loop-Safe Change Feed (preventing infinite write loops with hash-based deduplication), Hierarchical Partition Key (multi-level partitioning for multi-tenant data), Transactional Outbox (atomic dual-write using TransactionalBatch + change feed relay), and Patch API (partial document updates that avoid read-modify-write conflicts). The Distributed Lock pattern was also reworked with a live interactive playground. Every sample runs locally via Docker and the Cosmos DB Linux emulator with no Azure subscription required, features a Blazor web UI, and is backed by emulator-based CI tests on .NET 10 with keyless authentication.

Need a different partition key in Azure Cosmos DB? Pick the right approach

Khi partition key trong Azure Cosmos DB gây ra truy vấn chéo partition hoặc hot partition, bạn có bốn lựa chọn: sử dụng tính năng "Change partition key" trên portal (ít nỗ lực nhất), sao chép container qua CLI (có thể online/offline), hoặc di cư tùy chỉnh bằng bulk ingestion, Azure Data Factory/Spark cùng Change Feed (tùy chỉnh cao nhất). Nếu chỉ vấn đề nằm ở read pattern, Global Secondary Index (GSI) sẽ tạo container read-only, tự động đồng bộ với partition key mới mà không ảnh hưởng đến nguồn. Bài viết cũng phân tích điều kiện tiên quyết, đánh đổi (chi phí RU, TTL, tính nhất quán) và cung cấp bảng quyết định để chọn phương pháp phù hợp.

Lập trình viên nên đọc bài này để giải quyết hiệu quả vấn đề phân vùng không hiệu quả trong Cosmos DB, từ các giải pháp đơn giản đến phức tạp, giúp tối ưu hóa chi phí và hiệu suất cho ứng dụng của mình.

Top Use Cases for DynamoDB in 2024

DynamoDB là cơ sở dữ liệu NoSQL dạng key-value của AWS, phù hợp cho các ứng dụng yêu cầu thông lượng cao và độ trễ thấp như gaming, streaming, ngân hàng, ứng dụng di động/web và IoT. Nó cung cấp khả năng mở rộng ngang, linh hoạt schema và sao chép toàn cầu, với hai tùy chọn định giá (provisioned/on-demand) và gói miễn phí 25 RCU, 25 WCU cùng 25 GB lưu trữ.

Lập trình viên cần đọc bài này để hiểu cách tối ưu hóa DynamoDB cho các ứng dụng thực tế, từ việc lựa chọn mô hình dữ liệu cho đến cách kết hợp với công cụ phân tích để tránh rủi ro về chi phí và hiệu suất trong các dự án serverless.

Aggregation Optimization in MongoDB: Unnecessary Unwinds (Part 2)

A MongoDB expert walks through the first optimization step for a slow aggregation pipeline in a video streaming service use case. The pipeline was originally designed with an RDBMS mindset, using two unnecessary $unwind stages after $lookup joins. The key insight: when $lookup's localField points to a field inside array elements, MongoDB automatically runs the join for each element — making the preceding $unwind redundant. The second $unwind, used to filter out empty arrays, was replaced with a simpler $match stage. Removing both $unwinds also eliminated the need for a subsequent $group stage, reducing the pipeline from 10 to 8 stages. The result was a 60% performance improvement, dropping average query time from 11.8 seconds to 4.7 seconds, though still short of the 1-second SLA target.

Aggregation Optimization in MongoDB: A Case Study From the Field (Part 1)

A MongoDB expert walks through a real-world design review where a team modeled their data in an RDBMS-like fashion, resulting in 11.8-second query times. The post details a video streaming service use case with profiles, devices, and mappings collections, explaining each stage of a 10-stage aggregation pipeline ($match, $lookup, $unwind, $group, $sort, $skip, $limit). The initial pipeline suffered from poor performance despite proper indexing. Through data model and pipeline redesign, query time was reduced from 11.8 seconds to 14 milliseconds — an 800x improvement. Part 1 focuses on understanding the initial pipeline design before optimizations are introduced in subsequent parts.