ಮೆಸೆಂಜರ್ ಡೇಟಾಬೇಸ್ (ಭಾಗ 2): "ಲಾಭಕ್ಕಾಗಿ" ವಿಭಜನೆ

ಪತ್ರವ್ಯವಹಾರವನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾವು ನಮ್ಮ PostgreSQL ಡೇಟಾಬೇಸ್‌ನ ರಚನೆಯನ್ನು ಯಶಸ್ವಿಯಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದೇವೆ, ಒಂದು ವರ್ಷ ಕಳೆದಿದೆ, ಬಳಕೆದಾರರು ಅದನ್ನು ಸಕ್ರಿಯವಾಗಿ ತುಂಬುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಈಗ ಅದು ಒಳಗೊಂಡಿದೆ ಲಕ್ಷಾಂತರ ದಾಖಲೆಗಳು, ಮತ್ತು... ಏನೋ ನಿಧಾನವಾಗತೊಡಗಿತು.

• ಭಾಗ 1: ಬೇಸ್ ಫ್ರೇಮ್ ವಿನ್ಯಾಸ
• ಭಾಗ 2: "ಲಾಭಕ್ಕಾಗಿ" ವಿಭಾಗ

ಪಾಯಿಂಟ್ ಎಂಬುದು ಟೇಬಲ್ ಗಾತ್ರವು ಬೆಳೆದಂತೆ, ಸೂಚ್ಯಂಕಗಳ "ಆಳ" ಹೆಚ್ಚಾಗುತ್ತದೆ. - ಲಾಗರಿಥಮಿಕ್ ಆದರೂ. ಆದರೆ ಕಾಲಾನಂತರದಲ್ಲಿ ಇದು ಸರ್ವರ್ ಅನ್ನು ಅದೇ ಓದುವ/ಬರೆಯುವ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಒತ್ತಾಯಿಸುತ್ತದೆ ಡೇಟಾದ ಹಲವು ಪಟ್ಟು ಹೆಚ್ಚು ಪುಟಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆಆರಂಭದಲ್ಲಿದ್ದಕ್ಕಿಂತ.

ಇದು ಪಾರುಗಾಣಿಕಾಕ್ಕೆ ಬರುವ ಸ್ಥಳವಾಗಿದೆ ವಿಭಾಗೀಕರಣ.

ನಾವು ಶೇರ್ಡಿಂಗ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿಲ್ಲ ಎಂದು ನಾನು ಗಮನಿಸುತ್ತೇನೆ, ಅಂದರೆ, ವಿಭಿನ್ನ ಡೇಟಾಬೇಸ್‌ಗಳು ಅಥವಾ ಸರ್ವರ್‌ಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ವಿತರಿಸುವುದು. ಏಕೆಂದರೆ ಡೇಟಾವನ್ನು ಸಹ ವಿಭಜಿಸುವುದು ಹಲವಾರು ಸರ್ವರ್‌ಗಳು, ಕಾಲಾನಂತರದಲ್ಲಿ ಸೂಚ್ಯಂಕಗಳ "ಊತ" ಸಮಸ್ಯೆಯನ್ನು ನೀವು ತೊಡೆದುಹಾಕಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪ್ರತಿದಿನ ಹೊಸ ಸರ್ವರ್ ಅನ್ನು ಕಾರ್ಯರೂಪಕ್ಕೆ ತರಲು ನೀವು ಶಕ್ತರಾಗಿದ್ದರೆ, ನಿಮ್ಮ ಸಮಸ್ಯೆಗಳು ಇನ್ನು ಮುಂದೆ ನಿರ್ದಿಷ್ಟ ಡೇಟಾಬೇಸ್‌ನ ಸಮತಲದಲ್ಲಿ ಇರುವುದಿಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ.

"ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ" ವಿಭಜನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಾವು ನಿರ್ದಿಷ್ಟ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಪರಿಗಣಿಸುವುದಿಲ್ಲ, ಆದರೆ ವಿಧಾನ ಸ್ವತಃ - ಏನು ಮತ್ತು ಹೇಗೆ "ಸ್ಲೈಸ್‌ಗಳಾಗಿ ಕತ್ತರಿಸಬೇಕು" ಮತ್ತು ಅಂತಹ ಬಯಕೆ ಏನು ಕಾರಣವಾಗುತ್ತದೆ.

ಪರಿಕಲ್ಪನೆ

ಮತ್ತೊಮ್ಮೆ ನಮ್ಮ ಗುರಿಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸೋಣ: ಇಂದು, ನಾಳೆ ಮತ್ತು ಒಂದು ವರ್ಷದಲ್ಲಿ, ಯಾವುದೇ ಓದುವ/ಬರೆಯುವ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ PostgreSQL ಓದುವ ಡೇಟಾದ ಪ್ರಮಾಣವು ಸರಿಸುಮಾರು ಒಂದೇ ಆಗಿರುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಬಯಸುತ್ತೇವೆ.

ಯಾವುದಕ್ಕಾದರೂ ಕಾಲಾನುಕ್ರಮವಾಗಿ ಸಂಗ್ರಹಿಸಿದ ಡೇಟಾ (ಸಂದೇಶಗಳು, ದಾಖಲೆಗಳು, ದಾಖಲೆಗಳು, ಆರ್ಕೈವ್‌ಗಳು, ...) ವಿಭಜನಾ ಕೀಲಿಯಾಗಿ ನೈಸರ್ಗಿಕ ಆಯ್ಕೆಯಾಗಿದೆ ಈವೆಂಟ್ ದಿನಾಂಕ/ಸಮಯ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಅಂತಹ ಘಟನೆ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುವ ಕ್ಷಣ.

ಬಳಕೆದಾರರು ಬಹುತೇಕ ಯಾವಾಗಲೂ ಎಂಬುದನ್ನು ಗಮನಿಸಿ "ಇತ್ತೀಚಿನ" ಜೊತೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡಿ ಅಂತಹ ಡೇಟಾ - ಅವರು ಇತ್ತೀಚಿನ ಸಂದೇಶಗಳನ್ನು ಓದುತ್ತಾರೆ, ಇತ್ತೀಚಿನ ಲಾಗ್‌ಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತಾರೆ,... ಇಲ್ಲ, ಸಹಜವಾಗಿ, ಅವರು ಸಮಯಕ್ಕೆ ಮತ್ತಷ್ಟು ಹಿಂದಕ್ಕೆ ಸ್ಕ್ರಾಲ್ ಮಾಡಬಹುದು, ಆದರೆ ಅವರು ಇದನ್ನು ಬಹಳ ವಿರಳವಾಗಿ ಮಾಡುತ್ತಾರೆ.

ಈ ನಿರ್ಬಂಧಗಳಿಂದ ಇದು ಅತ್ಯುತ್ತಮ ಸಂದೇಶ ಪರಿಹಾರವಾಗಿದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ "ದೈನಂದಿನ" ವಿಭಾಗಗಳು - ಎಲ್ಲಾ ನಂತರ, ನಮ್ಮ ಬಳಕೆದಾರರು "ಇಂದು" ಅಥವಾ "ನಿನ್ನೆ" ಅವರಿಗೆ ಬಂದದ್ದನ್ನು ಯಾವಾಗಲೂ ಓದುತ್ತಾರೆ.

ನಾವು ಹಗಲಿನಲ್ಲಿ ಒಂದು ವಿಭಾಗದಲ್ಲಿ ಮಾತ್ರ ಬರೆಯಲು ಮತ್ತು ಓದಿದರೆ, ಇದು ನಮಗೆ ನೀಡುತ್ತದೆ ಮೆಮೊರಿ ಮತ್ತು ಡಿಸ್ಕ್ನ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ ಬಳಕೆ - ಎಲ್ಲಾ ವಿಭಾಗದ ಸೂಚ್ಯಂಕಗಳು RAM ಗೆ ಸುಲಭವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುವುದರಿಂದ, ಟೇಬಲ್‌ನಾದ್ಯಂತ “ದೊಡ್ಡ ಮತ್ತು ಕೊಬ್ಬು” ಗೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ.

ಹಂತ ಹಂತವಾಗಿ

ಸಾಮಾನ್ಯವಾಗಿ, ಮೇಲೆ ಹೇಳಿದ ಎಲ್ಲವೂ ನಿರಂತರ ಲಾಭದಂತೆ ತೋರುತ್ತದೆ. ಮತ್ತು ಇದು ಸಾಧಿಸಬಹುದಾಗಿದೆ, ಆದರೆ ಇದಕ್ಕಾಗಿ ನಾವು ಕಷ್ಟಪಟ್ಟು ಪ್ರಯತ್ನಿಸಬೇಕು - ಏಕೆಂದರೆ ಘಟಕಗಳಲ್ಲಿ ಒಂದನ್ನು ವಿಭಜಿಸುವ ನಿರ್ಧಾರವು ಸಂಬಂಧಿತವನ್ನು "ನೋಡುವ" ಅಗತ್ಯಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಸಂದೇಶ, ಅದರ ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ಪ್ರಕ್ಷೇಪಗಳು

ದಿನಾಂಕಗಳ ಮೂಲಕ ಸಂದೇಶಗಳನ್ನು ಕತ್ತರಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿರುವುದರಿಂದ, ಅವುಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಘಟಕಗಳು-ಪ್ರಾಪರ್ಟಿಗಳನ್ನು (ಲಗತ್ತಿಸಲಾದ ಫೈಲ್‌ಗಳು, ಸ್ವೀಕರಿಸುವವರ ಪಟ್ಟಿ) ಮತ್ತು ವಿಭಜಿಸಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಸಂದೇಶದ ದಿನಾಂಕದಿಂದಲೂ ಸಹ.

ನಮ್ಮ ವಿಶಿಷ್ಟ ಕಾರ್ಯಗಳಲ್ಲಿ ಒಂದಾದ ಸಂದೇಶ ರೆಜಿಸ್ಟರ್‌ಗಳನ್ನು ನಿಖರವಾಗಿ ವೀಕ್ಷಿಸುವುದರಿಂದ (ಓದದ, ಒಳಬರುವ, ಎಲ್ಲಾ), ಸಂದೇಶ ದಿನಾಂಕಗಳ ಮೂಲಕ ವಿಭಜನೆಗೆ "ಅವುಗಳನ್ನು ಸೆಳೆಯಲು" ತಾರ್ಕಿಕವಾಗಿದೆ.

ನಾವು ಎಲ್ಲಾ ಕೋಷ್ಟಕಗಳಿಗೆ ವಿಭಜನಾ ಕೀಲಿಯನ್ನು (ಸಂದೇಶ ದಿನಾಂಕ) ಸೇರಿಸುತ್ತೇವೆ: ಸ್ವೀಕರಿಸುವವರು, ಫೈಲ್, ನೋಂದಣಿಗಳು. ನೀವು ಅದನ್ನು ಸಂದೇಶಕ್ಕೆ ಸೇರಿಸಬೇಕಾಗಿಲ್ಲ, ಆದರೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ದಿನಾಂಕ ಸಮಯವನ್ನು ಬಳಸಿ.

ಎಳೆಗಳನ್ನು

ಹಲವಾರು ಸಂದೇಶಗಳಿಗೆ ಒಂದೇ ವಿಷಯವಿರುವುದರಿಂದ, ಅದೇ ಮಾದರಿಯಲ್ಲಿ ಅದನ್ನು "ಕಟ್" ಮಾಡಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ; ನೀವು ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಅವಲಂಬಿಸಬೇಕು. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಸೂಕ್ತವಾಗಿದೆ ಪತ್ರವ್ಯವಹಾರದಲ್ಲಿ ಮೊದಲ ಸಂದೇಶದ ದಿನಾಂಕ - ಅಂದರೆ, ಸೃಷ್ಟಿಯ ಕ್ಷಣ, ವಾಸ್ತವವಾಗಿ, ವಿಷಯದ.

ಎಲ್ಲಾ ಕೋಷ್ಟಕಗಳಿಗೆ ವಿಭಜನಾ ಕೀಲಿಯನ್ನು (ವಿಷಯ ದಿನಾಂಕ) ಸೇರಿಸಿ: ವಿಷಯ, ಭಾಗವಹಿಸುವವರು.

ಆದರೆ ಈಗ ನಮಗೆ ಏಕಕಾಲದಲ್ಲಿ ಎರಡು ಸಮಸ್ಯೆಗಳಿವೆ:

• ಯಾವ ವಿಭಾಗದಲ್ಲಿ ನಾನು ವಿಷಯದ ಕುರಿತು ಸಂದೇಶಗಳನ್ನು ನೋಡಬೇಕು?
• ಯಾವ ವಿಭಾಗದಲ್ಲಿ ನಾನು ಸಂದೇಶದಿಂದ ವಿಷಯವನ್ನು ಹುಡುಕಬೇಕು?

ನಾವು ಸಹಜವಾಗಿ, ಎಲ್ಲಾ ವಿಭಾಗಗಳಲ್ಲಿ ಹುಡುಕುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು, ಆದರೆ ಇದು ತುಂಬಾ ದುಃಖಕರವಾಗಿರುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ಎಲ್ಲಾ ಗೆಲುವುಗಳನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ನಿಖರವಾಗಿ ಎಲ್ಲಿ ನೋಡಬೇಕೆಂದು ತಿಳಿಯಲು, ನಾವು ವಿಭಾಗಗಳಿಗೆ ತಾರ್ಕಿಕ ಲಿಂಕ್‌ಗಳು/ಪಾಯಿಂಟರ್‌ಗಳನ್ನು ಮಾಡುತ್ತೇವೆ:

• ನಾವು ಸಂದೇಶದಲ್ಲಿ ಸೇರಿಸುತ್ತೇವೆ ವಿಷಯ ದಿನಾಂಕ ಕ್ಷೇತ್ರ
• ವಿಷಯಕ್ಕೆ ಸೇರಿಸೋಣ ಸಂದೇಶದ ದಿನಾಂಕವನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ ಈ ಪತ್ರವ್ಯವಹಾರ (ಪ್ರತ್ಯೇಕ ಕೋಷ್ಟಕ ಅಥವಾ ದಿನಾಂಕಗಳ ಒಂದು ಶ್ರೇಣಿಯಾಗಿರಬಹುದು)

ಪ್ರತಿಯೊಂದು ಪತ್ರವ್ಯವಹಾರಕ್ಕಾಗಿ ಸಂದೇಶ ದಿನಾಂಕಗಳ ಪಟ್ಟಿಗೆ ಕೆಲವು ಮಾರ್ಪಾಡುಗಳು ಇರುವುದರಿಂದ (ಎಲ್ಲಾ ನಂತರ, ಬಹುತೇಕ ಎಲ್ಲಾ ಸಂದೇಶಗಳು 1-2 ಪಕ್ಕದ ದಿನಗಳಲ್ಲಿ ಬರುತ್ತವೆ), ನಾನು ಈ ಆಯ್ಕೆಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇನೆ.

ಒಟ್ಟಾರೆಯಾಗಿ, ವಿಭಜನೆಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ನಮ್ಮ ಡೇಟಾಬೇಸ್ನ ರಚನೆಯು ಈ ಕೆಳಗಿನ ರೂಪವನ್ನು ಪಡೆದುಕೊಂಡಿದೆ:

ಕೋಷ್ಟಕಗಳು: RU, ನೀವು ಕೋಷ್ಟಕಗಳು / ಕ್ಷೇತ್ರಗಳ ಹೆಸರಿನಲ್ಲಿ ಸಿರಿಲಿಕ್ ವರ್ಣಮಾಲೆಯ ಬಗ್ಗೆ ಅಸಹ್ಯವನ್ನು ಹೊಂದಿದ್ದರೆ, ನೋಡದಿರುವುದು ಉತ್ತಮ

-- секции по дате сообщения
CREATE TABLE "Сообщение_YYYYMMDD"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "ДатаТемы"
    date
, "Автор"
    uuid
, "ДатаВремя" -- используем как дату
    timestamp
, "Текст"
    text
);

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

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

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

-- секции по дате темы
CREATE TABLE "Тема_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

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

CREATE TABLE "ДатыСообщенийТемы_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Дата"
    date
);

ಸಾಕಷ್ಟು ಪೆನ್ನಿ ಉಳಿಸಿ

ಸರಿ, ನಾವು ಬಳಸದಿದ್ದರೆ ಏನು ಕ್ಲಾಸಿಕ್ ಸೆಕ್ಷನ್ ಆಯ್ಕೆ ಕ್ಷೇತ್ರ ಮೌಲ್ಯಗಳ ವಿತರಣೆಯ ಆಧಾರದ ಮೇಲೆ (ಪ್ರಚೋದಕಗಳು ಮತ್ತು ಆನುವಂಶಿಕತೆ ಅಥವಾ ವಿಭಜನೆಯ ಮೂಲಕ), ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿ "ಹಸ್ತಚಾಲಿತವಾಗಿ", ವಿಭಜನಾ ಕೀಲಿಯ ಮೌಲ್ಯವನ್ನು ಈಗಾಗಲೇ ಟೇಬಲ್‌ನ ಹೆಸರಿನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಎಂದು ನೀವು ಗಮನಿಸಬಹುದು.

ಆದ್ದರಿಂದ ನೀವು ಹಾಗೆ ಇದ್ದರೆ ಸಂಗ್ರಹಿಸಲಾದ ಡೇಟಾದ ಮೊತ್ತದ ಬಗ್ಗೆ ನೀವು ತುಂಬಾ ಚಿಂತಿತರಾಗಿದ್ದೀರಾ?, ನಂತರ ನೀವು ಈ "ಹೆಚ್ಚುವರಿ" ಕ್ಷೇತ್ರಗಳನ್ನು ತೊಡೆದುಹಾಕಬಹುದು ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಕೋಷ್ಟಕಗಳನ್ನು ವಿಳಾಸ ಮಾಡಬಹುದು. ನಿಜ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ಹಲವಾರು ವಿಭಾಗಗಳಿಂದ ಎಲ್ಲಾ ಆಯ್ಕೆಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಬದಿಗೆ ವರ್ಗಾಯಿಸಬೇಕಾಗುತ್ತದೆ.

ಮೂಲ: www.habr.com