දැන් සෑම තැනකම පාහේ දත්ත විශාල ප්‍රමාණයක් තිබුණද, විශ්ලේෂණාත්මක දත්ත සමුදායන් තවමත් තරමක් විදේශීය ය. ඔවුන් දුර්වල ලෙස දන්නා අතර ඒවා ඵලදායී ලෙස භාවිතා කිරීමට ඊටත් වඩා නරක ය. බොහෝ දෙනෙක් MySQL හෝ PostgreSQL සමඟ "පතොක් අනුභව කිරීම" දිගටම කරගෙන යති, ඒවා වෙනත් අවස්ථා සඳහා නිර්මාණය කර ඇත, NoSQL සමඟ දුක් විඳිති, නැතහොත් වාණිජ විසඳුම් සඳහා වැඩිපුර ගෙවති. ClickHouse ක්‍රීඩාවේ නීති වෙනස් කරන අතර විශ්ලේෂණාත්මක DBMS ලෝකයට ඇතුළු වීමේ සීමාව සැලකිය යුතු ලෙස අඩු කරයි.
BackEnd Conf 2018 වෙතින් වාර්තාව සහ එය කථානායකවරයාගේ අවසරය ඇතිව ප්‍රකාශයට පත් කෙරේ.
මම කවුද සහ මම ClickHouse ගැන කතා කරන්නේ ඇයි? මම ClickHouse භාවිත කරන LifeStreet හි සංවර්ධන අධ්‍යක්ෂවරයෙක්. ඒ වගේම මම Altinity හි නිර්මාතෘ. එය ClickHouse ප්‍රවර්ධනය කරන Yandex හවුල්කරුවෙක් වන අතර Yandex ClickHouse වඩාත් සාර්ථක කර ගැනීමට උදවු කරයි. ClickHouse පිළිබඳ දැනුම බෙදා ගැනීමට ද සූදානම්.
මම පෙටියා සයිට්සෙව්ගේ සහෝදරයා නොවේ. මේ ගැන නිතර මගෙන් අසයි. නෑ අපි සහෝදරයෝ නෙවෙයි.
ClickHouse බව "හැමෝම දන්නවා":
- ඉතා වේගවත්,
- ඉතා සුවපහසුයි
- Yandex හි භාවිතා වේ.
කුමන සමාගම්වල සහ එය භාවිතා කරන්නේ කෙසේද යන්න ටිකක් අඩුවෙන් දන්නා කරුණකි.
Yandex හැර ClickHouse භාවිතා කරන්නේ ඇයි, කොහේද සහ කෙසේද යන්න මම ඔබට කියමි.
විවිධ සමාගම්වල ClickHouse ආධාරයෙන් නිශ්චිත කාර්යයන් විසඳන්නේ කෙසේද, ඔබේ කාර්යයන් සඳහා ඔබට භාවිතා කළ හැකි ClickHouse මෙවලම් සහ විවිධ සමාගම්වල ඒවා භාවිතා කළ ආකාරය මම ඔබට කියමි.
මම විවිධ කෝණවලින් ClickHouse පෙන්වන උදාහරණ තුනක් ගත්තා. මම හිතන්නේ එය රසවත් වනු ඇත.
පළමු ප්රශ්නය වන්නේ: "අපට ClickHouse අවශ්ය වන්නේ ඇයි?". එය තරමක් පැහැදිලි ප්‍රශ්නයක් බව පෙනේ, නමුත් එයට පිළිතුරු එකකට වඩා තිබේ.
- පළමු පිළිතුර කාර්ය සාධනය සඳහා ය. ClickHouse ඉතා වේගවත් වේ. ClickHouse මත Analytics ද ඉතා වේගවත් වේ. වෙනත් දෙයක් ඉතා මන්දගාමී හෝ ඉතා නරක නම් එය බොහෝ විට භාවිතා කළ හැකිය.
- දෙවන පිළිතුර පිරිවැයයි. සහ පළමුවෙන්ම, පරිමාණය කිරීමේ පිරිවැය. උදාහරණයක් ලෙස, Vertica යනු ඉතා විශිෂ්ට දත්ත සමුදායකි. ටෙරාබයිට් විශාල ප්‍රමාණයක් දත්ත නොමැති නම් එය ඉතා හොඳින් ක්රියා කරයි. නමුත් ටෙරාබයිට් හෝ පෙටාබයිට් සිය ගණනක් සම්බන්ධයෙන් ගත් කල, බලපත්‍රයක සහ ආධාරකයේ පිරිවැය තරමක් සැලකිය යුතු ප්‍රමාණයකට යයි. ඒ වගේම මිල අධිකයි. සහ ClickHouse නොමිලේ.
- තුන්වන පිළිතුර වන්නේ මෙහෙයුම් පිරිවැයයි. මෙය තරමක් වෙනස් ප්රවේශයකි. RedShift යනු විශිෂ්ට ප්රතිසමයකි. RedShift මත, ඔබට ඉතා ඉක්මනින් තීරණයක් ගත හැකිය. එය හොඳින් ක්රියාත්මක වනු ඇත, නමුත් ඒ සමඟම, සෑම පැයක්ම, සෑම දිනකම සහ සෑම මසකම, ඔබ ඇමේසන්ට බෙහෙවින් ගෙවනු ඇත, මන්ද මෙය සැලකිය යුතු මිල අධික සේවාවක් වන බැවිනි. Google BigQuery ද. යමෙකු එය භාවිතා කළේ නම්, එහිදී ඔබට ඉල්ලීම් කිහිපයක් ක්රියාත්මක කර හදිසියේම ඩොලර් සිය ගණනකට බිල්පතක් ලබා ගත හැකි බව ඔහු දනී.
ClickHouse හි මෙම ගැටළු නොමැත.
ClickHouse දැන් භාවිතා කරන්නේ කොහේද? Yandex වලට අමතරව, ClickHouse විවිධ ව්යාපාර සහ සමාගම් සමූහයක භාවිතා වේ.
- මුලින්ම කියන්න ඕනේ මේක web application analytics, ඒ කියන්නේ මේක Yandex වලින් ආපු use case එකක්.
- බොහෝ AdTech සමාගම් ClickHouse භාවිතා කරයි.
- විවිධ ප්‍රභවයන්ගෙන් ගනුදෙනු ලොග් විශ්ලේෂණය කිරීමට අවශ්ය බොහෝ සමාගම්.
- ආරක්ෂක ලොග් නිරීක්ෂණය කිරීමට සමාගම් කිහිපයක් ClickHouse භාවිතා කරයි. ඔවුන් ඒවා ClickHouse වෙත උඩුගත කර, වාර්තා සාදා, ඔවුන්ට අවශ්ය ප්‍රතිඵල ලබා ගනී.
- සමාගම් එය මූල්‍ය විශ්ලේෂණයේ දී භාවිතා කිරීමට පටන් ගෙන ඇත, එනම් ක්‍රමයෙන් විශාල ව්යාපාර ද ClickHouse වෙත ළඟා වෙමින් තිබේ.
- වලාකුළු. කවුරුහරි ClickHouse අනුගමනය කරන්නේ නම්, ඔවුන් මෙම සමාගමේ නම අසා ඇති. මෙය ප්‍රජාවෙන් අත්‍යවශ්‍ය දායකයන්ගෙන් එකකි. තවද ඔවුන් සතුව ඉතා බරපතල ClickHouse ස්ථාපනයක් ඇත. උදාහරණයක් ලෙස, ඔවුන් ClickHouse සඳහා Kafka එන්ජිම සෑදුවා.
- විදුලි සංදේශ සමාගම් භාවිතා කිරීමට පටන් ගත්තේය. සමාගම් කිහිපයක් ClickHouse භාවිතා කරන්නේ සංකල්පය මත හෝ දැනටමත් නිෂ්පාදනයේ ඇති සාක්ෂි ලෙස ය.
- නිෂ්පාදන ක්‍රියාවලීන් නිරීක්ෂණය කිරීමට එක් සමාගමක් ClickHouse භාවිතා කරයි. ඔවුන් ක්ෂුද්‍ර පරිපථ පරීක්ෂා කරයි, පරාමිති පොකුරක් ලියන්න, ලක්ෂණ 2 ක් පමණ ඇත. ඊට පස්සේ ක්‍රීඩාව හොඳද නරකද කියලා විශ්ලේෂණය කරනවා.
- බ්ලොක්චේන් විශ්ලේෂණ. Bloxy.info වැනි රුසියානු සමාගමක් තිබේ. මෙය Ethereum ජාලයේ විශ්ලේෂණයකි. ඔවුන් මෙය ClickHouse එකෙත් කළා.
ඒ වගේම ප්‍රමාණය වැදගත් නැහැ. එක් කුඩා සේවාදායකයක් භාවිතා කරන බොහෝ සමාගම් තිබේ. ඒ වගේම ඔහු ඔවුන්ට ඔවුන්ගේ ප්රශ්න විසඳගන්න ඉඩ දෙනවා. ඊටත් වඩා සමාගම් බොහෝ සේවාදායක හෝ දුසිම් සේවාදායක විශාල පොකුරු භාවිතා කරයි.
ඔබ වාර්තා දෙස බැලුවහොත්, එසේ නම්:
- Yandex: 500+ සේවාදායකයන්, ඔවුන් එහි දිනකට වාර්තා බිලියන 25 ක් ගබඩා කරයි.
- LifeStreet: සේවාදායක 60ක්, දිනකට වාර්තා බිලියන 75ක් පමණ. Yandex වලට වඩා අඩු සේවාදායක, වැඩි වාර්තා ඇත.
- CloudFlare: සේවාදායකයන් 36 ක්, ඔවුන් දිනකට වාර්තා බිලියන 200 ක් ඉතිරි කරයි. ඔවුන්ට ඊටත් වඩා අඩු සේවාදායකයක් ඇති අතර ඊටත් වඩා දත්ත ගබඩා කරයි.
- බ්ලූම්බර්ග්: සේවාදායක 102ක්, දිනකට ඇතුළත් කිරීම් ට්‍රිලියනයක් පමණ. වාර්තා දරන්නා.
භූගෝලීය වශයෙන්, මෙය ද බොහෝ ය. මෙහි ඇති මෙම සිතියම ලෝකයේ ClickHouse භාවිතා කරන ස්ථාන වල තාප සිතියමක් පෙන්වයි. රුසියාව, චීනය, ඇමරිකාව මෙහි පැහැදිලිව කැපී පෙනේ. යුරෝපීය රටවල් කිහිපයක් තිබේ. ඒ වගේම පොකුරු 4ක් තියෙනවා.
මෙය සංසන්දනාත්මක විශ්ලේෂණයකි, නිරපේක්ෂ සංඛ්යා සොයා බැලීම අවශ්ය නොවේ. මෙය Altinity වෙබ් අඩවියේ ඉංග්‍රීසි භාෂා ද්‍රව්‍ය කියවන අමුත්තන්ගේ විශ්ලේෂණයකි, මන්ද එහි රුසියානු කතා කරන අය නොමැති බැවිනි. රුසියාව, යුක්රේනය, බෙලාරුස්, එනම් ප්‍රජාවේ රුසියානු භාෂාව කතා කරන කොටස, මොවුන් බොහෝ පරිශීලකයින් වේ. ඉන්පසුව එක්සත් ජනපදය සහ කැනඩාව පැමිණේ. චීනය බොහෝ දුරට අල්ලාගෙන සිටී. මාස හයකට පෙර එහි චීනයක් නොතිබූ තරම්ය, දැන් චීනය දැනටමත් යුරෝපය අභිබවා ගොස් අඛණ්ඩව වර්ධනය වෙමින් පවතී. පැරණි යුරෝපය ද බොහෝ පසුපසින් නොසිටින අතර, ClickHouse භාවිතයේ ප්‍රමුඛයා වන්නේ, අමුතුවෙන් ප්‍රංශයයි.
ඇයි මම මේ සියල්ල කියන්නේ? ClickHouse විශාල දත්ත විශ්ලේෂණය සඳහා සම්මත විසඳුමක් බවට පත්වෙමින් පවතින බව පෙන්වීමට සහ දැනටමත් බොහෝ ස්ථානවල භාවිතා වේ. ඔබ එය භාවිතා කරන්නේ නම්, ඔබ නිවැරදි ප්රවණතාවයේ සිටී. ඔබ තවමත් එය භාවිතා නොකරන්නේ නම්, ඔබ තනිව සිටිනු ඇති අතර කිසිවෙකු ඔබට උදව් නොකරනු ඇතැයි ඔබට බිය විය නොහැක, මන්ද බොහෝ දෙනෙක් දැනටමත් මෙය කරමින් සිටිති.
මේවා සමාගම් කිහිපයක සැබෑ ClickHouse භාවිතය සඳහා උදාහරණ වේ.
- පළමු උදාහරණය වන්නේ දැන්වීම් ජාලයකි: Vertica සිට ClickHouse වෙත සංක්‍රමණය වීම. තවද Vertica වෙතින් සංක්‍රමණය වූ හෝ සංක්‍රාන්ති ක්‍රියාවලියේ යෙදී සිටින සමාගම් කිහිපයක් මම දනිමි.
- දෙවන උදාහරණය ClickHouse හි ගනුදෙනු ගබඩා කිරීමයි. මෙය ප්‍රති රටා මත ගොඩනැගුණු උදාහරණයකි. සංවර්ධකයින්ගේ උපදෙස් මත ClickHouse හි නොකළ යුතු සියල්ල මෙහි සිදු කෙරේ. එමෙන්ම එය ඉතා ඵලදායී ලෙස සිදු කර ඇති අතර එය ක්රියාත්මක වේ. තවද එය සාමාන්‍ය ගනුදෙනු විසඳුමට වඩා ඉතා හොඳින් ක්රියා කරයි.
- තුන්වන උදාහරණය ClickHouse මත බෙදා හරින ලද පරිගණනයයි. ClickHouse Hadoop පරිසර පද්ධතියට ඒකාබද්ධ කරන්නේ කෙසේද යන්න පිළිබඳව ප්‍රශ්නයක් විය. ඉතා සුළු නොවන කාර්යයක් ගණනය කිරීම සඳහා සමාගමක් ClickHouse හි ඇති සිතියම අඩු කිරීමේ කන්ටේනරය, දත්ත ස්ථානගත කිරීම ආදිය නිරීක්ෂණය කිරීම වැනි දෙයක් කළ ආකාරය පිළිබඳ උදාහරණයක් මම පෙන්වන්නම්.
- LifeStreet යනු දැන්වීම් ජාලයක් සමඟ එන සියලුම තාක්ෂණයන් ඇති Ad Tech සමාගමකි.
- ඇය දැන්වීම් ප්‍රශස්තකරණය, ක්‍රමලේඛන ලංසු තැබීමේ නිරතව සිටී.
- දත්ත ගොඩක්: දිනකට සිදුවීම් බිලියන 10 ක් පමණ. ඒ අතරම, එහි සිදුවීම් උප සිදුවීම් කිහිපයකට බෙදිය හැකිය.
- මෙම දත්තවල බොහෝ සේවාදායකයින් සිටින අතර, මේවා මිනිසුන් පමණක් නොවේ, තවත් බොහෝ දේ - මේවා වැඩසටහන්ගත ලංසු තැබීමේ නියැලී සිටින විවිධ ඇල්ගොරිතම වේ.
සමාගම දිගු හා කටු සහිත මාවතකට පැමිණ ඇත. මම ඒ ගැන HighLoad එකේ කතා කළා. පළමුව, LifeStreet MySQL (Oracle හි කෙටි නැවතුමක් සහිත) සිට Vertica වෙත මාරු විය. ඒ වගේම ඒ ගැන කතාවක් හොයාගන්න පුළුවන්.
සෑම දෙයක්ම ඉතා හොඳයි, නමුත් දත්ත වර්ධනය වන අතර Vertica මිල අධික බව ඉක්මනින් පැහැදිලි විය. ඒ නිසා විවිධ විකල්ප සෙව්වා. ඒවායින් සමහරක් මෙහි ලැයිස්තුගත කර ඇත. ඇත්ත වශයෙන්ම, අපි 13 සිට 16 වන වසර දක්වා වෙළඳපොලේ ලබා ගත හැකි සහ ක්‍රියාකාරීත්වය අනුව ආසන්න වශයෙන් සුදුසු වූ සියලුම දත්ත සමුදායන් පිළිබඳ සංකල්පය පිළිබඳ සාක්ෂි හෝ සමහර විට කාර්ය සාධනය පරීක්ෂා කළෙමු. ඒ වගේම මම සමහර ඒවා ගැන HighLoad එකේත් කතා කළා.
කර්තව්‍යය වූයේ දත්ත වර්ධනය වූ නිසා මුලින්ම Vertica සිට සංක්‍රමණය වීමයි. තවද ඔවුන් වසර ගණනාවක් පුරා ඝාතීය ලෙස වර්ධනය විය. ඉන්පසු ඔවුන් රාක්කයට ගිය නමුත් කෙසේ වෙතත්. තවද මෙම වර්ධනය පුරෝකථනය කිරීම, යම් ආකාරයක විශ්ලේෂණ සිදු කළ යුතු දත්ත ප්‍රමාණය සඳහා ව්‍යාපාරික අවශ්‍යතා, පෙටාබයිට් ඉක්මනින් සාකච්ඡා කෙරෙනු ඇති බව පැහැදිලි විය. පෙටාබයිට් සඳහා ගෙවීම දැනටමත් ඉතා මිල අධිකයි, එබැවින් අපි යා යුතු ස්ථානයට විකල්පයක් සොයමින් සිටියෙමු.
කොහේ යන්නද? දිගු කලක් යා යුත්තේ කොතැනටද යන්න පැහැදිලි නැත, මන්ද එක් අතකින් වාණිජ දත්ත සමුදායන් ඇති බැවින් ඒවා හොඳින් ක්රියාත්මක වන බව පෙනේ. සමහරු Vertica මෙන් ම පාහේ වැඩ කරති, සමහරක් නරක ය. නමුත් ඒවා සියල්ලම මිල අධිකයි, වඩා ලාභදායී හා වඩා හොඳ කිසිවක් සොයාගත නොහැකි විය.
අනෙක් අතට, විවෘත මූලාශ්‍ර විසඳුම් ඇත, ඒවා බොහෝ නොවේ, එනම් විශ්ලේෂණ සඳහා, ඒවා ඇඟිලි මත ගණන් කළ හැකිය. තවද ඒවා නොමිලේ හෝ ලාභදායී වේ, නමුත් මන්දගාමී වේ. තවද ඔවුන් බොහෝ විට අවශ්ය හා ප්රයෝජනවත් ක්රියාකාරිත්වයක් නොමැත.
තවද වාණිජ දත්ත සමුදායේ ඇති හොඳ සහ විවෘත මූලාශ්‍රයේ ඇති සියලුම නොමිලේ ඒකාබද්ධ කිරීමට කිසිවක් නොතිබුණි.
අනපේක්ෂිත ලෙස, Yandex තොප්පියකින් ඉන්ද්‍රජාලිකයෙකු මෙන්, හාවෙකු මෙන් ClickHouse එළියට ගන්නා තෙක් කිසිවක් නොතිබුණි. එය අනපේක්ෂිත තීරණයක් වූ අතර, ඔවුන් තවමත් ප්රශ්නය අසයි: "ඇයි?", කෙසේ වෙතත්.
2016 ගිම්හානයේදී වහාම අපි ClickHouse යනු කුමක්දැයි බැලීමට පටන් ගත්තෙමු. සමහර විට එය Vertica වඩා වේගවත් විය හැකි බව පෙනී ගියේය. අපි විවිධ ඉල්ලීම් මත විවිධ අවස්ථා පරීක්ෂා කළා. සහ විමසුම එක් වගුවක් පමණක් භාවිතා කළේ නම්, එනම්, කිසිදු සම්බන්ධයක් නොමැතිව (එකතු වීම), එවිට ClickHouse Vertica මෙන් දෙගුණයක් වේගවත් විය.
මම එතරම් කම්මැලි නොවූ අතර පසුගිය දිනක Yandex පරීක්ෂණ දෙස බැලුවෙමි. එහිද එය එසේමය: ClickHouse Vertica මෙන් දෙගුණයක් වේගවත් බැවින් ඔවුන් බොහෝ විට ඒ ගැන කතා කරයි.
නමුත් විමසුම්වල සම්බන්ධවීම් තිබේ නම්, සෑම දෙයක්ම ඉතා පැහැදිලි ලෙස සිදු නොවේ. තවද ClickHouse Vertica මෙන් දෙගුණයක් මන්දගාමී විය හැක. ඔබ ඉල්ලීම තරමක් නිවැරදි කර එය නැවත ලියන්නේ නම්, ඒවා ආසන්න වශයෙන් සමාන වේ. නරක නැහැ. සහ නොමිලේ.
පරීක්ෂණ ප්‍රතිඵල ලැබී, විවිධ කෝණවලින් එය බලා, LifeStreet ClickHouse වෙත ගියේය.
මේ 16 වැනි වසර, මම ඔබට මතක් කරමි. එය මීයන් ගැන විහිළුවක් වැනිය, ඔවුන් අඬන හා තමන්ටම ඇනගත් නමුත් දිගටම පතොක් අනුභව කළහ. තවද මෙය විස්තරාත්මකව විස්තර කරන ලදී, මේ ගැන වීඩියෝවක් ඇත, ආදිය.
ඒ නිසා මම ඒ ගැන විස්තරාත්මකව කතා නොකර ප්‍රතිඵල සහ එදා කතා නොකළ රසවත් කරුණු කිහිපයක් ගැන පමණක් කතා කරන්නම්.
ප්‍රතිඵල මෙසේය.
- සාර්ථක සංක්‍රමණය සහ වසරකට වැඩි කාලයක් පද්ධතිය දැනටමත් නිෂ්පාදනයේ වැඩ කරමින් සිටී.
- ඵලදායිතාව සහ නම්‍යශීලී බව වැඩි වී ඇත. අපට දිනකට ගබඩා කර කෙටි කාලයක් සඳහා ගත හැකි වාර්තා බිලියන 10 න්, LifeStreet දැන් දිනකට වාර්තා බිලියන 75 ක් ගබඩා කරන අතර මාස 3 ක් හෝ ඊට වැඩි කාලයක් මෙය කළ හැකිය. ඔබ උපරිමයෙන් ගණන් කරන්නේ නම්, මෙය තත්පරයට සිදුවීම් මිලියනයක් දක්වා වේ. දිනකට SQL විමසුම් මිලියනයකට වඩා වැඩි ප්‍රමාණයක් විවිධ රොබෝවරුන්ගෙන් මෙම පද්ධතියට පැමිණේ.
- Vertica සඳහා වඩා ClickHouse සඳහා වැඩි සේවාදායකයන් භාවිතා කර ඇතත්, Vertica හි තරමක් මිල අධික SAS තැටි භාවිතා කර ඇති නිසා ඒවා දෘඩාංග මතද ඉතිරි විය. ClickHouse SATA භාවිත කළා. සහ ඇයි? මොකද Vertica වල insert එක synchronous. සමමුහුර්තකරණය සඳහා තැටි ඕනෑවට වඩා මන්දගාමී නොවීම සහ ජාලය ඕනෑවට වඩා මන්දගාමී නොවීම, එනම් තරමක් මිල අධික මෙහෙයුමක් අවශ්ය වේ. ක්ලික්හවුස් හි ඇතුළු කිරීම අසමමිතික වේ. එපමණක් නොව, ඔබට සෑම විටම දේශීයව සෑම දෙයක්ම ලිවිය හැකිය, මේ සඳහා අමතර වියදම් නොමැත, එබැවින් මන්දගාමී ධාවකවල පවා Vertika වලට වඩා වේගයෙන් ක්ලික්හවුස් වෙත දත්ත ඇතුළත් කළ හැකිය. ඒ වගේම කියවීමත් ඒ හා සමානයි. SATA මත කියවීම, ඔවුන් RAID හි සිටී නම්, මේ සියල්ල ප්රමාණවත් තරම් වේගවත් වේ.
- බලපත්‍රයෙන් සීමා නොවේ, එනම් සේවාදායක 3ක පෙටාබයිට් 60ක දත්ත (සේවාදායක 20ක් එක් අනුරුවකි) සහ කරුණු සහ එකතු කිරීම්වලින් වාර්තා ට්‍රිලියන 6ක්. Vertica හි මෙවැනි කිසිවක් දැරිය නොහැකි විය.
මම දැන් මෙම උදාහරණයේ ප්‍රායෝගික දේවල් වෙත හැරෙමි.
- පළමුවැන්න කාර්යක්ෂම යෝජනා ක්රමයකි. බොහෝ දේ යෝජනා ක්රමය මත රඳා පවතී.
- දෙවැන්න කාර්යක්ෂම SQL උත්පාදනයයි.
සාමාන්‍ය OLAP විමසුමක් තෝරා ගැනීමකි. සමහර තීරු සමූහ වශයෙන්, සමහර තීරු සමූහ ශ්‍රිතවලට යයි. ඝනකයක් පෙත්තක් ලෙස නිරූපණය කළ හැකි තැනක් තිබේ. විසින් මුළු කණ්ඩායමම ප්රක්ෂේපණයක් ලෙස සැලකිය හැකිය. එය බහුවිචල්‍ය දත්ත විශ්ලේෂණය ලෙස හඳුන්වන්නේ එබැවිනි.
බොහෝ විට මෙය තරු යෝජනා ක්‍රමයක ස්වරූපයෙන් ආදර්ශනය කර ඇත, මෙම කරුණෙහි කේන්ද්‍රීය කරුණක් සහ ලක්ෂණ පැති දිගේ, කිරණ දිගේ ඇති විට.
තවද භෞතික සැලසුම් අනුව, මේසය මත එය ගැලපෙන ආකාරය, ඔවුන් සාමාන්යයෙන් සාමාන්යකරණය කළ නිරූපණයක් සිදු කරයි. ඔබට denormalize කළ හැක, නමුත් එය තැටියේ මිල අධික වන අතර විමසුම් මත ඉතා කාර්යක්ෂම නොවේ. එමනිසා, ඔවුන් සාමාන්යයෙන් සාමාන්‍ය නිරූපණයක්, එනම් කරුණු වගුවක් සහ බොහෝ මාන වගු සාදයි.
හැබැයි ClickHouse වල ඒක හරියට වැඩ කරන්නේ නෑ. හේතු දෙකක් තිබේ:
- පලවෙනි එක මොකද ClickHouse එකේ ගොඩක් හොද ජොයින්ස් නෑ, ඒ කියන්නේ Joins තියෙනවා, ඒත් ඒවා නරකයි. නරක අතර.
- දෙවැන්න නම් වගු යාවත්කාලීන නොවීමයි. සාමාන්යයෙන් තරු-පරිපථය වටා ඇති මෙම තහඩු තුළ, යමක් වෙනස් කළ යුතුය. උදාහරණයක් ලෙස, පාරිභෝගික නම, සමාගමේ නම, ආදිය. අනික ඒක හරියන්නෙ නෑ.
ඒවගේම ClickHouse එකේ මේකෙන් ගැලවෙන්න විදියක් තියෙනවා. දෙකක් පවා:
- පළමුවැන්න ශබ්දකෝෂ භාවිතයයි. බාහිර ශබ්දකෝෂ යනු 99% ට තරු-ක්‍රමලේඛනය, යාවත්කාලීන කිරීම් සහ යනාදිය සමඟ ගැටළුව විසඳීමට උපකාරී වේ.
- දෙවැන්න නම් අරා භාවිතා කිරීමයි. සාමාන්යකරණය සමඟ සම්බන්ධවීම් සහ ගැටළු ඉවත් කිරීමට අරා ද උපකාරී වේ.
- සම්බන්ධ වීමට අවශ්ය නැත.
- වැඩිදියුණු කළ හැකි. 2018 මාර්තු මාසයේ සිට, ශබ්ද කෝෂ අර්ධ වශයෙන් යාවත්කාලීන කිරීමට ලේඛනගත නොකළ අවස්ථාවක් (ඔබට මෙය ලේඛනගතව සොයාගත නොහැක) එනම් වෙනස් වී ඇති ප්‍රවේශයන් දර්ශනය වී ඇත. ප්රායෝගිකව, එය මේසයක් වැනි ය.
- සෑම විටම මතකයේ ඇති බැවින් එය තැටියේ ඇති වගුවකට වඩා වේගයෙන් ශබ්ද කෝෂයක් සමඟ සම්බන්ධ වන අතර එය හැඹිලියේ ඇති බව තවමත් සත්‍යයක් නොවේ, බොහෝ විට එසේ නොවේ.
- ඔබටත් සම්බන්ධ වීමට අවශ්ය නැත.
- මෙය සංයුක්ත 1 සිට බොහෝ නිරූපණයකි.
- අනික මගේ මතය අනුව arrays හදන්නේ geeks වලට. මේවා ලැම්ඩා ශ්‍රිත සහ යනාදියයි.
මෙය රතු වචන සඳහා නොවේ. මෙය ඉතා සරල හා අලංකාර ආකාරයෙන් බොහෝ දේ කිරීමට ඉඩ සලසන ඉතා බලවත් ක්රියාකාරිත්වයකි.
අරා විසඳීමට උපකාර වන සාමාන්‍ය උදාහරණ. මෙම උදාහරණ ප්රමාණවත් තරම් සරල සහ පැහැදිලි ය:
- ටැග් මගින් සොයන්න. ඔබට එහි හැෂ් ටැග් තිබේ නම් සහ හැෂ් ටැග් මගින් පළ කිරීම් කිහිපයක් සොයා ගැනීමට අවශ්ය නම්.
- යතුරු අගය යුගල අනුව සොයන්න. අගයක් සහිත සමහර ගුණාංග ද ඇත.
- ඔබට වෙනත් දෙයකට පරිවර්තනය කිරීමට අවශ්ය යතුරු ලැයිස්තු ගබඩා කිරීම.
මෙම සියලු කාර්යයන් අරා නොමැතිව විසඳා ගත හැකිය. ටැග් යම් පේළියකට දමා සාමාන්‍ය ප්‍රකාශනයකින් හෝ වෙනම වගුවකින් තෝරා ගත හැකිය, නමුත් පසුව ඔබට සම්බන්ධ කිරීම් කළ යුතුය.
ක්ලික්හවුස් හි, ඔබට කිසිවක් කිරීමට අවශ්ය නැත, එය හැෂ් ටැග් සඳහා තන්තු අරාව විස්තර කිරීමට හෝ ප්‍රධාන අගය පද්ධති සඳහා කැදලි ව්‍යුහයක් සෑදීමට ප්රමාණවත් වේ.
කැදලි ව්‍යුහය හොඳම නම නොවිය හැක. මේවා නමේ පොදු කොටසක් සහ ඊට අදාළ සමහර ලක්ෂණ ඇති අරා දෙකකි.
ඒවගේම tag එකෙන් search කරන්න හරිම ලේසියි. කාර්යයක් කරන්න has, අරාවෙහි මූලද්‍රව්‍යයක් තිබේදැයි පරීක්ෂා කරයි. හැමෝම, අපේ සම්මන්ත්‍රණයට අදාළ සියලුම ඇතුළත් කිරීම් සොයා ගත්තා.
Subid මගින් සෙවීම ටිකක් සංකීර්ණයි. අපි මුලින්ම යතුරේ දර්ශකය සොයා ගත යුතු අතර, පසුව මෙම දර්ශකය සමඟ මූලද්රව්යය රැගෙන මෙම අගය අපට අවශ්ය වන්නේ දැයි පරීක්ෂා කරන්න. කෙසේ වෙතත්, එය ඉතා සරල හා සංයුක්ත වේ.
ඔබ ඒ සියල්ල එක පේළියක තබා ගන්නේ නම්, ඔබ ලිවීමට කැමති නිත්‍ය ප්‍රකාශනය, පළමුව, එය අවුල් සහගත වනු ඇත. සහ, දෙවනුව, එය අරා දෙකකට වඩා වැඩි කාලයක් වැඩ කළේය.
තවත් උදාහරණයක්. ඔබට හැඳුනුම්පත ගබඩා කරන අරාවක් තිබේ. තවද ඔබට ඒවා නම් වලට පරිවර්තනය කළ හැකිය. කාර්යය arrayMap. මෙය සාමාන්‍ය ලැම්ඩා ශ්‍රිතයකි. ඔබ එහි lambda ප්‍රකාශන සමත් වේ. තවද ඇය එක් එක් හැඳුනුම්පත සඳහා නමේ වටිනාකම ශබ්දකෝෂයෙන් ඉවත් කරයි.
සෙවීම එකම ආකාරයකින් කළ හැකිය. මූලද්‍රව්‍ය ගැළපෙන දේ පරීක්ෂා කරන පුරෝකථන ශ්‍රිතයක් සම්මත වේ.
මෙම දේවල් පරිපථය බෙහෙවින් සරල කරන අතර ගැටළු රාශියක් විසඳයි.
නමුත් අප මුහුණ දෙන මීළඟ ගැටලුව, සහ මම සඳහන් කිරීමට කැමති, කාර්යක්ෂම විමසුම් ය.
- ClickHouse හට විමසුම් සැලසුම්කරුවෙකු නොමැත. කොහෙත්ම නැහැ.
- එසේ වුවද, සංකීර්ණ විමසුම් තවමත් සැලසුම් කළ යුතුය. කුමන අවස්ථා වලදීද?
- විමසුමේ බහුවිධ සම්බන්ධ කිරීම් තිබේ නම්, ඔබ ඒවා උප තේරීම් වලින් ඔතා ඇත. තවද ඒවා ක්රියාත්මක කරන පිළිවෙල වැදගත් වේ.
- සහ දෙවන - ඉල්ලීම බෙදා හරිනු ලැබුවහොත්. මක්නිසාද යත් බෙදා හරින ලද විමසුමකදී, ක්රියාත්මක වන්නේ අභ්‍යන්තරම උප තේරීම පමණක් බෙදා හරින අතර, අනෙක් සියල්ල ඔබ සම්බන්ධ කර එහි ක්රියාත්මක කළ එක් සේවාදායකයකට යවන බැවිනි. එබැවින්, ඔබ බොහෝ සම්බන්ධ කිරීම් (එකතු වීම) සමඟ විමසුම් බෙදා හැර තිබේ නම්, ඔබ ඇණවුම තෝරා ගත යුතුය.
සරල අවස්ථා වලදී පවා, සමහර විට උපලේඛකයාගේ කාර්යය කිරීමට සහ විමසුම් ටිකක් නැවත ලිවීමටද අවශ්ය වේ.
මෙන්න උදාහරණයක්. වම් පසින් ඉහළම රටවල් 5 පෙන්වන විමසුමකි. ඒ වගේම මගේ මතය අනුව තත්පර 2,5ක් ගත වෙනවා. සහ දකුණු පැත්තේ, එකම විමසුම, නමුත් තරමක් නැවත ලියා ඇත. තන්තු අනුව කණ්ඩායම් කිරීම වෙනුවට, අපි යතුර (int) අනුව කණ්ඩායම් කිරීමට පටන් ගත්තෙමු. ඒ වගේම එය වේගවත්. ඊට පස්සේ අපි ප්රතිඵලය සඳහා ශබ්දකෝෂයක් සම්බන්ධ කළා. තත්පර 2,5 වෙනුවට, ඉල්ලීම තත්පර 1,5 ක් ගතවේ. මේක හොඳයි.
පෙරහන් නැවත ලිවීම සමඟ සමාන උදාහරණයක්. මෙන්න රුසියාවෙන් ඉල්ලීමක්. එය තත්පර 5 ක් ධාවනය වේ. අපි එය නැවත ලියන්නේ නම්, අපි නැවත සංසන්දනය කරන්නේ නූලක් නොව, රුසියාවට අදාළ යතුරු කට්ටලයක් සමඟ සංඛ්යා, එවිට එය වඩා වේගවත් වනු ඇත.
එවැනි උපක්රම බොහොමයක් තිබේ. තවද ඔවුන් දැනටමත් වේගයෙන් ධාවනය වන බව ඔබ සිතන විමසුම් සැලකිය යුතු ලෙස වේගවත් කිරීමට ඉඩ සලසයි, නැතහොත්, අනෙක් අතට, සෙමින් ධාවනය වේ. ඒවා ඊටත් වඩා වේගයෙන් සෑදිය හැකිය.
- බෙදාහැරීමේ මාදිලියේ උපරිම වැඩ.
- මම ints මගින් කළාක් මෙන්, අවම වර්ග අනුව වර්ග කිරීම.
- කිසියම් සම්බන්ධවීම් (එකතු වීම), ශබ්ද කෝෂ තිබේ නම්, ඒවා අවසාන විසඳුම ලෙස කිරීම වඩා හොඳය, ඔබ දැනටමත් අවම වශයෙන් අර්ධ වශයෙන් කණ්ඩායම් වශයෙන් දත්ත ඇති විට, සම්බන්ධ වීමේ මෙහෙයුම හෝ ශබ්ද කෝෂ ඇමතුම අඩු වාර ගණනක් කැඳවනු ලබන අතර එය වේගවත් වනු ඇත. .
- පෙරහන් ප්රතිස්ථාපනය කිරීම.
මම ප්‍රදර්ශනය කර ඇති ඒවා පමණක් නොව වෙනත් ශිල්පීය ක්‍රම තිබේ. තවද ඒවා සියල්ලම සමහර විට විමසුම් ක්රියාත්මක කිරීම සැලකිය යුතු ලෙස වේගවත් කළ හැකිය.
අපි ඊළඟ උදාහරණයට යමු. එක්සත් ජනපදයෙන් X සමාගම. ඇය මොනවද කරන්නේ?
කාර්යයක් විය:
- වෙළඳ ප්‍රචාරණ ගනුදෙනු නොබැඳි සම්බන්ධ කිරීම.
- විවිධ බන්ධන ආකෘති ආකෘති නිර්මාණය.
දර්ශනය කුමක්ද?
සාමාන්‍ය අමුත්තෙකු වෙබ් අඩවියට පැමිණේ, උදාහරණයක් ලෙස, විවිධ දැන්වීම් වලින් මසකට 20 වතාවක්, නැතහොත් සමහර විට දැන්වීම් නොමැතිව පැමිණේ, ඔහුට මෙම වෙබ් අඩවිය මතක ඇති බැවිනි. සමහර නිෂ්පාදන දෙස බලයි, ඒවා කූඩයට දමා, කූඩයෙන් පිටතට ගෙන යයි. තවද, අවසානයේදී, යමක් මිලදී ගනී.
සාධාරණ ප්රශ්න: "අවශ්ය නම්, ප්රචාරණය සඳහා ගෙවිය යුත්තේ කවුද?" සහ "ඇත්නම් ඔහුට බලපෑ ප්රචාරණය කුමක්ද?". එනම්, ඔහු මිලදී ගත්තේ ඇයි සහ මෙම පුද්ගලයා වැනි පුද්ගලයින් ද මිලදී ගන්නේ කෙසේද?
මෙම ගැටළුව විසඳීම සඳහා, ඔබ වෙබ් අඩවියේ සිදුවන සිදුවීම් නිවැරදි ආකාරයෙන් සම්බන්ධ කළ යුතුය, එනම් ඒවා අතර සම්බන්ධතාවයක් කෙසේ හෝ ගොඩනඟා ගත යුතුය. ඉන්පසු ඒවා DWH වෙත විශ්ලේෂණය සඳහා යවනු ලැබේ. මෙම විශ්ලේෂණය මත පදනම්ව, පෙන්විය යුත්තේ කවුරුන්ද සහ කුමන දැන්වීම්ද යන්න පිළිබඳ ආකෘති සාදන්න.
වෙළඳ දැන්වීම් ගනුදෙනුවක් යනු වෙළඳ දැන්වීමක් පෙන්වීමෙන් ආරම්භ වන අදාළ පරිශීලක සිදුවීම් සමූහයකි, පසුව යමක් සිදු වේ, පසුව සමහර විට මිලදී ගැනීමක් විය හැකිය, පසුව මිලදී ගැනීමක් තුළ මිලදී ගැනීම් තිබිය හැකිය. උදාහරණයක් ලෙස, මෙය ජංගම යෙදුමක් හෝ ජංගම ක්‍රීඩාවක් නම්, සාමාන්යයෙන් යෙදුම ස්ථාපනය කිරීම නොමිලේ සිදු වන අතර, එහි යමක් සිදු කරන්නේ නම්, මේ සඳහා මුදල් අවශ්ය විය හැකිය. තවද පුද්ගලයෙකු යෙදුම තුළ වැඩිපුර වියදම් කරන තරමට එය වඩා වටිනා ය. නමුත් මේ සඳහා ඔබ සියල්ල සම්බන්ධ කළ යුතුය.
බොහෝ බන්ධන ආකෘති ඇත.
වඩාත්ම ජනප්රිය වන්නේ:
- අවසාන අන්තර්ක්‍රියාව, එහිදී අන්තර්ක්‍රියා යනු ක්ලික් කිරීමක් හෝ හැඟීමක් වේ.
- පළමු අන්තර්ක්‍රියා, එනම් වෙබ් අඩවියට පුද්ගලයෙකු ගෙන ආ පළමු දෙය.
- රේඛීය සංයෝජනය - සියල්ල සමානව.
- දුර්වල වීම.
- සහ යනාදි.
සහ ඒ සියල්ල මුලින්ම ක්රියාත්මක වූයේ කෙසේද? Runtime සහ Cassandra තිබුණා. Cassandra ගණුදෙණු ගබඩාව ලෙස භාවිතා කරන ලදී, එනම් අදාළ සියලුම ගනුදෙනු එහි ගබඩා කර ඇත. ඒවගේම Runtime එකේ යම් සිදුවීමක් එනකොට, උදාහරණයක් විදියට, මොකක් හරි පිටුවක් හෝ වෙන දෙයක් පෙන්නුවම, එතකොට Cassandra ට ඉල්ලීමක් කළා - එහෙම කෙනෙක් ඉන්නවද නැද්ද කියලා. එවිට ඊට අදාළ ගනුදෙනු ලබා ගත්තා. සහ සම්බන්ධතාවය ඇති විය.
ඉල්ලීමට ගනුදෙනු හැඳුනුම්පතක් තිබීම වාසනාවන්ත නම්, එය පහසු වේ. නමුත් සාමාන්යයෙන් වාසනාව නැත. එබැවින්, අවසාන ගනුදෙනුව හෝ අවසාන ක්ලික් කිරීම සමඟ ගනුදෙනුව සොයා ගැනීමට අවශ්ය විය.
බන්ධනය අවසාන ක්ලික් කිරීම දක්වා වූ තාක් කල් ඒ සියල්ල ඉතා හොඳින් ක්රියාත්මක විය. මොකද දවසකට ක්ලික් කිරීම් මිලියන 10ක් තියෙනවා, මාසෙකට මිලියන 300ක්, අපි මාසෙකට වින්ඩෝවක් සෙට් කරොත්. තවද Cassandra හි වේගයෙන් ධාවනය වීමට නම් සියල්ල මතකයේ තිබිය යුතු බැවින්, Runtime ඉක්මනින් ප්‍රතිචාර දැක්විය යුතු නිසා, එය සේවාදායකයන් 10-15 ක් පමණ ගත විය.
ඔවුන්ට ගනුදෙනුවක් සංදර්ශකයට සම්බන්ධ කිරීමට අවශ්ය වූ විට, එය වහාම එතරම් විනෝදජනක නොවන බව පෙනී ගියේය. සහ ඇයි? 30 ගුණයකින් වැඩි සිදුවීම් ගබඩා කළ යුතු බව පෙනේ. තවද, ඒ අනුව, ඔබට 30 ගුණයකින් වැඩි සේවාදායකයන් අවශ්ය වේ. මෙය යම් ආකාරයක තාරකා විද්‍යාත්මක රූපයක් බව පෙනේ. සම්බන්ධ කිරීම සිදු කිරීම සඳහා සේවාදායකයන් 500 ක් දක්වා තබා ගැනීම සඳහා, ධාවන කාලය තුළ සැලකිය යුතු තරම් අඩු සේවාදායකයක් තිබියදී, මෙය යම් ආකාරයක වැරදි අගයකි. සහ ඔවුන් කුමක් කළ යුතු දැයි සිතන්නට පටන් ගත්හ.
අපි ClickHouse එකට ගියා. සහ ClickHouse හි එය කරන්නේ කෙසේද? බැලූ බැල්මට පෙනෙන්නේ මෙය ප්‍රති-රදි රටා කට්ටලයක් බවයි.
- ගනුදෙනුව වර්ධනය වේ, අපි එයට වැඩි වැඩියෙන් සිදුවීම් සම්බන්ධ කරමු, එනම් එය විකෘති වන අතර ClickHouse විකෘති වස්තූන් සමඟ ඉතා හොඳින් ක්රියා නොකරයි.
- අමුත්තෙක් අප වෙත පැමිණෙන විට, අපි ඔහුගේ සංචාර හැඳුනුම්පත මගින් යතුරෙන් ඔහුගේ ගනුදෙනු ඉවත් කළ යුතුය. මේකත් point query එකක්, ClickHouse එකේ එහෙම කරන්නේ නැහැ. සාමාන්යයෙන් ClickHouse හි විශාල …ස්කෑන් ඇත, නමුත් මෙහිදී අපට වාර්තා කිහිපයක් ලබා ගත යුතුය. එසේම ප්‍රති රටාවකි.
- මීට අමතරව, ගනුදෙනුව json හි සිදු වූ නමුත්, එය නැවත ලිවීමට අවශ්ය නොවීය, එබැවින් ඔවුන්ට json ව්යුහගත නොවන ආකාරයෙන් ගබඩා කිරීමට අවශ්ය වූ අතර, අවශ්ය නම්, එයින් යමක් අදින්න. ඒ වගේම මේකත් antipattern එකක්.
එනම් ප්‍රති රටා කට්ටලයකි.
කෙසේ වෙතත්, එය ඉතා හොඳින් ක්රියාත්මක වන පද්ධතියක් බවට පත් විය.
මොනවද කළේ? ClickHouse දර්ශනය වූ අතර, ලොග් විසි කර, වාර්තා වලට බෙදා ඇත. ClickHouse වෙතින් ලොග් ලැබුණු ආරෝපණය කළ සේවාවක් දර්ශනය විය. ඊට පසු, එක් එක් ප්‍රවේශය සඳහා, පිවිසුම් හැඳුනුම්පත මගින්, මට තවම ක්‍රියාකර නොතිබිය හැකි ගනුදෙනු සහ ස්නැප්ෂොට්, එනම් දැනටමත් සම්බන්ධ කර ඇති ගනුදෙනු, එනම් පෙර වැඩවල ප්රතිඵලය මට ලැබුණි. මම දැනටමත් ඒවායින් තර්කනය කර, නිවැරදි ගනුදෙනුව තෝරාගෙන, නව සිදුවීම් සම්බන්ධ කර ඇත. නැවත ලොග් විය. ලොගය ClickHouse වෙත ආපසු ගියේය, එනම් එය නිරන්තරයෙන් චක්‍රීය පද්ධතියකි. ඊට අමතරව, මම එහි විශ්ලේෂණය කිරීමට DWH වෙත ගියෙමි.
එය ඉතා හොඳින් ක්රියාත්මක නොවූයේ මෙම ස්වරූපයෙන් ය. ක්ලික්හවුස් සඳහා එය පහසු කිරීම සඳහා, පිවිසුම් හැඳුනුම්පත මගින් ඉල්ලීමක් ඇති වූ විට, ඔවුන් මෙම ඉල්ලීම් 1-000 සංචාර හැඳුනුම්පත් කුට්ටිවලට කාණ්ඩ කර පුද්ගලයින් 2-000 ක් සඳහා සියලුම ගනුදෙනු ඉවත් කළහ. ඊට පස්සේ ඔක්කොම වැඩ කළා.
ඔබ ClickHouse ඇතුළත බැලුවහොත්, මේ සියල්ලට සේවා සපයන ප්‍රධාන වගු 3ක් පමණි.
ලඝු-සටහන් උඩුගත කරන ලද පළමු වගුව, සහ ලොග සැකසීමකින් තොරව පාහේ උඩුගත කරනු ලැබේ.
දෙවන වගුව. ද්‍රව්‍යමය දෘෂ්ටිය හරහා, මෙම ලඝු-සටහන් වලින්, තවමත් ආරෝපණය කර නොමැති, එනම් සම්බන්ධයක් නැති සිදුවීම් සපා කෑහ. ද්‍රව්‍යමය දර්ශනය හරහා, ස්නැප්ෂොට් එකක් තැනීම සඳහා මෙම ලොගවලින් ගනුදෙනු ඉවත් කරන ලදී. එනම්, විශේෂ ද්‍රව්‍යමය දසුනක්, එනම් ගනුදෙනුවේ අවසන් සමුච්චිත තත්වය, සැණෙපොතක් ගොඩනගා ඇත.
මෙන්න SQL වලින් ලියා ඇති පෙළ. එහි ඇති වැදගත් කරුණු කිහිපයක් පිළිබඳව අදහස් දැක්වීමට කැමැත්තෙමි.
පළමු වැදගත් දෙය නම් ClickHouse හි json වෙතින් තීරු සහ ක්ෂේත්‍ර පිටතට ඇද ගැනීමේ හැකියාවයි. එනම්, ClickHouse සතුව json සමඟ වැඩ කිරීමට ක්‍රම කිහිපයක් තිබේ. ඒවා ඉතා ප්‍රාථමිකයි.
visitParamExtractInt ඔබට json වෙතින් ගුණාංග උකහා ගැනීමට ඉඩ සලසයි, එනම් පළමු පහර වැඩ. මේ ආකාරයෙන් ඔබට ගනුදෙනු හැඳුනුම්පත හෝ පිවිසුම් හැඳුනුම්පත ඉවත් කළ හැකිය. මෙම අවස්ථාවේ.
දෙවනුව, උපක්‍රමශීලී ද්‍රව්‍යමය ක්ෂේත්‍රයක් මෙහි භාවිතා වේ. එයින් අදහස් කරන්නේ කුමක් ද? මෙයින් අදහස් කරන්නේ ඔබට එය මේසයට ඇතුල් කළ නොහැකි බවයි, එනම් එය ඇතුල් කර නැත, එය ගණනය කිරීම සහ ඇතුල් කිරීම මත ගබඩා කර ඇත. ඇලවීමේදී, ClickHouse ඔබ වෙනුවෙන් වැඩ කරයි. ඔබට පසුව අවශ්ය දේ දැනටමත් json වෙතින් ඉවත් කර ඇත.
මෙම අවස්ථාවේදී, අමු පේළි සඳහා ද්‍රව්‍යමය දර්ශනය වේ. ප්රායෝගිකව අමු ලඝු-සටහන් සහිත පළමු වගුව පමණක් භාවිතා වේ. සහ ඔහු කරන්නේ කුමක්ද? පළමුව, එය වර්ග කිරීම වෙනස් කරයි, එනම් දැන් වර්ග කිරීම සංචාර හැඳුනුම්පත මගින් සිදු වේ, මන්ද අපට නිශ්චිත පුද්ගලයෙකු සඳහා ඔහුගේ ගනුදෙනුව ඉක්මනින් ලබා ගත යුතු බැවිනි.
දෙවන වැදගත් කරුණ වන්නේ index_granularity වේ. ඔබ MergeTree දැක ඇත්නම්, එය සාමාන්යයෙන් පෙරනිමියෙන් 8 index_granularity වේ. එය කුමක්ද? මෙය දර්ශක විරල පරාමිතියයි. ClickHouse හි දර්ශකය විරල වේ, එය කිසි විටෙක සෑම ප්‍රවේශයක්ම සුචිගත නොකරයි. එය සෑම 192 කටම මෙය සිදු කරයි. තවද දත්ත විශාල ප්‍රමාණයක් ගණනය කිරීමට අවශ්ය වූ විට මෙය හොඳ ය, නමුත් ටිකක් විට නරක ය, මන්ද විශාල උඩිස් මුදලක් ඇති බැවිනි. අපි දර්ශක කැටිති අඩු කළහොත්, අපි පොදු කාර්ය අඩු කරමු. එය එකකට අඩු කළ නොහැක, මන්ද ප්රමාණවත් මතකයක් නොතිබිය හැකිය. දර්ශකය සෑම විටම මතකයේ ගබඩා කර ඇත.
Snapshot තවත් රසවත් ClickHouse විශේෂාංග භාවිතා කරයි.
පළමුව, එය AggregatingMergeTree වේ. සහ AggregatingMergeTree විසින් argMax ගබඩා කරයි, එනම් මෙය අවසන් වේලා මුද්‍රාවට අනුරූප වන ගනුදෙනුවේ තත්වයයි. දී ඇති ආගන්තුකයෙකු සඳහා ගනුදෙනු සෑම විටම උත්පාදනය වේ. තවද මෙම ගනුදෙනුවේ අවසාන අවස්ථාවේ දී, අපි සිදුවීමක් එක් කළ අතර අපට නව රාජ්‍යයක් ඇත. ඒක ආයෙත් ClickHouse ගැහුවා. තවද මෙම ද්‍රව්‍යමය දර්ශනය තුළ argMax හරහා, අපට සැමවිටම වත්මන් තත්ත්වය ලබා ගත හැක.
- බන්ධනය ධාවන කාලයෙන් "විසංයෝජනය" කර ඇත.
- මසකට ගනුදෙනු බිලියන 3 ක් දක්වා ගබඩා කර සකස් කර ඇත. මෙය කැසැන්ඩ්‍රාහි, එනම් සාමාන්‍ය ගණුදෙණු ක්‍රමයක තිබුනාට වඩා විශාලත්වයේ අනුපිළිවෙලකි.
- 2x5 ClickHouse සර්වර් පොකුර. සේවාදායකයන් 5 ක් සහ සෑම සේවාදායකයකටම අනුරුවක් ඇත. ක්ලික් පාදක ආරෝපණය කිරීම සඳහා මෙය Cassandra හි තිබුනාට වඩා අඩු වන අතර මෙහි අපට ප්‍රතිරූපය පදනම් කර ඇත. එනම්, සර්වර් ගණන 30 ගුණයකින් වැඩි කරනවා වෙනුවට, ඒවා අඩු කිරීමට ඔවුන් සමත් විය.
අවසාන උදාහරණය වන්නේ කොටස් මිල වෙනස්වීම්වල සහසම්බන්ධතා විශ්ලේෂණය කළ මූල්‍ය සමාගමක් වන Y ය.
සහ කාර්යය වූයේ:
- දළ වශයෙන් කොටස් 5 ක් ඇත.
- සෑම මිලි තත්පර 100 කට වරක් උපුටා දැක්වීම් දනී.
- දත්ත වසර 10 ක් පුරා රැස් කර ඇත. පෙනෙන විදිහට, සමහර සමාගම් සඳහා වැඩි, සමහරක් සඳහා අඩු.
- මුළු පේළි බිලියන 100 ක් පමණ ඇත.
වෙනස්කම්වල සහසම්බන්ධතාවය ගණනය කිරීම අවශ්ය විය.
මෙන්න කොටස් දෙකක් සහ ඒවායේ මිල ගණන්. එකක් ඉහළට සහ අනෙක ඉහළට ගියහොත්, මෙය ධනාත්මක සහසම්බන්ධයකි, එනම් එකක් ඉහළට යන අතර අනෙක ඉහළට යයි. ප්‍රස්ථාරයේ අවසානයේ මෙන් එකක් ඉහළට ගියහොත් සහ අනෙක පහළට ගියහොත් මෙය negative ණ සහසම්බන්ධයකි, එනම් එකක් නැඟෙන විට අනෙක වැටේ.
මෙම අන්‍යෝන්‍ය වෙනස්කම් විශ්ලේෂණය කිරීමෙන් කෙනෙකුට මූල්‍ය වෙළෙඳපොළ තුළ අනාවැකි පළ කළ හැකිය.
නමුත් කාර්යය දුෂ්කර ය. මේ සඳහා මොනවද කරන්නේ? අපට වාර්තා බිලියන 100 ක් ඇත: කාලය, කොටස් සහ මිල. අපි මිල ඇල්ගොරිතමයෙන් ධාවන වෙනස මෙන් පළමු බිලියන 100 ගුණයක් ගණනය කළ යුතුය. RunningDifference යනු ClickHouse හි ශ්‍රිතයක් වන අතර එය තන්තු දෙකක් අතර වෙනස අනුපිළිවෙලින් ගණනය කරයි.
ඊට පසු, ඔබ සහසම්බන්ධය ගණනය කළ යුතු අතර, එක් එක් යුගල සඳහා සහසම්බන්ධය ගණනය කළ යුතුය. කොටස් 5 ක් සඳහා යුගල මිලියන 000 කි. මෙය බොහෝ ය, එනම් 12,5 ගුණයක් එවැනි සහසම්බන්ධතා ශ්‍රිතයක් ගණනය කිරීම අවශ්ය වේ.
තවද යමෙකුට අමතක වූවා නම්, ͞x සහ ͞y චෙක්මේට් වේ. නියැදි අපේක්ෂාව. එනම්, මූලයන් සහ එකතුව ගණනය කිරීම පමණක් නොව, මෙම එකතු කිරීම් තුළ තවත් එක් එකතුවක් ද අවශ්ය වේ. ගණනය කිරීම් පොකුරක් මිලියන 12,5 වාරයක් සිදු කළ යුතු අතර පැය ගණනින් පවා කණ්ඩායම්ගත කළ යුතුය. අපිටත් පැය ගානක් තියෙනවා. තවද ඔබ එය තත්පර 60 කින් කළ යුතුය. ඒක විහිළුවක්.
ClickHouse එන්නට පෙර මේ සියල්ල ඉතා සෙමින් ක්රියාත්මක වූ නිසා අවම වශයෙන් කෙසේ හෝ කාලය ලබා ගැනීම අවශ්ය විය.
ඔවුන් එය Hadoop මත, Spark මත, Greenplum මත ගණනය කිරීමට උත්සාහ කළහ. මේ සියල්ල ඉතා මන්දගාමී හෝ මිල අධික විය. එනම්, එය කෙසේ හෝ ගණනය කිරීමට හැකි විය, නමුත් පසුව එය මිල අධික විය.
ඊට පස්සේ ClickHouse ඇවිත් දේවල් ගොඩක් හොඳ වුණා.
සහසම්බන්ධතා ස්ථානගත කළ නොහැකි නිසා, දත්ත ප්‍රදේශය සම්බන්ධයෙන් අපට ගැටලුවක් ඇති බව මම ඔබට මතක් කරමි. අපට සමහර දත්ත එක් සේවාදායකයක, සමහරක් තවත් සේවාදායකයක දමා ගණනය කළ නොහැක, අපට සියලු දත්ත සෑම තැනකම තිබිය යුතුය.
ඔවුන් කළේ කුමක්ද? මුලදී, දත්ත දේශීයකරණය කර ඇත. සෑම සේවාදායකයක්ම නිශ්චිත කොටස් කට්ටලයක මිල පිළිබඳ දත්ත ගබඩා කරයි. තවද ඒවා අතිච්ඡාදනය නොවේ. එබැවින්, logReturn සමාන්තරව සහ ස්වාධීනව ගණනය කළ හැකිය, මේ සියල්ල මෙතෙක් සිදු වන්නේ සමාන්තරව සහ බෙදා හැරීමෙනි.
එවිට අපි මෙම දත්ත අඩු කිරීමට තීරණය කළෙමු, නමුත් ප්රකාශිත බව නැති කර නොගනිමු. අරා භාවිතා කිරීම අඩු කරන්න, එනම් එක් එක් කාල සීමාව සඳහා, තොග අරාවක් සහ මිල ගණන් සාදන්න. එමනිසා, එය ඉතා අඩු දත්ත ඉඩක් ගනී. ඒ වගේම ඔවුන් සමඟ වැඩ කිරීමට ටිකක් පහසුයි. මේවා බොහෝ දුරට සමාන්තර මෙහෙයුම් වේ, එනම් අපි අර්ධ වශයෙන් සමාන්තරව කියවා සේවාදායකයට ලියන්නෙමු.
ඊට පසු, එය අනුකරණය කළ හැකිය. "r" අකුරෙන් අදහස් කරන්නේ අපි මෙම දත්ත අනුකරණය කළ බවයි. එනම්, අපට සේවාදායකයන් තුනේම එකම දත්ත ඇත - මේවා අරා වේ.
ඉන්පසු ගණනය කළ යුතු සහසම්බන්ධතා මිලියන 12,5 ක මෙම කට්ටලයෙන් විශේෂ පිටපතක් සමඟ, ඔබට පැකේජ සෑදිය හැකිය. එනම්, සහසම්බන්ධතා යුගල 2 ක් සහිත කාර්යයන් 500 කි. තවද මෙම කාර්යය නිශ්චිත ClickHouse සේවාදායකයක් මත ගණනය කළ යුතුය. ඔහු සතුව සියලුම දත්ත ඇත, මන්ද දත්ත සමාන වන අතර ඔහුට ඒවා අනුපිළිවෙලින් ගණනය කළ හැකිය.
නැවත වරක්, මෙය පෙනෙන්නේ එයයි. පළමුව, මෙම ව්යුහයේ සියලු දත්ත අප සතුව ඇත: කාලය, කොටස්, මිල. එවිට අපි logReturn ගණනය කළෙමු, එනම් එකම ව්යුහයේ දත්ත, නමුත් මිල වෙනුවට අපට දැනටමත් logReturn ඇත. පසුව ඒවා නැවත සකස් කරන ලදී, එනම් අපට කොටස් සහ මිල ගණන් සඳහා කාලය සහ groupArray ලැබුණි. අනුකරණය කරන ලදී. ඊට පසු, අපි කාර්යයන් රාශියක් ජනනය කර ක්ලික්හවුස් වෙත පෝෂණය කළෙමු, එවිට එය ඒවා ගණන් කරනු ඇත. සහ එය ක්රියා කරයි.
සංකල්පය සනාථ කිරීම මත, කාර්යය උප කාර්යයක් විය, එනම්, අඩු දත්ත ලබා ගන්නා ලදී. සහ සේවාදායක තුනක් පමණි.
මෙම පළමු අදියර දෙක: Log_return ගණනය කිරීම සහ අරාවන් එතීමට පැයක් පමණ ගත විය.
සහ සහසම්බන්ධය ගණනය කිරීම පැය 50 ක් පමණ වේ. හැබැයි පැය 50 මදි, මොකද උන් සති ගණන් වැඩ කරපු නිසා. එය විශාල සාර්ථකත්වයක් විය. ඔබ ගණන් කරන්නේ නම්, තත්පරයට 70 වතාවක් සෑම දෙයක්ම මෙම පොකුරේ ගණන් කර ඇත.
නමුත් වැදගත්ම දෙය නම්, මෙම පද්ධතිය ප්රායෝගිකව බාධාවකින් තොරව, එනම්, එය රේඛීයව පරිමාණය කරයි. ඔවුන් එය පරීක්ෂා කළා. එය සාර්ථකව පරිමාණය කරන ලදී.
- නිවැරදි යෝජනා ක්රමය සටනෙන් අඩකි. නිවැරදි යෝජනා ක්රමය නම් අවශ්ය සියලුම ClickHouse තාක්ෂණයන් භාවිතා කිරීමයි.
- Summing/AggregatingMergeTrees යනු ඔබට විශේෂ අවස්ථාවක් ලෙස රාජ්‍ය ඡායාරූපයක් එකතු කිරීමට හෝ සලකා බැලීමට ඉඩ සලසන තාක්ෂණයන් වේ. තවද එය බොහෝ දේ සරල කරයි.
- ද්‍රව්‍යමය දර්ශන ඔබට එක් දර්ශක සීමාව මඟ හැරීමට ඉඩ සලසයි. සමහර විට මම එය ඉතා පැහැදිලිව කීවේ නැත, නමුත් අපි ලඝු-සටහන් පටවන විට, අමු ලඝු-සටහන් එක් දර්ශකයක් සමඟ වගුවේ තිබූ අතර, උපලක්ෂණ ලඝු-සටහන් වගුවේ තිබුණි, එනම් එකම දත්ත, පෙරහන පමණක්, නමුත් දර්ශකය සම්පූර්ණයෙන්ම විය අන් අය. එය එකම දත්ත බව පෙනේ, නමුත් වෙනස් වර්ග කිරීම. ඔබට අවශ්ය නම්, එවැනි ClickHouse සීමාවක් මඟ හැරීමට Materialized Views ඔබට ඉඩ සලසයි.
- ලක්ෂ්‍ය විමසුම් සඳහා දර්ශක කැටිති අඩු කරන්න.
- තවද දත්ත බුද්ධිමත්ව බෙදාහරින්න, හැකිතාක් සේවාදායකය තුළ දත්ත ස්ථානගත කිරීමට උත්සාහ කරන්න. ඉල්ලීම් හැකිතාක් දුරට ප්‍රාදේශීයකරණය භාවිතා කරන බව සහතික කිරීමට උත්සාහ කරන්න.
මෙම කෙටි කතාව සාරාංශගත කරමින්, ClickHouse දැන් වාණිජ දත්ත සමුදායන් සහ විවෘත මූලාශ්‍ර දත්ත සමුදායන් යන දෙකෙහිම භූමිය ස්ථිරව අල්ලාගෙන ඇති බව අපට පැවසිය හැකිය, එනම් විශේෂයෙන් විශ්ලේෂණ සඳහා. ඔහු මෙම භූ දර්ශනයට හොඳින් ගැලපේ. ඊටත් වඩා, එය සෙමින් සෙමින් අනෙක් අයව යටපත් කිරීමට පටන් ගනී, මන්ද ඔබට ClickHouse ඇති විට, ඔබට InfiniDB අවශ්ය නොවේ. ඔවුන් සාමාන්‍ය SQL සහාය ලබා දෙන්නේ නම් Vertika ඉක්මනින් අවශ්ය නොවනු ඇත. භුක්ති විඳින්න!
-වාර්තාවට ස්තූතියි! ඉතා රසවත්! Apache Phoenix සමඟ සැසඳීම් තිබේද?
නැහැ, මම කවුරුත් සංසන්දනය කරනවා අසා නැහැ. අපි සහ Yandex විවිධ දත්ත සමුදායන් සමඟ සියලු ClickHouse සැසඳීම් නිරීක්ෂණය කිරීමට උත්සාහ කරමු. මක්නිසාද යත් හදිසියේම යමක් ClickHouse වලට වඩා වේගවත් වුවහොත්, Lesha Milovidovට රාත්‍රියේ නිදා ගත නොහැකි අතර එය ඉක්මනින් වේගවත් කිරීමට පටන් ගනී. එහෙම සංසන්දනයක් මම අහලා නැහැ.
-
(Aleksey Milovidov) Apache Phoenix යනු Hbase මගින් බල ගැන්වෙන SQL එන්ජිමකි. Hbase ප්‍රධාන වශයෙන් ප්‍රධාන වටිනාකම් වැඩ අවස්ථා සඳහා වේ. එහිදී, එක් එක් පේළිය තුළ, අත්තනෝමතික නම් සහිත අත්තනෝමතික තීරු සංඛ්යාවක් තිබිය හැකිය. Hbase, Cassandra වැනි එවැනි පද්ධති ගැන මෙය පැවසිය හැකිය. තවද එය ඔවුන් සඳහා සාමාන්යයෙන් ක්රියා නොකරනු ඇති නිශ්චිතවම බර විශ්ලේෂණ විමසුම් වේ. එසේත් නැතිනම් ClickHouse සමඟ ඔබට කිසිදු අත්දැකීමක් නොමැති නම් ඒවා හොඳින් ක්රියාත්මක වේ යැයි ඔබ සිතනු ඇත.
-
ස්තුතියි
-
සුභ සන්ධ්යාවක් මට විශ්ලේෂණ උප පද්ධතියක් ඇති නිසා මම දැනටමත් මෙම මාතෘකාව ගැන බෙහෙවින් උනන්දු වෙමි. නමුත් මම ClickHouse දෙස බලන විට, සිදුවීම් විශ්ලේෂණය සඳහා ClickHouse ඉතා හොඳින් ගැලපෙන බව මට හැඟේ. මට විශාල වගු පොකුරක් සමඟ ව්‍යාපාරික දත්ත රාශියක් විශ්ලේෂණය කිරීමට අවශ්ය නම්, ක්ලික්හවුස්, මා තේරුම් ගත් පරිදි, මට එතරම් සුදුසු නොවේද? විශේෂයෙන් ඔවුන් වෙනස් නම්. මෙය නිවැරදිද නැතහොත් මෙය ප්‍රතික්ෂේප කළ හැකි උදාහරණ තිබේද?
-
මේක හරි. බොහෝ විශේෂිත විශ්ලේෂණ දත්ත සමුදායන් සම්බන්ධයෙන් මෙය සත්‍ය වේ. විචල්‍ය වන විශාල වගු එකක් හෝ කිහිපයක් තිබීම සහ සෙමින් වෙනස් වන බොහෝ කුඩා ඒවා සඳහා ඒවා සකස් කර ඇත. ඒ කියන්නේ ClickHouse කියන්නේ Oracle වගේ නෙවෙයි, හැම දෙයක්ම දාලා ඉතා සංකීර්ණ විමසුම් කිහිපයක් ගොඩනගා ගන්න පුළුවන්. ClickHouse ඵලදායී ලෙස භාවිතා කිරීම සඳහා, ඔබ ClickHouse තුළ හොඳින් ක්රියාත්මක වන ආකාරයට යෝජනා ක්‍රමයක් ගොඩනගා ගත යුතුය. එනම්, අධික සාමාන්යකරණයෙන් වැළකී සිටීම, ශබ්දකෝෂ භාවිතා කිරීම, අඩු දිගු සබැඳි සෑදීමට උත්සාහ කරන්න. යෝජනා ක්රමය මේ ආකාරයෙන් ගොඩනගා ඇත්නම්, සාම්ප්‍රදායික සම්බන්ධතා දත්ත ගබඩාවකට වඩා බොහෝ කාර්යක්ෂමව ClickHouse මත සමාන ව්‍යාපාරික කාර්යයන් විසඳිය හැකිය.
-
වාර්තාවට ස්තූතියි! මට අලුත්ම මූල්‍ය නඩුව ගැන ප්‍රශ්නයක් තියෙනවා. ඔවුන්ට විශ්ලේෂණ තිබුණා. ඒවා ඉහළ පහළ යන ආකාරය සංසන්දනය කිරීම අවශ්ය විය. ඔබ මෙම විශ්ලේෂණ සඳහා විශේෂයෙන් පද්ධතිය ගොඩනඟා ඇති බව මට වැටහෙනවාද? හෙට, උදාහරණයක් ලෙස, ඔවුන්ට මෙම දත්ත පිළිබඳ වෙනත් වාර්තාවක් අවශ්ය නම්, ඔවුන්ට ස්කීමා නැවත ගොඩනඟා දත්ත උඩුගත කිරීමට අවශ්‍යද? එනම්, ඉල්ලීම ලබා ගැනීම සඳහා යම් ආකාරයක පූර්ව සැකසුම් සිදු කිරීමට?
ඇත්ත වශයෙන්ම, මෙය ඉතා නිශ්චිත කාර්යයක් සඳහා ClickHouse භාවිතා කිරීමයි. එය වඩාත් සාම්ප්‍රදායිකව Hadoop තුළ විසඳිය හැකිය. Hadoop සඳහා, මෙය කදිම කාර්යයකි. නමුත් Hadoop මත එය ඉතා මන්දගාමී වේ. මගේ ඉලක්කය වන්නේ ClickHouse ට සාමාන්යයෙන් සම්පූර්ණයෙන්ම වෙනස් ක්‍රම මගින් විසඳන කාර්යයන් විසඳිය හැකි බව පෙන්වීමයි, නමුත් ඒ සමඟම එය වඩාත් කාර්යක්ෂමව කරන්න. එය නිශ්චිත කාර්යයක් සඳහා සකස් කර ඇත. ඒ හා සමාන දෙයක ගැටලුවක් තිබේ නම්, එය සමාන ආකාරයකින් විසඳා ගත හැකි බව පැහැදිලිය.
එය පැහැදිලියි. ඔබ කිව්වා පැය 50 ක් සකස් කළා කියලා. මුල ඉඳන්මද, කවදද ඩේටා ලෝඩ් කළේ නැත්නම් ප්‍රතිඵල ගත්තෙ?
ඔව් ඔව්.
හරි .. ඔයාට බෙහෝම ස්තූතියි.
මේක තියෙන්නේ 3 server cluster එකක.
සුභ පැතුම්! වාර්තාවට ස්තූතියි! සෑම දෙයක්ම ඉතා සිත්ගන්නා සුළුය. මම ක්‍රියාකාරීත්වය ගැන ටිකක් අහන්නේ නැහැ, නමුත් ස්ථාවරත්වය අනුව ClickHouse භාවිතය ගැන. එනම්, ඔබට කිසිවක් තිබේද, ඔබට නැවත යථා තත්ත්වයට පත් කළ යුතුද? මෙම නඩුවේදී ClickHouse හැසිරෙන්නේ කෙසේද? ඔබටත් අනුරුවක් තිබුණාද? උදාහරණයක් ලෙස, ClickHouse තවමත් එහි සීමාවෙන් මිදී වැටෙන විට අපට ගැටලුවක් ඇති විය.
ඇත්ත වශයෙන්ම, පරිපූර්ණ පද්ධති නොමැත. තවද ClickHouse හට ද එහි ම ගැටළු තිබේ. නමුත් Yandex.Metrica දිගු කලක් වැඩ නොකිරීම ගැන ඔබ අසා තිබේද? නොවෙන්නත් පුළුවන්. එය ClickHouse හි 2012-2013 සිට විශ්වාසනීය ලෙස ක්රියා කරයි. මගේ අත්දැකීම ගැන මටත් කියන්න පුළුවන්. අපි කවදාවත් සම්පූර්ණ අසාර්ථකත්වයට පත්වෙලා නැහැ. සමහර පාර්ශවීය දේවල් සිදු විය හැකි නමුත්, ඒවා කිසි විටෙක ව්‍යාපාරයට බැරෑරුම් ලෙස බලපාන තරම් විවේචනාත්මක නොවීය. එය කිසි විටෙකත් සිදු නොවීය. ClickHouse තරමක් විශ්වාසදායක වන අතර අහඹු ලෙස කඩා වැටෙන්නේ නැත. ඔබ ඒ ගැන කරදර විය යුතු නැත. එය අමු දෙයක් නොවේ. මෙය බොහෝ සමාගම් විසින් ඔප්පු කර ඇත.
ආයුබෝවන්! ඔබ දත්ත ක්රමය ගැන වහාම සිතා බැලිය යුතු බව ඔබ පැවසුවා. එය සිදු වූවා නම්? මගේ දත්ත වැගිරෙයි. මාස හයක් ගත වන අතර, මේ ආකාරයෙන් ජීවත් වීමට නොහැකි බව මට වැටහෙනවා, මට දත්ත නැවත උඩුගත කර ඔවුන් සමඟ යමක් කළ යුතුය.
මෙය ඇත්ත වශයෙන්ම ඔබේ පද්ධතිය මත රඳා පවතී. ප්රායෝගිකව නැවතීමකින් තොරව මෙය කිරීමට ක්‍රම කිහිපයක් තිබේ. උදාහරණයක් ලෙස, ඔබට එය අනන්‍ය ලෙස සිතියම්ගත කළ හැකි නම් වෙනස් දත්ත ව්‍යුහයක් සෑදීමට ද්‍රව්‍යමය දසුනක් සෑදිය හැක. එනම්, එය ClickHouse භාවිතයෙන් සිතියම්ගත කිරීමට ඉඩ දෙන්නේ නම්, එනම් සමහර දේවල් උපුටා ගැනීම, ප්‍රාථමික යතුර වෙනස් කිරීම, කොටස් කිරීම වෙනස් කිරීම, එවිට ඔබට Materialized View එකක් සෑදිය හැක. ඔබගේ පැරණි දත්ත එහි උඩින් ලියන්න, නව ඒවා ස්වයංක්‍රීයව ලියා ඇත. ඉන්පසු Materialized View භාවිතා කිරීමට මාරු වන්න, ඉන්පසු වාර්තාව මාරු කර පැරණි වගුව මරා දමන්න. මෙය සාමාන්යයෙන් නොනවතින ක්රමයකි.
ස්තුතියි.
මූලාශ්රය: www.habr.com