විශාල ගොනු (10 MB) දත්ත ගබඩාවක ගබඩා කිරීම නරක පුරුද්දක්ද?

1 MB - 10 MB ප්‍රමාණයේ ලිපිගොනු ගබඩා කිරීමට සහ බෙදා ගැනීමට පරිශීලකයින්ට ඉඩ සලසන වෙබ් යෙදුමක් මම දැනට නිර්මාණය කරමින් සිටිමි.

දත්ත සමුදායක් තුළ ගොනු ගබඩා කිරීම දත්ත සමුදායේ ප්‍රවේශය සැලකිය යුතු ලෙස මන්දගාමී කරන බව මට පෙනේ.

මෙය වලංගු කාරණයක්ද? ගොනු පද්ධතියේ ගොනු ගබඩා කර දත්ත ගබඩාවේ ගොනු නම සහ මාර්ගය සුරැකීම වඩා හොඳද? දත්ත සමුදායක් සමඟ වැඩ කිරීමේදී ලිපිගොනු ගබඩා කිරීම හා සම්බන්ධ හොඳම භාවිතයන් තිබේද?

මම මෙම ව්‍යාපෘතිය සඳහා PHP සහ MySQL හි වැඩ කරමි, නමුත් බොහෝ පරිසරයන්ට ( රූබි ඔන් රේල්ස් , PHP , .NET ) සහ දත්ත සමුදායන් (MySQL, PostgreSQL ) සඳහාද මෙයම වේ .

දත්ත සමුදායේ ගොනු ගබඩා කිරීමට පක්ෂව ඇති හේතු:

1. දත්ත සමුදායෙන් පිටත ගොනු ගබඩා කරන විට සංකීර්ණ වන යාවත්කාලීනයක පෙරළීම ඇතුළුව ACID අනුකූලතාව. මෙය සැහැල්ලුවෙන් විස්තර කළ යුතු නොවේ. ලිපිගොනු සහ දත්ත සමුදාය සමමුහුර්තව තබා ගැනීම සහ ගනුදෙනු සඳහා සහභාගී වීම ඉතා ප්‍රයෝජනවත් වේ.
2. ලිපිගොනු දත්ත සමුදාය සමඟ යන අතර එයින් අනාථ විය නොහැක.
3. උපස්ථ ස්වයංක්‍රීයව ගොනු ද්විමය ඇතුළත් වේ.

දත්ත සමුදායේ ගොනු ගබඩා කිරීමට හේතුව:

1. ද්විමය ගොනුවක ප්‍රමාණය දත්ත සමුදායන් අතර වෙනස් වේ. SQL සේවාදායකයේ, FILESTREAM වස්තුව භාවිතා නොකරන විට, උදාහරණයක් ලෙස එය 2 GB වේ. පරිශීලකයින්ට ලිපිගොනු විශාල වශයෙන් ගබඩා කිරීමට අවශ්‍ය නම් (චිත්‍රපටයක් කියන්නාක් මෙන්), එම මැජික් සිදු කිරීම සඳහා ඔබ වළලු හරහා පැනිය යුතුය.
2. දත්ත සමුදායේ ප්‍රමාණය වැඩි කරයි. ඔබ මතක තබා ගත යුතු එක් පොදු සංකල්පයක්: දත්ත සමුදායක් පවත්වා ගැනීමට අවශ්‍ය දැනුමේ මට්ටම දත්ත සමුදායේ ප්‍රමාණයට සමානුපාතිකව ඉහළ යයි.එනම්, කුඩා දත්ත සමුදායන්ට වඩා විශාල දත්ත සමුදායන් නඩත්තු කිරීමට වඩා සංකීර්ණ ය. දත්ත සමුදාය තුළ ගොනු ගබඩා කිරීමෙන් දත්ත සමුදාය වඩා විශාල කළ හැකිය. විශාල දත්ත සමුදා ප්‍රමාණයක් සහිත දෛනික පූර්ණ උපස්ථයක් ප්‍රමාණවත් වනු ඇතැයි පැවසුවද, ඔබට එය තවදුරටත් කළ නොහැකි වනු ඇත. ලිපිගොනු වෙනත් ගොනු කණ්ඩායමකට දැමීම ගැන සලකා බැලිය යුතුය (දත්ත සමුදාය එයට සහය දක්වන්නේ නම්), දත්තවල උපස්ථය ගොනු වල උපස්ථයෙන් වෙන් කිරීමට උපස්ථ කරකවන්න. මේ කිසිවක් ඉගෙන ගැනීමට අපහසු නමුත් එසේ කරන්න නඩත්තු කිරීම සඳහා සංකීර්ණත්වය එකතු කිරීම එයින් අදහස් වන්නේ ව්‍යාපාරයට පිරිවැයයි. විශාල දත්ත සමුදායන් ද හැකි තරම් මතක ප්‍රමාණයක් පරිභෝජනය කරයි.
3. ඔබ SQL සේවාදායකයේ FILESTREAMවස්තුව වැනි පද්ධති විශේෂිත අංග භාවිතා කරන්නේ නම් සහ වෙනත් දත්ත සමුදා පද්ධතියකට සංක්‍රමණය වීමට අවශ්‍ය නම් අතේ ගෙන යා හැකි බව සැලකිලිමත් විය හැකිය .
4. දත්ත සමුදායට ලිපිගොනු ලියන කේතය ගැටළුවක් විය හැකිය. මම බොහෝ චන්ද්‍රයින්ට පෙර උපදෙස් ලබා ගත් එක් සමාගමක් යම් අවස්ථාවක දී මයික්‍රොසොෆ්ට් ඇක්සස් ෆ්‍රොන්ටෙන්ඩ් එකක් ඔවුන්ගේ දත්ත සමුදා සේවාදායකයට සම්බන්ධ කළ අතර එහි ඔලේ වස්තු පාලනය භාවිතා කරමින් “ඕනෑම දෙයක්” උඩුගත කිරීමේ ප්‍රවේශය භාවිතා කළේය. පසුව ඔවුන් වෙනස් පාලනයක් භාවිතා කිරීමට වෙනස් වූ අතර එය තවමත් ඔලේ මත රඳා පැවතුනි. බොහෝ කලකට පසු අමු ද්විමය ගබඩා කිරීම සඳහා යමෙක් අතුරු මුහුණත වෙනස් කළේය. එම ඔලේ වස්තුව උපුටා ගැනීම අපායේ නව මට්ටමකි. ඔබ ගොනු පද්ධතියේ ගොනු ගබඩා කරන විට, ප්‍රභව ගොනුව එතීමට / වෙනස් කිරීමට / වෙනස් කිරීමට අමතර තට්ටුවක් නොමැත.
5. වෙබ් අඩවියකට ලිපිගොනු සැපයීම වඩාත් සංකීර්ණ වේ. ද්විමය තීරු සමඟ එය සිදු කිරීම සඳහා, දත්ත ගබඩාවෙන් ද්විමය ගොනුව ප්‍රවාහනය කිරීම සඳහා ඔබ හසුරුවන්නෙකු ලිවිය යුතුය. ඔබ ද ඔබට ගොනු මාර්ග ගබඩා එහෙත් ඔබ නොමැති වුවත් මෙය කළ හැකි ඇති මෙය කිරීමට. නැවතත්, හසුරුවන්නෙකු එකතු කිරීම කළ නොහැකි නමුත් සංකීර්ණත්වය එකතු කරන අතර එය අසාර්ථක වීමේ තවත් කරුණකි.
6. ඔබට වලාකුළු ආචයනයෙන් ප්‍රයෝජන ගත නොහැක. එක් දිනක් ඔබේ ලිපිගොනු ඇමසන් එස් 3 බාල්දියක ගබඩා කිරීමට අවශ්‍ය යැයි සිතමු. ඔබ දත්ත ගබඩාවේ ගබඩා කර ඇති දේ ගොනු මාර්ග නම්, ඒවා S3 හි මාර්ග වලට වෙනස් කිරීමේ හැකියාව ඔබට ඇත. මා දන්නා පරිදි, කිසිදු ඩීබීඑම්එස් සමඟ කිසිදු අවස්ථාවක එය කළ නොහැකිය.

IMO, දත්ත සමුදායේ ගොනු ගබඩා කිරීම හෝ "නරක" ලෙස නොසැලකීම සඳහා තත්වයන් සහ අවශ්‍යතා පිළිබඳ වැඩි විස්තර අවශ්‍ය වේ. ලිපිගොනු වල ප්‍රමාණය සහ / හෝ ගණන සැමවිටම කුඩා වේද? වලාකුළු ආචයනය භාවිතා කිරීමට කිසිදු සැලසුමක් නැද්ද? ලිපිගොනු වෙබ් අඩවියක හෝ වින්ඩෝස් යෙදුමක් වැනි ද්විමය ක්‍රියාත්මක කළ හැකිද?

පොදුවේ ගත් කල, මගේ අත්දැකීම් වලින් සොයාගෙන ඇත්තේ ACID හි and නතාවය සහ අනාථ දරුවන් සඳහා ඇති ඉඩකඩ නිසා පවා මාර්ග ගබඩා කිරීම ව්‍යාපාරයට අඩු වියදම් බවයි. කෙසේ වෙතත්, අන්තර්ජාලය ACID පාලනයේ lack නතාවයෙන් පෙළෙන ලිපිගොනු ගබඩා කිරීමක් ලෙස වැරදියට වැටී ඇති බවක් එයින් අදහස් නොකෙරේ, නමුත් එයින් අදහස් කරන්නේ පොදුවේ එම විසඳුම ගොඩනැගීම, තේරුම් ගැනීම සහ නඩත්තු කිරීම පහසු බවය.

බොහෝ අවස්ථාවලදී මෙය නරක අදහසකි. එය දත්ත සමුදා ලිපිගොනු පුපුරා යන අතර කාර්ය සාධන ගැටළු කිහිපයක් ඇති කරයි. තීරු විශාල සංඛ්‍යාවක් ඇති මේසයක ඔබ බ්ලොබ් ඇලවූ විට එය ඊටත් වඩා භයානක ය.

කෙසේවෙතත්! SQL සේවාදායකය වැනි සමහර දත්ත සමුදායන්ට FILESTREAM තීරු වර්ගයක් ඇත. මෙම අවස්ථාවේදී, ඔබේ දත්ත ඇත්ත වශයෙන්ම දත්ත සමුදා සේවාදායකයේ වෙනම ගොනුවක ගබඩා කර ඇති අතර ගොනුවේ හැඳුනුම්පතක් පමණක් වගුවේ සුරකිනු ඇත. මෙම අවස්ථාවේ දී SQL සේවාදායකයේ දත්ත තබා නොගැනීමට බොහෝ හේතු මා දකින්නේ නැත. සේවාදායක උපස්ථයේ කොටසක් ලෙස ගොනු ස්වයංක්‍රීයව ඇතුළත් වන අතර දත්ත සමුදාය සහ ගොනු කිසි විටෙකත් සමමුහුර්ත නොවේ. ටෝනි විසින් ගොනු නාම ගබඩා කිරීම පිළිබඳ යෝජනාවේ ඇති ගැටළුව නම්, දත්ත සමුදාය සහ ගොනු පද්ධතියට සමමුහුර්තතාවයෙන් මිදිය හැකි වීමයි. ගොනුවක් තැටියේ මකා දැමූ විට එය පවතින බව දත්ත සමුදාය කියා සිටී. ක්‍රියාවලියක් දත්ත සමුදාය වෙනස් කර පසුව බිඳ වැටේ නම්, ගොනු සහ දත්ත සමුදාය නොගැලපේ (එනම් දත්ත සමුදායෙන් පිටත ලිපිගොනු සහිත ACID නොමැත).

ඔව්, එය නරක පුරුද්දකි.

DB මත කාර්ය සාධන බලපෑම:

• ඔබ SELECTකිසියම් BLOB තීරුවක් සමඟ කරන්නේ නම් , ඔබ සැමවිටම තැටි ප්‍රවේශයක් කරනු ඇති අතර , BLOB නොමැතිව ඔබට RAM වෙතින් කෙලින්ම දත්ත ලබා ගැනීමට අවස්ථාව තිබේ (ඉහළ ප්‍රතිදාන DB RAM හි වගු වලට ගැලපෙන පරිදි ප්‍රශස්තිකරණය වනු ඇත);
• අනුරූකරණය මන්දගාමී වනු ඇත, අනුරූකරණ ප්‍රමාදය ඉහළය, මන්ද එය BLOB වහලුන් වෙතට තල්ලු කිරීමට සිදුවනු ඇත. ඉහළ අනුරූකරණ ප්‍රමාදය ඔබ සියලු වර්ගවල ධාවන තත්වයන් සහ වෙනත් සමමුහුර්තකරණ ගැටළු ඇති කරයි, ඔබ එය පැහැදිලිවම සැලකිල්ලට නොගන්නේ නම්;
• ඩීබී උපස්ථ / ප්‍රතිස්ථාපනය සඳහා වැඩි කාලයක් ගතවනු ඇත;

වේග වාසිය - කිසිවක් නැත ! සමහර පැරණි ගොනු පද්ධති මිලියන ගණනක් ලිපිගොනු සහිත ඩිරෙක්ටරි හසුරුවන්නේ නැතත්, බොහෝ නූතනයන්ට කිසිසේත්ම ගැටළුවක් නොමැති අතර ඇත්ත වශයෙන්ම බීඩී (සාමාන්‍යයෙන් බී-ගස්) වැනි දත්ත ව්‍යුහයන් භාවිතා කරයි. උදාහරණයක් ලෙස ext4 (සුපුරුදු ලිනක්ස් ගොනු පද්ධතිය) Htree භාවිතා කරයි .

නිගමනය: එය ඔබගේ ඩීබී කාර්ය සාධනයට බාධාවක් වන අතර ගොනු ලබා ගැනීමේ කාර්ය සාධනය වැඩි දියුණු නොකරයි.

එසේම, ඔබ ඉන්නේ වෙබ් යෙදුම ගැන කතා සිට - සෘජුව ගොනු පද්ධතිය සිට නවීන වෙබ්-සේවාදායකය භාවිතා ස්ථිතික ගොනු සේවය කරන්න පුළුවන් වන sendfile()syscall වේ දැවැන්ත කාර්ය සාධන වැඩි දියුණු කිරීම. ඔබ ඩීබී වෙතින් ලිපිගොනු ලබා ගන්නේ නම් මෙය කළ නොහැකි ය. නිදසුනක් ලෙස මෙම මිණුම් ලකුණ සලකා බලන්න , අඩු අගයක ලැප්ටොප් එකක සමගාමී සම්බන්ධතා 1000 ක් සමඟ Ngnix 25K req / s කරන බව පෙන්වයි . ඒ ආකාරයේ බරක් ඕනෑම ආකාරයක ඩී.බී.

මම ඒ ගැන ප්‍රායෝගිකව සිතන අතර “තවම ප්‍රශස්තිකරණය නොකරන්න” යන මූලධර්මය අනුගමනය කරන්න. මේ මොහොතේ අර්ථවත් වන විසඳුම සාදන්න, සහ නිසි ලෙස ක්‍රියාත්මක කිරීමට ඔබට සංවර්ධන සම්පත් තිබේ. විභව ගැටළු ඕනෑ තරම් තිබේ . නමුත් ඒවා අනිවාර්යයෙන්ම සැබෑ ගැටළු බවට පත් නොවේ. උදා: ඔබට පරිශීලකයින් 100 ක් සිටී නම් එය ගැටලුවක් නොවනු ඇත. එය විය හැකි ඔබ 100,000 ක් හෝ .10,000,000 පරිශීලකයන් තිබේ නම් ගැටලුවක් විය. එහෙත් අවසාන අවස්ථාවේ දී, සියලු ගැටළු සමඟ කටයුතු කිරීම සඳහා වැඩි සංවර්ධන සම්පත් සඳහා පදනමක් තිබිය යුතුය.

නමුත් දත්ත සමුදාය තුළ දත්ත ගබඩා කිරීම මඟින් වෙනත් ගැටළු සමඟ කටයුතු කිරීමෙන් ඔබව නිදහස් කරයි, උදා: ලිපිගොනු ගබඩා කළ යුත්තේ කොතැනද, ඒවා උපස්ථ කළ යුත්තේ කෙසේද යනාදිය. ඔබ වෙබ් යෙදුමක් ලියන බැවින් එය ආරක්ෂක හේතූන් මත ඉතා හොඳ අදහසකි යෙදුම සත්කාරක කිරීමේ ක්‍රියාවලියට ගොනු පද්ධතියට ලිඛිත ප්‍රවේශයක් නොමැති බව තහවුරු කර ගැනීම සඳහා, ඔබ සේවාදායකය වින්‍යාස කිරීමට අවශ්‍ය වන අතර එමඟින් දත්ත ගබඩා කර ඇති ෆෝල්ඩරයට කියවීමට / ලිවීමට ප්‍රවේශය ඇත.

දත්ත ගබඩාවේ දත්ත ගබඩා කිරීමට මම පුද්ගලිකව තෝරා ගත්තෙමි, නමුත් ඒවා සැබවින්ම අවශ්‍ය වන තෙක් බ්ලොබ්ස් කියවා නැති බවට වග බලා ගන්න, එනම් බ්ලොග් අඩංගු වගු වල "SELECT * FROM ..." ක්‍රියාත්මක නොවේ. ඔබට කාර්ය සාධන ගැටලු ඇති වුවහොත්, දත්ත සමුදායෙන් දත්ත ගොනු පද්ධතියට ගෙනයාමට සැලසුම පහසු බව මම සහතික කරමි. උදාහරණයක් ලෙස ගොනු තොරතුරු වෙනම ගොනු වගුවක ගබඩා කරන්න , එමඟින් ගොනු තොරතුරු වෙනත් ව්‍යාපාරික ආයතන වලින් keeping ත් කර තබයි.

දත්ත සමුදායේ කියවන ලද ගොනුවක් නිරූපණය කිරීම සඳහා ඔබට ගොනු පන්තියක් ඇතැයි උපකල්පනය කිරීම, පසුව එය පිටතට ගෙනයාමේ කේතීකරණ බලපෑම අවම වනු ඇත.

මයික්‍රොසොෆ්ට් ආයතනය මීට වසර කිහිපයකට පෙර ධවල පත්‍රිකාවක් නිකුත් කළේය. එය SqlServer වෙත අවධානය යොමු කරයි, නමුත් ඔබට එහි රසවත් තොරතුරු කිහිපයක් සොයාගත හැකිය:

BLOB වෙතද නැතිනම් BLOB වෙතද? දත්ත සමුදායක හෝ ගොනු පද්ධතියක විශාල වස්තු ගබඩා කිරීම?

ඔවුන්ගේ නිගමනයෙහි ඉතා සංක්ෂිප්ත අනුවාදයක් නම්:

NTFS ගොනු පද්ධතිය හා SQL Server 2005 සංසන්දනය කිරීමේදී, 256KB ට වඩා කුඩා BLOBS SQL සේවාදායකය විසින් වඩාත් කාර්යක්ෂමව හසුරුවනු ලබන අතර NTFS 1MB ට වඩා විශාල BLOBS සඳහා වඩාත් කාර්යක්ෂම වේ.

ඔබේ විශේෂිත භාවිත අවස්ථාව සඳහා කුඩා පරීක්ෂණ කිහිපයක් ලිවීමට මම නිර්දේශ කරමි. හැඹිලි බලපෑම් වලින් ඔබ පරෙස්සම් විය යුතු බව මතක තබා ගන්න. (භෞතිකව කළ හැකි ප්‍රමාණයට වඩා ඉහළ ප්‍රතිදානයන් ඇති බව පෙනෙන්නට තිබූ තැටියේ ඉතිරි කිරීමේ වේගය මට ලැබුණු පළමු අවස්ථාව ගැන මා මවිතයට පත් විය!)

දත්ත සමුදායෙන් පිටත ලිපිගොනු ගබඩා කිරීමේ පැරණි සාම්ප්‍රදායික ප්‍ර wisdom ාව තවදුරටත් නොපවතිනු ඇත. මූලධර්මයක් ලෙස, මම වේගයට වඩා අඛණ්ඩතාවයට කැමතියි, නවීන ඩීබීඑම්එස් සමඟ ඔබට දෙකම තිබිය හැකිය.

ටොම් කයිට් එකඟ වන බව පෙනේ :

දත්ත සමුදායකින් පිටත දීර් keep කාලයක් තබා ගැනීමට අවශ්‍ය දත්ත ගබඩා කිරීමෙන් කිසිදු වාසියක් මා නොදනිමි.

එය දත්ත ගබඩාවේ තිබේ නම් මට හැකි ය

එය වෘත්තීයමය වශයෙන් කළමනාකරණය කර ඇති බවට වග බලා ගන්න

උපස්ථ

අයකර ගත හැකි (ඉතිරි දත්ත සමඟ)

ආරක්ෂිතයි

පරිමාණය කළ හැකි (එක් ඩිරෙක්ටරියක් තුළ ලේඛන 100,000 ක් දැමීමට උත්සාහ කරන්න, දැන් ඒවා වගුවට දමන්න - කුමන 'පරිමාණයන්' - එය නාමාවලිය නොවේ)

මට පහසුවෙන් ඉවත් කළ හැකිය (ෆ්ලෑෂ්බැක්)

මට අගුලු දමා ඇත

මම අනුකූලතාව කියවා ඇත්තෙමි ...

ඔව්.

ඔබ ඔබේ ගොනු පද්ධතියෙන් ගොනුවක් සේවය කරන්නේ නම්, ඔබේ වෙබ් සේවාදායකයාට BSD හෝ ලිනක්ස් හි සෙන්ඩ්ෆයිල් () වැනි කර්නල් කේතය භාවිතා කර ගොනුව කෙලින්ම සොකට්ටුවට පිටපත් කළ හැකිය. එය ඉතා වේගවත් හා ඉතා කාර්යක්ෂමයි.

දත්ත සමුදායෙන් ලිපිගොනු සේවය කිරීම යන්නෙන් අදහස් වන්නේ ඔබ දත්ත සමුදා සේවාදායකයේ තැටියේ සිට දත්ත සමුදා සේවාදායක මතකයට පිටපත් කළ යුතු බවයි, ඉන්පසු db සේවාදායකයේ මතකයේ සිට db සේවාදායකයේ ජාල වරාය දක්වාද, පසුව ජාලයේ සිට ඔබේ වෙබ් සේවාදායක ක්‍රියාවලිය දක්වාද, ඉන්පසු නැවත පිටතට පිටතට යන ජාල සම්බන්ධතාවය.

එසේ නොකිරීමට ඔබට හොඳ හේතුවක් නොමැති නම්, ගොනු පද්ධතියෙන් ස්ථිතික ලිපිගොනු සේවය කිරීම සැමවිටම හොඳය.

සුප්‍රසිද්ධ ටොම් කයිට් ලියා ඇත්තේ ඔවුන් (ඔරකල්) ඔරකල් දත්ත සමුදාය ගොනු සේවාදායකයක් ලෙස භාවිතා කරන අතර එය ඉතා හොඳින් ක්‍රියාත්මක වන බවයි.

ඔව්, නමුත් සටහන් කරන්න, ඔවුන් ඔරකල් ඩීබී හි නිෂ්පාදකයා වන අතර වෙනත් ඕනෑම පරිශීලකයෙකු සඳහා පිරිවැය ගැටළු තිබේ. ලිපිගොනු ගබඩා කිරීම සඳහා ඔරකල් වැනි වාණිජ ඩීබී භාවිතා කිරීම පිරිවැය අකාර්යක්ෂම වේ.

කෙසේ වෙතත්, උදාහරණයක් ලෙස PostgreSQL සමඟ, ඔබට තවත් DB නිදසුනක් ධාවනය කළ හැක්කේ බ්ලොබ් ගබඩා කිරීම සඳහා පමණි. එවිට ඔබට පූර්ණ ගනුදෙනු සහාය ඇත. නමුත් ගනුදෙනු සඳහා DB අවකාශය වැය වේ. සමගාමී ගනුදෙනු සඳහා බහු අවස්ථා අවස්ථා ගබඩා කිරීම සඳහා දත්ත සමුදායේ අවශ්‍යතාවය පවතී. PostgreSQL හි එය වඩාත් වේදනාකාරී වේ, මන්ද මෙම දත්ත ගබඩාව ගණුදෙනු සඳහා සාදන ලද බ්ලොබ් වල අනුපිටපත් ගබඩා කර ඇති බැවින් ඒවා තවදුරටත් අවශ්‍ය නොවුවද, VACUUM ක්‍රියාවලිය සිදු වන තුරු ගබඩා කර ඇත.

ගොනු පද්ධති ආචයනය සමඟ, අනෙක් අතට, යමෙකු ගොනුව වෙනස් කරන විට ඔබ ඉතා පරිස්සම් විය යුතුය, මන්ද ගනුදෙනුව පෙරළා දැමිය හැකි අතර පැරණි අනුවාදය තවදුරටත් නොපෙනෙන තෙක් ගොනුවේ පිටපත තබා ගත යුතුය.

ලිපිගොනු එකතු කිරීම සහ මකා දැමීම පමණක් වන අතර, ලිපිගොනු වලට ගනුදෙනු කිරීමේ ප්‍රවේශය ගැටළුවක් නොවන අතර, ගොනු පද්ධති ආචයනය IMHO හොඳම තේරීම වනු ඇත.

සාමාන්‍යයෙන් විශාල BLOBs වෙනම වගුවක ගබඩා කර ඔබේ ප්‍රධාන වගුවේ BLOB වෙත විදේශීය යතුරු යොමු කිරීමක් තබා ගැනීම වඩාත් සුදුසුය. ඒ ආකාරයෙන්, ඔබට තවමත් දත්ත සමුදායෙන් ගොනුව ලබා ගත හැකිය (එබැවින් ඔබට විශේෂ කේතයක් අවශ්‍ය නොවේ) සහ බාහිර ඩීබී පරායත්තතාවයන් (ඩීබී සහ ගොනු පද්ධතිය සමමුහුර්තව තබා ගැනීම ආදිය) අවට ඇති ගැටළු මඟහරවා ගත හැකිය, නමුත් ඔබට සිදුවන්නේ එම පොදු කාර්යයට පමණි ඔබ පැහැදිලිවම එම වගුවට සම්බන්ධ වන්නේ නම් (හෝ වෙනම ඇමතුමක් ගන්න). 10MB ඉතා විශාල නොවේ, බොහෝ නවීන වාණිජ දත්ත ගබඩාවලට ගැටලුවක් නොමැත. මම ගොනු පද්ධතියේ ගොනුවක් ගබඩා කිරීමට ඇති එකම හේතුව දත්ත සමුදා කලාප පළල අඩු කිරීමයි. ඔබේ දත්ත සමුදාය මෙම ලිපිගොනු විශාල ප්‍රමාණයක් මාරු කිරීමට යන්නේ නම්, එවිට ඔබට කාර්ය භාරය බෙදීමට අවශ්‍ය විය හැකි අතර යම් ආකාරයක ගොනු විස්තරයක් පමණක් ගබඩා කරන්න. වෙනත් සේවාදායකයකින් ගොනුව පූරණය කිරීමට ඔබට වෙනම ඇමතුමක් ලබා ගත හැකිය,

ඔබට මෙම ගැටලුවලට මුහුණ දිය හැකිය:

• එය කරන්නේ SELECT *විශාල blob සහිත පේළිය ඇතුළත් වන ඔබ blob අවශ්ය වුවද නැහැ (ඇත්තෙන්ම ඔබ තෝරාගන්නා නිශ්චිත කළ යුත්තේ, නමුත් සමහර විට අයදුම්පත් මේ වගේ ලියා ඇත), ඉතා දිගු වේ
• උපස්ථයක් කිරීමට බොහෝ කාලයක් ගතවනු ඇත. ඔබගේ අවශ්‍යතා මත පදනම්ව උපස්ථයේ වේලාව සඳහා ඔබේ වගු අගුළු දැමීමට ඔබට අවශ්‍ය විය හැකිය, එබැවින් ඔබට උපස්ථ කාලය අඩු මට්ටමක තබා ගැනීමට අවශ්‍ය විය හැකිය
• ප්‍රතිස්ථාපනය කිරීමට තවත් බොහෝ කාලයක් ගතවනු ඇත.
• ඔබට ඉඩක් නොමැති නම්, මෙම ගැටළුව විසඳීම සඳහා ඔබට යම් ක්‍රමයක් ගැන සිතා බැලිය යුතුය (සමහර විට මුළු දත්ත සමුදායම නව සේවාදායකයකට ගෙන යාම). ගොනු පද්ධතියේ ගොනු ගබඩා කිරීමෙන් ඔබට සෑම විටම වෙනත් දෘ hard තැටියක් සවි කර මෘදු සම්බන්ධතා සැකසිය හැකිය.
• නිදොස් කිරීම හෝ වෙනත් තොරතුරු සඳහා ගොනුවක් සොයා බැලීම එතරම් පහසු නැත. දත්ත සමුදායට ප්‍රවේශය නොමැති නමුත් විවිධ ලිපිගොනු වලින් යම් තොරතුරු අවශ්‍ය විය හැකි ස්ක්‍රිප්ට් ද මෙයට ඇතුළත් ය.

ඇත්ත වශයෙන්ම ඔබට යම් ප්‍රතිලාභද ලැබේ:

• දත්ත සහ ගොනු මෙනස් උපස්ථ කිරීම ඒවා සමමුහුර්තව පවතී
• දත්ත සමුදාය නොදැන ගොනුව ඉවත් කිරීම කළ නොහැක
• ඔබට ගොනුව තැටියෙන් කියවිය යුතු නැත, නමුත් එය එක් වර්ග ප්‍රකාශයකින් කළ හැකිය
• ඔබට දත්ත සමුදාය බාගත කළ හැකිය, ඔබේ සංවර්ධන පරිසරයට ඩම්ප් ඇතුළත් කළ හැකි අතර එහි සියලු පරායත්තතා තිබිය හැකිය

පෞද්ගලිකව මම එය කරන්නේ නැත. නමුත් ඉහත සඳහන් කළ පරිදි එය සම්පූර්ණයෙන්ම රඳා පවතින්නේ ඔබේ භාවිත අවස්ථාව සහ එවැනි දේ මත ය.

SiteCore වැනි සමහර Enterpirse අන්තර්ගත කළමනාකරණ පද්ධති, පිටු දත්ත ගබඩා කිරීම සඳහා එක් දත්ත සමුදායක් සහ ලිපිගොනු ගබඩා කිරීම සඳහා තවත් දත්ත සමුදායක් භාවිතා කරයි. ඔවුන් MS SQL සේවාදායකය භාවිතා කරයි.

ප්‍රායෝගිකව ක්‍රියාත්මක කිරීම සඳහා, ඔබ සැලකිලිමත් විය හැකි දේ මෙන්න:

බෙනිෆිට්ස්:

1. සියලුම ගොනු අන්තර්ගතයන් අනිවාර්යයෙන්ම ඔබගේ වගුව සමඟ සමමුහුර්ත කර ඇත. ඉහත අදහස් දැක්වූ පරිදි, දත්ත පද්ධතිය සමඟ සමමුහුර්තව තබා ගැනීමට ඔබට අවශ්‍ය නොවන බැවින් දත්ත උපස්ථ කිරීම මුළුමනින්ම පහසුය.
2. කේතීකරණයෙන්, ඔබට SQL තේරීමකින් කෙලින්ම ගොනු අන්තර්ගතය ලබා ගත හැකිය.
3. විමසුමකින්, ඔබට SQL ප්‍රකාශයෙන් ගොනු අන්තර්ගතය හෝ එහි ප්‍රමාණය පැහැදිලිව පෙරණය කළ හැකිය.

අවාසි:

1. දත්ත සමුදායක් සමඟ සසඳන විට අර්ථකථනමය වශයෙන් සමාන නමුත් ගොනු අන්තර්ගතයන් ගබඩා නොකරයි, ඔබේ දත්ත සමුදාය විමසීමේදී රැඩිකල් ලෙස වැඩි මතකයක් පරිභෝජනය කරයි.
2. ස්වයංක්‍රීය උපස්ථය මඟින් කාර්ය සාධන ගැටලුවක් ඇතිවිය හැකි නමුත් එතරම් නොවේ. ඔබගේ දත්ත සමුදා සේවාදායකය සෑම පැය 6 කට වරක් දේවල් උපස්ථ කරයි යැයි සිතමු. ඔබ සතුව ඇති දත්ත සමුදායන් එක් වාර්තාවකට 10-MB ගොනුවක් ගබඩා කරයි. එම තත්වය ඔබට අවශ්‍ය දේ නොවේ.

මෙය "ඇපල් ගෙඩියක් විවෘත කිරීමට මට රේසර් තලයක් භාවිතා කළ හැකිද?" ඔව් ඔබට පුළුවන්.

ඔයාට හැකිද? කාට කියන්නද ...

ඔබගේ මෙවලම් එයට ඉඩ දෙන විට හෝ පවතින එකම මෙවලම (අවම වශයෙන් එම කාලසීමාව ලබා ගැනීම සඳහා) ඔබ සිටින විට ඔබ අනුමාන කරන බව මම අනුමාන කරමි. උදාහරණයක් ලෙස මම පිලිප්ස් බෝල්ට් වර්ගයක් ඉවත් කිරීම සඳහා පැතලි ඉස්කුරුප්පු නියනක් භාවිතා කර ඇත්තෙමි ... එය නිවැරදිද? එය නිවැරදි මෙවලමද? එය නරක තේරීමක්ද?

මෙම නඩුවට පිළිතුර නම්: ඩීබී ලිපිගොනු ගබඩා කිරීම අවශ්‍ය නොවේ ... ඔබ එය කරන සෑම අවස්ථාවකම එය වැරදියි, න්‍යායාත්මකව මම පිලිප්ස් බෝල්ට් ඉවත් කිරීම සඳහා පැතලි ඉස්කුරුප්පු නියනක් භාවිතා නොකළ යුතුව තිබුණි, මන්ද එසේ කරන විට මට අහිමි විය ෆිලිප්ස් ඉස්කුරුප්පු නියන ස්ථානයෙන් ඉවත් නොවීම සහ මා වැඩ කරන ඕනෑම දෙයකට හානි කිරීම (ඔබ ඩීබී ගොනු ගබඩා විසඳුමක් ලෙස භාවිතා කරන්නේ නම් ඔබට ප්‍රතිලාභ අහිමි වනු ඇත) ... එහෙත් මම අවදානම නිසි ලෙස ගණනය කළ අතර සියල්ල හොඳින් සිදු විය.

ඔබ නිවැරදිව දේවල් කිරීමට කැමති නම්, ඔබ බොහෝ විට ඔබේ ලිපිගොනු ගබඩා කිරීම සඳහා git භාවිතා කළ යුතු අතර ඔබට අවශ්‍ය නිවැරදි ගොනු අනුවාදය වෙත යොමු කිරීම සඳහා ඔබේ ඩීබී හි අවශ්‍ය වන git හෑෂ් තබා ගත යුතුය ... මගේ මෙවලම වෙත ඇවිදීමට මට හැකි වූ ආකාරයටම කොටුව සහ පිලිප්ස් ඉස්කුරුප්පු නියනක් ලබා ගන්න ...