ProHoster > Блог > administratio > Messenger database (part 2): partitionibus "pro lucri"

Messenger database (part 2): partitionibus "pro lucri"

Feliciter constituimus structuram datorum nostrorum PostgreSQL ad correspondentiam reponendarum, annus transiit, utentes eam actuose implent et nunc continet decies recordsac .... aliquid tardius incepit.

Messenger database (part 2): partitionibus "pro lucri"
Punctum est, Quemadmodum magnitudo mensae crescit, sic "profundum" indices. — Logarithme licet. Sed super hoc tempus cogit servo ut eadem opera legere/scriberet plures paginas pluries aliquid de notitiaquam initio.

Hoc est, ubi fit, ad liberandum sectioning.

Sit mihi nota quod non loquimur de shargia, id est, notitias distribuentes inter varias databases vel ministrantes. Quia etiam divisio data in aliquot ministri, quaestionem indices "tumores" in tempore non tolles. Patet, si quotidie novum ministratorem in operatione praebere potes, tunc difficultates tuae omnino in plano datorum specifici non iacebunt.

Scripta specifica non considerabimus ad partitionem "in ferramentis", sed ipsam accessionem - quid et quomodo "in segmenta dividenda", et quid tale desiderium inducat.

conceptu

Propositum nostrum semel iterum definiamus: efficere volumus ut hodie, cras et in anno, copia notitiarum ab PostgreSQL recitata in quavis lege/scribenda operatione eadem proxime maneat.

Nam quis tempora exaggeratus notitia nuntia, documenta, tabulae, tabularia, ... res diem / tempore. In casu nostro, talis eventus est nunc mittens nuntium.

Nota ut users fere semper opus solum cum "tardus" ones tales notitias - epistulas novissimas legunt, recentissimas tabulas resolvere, ... Non, utique, in tempore adhuc librum recipere possunt, sed hoc rarissime faciunt.

Ex his angustiis patet solutionem nuntium meliorem fore "Cotidiana" sectiones - Post omnes, noster usor fere semper leget ea quae ad illum "hodie" vel "heri" evenerunt.

Si fere interdiu scribimus et legamus in una sectione, hoc quoque nobis dat plus agentibus uti memoria et orbis - Cum indices omnes sectionis facile in arietem coaptantur, contraque "magnos et pingues" per totam mensam.

GRADATUS

Fere omnia supra dicta, unum continuum sonat lucrum. Et impetrabile est, sed propter hoc conari debebimus consilium partiendi unum entium perducit ad necessitatem "vidi" iuncta.

Nuntius, proprietates et proiectiones

Cum nuntiis per dies secare decrevimus, sensum efficit ut res substantias dividendas ab iis pendentes (adiunctis fasciculis, indicem recipientium), ac et per tempus nuntio.

Cum unus e nostris officiis typicis accurate inspiciat nuntios scriptos (illectum, venientes, omnes), etiam consentaneum est eos "inducere" in partitionem per nuntios dies.

Messenger database (part 2): partitionibus "pro lucri"

Particulationem clavem (nuntii) ad omnes tabulas addimus: recipientes, fasciculi, registras. Ipsum nuntium addere non debes, sed DateTime existentem utere.

topics

Cum unus tantum locus sit pluribus nuntiis, non est modus "secare" in eodem exemplari, alio nitendum est. In nobis est specimen date primae nuntius correspondentia — id est, momentum creationis, immo thematis.

Messenger database (part 2): partitionibus "pro lucri"

Particulationem clavem (topice datam) ad omnes tabulas adde: thema, participem.

Sed nunc duas quaestiones simul habemus:

  • In qua sectione nuntios de re quaeram?
  • In qua sectione quaeram thema ex verbo?

Possumus sane in omnibus sectionibus quaerere, sed hoc triste erit et omnes lucra negabit. Ut igitur cognoscamus ubinam diligentius inspiciamus, nexus logicos/indices ad sectiones faciemus;

  • addemus in verbo topic date agri
  • Addamus in topic nuntius diem paro haec correspondentia (potest esse mensa separata, vel ordo temporum)

Messenger database (part 2): partitionibus "pro lucri"

Cum paucae modificationes erunt in indice epistularum ad singulas correspondentias (post omnes, fere omnes epistulae in diebus proximis 1-2 cadunt), hanc optionem intendunt.

In summa, structura datorum nostrorum hanc formam accepit, attentis partitionibus:

Tabulae: RU, si aversiones habes in nominibus cyrillianis alphabeti tabularum/agrorum, melius est non respicere.

-- секции по дате сообщения
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
);

Servo satis denarium

Quid si non? classic sectioning optionem fundatur in distributione valorum campi (per triggers et hereditatem vel PARTITIONEM BY), et "manualiter" in gradu applicationis, animadvertes valorem clavem partitionis iam in nomine ipsius mensae repositam esse.

Itaque si ita Tu es valde curare moles notitia repono?ergo has "extra" agros et certas tabulas electronicas auferre potes. Verum omnia excerpta ex pluribus sectionibus in hoc casu transferri debebunt ad schedulam partem.

Source: www.habr.com

Add a comment