PostgreSQL-ൽ വലിയ വോള്യങ്ങളിൽ ഒരു പൈസ ലാഭിക്കുക

ഉയർത്തിയ വലിയ ഡാറ്റ സ്ട്രീമുകൾ റെക്കോർഡ് ചെയ്യുന്ന വിഷയം തുടരുന്നു വിഭജനത്തെക്കുറിച്ചുള്ള മുൻ ലേഖനം, ഇതിൽ നിങ്ങൾക്ക് കഴിയുന്ന വഴികൾ ഞങ്ങൾ നോക്കും സംഭരിച്ചവയുടെ "ഭൗതിക" വലിപ്പം കുറയ്ക്കുക PostgreSQL-ലും സെർവർ പ്രകടനത്തിൽ അവയുടെ സ്വാധീനവും.

നമ്മൾ സംസാരിക്കും TOAST ക്രമീകരണങ്ങളും ഡാറ്റ വിന്യാസവും. "ശരാശരി," ഈ രീതികൾ വളരെയധികം വിഭവങ്ങൾ സംരക്ഷിക്കില്ല, പക്ഷേ ആപ്ലിക്കേഷൻ കോഡ് പരിഷ്കരിക്കാതെ തന്നെ.

എന്നിരുന്നാലും, ഞങ്ങളുടെ അനുഭവം ഇക്കാര്യത്തിൽ വളരെ ഉൽപ്പാദനക്ഷമമായി മാറി, കാരണം അതിൻ്റെ സ്വഭാവമനുസരിച്ച് ഏതൊരു നിരീക്ഷണത്തിൻ്റെയും സംഭരണം കൂടുതലും അനുബന്ധമായി മാത്രം രേഖപ്പെടുത്തിയ ഡാറ്റയുടെ കാര്യത്തിൽ. പകരം ഡിസ്കിലേക്ക് എഴുതാൻ ഡാറ്റാബേസിനെ എങ്ങനെ പഠിപ്പിക്കാം എന്ന് നിങ്ങൾ ചിന്തിക്കുകയാണെങ്കിൽ 200MB / സെക്കന്റ് പകുതി - ദയവായി പൂച്ചയ്ക്ക് കീഴിൽ.

വലിയ ഡാറ്റയുടെ ചെറിയ രഹസ്യങ്ങൾ

ജോലി പ്രൊഫൈൽ പ്രകാരം ഞങ്ങളുടെ സേവനം, അവർ പതിവായി ഗുഹകളിൽ നിന്ന് അവനിലേക്ക് പറക്കുന്നു ടെക്സ്റ്റ് പാക്കേജുകൾ.

കൂടാതെ VLSI സമുച്ചയംസങ്കീർണ്ണമായ ഡാറ്റാ ഘടനകളുള്ള ഒരു മൾട്ടി-ഘടക ഉൽപ്പന്നമാണ് ഞങ്ങൾ നിരീക്ഷിക്കുന്ന ഡാറ്റാബേസ്, തുടർന്ന് അന്വേഷണങ്ങൾ പരമാവധി പ്രകടനത്തിന് ഇതുപോലെ മാറുക സങ്കീർണ്ണമായ അൽഗോരിതം ലോജിക്കോടുകൂടിയ "മൾട്ടി-വോളിയം". അതിനാൽ ഞങ്ങൾക്ക് വരുന്ന ലോഗിലെ ഒരു അഭ്യർത്ഥനയുടെ ഓരോ വ്യക്തിഗത സംഭവത്തിൻ്റെയും അല്ലെങ്കിൽ അതിൻ്റെ ഫലമായുള്ള നിർവ്വഹണ പദ്ധതിയുടെയോ അളവ് "ശരാശരി" വളരെ വലുതായി മാറുന്നു.

“റോ” ഡാറ്റ എഴുതുന്ന പട്ടികകളിലൊന്നിൻ്റെ ഘടന നോക്കാം - അതായത്, ലോഗ് എൻട്രിയിൽ നിന്നുള്ള യഥാർത്ഥ വാചകം ഇതാ:

CREATE TABLE rawdata_orig(
  pack -- PK
    uuid NOT NULL
, recno -- PK
    smallint NOT NULL
, dt -- ключ секции
    date
, data -- самое главное
    text
, PRIMARY KEY(pack, recno)
);

ഒരു സാധാരണ ചിഹ്നം (ഇതിനകം തന്നെ വിഭാഗീകരിച്ചിരിക്കുന്നു, അതിനാൽ ഇത് ഒരു സെക്ഷൻ ടെംപ്ലേറ്റ് ആണ്), ഇവിടെ ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം വാചകമാണ്. ചിലപ്പോൾ വളരെ വലുതാണ്.

ഒരു പിജിയിലെ ഒരു റെക്കോർഡിൻ്റെ “ഫിസിക്കൽ” വലുപ്പത്തിന് ഒന്നിലധികം പേജ് ഡാറ്റ ഉൾക്കൊള്ളാൻ കഴിയില്ല, എന്നാൽ “ലോജിക്കൽ” വലുപ്പം തികച്ചും വ്യത്യസ്തമായ കാര്യമാണ്. ഒരു ഫീൽഡിലേക്ക് ഒരു വോള്യൂമെട്രിക് മൂല്യം (varchar/text/bytea) എഴുതാൻ, ഉപയോഗിക്കുക TOAST സാങ്കേതികവിദ്യ:

PostgreSQL ഒരു നിശ്ചിത പേജ് വലുപ്പം ഉപയോഗിക്കുന്നു (സാധാരണയായി 8 KB), കൂടാതെ ഒന്നിലധികം പേജുകൾ വ്യാപിപ്പിക്കാൻ tuples-നെ അനുവദിക്കുന്നില്ല. അതിനാൽ, വളരെ വലിയ ഫീൽഡ് മൂല്യങ്ങൾ നേരിട്ട് സംഭരിക്കുന്നത് അസാധ്യമാണ്. ഈ പരിമിതി മറികടക്കാൻ, വലിയ ഫീൽഡ് മൂല്യങ്ങൾ കംപ്രസ് ചെയ്യുകയും കൂടാതെ/അല്ലെങ്കിൽ ഒന്നിലധികം ഫിസിക്കൽ ലൈനുകളിൽ വിഭജിക്കുകയും ചെയ്യുന്നു. ഇത് ഉപയോക്താവിൻ്റെ ശ്രദ്ധയിൽപ്പെടാതെ സംഭവിക്കുകയും മിക്ക സെർവർ കോഡുകളിലും ചെറിയ സ്വാധീനം ചെലുത്തുകയും ചെയ്യുന്നു. ഈ രീതി TOAST എന്നാണ് അറിയപ്പെടുന്നത്...

വാസ്തവത്തിൽ, "സാധ്യതയുള്ള" ഫീൽഡുകളുള്ള എല്ലാ ടേബിളിനും സ്വയമേവ "സ്ലൈസിംഗ്" ഉള്ള ഒരു ജോടിയാക്കിയ പട്ടിക സൃഷ്ടിച്ചു 2KB സെഗ്‌മെൻ്റുകളിലെ ഓരോ "വലിയ" റെക്കോർഡും:

TOAST(
  chunk_id
    integer
, chunk_seq
    integer
, chunk_data
    bytea
, PRIMARY KEY(chunk_id, chunk_seq)
);

അതായത്, "വലിയ" മൂല്യമുള്ള ഒരു സ്ട്രിംഗ് എഴുതണമെങ്കിൽ data, അപ്പോൾ യഥാർത്ഥ റെക്കോർഡിംഗ് സംഭവിക്കും പ്രധാന ടേബിളിലേക്കും അതിൻ്റെ പികെയിലേക്കും മാത്രമല്ല, ടോസ്‌റ്റിലേക്കും അതിൻ്റെ പികെയിലേക്കും.

TOAST സ്വാധീനം കുറയ്ക്കുന്നു

എന്നാൽ ഞങ്ങളുടെ മിക്ക റെക്കോർഡുകളും ഇപ്പോഴും അത്ര വലുതല്ല, 8KB-യിലേക്ക് യോജിപ്പിക്കണം - ഇതിൽ എനിക്ക് എങ്ങനെ പണം ലാഭിക്കാം?..

ഇവിടെയാണ് ആട്രിബ്യൂട്ട് നമ്മുടെ സഹായത്തിന് വരുന്നത് STORAGE പട്ടിക നിരയിൽ:

• വിപുലീകരിച്ചു കംപ്രഷനും പ്രത്യേക സംഭരണവും അനുവദിക്കുന്നു. ഈ സ്റ്റാൻഡേർഡ് ഓപ്ഷൻ മിക്ക ടോസ്റ്റ് കംപ്ലയിൻ്റ് ഡാറ്റാ തരങ്ങൾക്കും. ഇത് ആദ്യം കംപ്രഷൻ നടത്താൻ ശ്രമിക്കുന്നു, തുടർന്ന് വരി ഇപ്പോഴും വളരെ വലുതാണെങ്കിൽ അത് പട്ടികയ്ക്ക് പുറത്ത് സൂക്ഷിക്കുന്നു.
• കൈ കംപ്രഷൻ അനുവദിക്കുന്നു എന്നാൽ പ്രത്യേക സംഭരണമല്ല. (വാസ്തവത്തിൽ, അത്തരം നിരകൾക്കായി പ്രത്യേക സംഭരണം തുടർന്നും നടപ്പിലാക്കും, പക്ഷേ മാത്രം അവസാന ആശ്രയമായി, സ്ട്രിംഗ് ചുരുക്കാൻ മറ്റൊരു മാർഗവുമില്ലാത്തപ്പോൾ അത് പേജിൽ യോജിക്കും.)

വാസ്തവത്തിൽ, ടെക്സ്റ്റിനായി നമുക്ക് വേണ്ടത് ഇതാണ് - ഇത് കഴിയുന്നത്ര കംപ്രസ് ചെയ്യുക, അത് ഒട്ടും യോജിക്കുന്നില്ലെങ്കിൽ, അത് ടോസ്റ്റിൽ ഇടുക. ഒരു കമാൻഡ് ഉപയോഗിച്ച് ഇത് ഫ്ലൈയിൽ നേരിട്ട് ചെയ്യാം:

ALTER TABLE rawdata_orig ALTER COLUMN data SET STORAGE MAIN;

പ്രഭാവം എങ്ങനെ വിലയിരുത്താം

ഡാറ്റാ ഫ്ലോ ഓരോ ദിവസവും മാറുന്നതിനാൽ, നമുക്ക് കേവല സംഖ്യകളെ താരതമ്യം ചെയ്യാൻ കഴിയില്ല, പക്ഷേ ആപേക്ഷികമായി ചെറിയ പങ്ക് ഞങ്ങൾ അത് ടോസ്റ്റിൽ എഴുതി - അത്രയും നല്ലത്. എന്നാൽ ഇവിടെ ഒരു അപകടമുണ്ട് - ഓരോ വ്യക്തിഗത റെക്കോർഡിൻ്റെയും "ഫിസിക്കൽ" വോളിയം വലുതാകുമ്പോൾ, സൂചിക "വിശാലമായി" മാറുന്നു, കാരണം ഞങ്ങൾക്ക് കൂടുതൽ ഡാറ്റ പേജുകൾ നൽകേണ്ടതുണ്ട്.

വിഭാഗം മാറ്റങ്ങൾക്ക് മുമ്പ്:

heap  = 37GB (39%)
TOAST = 54GB (57%)
PK    =  4GB ( 4%)

വിഭാഗം മാറ്റങ്ങൾക്ക് ശേഷം:

heap  = 37GB (67%)
TOAST = 16GB (29%)
PK    =  2GB ( 4%)

വാസ്തവത്തിൽ, ഞങ്ങൾ TOAST ലേക്ക് 2 മടങ്ങ് കുറച്ച് തവണ എഴുതാൻ തുടങ്ങി, ഇത് ഡിസ്ക് മാത്രമല്ല, സിപിയുവും അൺലോഡ് ചെയ്തു:

"എഴുത്ത്" മാത്രമല്ല, ഡിസ്ക് "വായന" ചെയ്യുന്നതിലും ഞങ്ങൾ ചെറുതായിരിക്കുന്നുവെന്ന് ഞാൻ ശ്രദ്ധിക്കും - ഒരു പട്ടികയിൽ ഒരു റെക്കോർഡ് ചേർക്കുമ്പോൾ, ഓരോ സൂചികയുടെയും വൃക്ഷത്തിൻ്റെ ഒരു ഭാഗം നിർണ്ണയിക്കാൻ ഞങ്ങൾ "വായിക്കേണ്ടതുണ്ട്" അവയിൽ ഭാവി സ്ഥാനം.

PostgreSQL 11-ൽ ആർക്കൊക്കെ നന്നായി ജീവിക്കാനാകും

PG11-ലേക്ക് അപ്‌ഡേറ്റ് ചെയ്‌ത ശേഷം, TOAST “ട്യൂണിംഗ്” തുടരാൻ ഞങ്ങൾ തീരുമാനിച്ചു, ഈ പതിപ്പിൽ നിന്ന് പാരാമീറ്റർ ആരംഭിക്കുന്നത് ശ്രദ്ധിച്ചു toast_tuple_target:

പട്ടികയിൽ സംഭരിക്കേണ്ട വരി മൂല്യം TOAST_TUPLE_THRESHOLD ബൈറ്റുകളേക്കാൾ (സാധാരണയായി 2 KB) വലുതായിരിക്കുമ്പോൾ മാത്രമേ TOAST പ്രോസസ്സിംഗ് കോഡ് പ്രവർത്തിക്കൂ. വരിയുടെ മൂല്യം TOAST_TUPLE_TARGET ബൈറ്റുകളേക്കാൾ (വേരിയബിൾ മൂല്യം, സാധാരണയായി 2 KB) കുറയുന്നത് വരെ അല്ലെങ്കിൽ വലുപ്പം കുറയ്ക്കാൻ കഴിയാത്തത് വരെ TOAST കോഡ് ഫീൽഡ് മൂല്യങ്ങൾ കംപ്രസ്സുചെയ്യുകയും കൂടാതെ/അല്ലെങ്കിൽ പട്ടികയിൽ നിന്ന് നീക്കുകയും ചെയ്യും.

സാധാരണയായി ഞങ്ങളുടെ പക്കലുള്ള ഡാറ്റ ഒന്നുകിൽ "വളരെ ചെറുത്" അല്ലെങ്കിൽ "വളരെ നീണ്ടത്" ആണെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു, അതിനാൽ സാധ്യമായ ഏറ്റവും കുറഞ്ഞ മൂല്യത്തിലേക്ക് സ്വയം പരിമിതപ്പെടുത്താൻ ഞങ്ങൾ തീരുമാനിച്ചു:

ALTER TABLE rawplan_orig SET (toast_tuple_target = 128);

വീണ്ടും കോൺഫിഗറേഷനുശേഷം പുതിയ ക്രമീകരണങ്ങൾ ഡിസ്ക് ലോഡിംഗിനെ എങ്ങനെ ബാധിച്ചുവെന്ന് നോക്കാം:

മോശമല്ല! ശരാശരി ഡിസ്കിലേക്കുള്ള ക്യൂ കുറഞ്ഞു ഏകദേശം 1.5 തവണ, ഡിസ്ക് "തിരക്കിലാണ്" 20 ശതമാനം! എന്നാൽ ഇത് എങ്ങനെയെങ്കിലും സിപിയുവിനെ ബാധിച്ചിരിക്കുമോ?

കുറഞ്ഞത് മോശമായില്ല. എന്നിരുന്നാലും, അത്തരം വോള്യങ്ങൾക്ക് പോലും ശരാശരി സിപിയു ലോഡ് ഉയർത്താൻ കഴിയുന്നില്ലെങ്കിൽ വിലയിരുത്താൻ പ്രയാസമാണ് 5%.

നിബന്ധനകളുടെ സ്ഥലങ്ങൾ മാറ്റുന്നതിലൂടെ, തുക... മാറുന്നു!

നിങ്ങൾക്കറിയാവുന്നതുപോലെ, ഒരു ചില്ലിക്കാശും ഒരു റൂബിൾ ലാഭിക്കുന്നു, ഞങ്ങളുടെ സംഭരണ ​​വോള്യങ്ങൾക്കൊപ്പം അത് ഏകദേശം 10TB/മാസം ഒരു ചെറിയ ഒപ്റ്റിമൈസേഷൻ പോലും നല്ല ലാഭം നൽകും. അതിനാൽ, ഞങ്ങളുടെ ഡാറ്റയുടെ ഭൗതിക ഘടന ഞങ്ങൾ ശ്രദ്ധിച്ചു - എത്ര കൃത്യമായി റെക്കോർഡിനുള്ളിൽ "സഞ്ചിത" ഫീൽഡുകൾ ഓരോ മേശകളും.

കാരണം ഡാറ്റ വിന്യാസം ഇത് നേരെ മുന്നോട്ട് തത്ഫലമായുണ്ടാകുന്ന വോളിയത്തെ ബാധിക്കുന്നു:

പല ആർക്കിടെക്ചറുകളും മെഷീൻ വേഡ് ബൗണ്ടറികളിൽ ഡാറ്റ വിന്യാസം നൽകുന്നു. ഉദാഹരണത്തിന്, ഒരു 32-ബിറ്റ് x86 സിസ്റ്റത്തിൽ, പൂർണ്ണസംഖ്യകൾ (പൂർണ്ണസംഖ്യ തരം, 4 ബൈറ്റുകൾ) ഒരു 4-ബൈറ്റ് വേഡ് ബൗണ്ടറിയിൽ വിന്യസിക്കും, അതുപോലെ ഇരട്ട പ്രിസിഷൻ ഫ്ലോട്ടിംഗ് പോയിൻ്റ് നമ്പറുകൾ (ഡബിൾ പ്രിസിഷൻ ഫ്ലോട്ടിംഗ് പോയിൻ്റ്, 8 ബൈറ്റുകൾ). ഒരു 64-ബിറ്റ് സിസ്റ്റത്തിൽ, ഇരട്ട മൂല്യങ്ങൾ 8-ബൈറ്റ് വേഡ് ബൗണ്ടറികളിലേക്ക് വിന്യസിക്കും. ഇത് പൊരുത്തക്കേടിൻ്റെ മറ്റൊരു കാരണമാണ്.

വിന്യാസം കാരണം, ഒരു പട്ടിക വരിയുടെ വലുപ്പം ഫീൽഡുകളുടെ ക്രമത്തെ ആശ്രയിച്ചിരിക്കുന്നു. സാധാരണയായി ഈ പ്രഭാവം വളരെ ശ്രദ്ധേയമല്ല, എന്നാൽ ചില സന്ദർഭങ്ങളിൽ ഇത് വലുപ്പത്തിൽ ഗണ്യമായ വർദ്ധനവിന് കാരണമാകും. ഉദാഹരണത്തിന്, നിങ്ങൾ char(1) ഉം പൂർണ്ണസംഖ്യ ഫീൽഡുകളും മിക്സ് ചെയ്യുകയാണെങ്കിൽ, അവയ്ക്കിടയിൽ സാധാരണയായി 3 ബൈറ്റുകൾ പാഴായിപ്പോകും.

സിന്തറ്റിക് മോഡലുകളിൽ നിന്ന് നമുക്ക് ആരംഭിക്കാം:

SELECT pg_column_size(ROW(
  '0000-0000-0000-0000-0000-0000-0000-0000'::uuid
, 0::smallint
, '2019-01-01'::date
));
-- 48 байт

SELECT pg_column_size(ROW(
  '2019-01-01'::date
, '0000-0000-0000-0000-0000-0000-0000-0000'::uuid
, 0::smallint
));
-- 46 байт

ആദ്യ കേസിൽ രണ്ട് അധിക ബൈറ്റുകൾ എവിടെ നിന്ന് വന്നു? ഇത് ലളിതമാണ് - 2-ബൈറ്റ് സ്മോൾലിൻ്റ് 4-ബൈറ്റ് അതിർത്തിയിൽ വിന്യസിച്ചു അടുത്ത ഫീൽഡിന് മുമ്പായി, അത് അവസാനത്തേതായിരിക്കുമ്പോൾ, ഒന്നുമില്ല, വിന്യസിക്കേണ്ടതില്ല.

സിദ്ധാന്തത്തിൽ, എല്ലാം ശരിയാണ്, നിങ്ങൾക്ക് ഇഷ്ടമുള്ള ഫീൽഡുകൾ പുനഃക്രമീകരിക്കാൻ കഴിയും. പട്ടികകളിലൊന്നിൻ്റെ ഉദാഹരണം ഉപയോഗിച്ച് യഥാർത്ഥ ഡാറ്റയിൽ ഇത് പരിശോധിക്കാം, അതിൻ്റെ പ്രതിദിന വിഭാഗം 10-15GB ഉൾക്കൊള്ളുന്നു.

പ്രാരംഭ ഘടന:

CREATE TABLE public.plan_20190220
(
-- Унаследована from table plan:  pack uuid NOT NULL,
-- Унаследована from table plan:  recno smallint NOT NULL,
-- Унаследована from table plan:  host uuid,
-- Унаследована from table plan:  ts timestamp with time zone,
-- Унаследована from table plan:  exectime numeric(32,3),
-- Унаследована from table plan:  duration numeric(32,3),
-- Унаследована from table plan:  bufint bigint,
-- Унаследована from table plan:  bufmem bigint,
-- Унаследована from table plan:  bufdsk bigint,
-- Унаследована from table plan:  apn uuid,
-- Унаследована from table plan:  ptr uuid,
-- Унаследована from table plan:  dt date,
  CONSTRAINT plan_20190220_pkey PRIMARY KEY (pack, recno),
  CONSTRAINT chck_ptr CHECK (ptr IS NOT NULL),
  CONSTRAINT plan_20190220_dt_check CHECK (dt = '2019-02-20'::date)
)
INHERITS (public.plan)

നിര ക്രമം മാറ്റിയതിന് ശേഷമുള്ള വിഭാഗം - കൃത്യമായി ഒരേ ഫീൽഡുകൾ, വ്യത്യസ്ത ക്രമം:

CREATE TABLE public.plan_20190221
(
-- Унаследована from table plan:  dt date NOT NULL,
-- Унаследована from table plan:  ts timestamp with time zone,
-- Унаследована from table plan:  pack uuid NOT NULL,
-- Унаследована from table plan:  recno smallint NOT NULL,
-- Унаследована from table plan:  host uuid,
-- Унаследована from table plan:  apn uuid,
-- Унаследована from table plan:  ptr uuid,
-- Унаследована from table plan:  bufint bigint,
-- Унаследована from table plan:  bufmem bigint,
-- Унаследована from table plan:  bufdsk bigint,
-- Унаследована from table plan:  exectime numeric(32,3),
-- Унаследована from table plan:  duration numeric(32,3),
  CONSTRAINT plan_20190221_pkey PRIMARY KEY (pack, recno),
  CONSTRAINT chck_ptr CHECK (ptr IS NOT NULL),
  CONSTRAINT plan_20190221_dt_check CHECK (dt = '2019-02-21'::date)
)
INHERITS (public.plan)

വിഭാഗത്തിൻ്റെ ആകെ അളവ് നിർണ്ണയിക്കുന്നത് "വസ്തുതകളുടെ" എണ്ണം അനുസരിച്ചാണ്, അത് ബാഹ്യ പ്രക്രിയകളെ മാത്രം ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ നമുക്ക് കൂമ്പാരത്തിൻ്റെ വലുപ്പം വിഭജിക്കാം (pg_relation_size) അതിലെ റെക്കോർഡുകളുടെ എണ്ണം അനുസരിച്ച് - അതായത്, നമുക്ക് ലഭിക്കും യഥാർത്ഥ സംഭരിച്ച റെക്കോർഡിൻ്റെ ശരാശരി വലിപ്പം:

മൈനസ് 6% വോളിയം, കൊള്ളാം!

എന്നാൽ എല്ലാം, തീർച്ചയായും, അത്ര റോസി അല്ല - എല്ലാത്തിനുമുപരി, സൂചികകളിൽ നമുക്ക് ഫീൽഡുകളുടെ ക്രമം മാറ്റാൻ കഴിയില്ല, അതിനാൽ "പൊതുവായി" (pg_total_relation_size)…

...ഇപ്പോഴും ഇവിടെയുണ്ട് 1.5% ലാഭിച്ചുകോഡിൻ്റെ ഒരു വരി പോലും മാറ്റാതെ. അതെ അതെ!

ഫീൽഡുകൾ ക്രമീകരിക്കുന്നതിനുള്ള മുകളിലുള്ള ഓപ്ഷൻ അത് ഏറ്റവും ഒപ്റ്റിമൽ ആണെന്ന വസ്തുതയല്ലെന്ന് ഞാൻ ശ്രദ്ധിക്കുന്നു. സൗന്ദര്യപരമായ കാരണങ്ങളാൽ ചില ഫീൽഡുകൾ "കീറാൻ" നിങ്ങൾ ആഗ്രഹിക്കുന്നില്ല - ഉദാഹരണത്തിന്, ഒരു ദമ്പതികൾ (pack, recno), ഈ ടേബിളിൻ്റെ പി.കെ.

പൊതുവേ, ഫീൽഡുകളുടെ "മിനിമം" ക്രമീകരണം നിർണ്ണയിക്കുന്നത് വളരെ ലളിതമായ ഒരു "ബ്രൂട്ട് ഫോഴ്സ്" ആണ്. അതിനാൽ, ഞങ്ങളുടേതിനേക്കാൾ മികച്ച ഫലങ്ങൾ നിങ്ങളുടെ ഡാറ്റയിൽ നിന്ന് നിങ്ങൾക്ക് ലഭിക്കും - ഇത് പരീക്ഷിക്കുക!

അവലംബം: www.habr.com