‘நாளைக்கு வியாழக்கிழமையாச்சே.. ஒன்றரை டூ மூணுதானே ராகுகாலம்?’ என்றார் நண்பர். ‘ஆமாம், ஏண்டா எதுக்கு கேட்குறே?’ என்றேன். ‘டெவ் டீம் கிட்டேர்ந்து ஒரு query வரும், அதை ஓட்டணும்’ என்றார். ஒரு பன்னாட்டு நிறுவனத்தில் எட்டு ஆண்டுகளாக டேட்டாபேஸ் அனலிஸ்ட் ஆகப் பணிபுரிகிறார், நண்பர். Query ஓட்டவும் நேரம், காலம் பார்த்துதான் செய்கிறார். அவர் மீது தப்பில்லை. 14 வரி கொண்டு Query-ஐ, இரண்டு பேர், நான்கு மணி நேரம் உட்கார்ந்து எழுதுகிறார்கள். Query Tool வைத்து கவனமாக எழுதினாலும், ஏதாவது ஒரு parameter விடுபட்டு, error அடித்துவிடும். சாதாரண Query என்றாலும் இடம், பொருள், ஏவல் என அனைத்து விஷயங்களையும் பார்த்த பின்னர்தான் execute பண்ணமுடியும் என்று அவ்வப்போது அலுத்துக்கொள்வார் நண்பர்.
SQL queries-ல் உள்ள சிக்கல் இது. 90 சதவீத பன்னாட்டு நிறுவனங்கள் இந்தச் சிக்கலில் சிக்கி, வெளியே வரமுடியாமல் தவிக்கிறார்கள். வழக்கமான பணியாக இருந்தாலும், தவறு இல்லாமல் செய்யமுடிவதில்லை. குறிப்பாக, அனாலிடிக்ஸ் சம்பந்தப்பட்ட செயலியோ அல்லது அது தொடர்பான டேட்டாவை எடுக்கும் பணியாக இருந்தால், என்ன query, எப்படி எழுதுவது என்று தெரியாமல் நிறைய பேர் குழம்புவது உண்டு. ஏகப்பட்ட சோதனை முயற்சிகள், சின்னச் சின்ன மாற்றங்களெல்லாம் செய்து, அனுமார் வால்போல் நீண்டிருக்கும் Query நீளத்தைக் குறைப்பார்கள். காரணம், டேட்டா எப்போதும் ரிலேஷனல் வடிவத்தில் இருப்பதுதான்.
ரிலேஷனல் என்று வரும்போது அதன் சட்டகமே பிரதானம். சட்டகமே, சட்ட திட்டங்களைத் தீர்மானிக்கிறது. அதற்குள் அடைக்கப்பட்டிருக்கும் டேட்டாவை வெளிக்கொண்டு வர, அந்த சட்டகத்தின் விதிகளுக்கு உட்பட்டு, உள்ளே சென்று தேவையானதை எடுத்துக்கொண்டு வர வேண்டும். என்டர் த டிராகன் பாதிப்பில் வந்த தமிழ்ப்படமான பாயும்புலியில் உடலை வளைத்து, நெளித்து ஒரு பாதாள மர்ம குகைக்குள் சென்று, சாகசங்களை நிகழ்த்திக் காட்டிவிட்டு வெற்றிகரமாக வெளியே வருவார் ரஜினி. அதுபோன்ற சாகசம்தான், நமக்குத் தேவையான டேட்டாவை சரியான SQL Query மூலம் வடிவமைத்து வெளியே எடுப்பது. சில நேரம் டேட்டா வரும். சில நேரம் வரவே வராது. இதைத்தான் long running query என்பார்கள். ஓஓஓஓஓடிக்கொண்டே இருக்கும். ரிசல்ட் வராது. அப்ளிகேஷனின் பெர்ஃபாமென்ஸ் பலத்த சேதத்துக்கு உள்ளாகும்.
டேபிள் வடிவமைப்பை சரியாக உள்வாங்கிக்கொண்டு, Query எழுதாததுதான் பிரச்னைக்கான அடிப்படையான காரணம். வடிவமைப்பை (extracting table structure) புரிந்துகொள்வது எப்போதும் சவாலான விஷயம்தான். உண்மையில், அதுவொரு தனி நடைமுறையாகச் செய்யவேண்டி இருக்கும். காரணம், நாம் டேட்டாவை வெளியே எடுத்துக்கொண்டிருக்கும் அதே நேரத்தில், டேபிள் வடிவமைப்பும் மாறிக்கொண்டே இருக்கும். பிஸினெஸ் தேவைக்காக, செயலியில் புதிய மாற்றங்களைச் செய்யும்போது, இதுபோன்ற மாற்றங்கள் தவிர்க்க முடியாதவை. எதையும் நம்மால் கட்டுப்படுத்த முடியாது, அப்படி கட்டுப்படுத்தவும் கூடாது.
சட்டகத்தின் ஸ்கீமா (schema) கடுமையாகும்போது, டேட்டாவை உள்ளே அனுப்புவதும், வெளியே எடுப்பதும் கஷ்டமான விஷயமாகிவிடுகின்றன. இப்படித்தான் இருக்க வேண்டும் என்று ஏராளமான கட்டுப்பாடுகளை விதிக்கும் ஸ்கீமாவை ஒரு கண்டிப்பான செக்யூரிட்டி ஆசாமியாக உருவகப்படுத்தவேண்டி இருக்கிறது. செக்யூரிட்டிக்காக ஆதரித்தால், தலைவலி போய் திருகுவலி வந்ததுபோல் வேறு சில பிரச்னைகள். வீட்டுக்குள்ளே தகவல் பரிமாற்றம் நடக்கும்போது எதற்கு செக்யூரிட்டி?
ஸ்கீமா என்பதை எனிமாபோல எடுத்துக்கொள்ளலாம். ஆறு மாதங்களுக்கு ஒருமுறை வேப்பெண்ணெய் குடிப்பதுபோல, கொஞ்சம் எனிமா எடுத்துக்கொண்டால் வயிற்றுக்கு நல்லது. அடிக்கடி எடுத்துக்கொண்டால் வயிறு தாங்காது. ஸ்கீமாவுக்கும் எனிமாவுக்கும் வித்தியாசமில்லை. புதிதாக மாற்றங்கள் வரும்போது ஸ்கீமா கடுமையாக இருப்பதில் தப்பில்லை. ஆனால், ஏற்கெனவே பலமுறை செய்து, சலித்துப்போன விஷயத்தில் கொஞ்சம் சுதந்திரத்தைத் தேடுவதில் தவறில்லை. அதன் காரணமாகத்தான், Structured என்பதைத் தாண்டி semistructured பக்கம் நகரவேண்டி இருக்கிறது. SQL வேண்டாம், NoSQL பக்கம் நிறைய பேர் வருவதற்கு இதுவே காரணம்.
உதாரணத்துக்கு, வாடிக்கையாளர்களின் விவரங்களைப் பெற்று சேமிக்கும் ஒரு டேட்டாபேஸை எடுத்துக்கொள்வோம். ஒரு சிலரிடம் First Name, Last Name மட்டுமே இருக்கும். என்னுடைய பெயர் ராமகிருஷ்ணன். அப்பாவின் பெயர் ஜெயபாலன் என்றிருந்தால், ராமகிருஷ்ணன் ஜெயபாலன் என்று எடுத்துக்கொள்ளலாம். ஓவர் ஊர்ப்பாசத்தோடு அய்யம்பேட்டை அறிவுடைநம்பி கலியபெருமாள் சந்திரன் என்று பெயர் வைத்துக்கொண்டால் எதை, எங்கே வைப்பது? இதுபோன்றவற்றைக் கையாளுவதற்கு Middle Name fileld ஒன்றை அறிமுகப்படுத்தியாக வேண்டும். ஒரு Middle Name போதாது என்று குறைந்தபட்சம் மூன்றாவது கொண்டுவர வேண்டும். Milddle Name இல்லாதவர்களுக்குக் காலியாக விட வேண்டும். பத்தாயிரம் வாடிக்கையாளர்கள் என்றால் பரவாயில்லை. கோடிக்கணக்கான வாடிக்கையாளர்கள், அதில் பல கோடி பேருக்கும் Middle Name இல்லையென்றால் நேரம் வேஸ்ட். இடமும் வேஸ்ட்.
பெயர் மட்டுமல்ல மற்ற தவல்கள் அனைத்தையும் முழுவதுமாகத் தந்துவிடுவார்கள் என்று சொல்லிவிடமுடியாது. சிலர் பின்கோடு தருவார்கள். சிலர் ஊர் பெயரைக்கூட சொல்லமாட்டார்கள். சிலரிடம் இமெயில் இருக்கும். கேட்டதும் மொபைல் நம்பர் தந்துவிடுவார்கள். சிலர், மொபைல் நம்பரை தராமல் லேண்ட் லைன் நம்பரை தந்துவிடவார்கள். அதைக் கொண்டுபோய் மொபைல் நம்பர் field-ல் சேமிக்கவும் முடியாது. SQL வைத்துக்கொண்டு இதையெல்லாம் சமாளிப்பது ரொம்ப கஷ்டம்! ஒரே வழி NoSQL களத்தில் இறங்குவதுதான். டேட்டா முழுமையாக இருக்க வேண்டிய அவசியமில்லை. Unstructured-ஆக இருந்தால், முதலை வாய்க்குள் தள்ளுவதுபோல் டேட்டாவை அப்படியே அனுப்பி வைத்துவிடலாம். ஓரளவு Seminstructured-ஆக இருந்தால் எல்லோருக்கும் நல்லது.
Seminstructured டேட்டா என்றால், சாதாரண text வடிவத்திலேயே அனுப்ப முடியும். இருப்பினும், ஓரளவு ஸ்கீமாவை பயன்படுத்திக்கொள்வது புத்திசாலித்தனம். ஏதாவது மாற்றங்கள் செய்து, டேட்டாவை filter செய்வதற்கு உதவும். அடிப்படையான சில ஸ்கீமாக்களைத் தரும் சில டூல்கள் இலவசமாகக் கிடைக்கின்றன. இதற்கு சீரியலைசேஷன் சிஸ்டம் (serialization system) என்பார்கள். அபாச்சி தரும் ஆவ்ரோ குறிப்பிடத்தக்கது. இதைப் பயன்படுத்துவதும் எளிது.
{
"type":"record",
"name":"RawEmail",
"fields":
[
{
"name":"thread_id",
"type":["string", "null"],
"doc":""
},
{
"name":"raw_email",
"type": ["string", "null"]
}
]
}
எளிமையான ஆவ்ரோ ஸ்கீமாவை பயன்படுத்தி ஒரு மெயில் டாக்குமெண்ட்டை சேமித்து வைக்கலாம். இங்கே thread_id என்பது ஒரு unique identifier. இது ஒட்டுமொத்த இமெயில் டெக்ஸ்டை அப்படியே சேமித்துவிடுகிறது. டேட்டாவை பிராசஸ் செய்யும்போது, ஸ்கீமாவில் எங்கெல்லாம் field தேவையோ, அங்கெல்லாம் இணைத்து, தேவையானதை வெளியே எடுக்க முடியும். இதற்கென்று தனியாக code எழுத வேண்டியதில்லை. Avro போன்றவற்றின் சிறப்பம்சம் இதுதான். இதைத்தான் நாம் முக்கியமாகக் கவனிக்கவேண்டி இருக்கிறது.
இனி, ஸ்கீமா என்பது புரோகிராமில் உள்ள சங்கதி அல்ல. புரோகிராம் என்னும் கூட்டுக் குடும்பத்திலிருந்து விலகி வந்து, ஸ்கீமாக்கள் தனிக்குடித்தனம் நடத்த ஆரம்பித்துவிட்டார்கள். இனி ஸ்கீமாவை வடிவமைப்பது, அதை புரோகிராமில் பயன்படுத்துவது டெவலப்பர்களின் வேலை அல்ல. டேட்டாபேஸ் தெரிந்தவர்களே அதைச் செய்துவிடமுடியும். இன்னொன்றும் தெளிவாகிறது. ஜாவா, பைதான், டாட்நெட் என்றெல்லாம் அந்தந்த மொழிகளில் ஸ்கீமாவை எழுதத் தேவையில்லை. ஆவ்ரோ போன்றவை எந்த மொழியில் புரோகிராம் எழுதப்பட்டிருந்தாலும் சப்போர்ட் செய்கின்றன.
ஆவ்ரோ ஸ்கீமா, எளிமையாக JSON மொழியில் எழுதப்படுகின்றன. புரிந்துகொள்வதும், பயன்படுத்துவதும் எளிது. ஆவ்ரோ போல் த்ரிப்ட், புரோடாகாலபவ் என ஒரு சில பிரபலமான சீரியலைசேஷன் சிஸ்டம் உண்டு. ஆனால், மற்றவை code உடன் இணைந்து இயக்கப்படுபவை. ஆவ்ரோவுக்கு code தேவையில்லை. ஸ்கீமாவில் ஏதாவது மாற்றங்கள் இருந்தாலும் பிரச்னை வராது. காரணம், பழைய ஸ்கீமாவும், புதிய ஸ்கீமாவோடு உடன் இருக்கும். பிரச்னை வந்தால், என்ன காரணம், எந்த field மூலமாகப் பிரச்னை ஏற்பட்டது என்பதை உடனே சொல்லிவிடும்.
இதெல்லாம் எதற்காக? சிம்பிள். டேட்டாவை எப்படி உள்ளே அனுப்புவது, எப்படி வெளியே எடுப்பது என்கிற விஷயத்துக்காக நாம் மண்டையை உடைத்துக்கொள்ளக் கூடாது என்பதற்காக மட்டுமே. பிக் டேட்டா பக்கம் வராமல், ரிலேஷனல் டேட்டாபேஸை கட்டி மேய்ப்பவர்களில் 70 சதவீதம் பேர் ஸ்கீமா வேறுபாட்டால் (Schema Mismatch) நிம்மதி இழக்கிறார்கள். ஏராளமான நேரம் விரயமாகிறது. எதற்காக சிக்கலாக்கிக்கொள்ள வேண்டும்? எளிமையாகவே இருந்துவிடட்டும். கிஸ் அடிப்பது உடம்புக்கும், மனதுக்கும் நல்லது என்பார்கள். கிஸ் என்பது அது அல்ல, இது வேறு. KISS! அதாவது Keep it Short & Simple அல்லது Keep it Simple & Straight forward என்று ஒரு டஜன் அர்த்தம் சொல்லலாம். ஆனால், அசலான விரிவாக்கம் என்பது, Keep It Simple, Stupid!
(தொடரும்)