Cơ sở dữ liệu Messenger (phần 1): thiết kế khung cơ sở

Cách bạn có thể chuyển các yêu cầu kinh doanh thành các cấu trúc dữ liệu cụ thể bằng cách sử dụng ví dụ về thiết kế cơ sở dữ liệu nhắn tin từ đầu.

• Phần 1: thiết kế khung đế
• Phần 2: phân đoạn “vì lợi nhuận”

Cơ sở của chúng tôi sẽ không lớn và phân tán, như VKontakte hoặc Badoo, nhưng “thì ra là vậy”, nhưng nó tốt - hoạt động tốt, nhanh chóng và phù hợp trên một máy chủ PostgreSQL - chẳng hạn, để bạn có thể triển khai một phiên bản dịch vụ riêng biệt ở đâu đó bên cạnh.

Do đó, chúng tôi sẽ không đề cập đến các vấn đề về hệ thống phân chia, sao chép và phân phối địa lý mà sẽ tập trung vào các giải pháp mạch bên trong cơ sở dữ liệu.

Bước 1: Một số thông tin cụ thể về doanh nghiệp

Chúng tôi sẽ không thiết kế thông điệp của mình một cách trừu tượng mà sẽ tích hợp nó vào môi trường mạng xã hội doanh nghiệp. Nghĩa là, mọi người của chúng tôi không “chỉ trao đổi thư từ” mà giao tiếp với nhau trong bối cảnh giải quyết một số vấn đề kinh doanh nhất định.

Và nhiệm vụ của một doanh nghiệp là gì?.. Hãy xem ví dụ của Vasily, trưởng bộ phận phát triển.

• “Nikolai, hôm nay chúng ta cần một bản vá cho nhiệm vụ này!”
  Điều này có nghĩa là việc trao đổi thư từ có thể được tiến hành trong bối cảnh của một số tài liệu.
• “Kolya, tối nay bạn có đi chơi Dota không?”
  Nghĩa là, ngay cả một cặp người đối thoại cũng có thể giao tiếp đồng thời về các chủ đề khác nhau.
• “Peter, Nikolay, xem bảng giá máy chủ mới trong tệp đính kèm.”
  Vì vậy, một tin nhắn có thể có một số người nhận. Trong trường hợp này, tin nhắn có thể chứa File đính kèm.
• “Semyon, hãy nhìn xem.”
  Và cần có cơ hội tham gia vào các thư từ hiện có mời thành viên mới.

Bây giờ chúng ta hãy tập trung vào danh sách các nhu cầu “hiển nhiên” này.

Nếu không hiểu các chi tiết cụ thể được áp dụng của vấn đề và những hạn chế của nó, thiết kế Có hiệu quả lược đồ cơ sở dữ liệu để giải quyết nó gần như là không thể.

Bước 2: Mạch logic tối thiểu

Cho đến nay, mọi thứ diễn ra rất giống với thư từ qua email - một công cụ kinh doanh truyền thống. Đúng, về mặt thuật toán, nhiều vấn đề kinh doanh tương tự nhau, do đó các công cụ để giải quyết chúng sẽ có cấu trúc tương tự nhau.

Hãy sửa sơ đồ logic đã thu được của các mối quan hệ thực thể. Để làm cho mô hình của chúng tôi dễ hiểu hơn, chúng tôi sẽ sử dụng tùy chọn hiển thị nguyên thủy nhất mô hình ER không có sự phức tạp của các ký hiệu UML hoặc IDEF:

Trong ví dụ của chúng tôi, người, tài liệu và “nội dung” nhị phân của tệp là các thực thể “bên ngoài” tồn tại độc lập mà không cần dịch vụ của chúng tôi. Do đó, trong tương lai chúng ta sẽ chỉ coi chúng là một số liên kết “ở đâu đó” của UUID.

Vẽ tranh sơ đồ càng đơn giản càng tốt - hầu hết những người bạn sẽ giới thiệu cho họ không phải là chuyên gia đọc UML/IDEF. Nhưng hãy chắc chắn để vẽ.

Bước 3: Phác thảo cấu trúc bảng

Về tên bảng và trườngTên trường và bảng "tiếng Nga" có thể được xử lý khác nhau, nhưng đây là vấn đề về sở thích. Bởi vì ở đây tại Tensor không có nhà phát triển nước ngoài nào và PostgreSQL cho phép chúng tôi đặt tên ngay cả bằng chữ tượng hình, nếu họ kèm theo dấu ngoặc kép, thì chúng ta muốn đặt tên các đối tượng một cách rõ ràng và rõ ràng để không có sự khác biệt.
Vì nhiều người viết tin nhắn cho chúng tôi cùng một lúc nên một số người trong số họ thậm chí có thể làm điều này ngoại tuyến, thì lựa chọn đơn giản nhất là sử dụng UUID làm định danh không chỉ cho các thực thể bên ngoài mà còn cho tất cả các đối tượng bên trong dịch vụ của chúng tôi. Hơn nữa, chúng có thể được tạo ngay cả ở phía máy khách - điều này sẽ giúp chúng tôi hỗ trợ gửi tin nhắn khi cơ sở dữ liệu tạm thời không khả dụng và khả năng xảy ra xung đột là cực kỳ thấp.

Cấu trúc bảng dự thảo trong cơ sở dữ liệu của chúng tôi sẽ trông như thế này:
Bàn : RU

CREATE TABLE "Тема"(
  "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

CREATE TABLE "Сообщение"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "Автор"
    uuid
, "ДатаВремя"
    timestamp
, "Текст"
    text
);

CREATE TABLE "Адресат"(
  "Сообщение"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Сообщение", "Персона")
);

CREATE TABLE "Файл"(
  "Файл"
    uuid
      PRIMARY KEY
, "Сообщение"
    uuid
, "BLOB"
    uuid
, "Имя"
    text
);

Bàn: VN

CREATE TABLE theme(
  theme
    uuid
      PRIMARY KEY
, document
    uuid
, title
    text
);

CREATE TABLE message(
  message
    uuid
      PRIMARY KEY
, theme
    uuid
, author
    uuid
, dt
    timestamp
, body
    text
);

CREATE TABLE message_addressee(
  message
    uuid
, person
    uuid
, PRIMARY KEY(message, person)
);

CREATE TABLE message_file(
  file
    uuid
      PRIMARY KEY
, message
    uuid
, content
    uuid
, filename
    text
);

Điều đơn giản nhất khi mô tả một định dạng là bắt đầu “tháo gỡ” biểu đồ kết nối từ các bảng không được tham chiếu bản thân họ không với ai cả.

Bước 4: Tìm hiểu những nhu cầu không rõ ràng

Thế là xong, chúng tôi đã thiết kế một cơ sở dữ liệu trong đó bạn có thể viết một cách hoàn hảo và bằng cách nào đó để đọc

Hãy đặt mình vào vị trí của người sử dụng dịch vụ của chúng tôi - chúng tôi muốn làm gì với nó?

• Tin nhắn cuối cùng
  Nó sắp xếp theo thứ tự thời gian sổ đăng ký các tin nhắn “của tôi” dựa trên nhiều tiêu chí khác nhau. Nơi tôi là một trong những người nhận, nơi tôi là tác giả, nơi họ viết thư cho tôi và tôi không trả lời, nơi họ không trả lời tôi, ...
• Những người tham gia thư từ
  Ai thậm chí còn tham gia vào cuộc trò chuyện dài này?

Cấu trúc của chúng tôi cho phép chúng tôi giải quyết cả hai vấn đề này “nói chung” nhưng không nhanh chóng. Vấn đề là để sắp xếp trong nhiệm vụ đầu tiên không thể tạo chỉ mục, phù hợp với từng người tham gia (và bạn sẽ phải trích xuất tất cả các bản ghi) và để giải quyết vấn đề thứ hai, bạn cần trích xuất tất cả tin nhắn về chủ đề này.

Các tác vụ người dùng ngoài ý muốn có thể được in đậm chéo về năng suất.

Bước 5: Phi chuẩn hóa thông minh

Cả hai vấn đề của chúng ta sẽ được giải quyết bằng các bảng bổ sung trong đó chúng ta sẽ phần trùng lặp của dữ liệu, cần thiết để hình thành các chỉ số phù hợp với nhiệm vụ của chúng ta.


Bàn : RU

CREATE TABLE "РеестрСообщений"(
  "Владелец"
    uuid
, "ТипРеестра"
    smallint
, "ДатаВремя"
    timestamp
, "Сообщение"
    uuid
, PRIMARY KEY("Владелец", "ТипРеестра", "Сообщение")
);
CREATE INDEX ON "РеестрСообщений"("Владелец", "ТипРеестра", "ДатаВремя" DESC);

CREATE TABLE "УчастникТемы"(
  "Тема"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Тема", "Персона")
);

Bàn: VN

CREATE TABLE message_registry(
  owner
    uuid
, registry
    smallint
, dt
    timestamp
, message
    uuid
, PRIMARY KEY(owner, registry, message)
);
CREATE INDEX ON message_registry(owner, registry, dt DESC);

CREATE TABLE theme_participant(
  theme
    uuid
, person
    uuid
, PRIMARY KEY(theme, person)
);

Ở đây chúng tôi đã áp dụng hai cách tiếp cận điển hình được sử dụng khi tạo các bảng phụ:

• Nhân bản ghi
  Bằng cách sử dụng một bản ghi tin nhắn ban đầu, chúng tôi tạo một số bản ghi tiếp theo trong các loại sổ đăng ký khác nhau cho các chủ sở hữu khác nhau - cho cả người gửi và người nhận. Nhưng mỗi thanh ghi hiện nằm trong chỉ mục - xét cho cùng, trong trường hợp điển hình, chúng ta sẽ chỉ muốn xem trang đầu tiên.
• Kỷ lục duy nhất
  Mỗi khi bạn gửi tin nhắn trong một chủ đề cụ thể, việc kiểm tra xem mục đó đã tồn tại hay chưa là đủ. Nếu không, hãy thêm nó vào “từ điển” của chúng tôi.

Trong phần tiếp theo của bài viết chúng ta sẽ nói về thực hiện phân vùng vào cấu trúc cơ sở dữ liệu của chúng tôi.

Nguồn: www.habr.com