Cách cấu trúc cơ sở dữ liệu mongodb

Có một cách lý tưởng để thiết kế cơ sở dữ liệu trong cơ sở dữ liệu quan hệ — dạng chuẩn thứ 3. Trong

//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1, điều quan trọng là phải giữ dữ liệu theo cách có lợi cho ứng dụng sử dụng dữ liệu. Bạn nghĩ về

  • mẫu dữ liệu ứng dụng
  • những phần dữ liệu nào được sử dụng cùng nhau
  • phần dữ liệu nào được sử dụng chủ yếu ở dạng chỉ đọc
  • những phần dữ liệu nào được viết mọi lúc

Ngược lại, trong DBMS quan hệ — dữ liệu được tổ chức theo cách mà ứng dụng không thể biết được

//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1 hỗ trợ tài liệu phong phú. Chúng tôi có thể lưu trữ một mảng các mục, một giá trị cho một khóa nhất định có thể là toàn bộ tài liệu khác. Điều này sẽ cho phép chúng tôi tham gia trước/nhúng dữ liệu để truy cập nhanh. Và điều đó quan trọng vì
//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
1 không hỗ trợ nối trực tiếp bên trong nhân. Thay vào đó, nếu chúng ta cần tham gia, chúng ta cần tham gia vào chính ứng dụng. Lý do là các tham gia rất khó mở rộng. Điều này buộc chúng tôi phải suy nghĩ trước về dữ liệu bạn muốn sử dụng cùng với dữ liệu khác. Chúng tôi có thể muốn nhúng dữ liệu trực tiếp vào tài liệu. Không có ràng buộc. Trong trường hợp của
//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1, nó quan trọng như chúng ta nghĩ vì việc nhúng.
//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1 xem xét tính nguyên tử theo cách. Ngoài ra, nó không hỗ trợ các giao dịch, tuy nhiên các hoạt động nguyên tử được hỗ trợ trong một tài liệu. Dữ liệu cần được thiết kế theo cách nó hỗ trợ các hoạt động nguyên tử

Không có lược đồ nào được khai báo nhưng rất có thể một ứng dụng sẽ có lược đồ. Bằng cách có một lược đồ, chúng tôi muốn nói rằng mọi tài liệu trong một bộ sưu tập cụ thể có thể sẽ có cấu trúc khá giống nhau. Có thể có những thay đổi nhỏ đối với cấu trúc đó tùy thuộc vào các phiên bản khác nhau của ứng dụng của bạn. Mặc dù nó không được khai báo trước, nhưng điều quan trọng là phải suy nghĩ về cấu trúc dữ liệu để bản thân lược đồ dữ liệu hỗ trợ tất cả các tính năng khác nhau của ứng dụng của bạn

Chuẩn hóa quan hệ

Hãy xem bảng không chuẩn hóa bên dưới cho một dự án bài đăng trên blog. Nó không phải là dạng bình thường thứ 3, nó bị hỏng. Giả sử có nhiều bài đăng với cùng một tác giả, chúng tôi có thể cập nhật một vài hàng và để những hàng khác không được cập nhật. Để dữ liệu bảng không nhất quán

Do đó, điều này vi phạm chuẩn hóa vì nó vi phạm một cách phổ biến để mô tả các bảng đã chuẩn hóa ở dạng chuẩn hóa thứ 3, đó là mọi thuộc tính không khóa trong bảng phải cung cấp thông tin về khóa, toàn bộ khóa và không có gì khác ngoài khóa. Và đó là một cách chơi chữ cho những gì bạn nói trong phòng xử án ở Hoa Kỳ, nói sự thật, toàn bộ sự thật và không có gì khác ngoài sự thật. Khóa trong trường hợp này là

//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
4 và có một thuộc tính không phải là khóa
//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
5 không tuân theo điều đó. Bởi vì nó thực sự nói lên điều gì đó về tác giả. Và do đó nó vi phạm dạng chuẩn thứ 3 đó

Bảng trên có thể được biểu diễn trong

//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1 dưới dạng

{
id: 'some id',
title: 'some title',
body: 'some content here',
author: {
name: 'author name',
email: 'author email id'
}
}
Refresher — mục tiêu của bình thường hóa là gì?
  • Giải phóng cơ sở dữ liệu khỏi các bất thường sửa đổi — Đối với
    //city
    {
    _id: 1,
    name: 'NYC',
    area: 30,
    people: [{
    _id: 1,
    name: 'name',
    gender: 'gender'
    .....
    },
    ....
    8 million people data inside this array
    ....
    ]
    }
    1, có vẻ như việc nhúng dữ liệu chủ yếu sẽ gây ra điều này. Và trên thực tế, chúng ta nên cố gắng tránh nhúng dữ liệu vào tài liệu trong
    //city
    {
    _id: 1,
    name: 'NYC',
    area: 30,
    people: [{
    _id: 1,
    name: 'name',
    gender: 'gender'
    .....
    },
    ....
    8 million people data inside this array
    ....
    ]
    }
    1, điều có thể tạo ra những điểm bất thường này. Đôi khi, chúng tôi có thể cần sao chép dữ liệu trong tài liệu vì lý do hiệu suất. Tuy nhiên đó không phải là cách tiếp cận mặc định. Mặc định là để tránh nó
  • Nên giảm thiểu thiết kế lại khi mở rộng —
    //city
    {
    _id: 1,
    name: 'NYC',
    area: 30,
    people: [{
    _id: 1,
    name: 'name',
    gender: 'gender'
    .....
    },
    ....
    8 million people data inside this array
    ....
    ]
    }
    1 đủ linh hoạt vì nó cho phép thêm khóa mà không cần thiết kế lại tất cả tài liệu
  • Tránh thiên vị đối với bất kỳ mẫu truy cập cụ thể nào — đây là điều mà chúng ta sẽ không phải lo lắng khi mô tả lược đồ trong
    //city
    {
    _id: 1,
    name: 'NYC',
    area: 30,
    people: [{
    _id: 1,
    name: 'name',
    gender: 'gender'
    .....
    },
    ....
    8 million people data inside this array
    ....
    ]
    }
    1. Và một trong những ý tưởng đằng sau
    //city
    {
    _id: 1,
    name: 'NYC',
    area: 30,
    people: [{
    _id: 1,
    name: 'name',
    gender: 'gender'
    .....
    },
    ....
    8 million people data inside this array
    ....
    ]
    }
    1 là điều chỉnh cơ sở dữ liệu của bạn cho phù hợp với các ứng dụng mà chúng tôi đang cố gắng viết và vấn đề mà chúng tôi đang cố gắng giải quyết

Một trong những điều tuyệt vời về cơ sở dữ liệu quan hệ là nó thực sự tốt trong việc giữ cho dữ liệu nhất quán trong cơ sở dữ liệu. Một trong những cách thực hiện điều đó là sử dụng khóa ngoại. Một ràng buộc khóa ngoại là giả sử có một bảng với một số cột sẽ có một cột khóa ngoại với các giá trị từ cột của bảng khác. Trong

//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1, không có gì đảm bảo rằng các khóa ngoại sẽ được bảo toàn. Lập trình viên phải đảm bảo rằng dữ liệu nhất quán theo cách đó. Điều này có thể khả thi trong các phiên bản tương lai của
//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1 nhưng ngày nay, không có tùy chọn nào như vậy. Giải pháp thay thế cho các ràng buộc khóa ngoại là nhúng dữ liệu

Sống không có giao dịch

Các giao dịch hỗ trợ các thuộc tính ACID nhưng mặc dù không có giao dịch nào trong

//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1, nhưng chúng tôi có các hoạt động nguyên tử. Chà, các phép toán nguyên tử có nghĩa là khi bạn làm việc trên một tài liệu thì công việc đó sẽ được hoàn thành trước khi bất kỳ ai khác nhìn thấy tài liệu đó. Họ sẽ thấy tất cả những thay đổi mà chúng tôi đã thực hiện hoặc không có thay đổi nào. Và bằng cách sử dụng các phép toán nguyên tử, bạn thường có thể hoàn thành điều tương tự mà chúng ta đã hoàn thành bằng cách sử dụng các giao dịch trong cơ sở dữ liệu quan hệ. Và lý do là, trong một cơ sở dữ liệu quan hệ, chúng ta cần thực hiện các thay đổi trên nhiều bảng. Thông thường các bảng cần được nối và vì vậy chúng tôi muốn làm điều đó cùng một lúc. Và để làm điều đó, vì có nhiều bảng, chúng tôi sẽ phải bắt đầu một giao dịch và thực hiện tất cả các cập nhật đó rồi kết thúc giao dịch. Nhưng với
//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1, chúng tôi sẽ nhúng dữ liệu, vì chúng tôi sẽ kết hợp trước dữ liệu đó trong các tài liệu và chúng là những tài liệu phong phú có phân cấp. Chúng ta thường có thể đạt được điều tương tự. Chẳng hạn, trong ví dụ về blog, nếu chúng tôi muốn đảm bảo rằng chúng tôi đã cập nhật nguyên bản một bài đăng trên blog, chúng tôi có thể làm điều đó vì chúng tôi có thể cập nhật toàn bộ bài đăng trên blog cùng một lúc. Nếu như đó là một loạt các bảng quan hệ, chúng tôi có thể phải mở một giao dịch để có thể cập nhật bộ sưu tập bài đăng và bộ sưu tập nhận xét

Vì vậy, những cách tiếp cận nào mà chúng ta có thể thực hiện trong

//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1 để khắc phục tình trạng thiếu giao dịch?

  • tái cấu trúc — tái cấu trúc mã, để chúng tôi đang làm việc trong một tài liệu duy nhất và tận dụng các hoạt động nguyên tử mà chúng tôi cung cấp trong tài liệu đó. Và nếu chúng ta làm điều đó, thì thường thì chúng ta đã sẵn sàng
  • triển khai trong phần mềm — chúng tôi có thể triển khai khóa trong phần mềm bằng cách tạo một phần quan trọng. Chúng tôi có thể xây dựng thử nghiệm, thử nghiệm và thiết lập bằng cách sử dụng tìm và sửa đổi. Chúng ta có thể xây dựng các semaphore, nếu cần. Và theo một cách nào đó, đó là cách thế giới rộng lớn hơn hoạt động. Nếu chúng ta nghĩ về điều đó, nếu một ngân hàng cần chuyển tiền sang ngân hàng khác, họ không sống trong cùng một hệ thống quan hệ. Và họ thường có cơ sở dữ liệu quan hệ riêng. Và họ có thể điều phối hoạt động đó mặc dù chúng tôi không thể bắt đầu giao dịch và kết thúc giao dịch trên các hệ thống cơ sở dữ liệu đó, chỉ trong một hệ thống trong một ngân hàng. Vì vậy, chắc chắn có những cách trong phần mềm để giải quyết vấn đề
  • khoan dung — cách tiếp cận cuối cùng, thường hoạt động trong các ứng dụng web hiện đại và các ứng dụng khác sử dụng lượng dữ liệu khổng lồ là chỉ chấp nhận một chút không nhất quán. Ví dụ: nếu chúng ta đang nói về nguồn cấp dữ liệu bạn bè trên Facebook, sẽ không có vấn đề gì nếu mọi người thấy cập nhật tường của bạn đồng thời. Nếu được, nếu một người chậm vài nhịp trong vài giây và họ bắt kịp. Trong rất nhiều thiết kế hệ thống, điều quan trọng là mọi thứ phải được giữ hoàn toàn nhất quán và mọi người đều có một cách nhìn hoàn toàn nhất quán và giống nhau về cơ sở dữ liệu. Vì vậy, chúng ta có thể đơn giản chấp nhận một chút mâu thuẫn tạm thời

Các hoạt động

//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
7,
//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
8,
//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
9 (trong một bản cập nhật) &
//people
{
_id: 1,
name: 'John Doe',
gender: gender,
city: {
_id: 1,
name: 'NYC',
area: '30'
.....
}
}
0 (trong một bản cập nhật) hoạt động nguyên tử trong một tài liệu duy nhất

quan hệ một đối một

Quan hệ 1-1 là quan hệ trong đó mỗi mục tương ứng với chính xác một mục khác. e. g

  • một nhân viên có một sơ yếu lý lịch và ngược lại
  • một tòa nhà có và sơ đồ tầng và ngược lại
  • một bệnh nhân có tiền sử bệnh và ngược lại
//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}

Chúng ta có thể lập mô hình quan hệ nhân viên-sơ yếu lý lịch bằng cách có một tập hợp nhân viên và một tập hợp các sơ yếu lý lịch và để nhân viên trỏ đến sơ yếu lý lịch thông qua liên kết, trong đó chúng ta có một

//people
{
_id: 1,
name: 'John Doe',
gender: gender,
city: {
_id: 1,
name: 'NYC',
area: '30'
.....
}
}
1 tương ứng với một
//people
{
_id: 1,
name: 'John Doe',
gender: gender,
city: {
_id: 1,
name: 'NYC',
area: '30'
.....
}
}
1 trong tập hợp sơ yếu lý lịch đó. Hoặc nếu muốn, chúng ta có thể liên kết theo một hướng khác, nơi chúng ta có khóa nhân viên bên trong bộ sưu tập sơ yếu lý lịch và nó có thể trỏ đến chính nhân viên đó. Hoặc nếu muốn, chúng ta có thể nhúng. Vì vậy, chúng tôi có thể lấy toàn bộ tài liệu sơ yếu lý lịch này và chúng tôi có thể nhúng nó ngay bên trong bộ sưu tập nhân viên hoặc ngược lại

Việc nhúng này phụ thuộc vào cách ứng dụng truy cập dữ liệu và tần suất dữ liệu được truy cập. Chúng ta cần phải xem xét

  • tần suất truy cập
  • kích thước của các mặt hàng - những gì đang phát triển mọi lúc và những gì không phát triển. Vì vậy, mỗi khi chúng tôi thêm một cái gì đó vào tài liệu, có một điểm mà tài liệu cần phải được di chuyển trong bộ sưu tập. Nếu kích thước tài liệu vượt quá 16 MB, điều này hầu như không thể xảy ra
  • tính nguyên tử của dữ liệu — không có giao dịch nào trong
    //city
    {
    _id: 1,
    name: 'NYC',
    area: 30,
    people: [{
    _id: 1,
    name: 'name',
    gender: 'gender'
    .....
    },
    ....
    8 million people data inside this array
    ....
    ]
    }
    1, có các hoạt động nguyên tử trên các tài liệu riêng lẻ. Vì vậy, nếu chúng tôi biết rằng chúng tôi không thể chịu được bất kỳ sự không nhất quán nào và chúng tôi muốn có thể cập nhật toàn bộ nhân viên cùng với sơ yếu lý lịch mọi lúc, chúng tôi có thể quyết định đưa chúng vào cùng một tài liệu và nhúng chúng theo cách này hay cách khác.
Mối quan hệ một đến nhiều

Trong mối quan hệ này, có rất nhiều thực thể hoặc nhiều thực thể ánh xạ tới một thực thể. e. g

  • một thành phố có nhiều người sống trong thành phố đó. Giả sử NYC có 8 triệu người

Giả sử mô hình dữ liệu dưới đây

//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}

Điều này sẽ không hiệu quả vì điều đó sẽ THỰC SỰ KHỔNG LỒ. Hãy thử lật đầu

//people
{
_id: 1,
name: 'John Doe',
gender: gender,
city: {
_id: 1,
name: 'NYC',
area: '30'
.....
}
}

Bây giờ, vấn đề với thiết kế này là nếu rõ ràng có nhiều người sống ở NYC, thì chúng tôi đã thực hiện rất nhiều bản sao cho dữ liệu thành phố

Có lẽ, cách tốt nhất để lập mô hình dữ liệu này là sử dụng liên kết thực

//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
3

Trong trường hợp này, bộ sưu tập

//people
{
_id: 1,
name: 'John Doe',
gender: gender,
city: {
_id: 1,
name: 'NYC',
area: '30'
.....
}
}
4 có thể được liên kết với bộ sưu tập
//people
{
_id: 1,
name: 'John Doe',
gender: gender,
city: {
_id: 1,
name: 'NYC',
area: '30'
.....
}
}
5. Biết rằng chúng tôi không có ràng buộc khóa ngoại, chúng tôi phải nhất quán về điều đó. Vì vậy, đây là một quan hệ nhiều. Nó yêu cầu 2 bộ sưu tập. Đối với một đến ít (cũng là một đến nhiều), các mối quan hệ như bài đăng trên blog với nhận xét. Nhận xét có thể được nhúng bên trong tài liệu bài đăng dưới dạng một mảng

Vì vậy, nếu nó thực sự là một đến nhiều, thì 2 bộ sưu tập hoạt động tốt nhất với liên kết. Nhưng đối với một đến một số ít, một bộ sưu tập nói chung là đủ

Quan hệ nhiều đến nhiều

e. g

  • sách cho tác giả
  • học sinh đến giáo viên

Các cuốn sách đối với các tác giả là một mối quan hệ ít nhiều, vì vậy chúng ta có thể có một mảng sách hoặc tác giả bên trong tài liệu của người khác. Đối với học sinh đối với giáo viên cũng vậy. Chúng tôi cũng có thể nhúng vào rủi ro trùng lặp. Tuy nhiên, điều này sẽ yêu cầu mỗi học sinh phải có một giáo viên trong hệ thống trước khi chèn và ngược lại. Logic ứng dụng có thể luôn không cho phép nó. Nói cách khác, đối tượng cha phải tồn tại thì đối tượng con mới tồn tại.

đa phím

Multikey indexes là tính năng giúp liên kết và nhúng hoạt động rất tốt. Giả sử rằng chúng ta có 2 lược đồ cho học sinh và giáo viên

//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
6

Bây giờ có 2 truy vấn rõ ràng

  • Làm thế nào để tìm tất cả các giáo viên mà một học sinh cụ thể đã có?
  • Làm thế nào để tìm tất cả các sinh viên đã có một giáo viên cụ thể? . Và để đạt được điều đó, chúng ta cần phải hiệu quả, chúng ta cần sử dụng các chỉ mục Multikey

Để tạo một chỉ mục trên cột

//people
{
_id: 1,
name: 'John Doe',
gender: gender,
city: {
_id: 1,
name: 'NYC',
area: '30'
.....
}
}
7 trên bộ sưu tập
//people
{
_id: 1,
name: 'John Doe',
gender: gender,
city: {
_id: 1,
name: 'NYC',
area: '30'
.....
}
}
8, hãy sử dụng
//people
{
_id: 1,
name: 'John Doe',
gender: gender,
city: {
_id: 1,
name: 'NYC',
area: '30'
.....
}
}
9

Bây giờ để tìm tất cả các sinh viên đã có một giáo viên cụ thể? . Bây giờ, nếu chúng ta thêm

//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
31 vào truy vấn trên - nó cho thấy hoạt động bên trong bằng cách hiển thị vị trí các phím được áp dụng, v.v.

Lợi ích của việc nhúng

Lý do chính để nhúng tài liệu vào

//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1 là hiệu suất. Lợi ích hiệu suất chính đến từ hiệu suất đọc được cải thiện. Bây giờ, tại sao chúng ta nhận được hiệu suất đọc. Lý do là bản chất của cách hệ thống máy tính được xây dựng, đó là chúng thường có đĩa quay và những đĩa quay đó có độ trễ rất cao, có nghĩa là chúng mất rất nhiều thời gian (tối đa 1ms) để truy cập byte đầu tiên. Tuy nhiên, khi byte đầu tiên được truy cập, mỗi byte bổ sung sẽ đến rất nhanh. Vì vậy, chúng có xu hướng có băng thông khá cao. Vì vậy, ý tưởng là nếu chúng ta có thể định vị dữ liệu được sử dụng cùng nhau trong cùng một tài liệu, nhúng nó và sau đó chúng ta sẽ quay đĩa, tìm khu vực mà chúng ta cần thông tin này và sau đó chúng ta sẽ bắt đầu đọc . Và chúng tôi sẽ nhận được tất cả thông tin chúng tôi cần trong một lần. Ngoài ra, điều đó có nghĩa là nếu chúng ta có 2 mẩu dữ liệu thường nằm trong 2 bộ sưu tập hoặc trong một số bảng cơ sở dữ liệu quan hệ. Thay vào đó, chúng ở trong một tài liệu, chúng tôi tránh các chuyến đi vòng quanh cơ sở dữ liệu

Cây

Một vấn đề kinh điển trong thế giới thiết kế lược đồ là làm thế nào để bạn biểu diễn một cây bên trong cơ sở dữ liệu? . Nơi chúng ta có nhà, ngoài trời, mùa đông, tuyết. Và ý tưởng là chúng ta có

//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
33. Ngoài ra, chúng tôi có một
//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
34, nơi chúng tôi có thể tra cứu danh mục 7 và xem
//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
35, một số thuộc tính của
//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
34

//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
7

Một cách để làm điều đó là giữ id

//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
37 - đây có thể là điều chúng ta có thể làm trong cơ sở dữ liệu quan hệ đơn giản. Nhưng điều này không giúp bạn dễ dàng tìm thấy tất cả các
//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
37 cho đến
//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
34 này. Chúng tôi phải truy vấn lặp đi lặp lại, tìm cha của cái này và cha của cái kia cho đến khi chúng tôi đi đến đầu trang

Vì vậy, một cách khác để làm điều đó trong

//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1 là có thể liệt kê tổ tiên hoặc con cái. Vì vậy, hãy nghĩ về điều đó và cách thức hoạt động của nó. Vì vậy, chúng tôi có thể quyết định liệt kê tất cả những đứa trẻ của
//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
34 này

{
id: 'some id',
title: 'some title',
body: 'some content here',
author: {
name: 'author name',
email: 'author email id'
}
}
2

Điều đó cũng khá hạn chế, nếu chúng ta muốn có thể nhìn và tìm thấy toàn bộ cây con phía trên một phần cây nhất định. Thay vào đó, thứ hoạt động khá tốt và một lần nữa, kích hoạt khả năng đặt mảng bên trong

//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1 là liệt kê tổ tiên từ trên xuống theo thứ tự

{
id: 'some id',
title: 'some title',
body: 'some content here',
author: {
name: 'author name',
email: 'author email id'
}
}
3

Một lần nữa, khả năng cấu trúc và thể hiện dữ liệu phong phú là một trong những điều khiến

//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1 trở nên thú vị. Điều này sẽ rất khó thực hiện trong cơ sở dữ liệu quan hệ. Bây giờ, về cách bạn trình bày dữ liệu cho thứ gì đó như hệ thống phân cấp ________ 164 ________ 134, một lần nữa, tất cả phụ thuộc vào các mẫu truy cập. Nó phụ thuộc vào cách chúng tôi tin rằng chúng tôi sẽ cần hiển thị dữ liệu, truy cập dữ liệu cho người dùng. Và sau đó dựa vào đó, chúng tôi biết cách mô hình hóa nó

Khi nào cần chuẩn hóa

Một trong những lý do để chuẩn hóa trong cơ sở dữ liệu quan hệ là để tránh các bất thường sửa đổi đi kèm với việc sao chép dữ liệu. Và khi chúng tôi xem xét

//city
{
_id: 1,
name: 'NYC',
area: 30,
people: [{
_id: 1,
name: 'name',
gender: 'gender'
.....
},
....
8 million people data inside this array
....
]
}
1 và cách nó được cấu trúc, cho phép các tài liệu phong phú này, thật dễ dàng cho rằng những gì chúng tôi đang làm là chúng tôi đang chuẩn hóa dữ liệu. Và ở một mức độ nào đó, điều đó đúng. Miễn là chúng tôi không trùng lặp dữ liệu, chúng tôi không mở bản thân để sửa đổi sự bất thường

Nói chung, thật tốt khi nhúng dữ liệu đó trong trường hợp có mối quan hệ 1-1. Trong trường hợp có mối quan hệ từ một đến nhiều, quá trình nhúng cũng có thể hoạt động tốt mà không cần sao chép dữ liệu miễn là chúng ta nhúng từ nhiều vào một. Bây giờ, nếu chúng ta đi từ một đến nhiều, thì việc liên kết sẽ tránh được sự trùng lặp dữ liệu. Bây giờ, nếu chúng tôi muốn nhúng nội dung nào đó, ngay cả khi nội dung đó gây trùng lặp dữ liệu vì lý do hiệu suất để phù hợp với kiểu truy cập của ứng dụng. Điều đó có thể hợp lý, đặc biệt nếu dữ liệu hiếm khi thay đổi hoặc được cập nhật. Nhưng chúng ta có thể tránh nó thường xuyên, ngay cả trong mối quan hệ này, nếu chúng ta đi từ nhiều đến một. Trong mối quan hệ nhiều-nhiều, mà chúng ta đã xem xét với

//people
{
_id: 1,
name: 'John Doe',
gender: gender,
city: {
_id: 1,
name: 'NYC',
area: '30'
.....
}
}
8 và
//people
{
_id: 1,
name: 'John Doe',
gender: gender,
city: {
_id: 1,
name: 'NYC',
area: '30'
.....
}
}
7 và
//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
69 và
//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
70, ở đó nếu bạn muốn tránh những bất thường sửa đổi đi kèm với việc không chuẩn hóa, tất cả những gì chúng ta cần làm là liên kết thông qua các mảng của
//employee
{
_id : '25',
name: 'john doe',
resume: 30
}
//resume
{
_id : '30',
jobs: [....],
education: [...],
employee: 25
}
71 trong tài liệu

Đây là tất cả các hướng dẫn. Đối với ứng dụng trong thế giới thực, chúng tôi có thể cần nhúng dữ liệu vì lý do hiệu suất, để phù hợp với các mẫu truy cập dữ liệu — — có thể cần nhúng dữ liệu

Dữ liệu MongoDB được cấu trúc như thế nào?

MongoDB là một hệ thống quản lý cơ sở dữ liệu NoSQL hướng tài liệu (DBMS). Không giống như các DBMS quan hệ truyền thống lưu trữ dữ liệu trong các bảng bao gồm các hàng và cột, MongoDB lưu trữ dữ liệu trong Cấu trúc giống JSON được gọi là tài liệu .

Cấu trúc bên trong của MongoDB là gì?

Đó là kiến ​​trúc được xây dựng trên các bộ sưu tập và tài liệu. Đơn vị dữ liệu cơ bản trong cơ sở dữ liệu này bao gồm tập hợp các cặp khóa-giá trị . Nó cho phép các tài liệu có các trường và cấu trúc khác nhau. Cơ sở dữ liệu này sử dụng định dạng lưu trữ tài liệu có tên là BSON, đây là kiểu tài liệu JSON nhị phân.

MongoDB có lược đồ không?

Dữ liệu trong MongoDB có lược đồ linh hoạt . Bộ sưu tập không thực thi cấu trúc tài liệu theo mặc định. Tính linh hoạt này cung cấp cho bạn các lựa chọn lập mô hình dữ liệu để phù hợp với ứng dụng của bạn và các yêu cầu về hiệu suất của nó. Giới thiệu về mô hình hóa dữ liệu trong MongoDB.

Thiết kế lược đồ MongoDB là gì?

Thiết kế lược đồ MongoDB thực sự chỉ có hai lựa chọn cho mọi phần dữ liệu . Bạn có thể nhúng dữ liệu đó trực tiếp hoặc tham chiếu một phần dữ liệu khác bằng cách sử dụng toán tử tra cứu $ (tương tự như THAM GIA). Hãy xem xét những ưu và nhược điểm của việc sử dụng từng tùy chọn trong lược đồ của bạn.