Яаж яваад Парис рүү нүүчихэв?

Унтах гэсэн чинь нойр хүрдэггүй.
Зүгээр сууж байхаар, яаж яваад Парист ирчихсэн талаараа бичье гэж бодлоо.

Токио ч дажгүй газар л даа. Тэгэхдээ таарах хүн, таарахгүй хүн гэж байдаг санагддаг. 10 жил Японд амьдарчихаад таараагүй гэх нь хайшаа ч юм. Тэгэхдээ удаан хугацаанд Японд амьдарч байгаад, хэсэг өөр улсад амьдраад, өөр амьдралын хэмнэлд байж байгаад буцаад Япон руугаа ирэхээр, яагаад ч амьдарч чадахаа больдог юм шиг санагдсан. Мэдээж хүн хүнээсээ болох байх. Миний хувьд, хамаг юм Сан Франциско руу ажлаар 1 жил явсанаас л эхэлсэн байх.

Амьдрах хэв маяг, цаг агаар, хүмүүсийн характер, хоорондын харилцаа гээд тэнгэр газар шиг л даа.

Анхнаасаа 1 жил л ажиллах гэрээтэй байсан тул, 1 жил болчихоод буцаад Токио руугаа явлаа. Эхний хэдэн сар, яаж ийм газар насаараа амьдрах юм гэж бодогдоод болдоггүй. Бүүр тэсэхээ байгаад, Сан Франциско дахь салбар руугаа бүр мөсөн шилжихээр бүх бичиг баримтаа хөөцөлдөөд, хүний нөөц болон хэлтсийн даргатайгаа яриад дууслаа.
Эхлээд H1B визээр өгч сугалаанд нь унаад, дараа нь L1 хөөцөлдөж байсан юм. Гэтэл headquarter гэнэт Сан Франциско дахь оффисыг хаахаар шийдээд, миний байсан western маркетийг хариуцдаг байсан багийг тараахаар болов. Үнэхээр ашиг олохгүй байгаа бол тараах нь logical шийдвэр л дээ. Тэгээд нэг сонин багт ороод, тэр цагаас хойш ер нь өөр компани руу оръё гэдгээ бат шийдчихсэн л дээ.

Эхлээд Токио дахь компаниудыг сонирхов. 2 компанид өгөөд уналаа. Тэгэхдээ яагаад ч юм унасандаа сүртэй харамсаагүй санагдаад байна.

Тэгээд нэг өдөр LinkedIn-ээ цэгцлье гэж бодоод, өмнө ирсэн mail-үүдэд хариу бичиж суутал, 2 сарын өмнө Испанид байдаг recruiter залуу Европ руу нүүхгүй биз гэж бичсэн байна.

Эхэндээ serious хүлээж авалгүй зүгээр л сонирхоё гэж бичлээ. Тэгээд Европын хэд хэдэн хотуудад хэдэн компани танилцууллаа. Хамгийн их таалагдсан нь Барселона, Парис 2 л байсан. Германыг уг нь инженерүүдэд их тааламжтай улс гэж сонсож байсан ч, яагаад ч юм Японы Европ хувилбарт оччих юм шиг санагдаад, Барселона, Парис 2т өгч үзэхээр шийдсэн юм. Барселонагийн компанид унасан, хаха.

Парисынх нь одоогийн компани. Skype-аар нийт 6, 7 удаа ярилцлага өгөөд оффероо авлаа. Эхэндээ бас Европ явж амьдрана гэж бодохоор нэг л төсөөлөгдөхгүй байсан тул, болохгүй бол 3 сар ажиллаад буцаад хүрээд ирье гэж бодоод, танидаг хүмүүстэй амралтаар явлаа гээд хэлээд явсан санагдаж байна, худлаа ярьсаныг маань уулчлана гэж найдъя.

Ярилцлагын хувьд:
Ер нь бол Америкийн компаниуд шиг, аймар нарийн кодчилолын чадвар шалгалгүйгээр, resume дээр үндэслээд л, бараг resume нь үнэн байна уу гэж шалгах гэж хэдэн технологийн асуулт асуугаад л болчихдог санагдсан. Мөн ярицлагын ихэнх хэсэг нь, миний юу мэдэх гэхээс илүүтэйгээр, намайг Парист яаж дасан зохицох уу гэдэг дээр л өрнөөд байгаа санагдсан. Стартап компани, мөн инженер эрчимтэй хайж байсан болохоор, сүртэй шалгуур тавиагүй ч байж болох юм.
Ярилцлага бол Япон компаниудыг санагдуулмаар.

Визны хувьд:
Европын холбоо чинь EU Blue Card гээд үнэн дажгүй визтэй юм байна. Тэгэхдээ энэ визний шалгуур болон, нөхцөлүүд нь улс болгон өөр. Жишээ нь Францын хувьд, шалгуур нь Францын дундаж цалингийн 1.5 дахин хэмжээнээс илүү цалин авах ёстой. Мөн виз нь 4 жилээр гарах тул, нэг хэсэгтээ виз сунгана гэж заваарахгүй (Япон 5 жилээр л дээ). Бас нэг нөхцөл нь, эхний 2 жил анх виз авсан компаниа сольж болохгүй. Тэгэхээр би нэг хэсэгтээ энэ компанидаа байна гэсэн үг. Энэ виз нь мөн, компани чинь шаардлагатай бичгийг чинь илгээвэл, маш хурдан гарна (7 хоног ч билүү).

Миний судалснаар, энгийн ажлын виз бас байдаг юм байна лээ. Тэрний нэг асуудалтай тал нь, заавал эндхийн OFII буюу цагаачлалын албанаас зөвшөөрөл авна. Тэр нь гарах эсэх нь мэдэгдэхгүй, гарах гэж бараг сар болно. Мөн гэр бүлтэй бол, тэд нарыгаа өөрийнхөө визэн доор оруулахын тулд, заавал 18 сар энд оршин суусан байх шаардлагатай. Тэгэхдээ 18 сарыг хүлээж байх хоорондоо аялалын визээр ирээд байж болдог л юм шиг байна лээ.

Хэрвээ EU Blue Card-ын талаар сонирхож байвал доорх link-ээр уншаарай
https://www.apply.eu/Questions/

2018 оны 11-р сарын 4-ны өдөр by Өдрийн тэмдэглэл 0

Data Scientist болон BI(Business Intelligence) Analyst-ын тухай товчхон

Сүүлийн хэдэн жил trend болж байгаа, Data Scientist болон BI(Business Intelligence) Analyst гэсэн 2 мэргэжлийн талаар хальт бичмээр санагдлаа. Би яг мэргэжлийн хүн биш болохоор андуурсан зүйл байвал залруулаарай.

Орчин үед технологийн компаниуд ямар нэгэн бүтээгдэхүүн гаргачихаад хаячихдаг цаг байхаа больсон. Өрсөлдөөн их тул ямагт сайжруулж, хэрэглэгчийн needs(хэрэгцээ, шаардлага) болон үйл хөдлөлд тааруулж байнга өөрчилж байхгүй бол, өрсөлдөөн ихтэй салбарт амьд гарах боломжгүй юм.

Хэрэглэгчийн юу хүсэж байгааг хэрхэн мэдэх вэ? Яахав анкет явуулаад асуултууд асууж болох юм. Тэгэхдээ 100 хүн рүү анкет бөглөх хүсэлт явуулахад хэд нь хариулдаг гэж бодож байна? 1-2 нь хариулбал их юм. Бас нэг өөр асуудал нь, хэрэглэгчид өөрсдөө ч юу хүсээд байгаагаа мэдэхгүй тохиолдлууд их юм. Бас яавал хэрэглэгчдийг өөрсдийнхөө бүтээгдхүүнд зарцуулах мөнгийг боломжит хамгийн ихээр өсгөх вэ? Эдгээр асуудлуудыг шийдхийн тулд, сүүлийн хэдэн жилүүдэд компаниуд бараг хэрэглэгчдийн бүх үйл хөдлөлүүдийг цуглуулж эхэлсэн юм. Жишээ нь хэрэглэгчид ямар хуудас руу орсоныхоо дараа, ямар хуудас руу шилжиж байна, эсвэл ямар хуудсан дээр илүү их цаг зарцуулж байна, эсвэл ямар хэрэглэгч нар ямар бүтээгдхүүнд илүү мөнгө зарцуулж байна гэх мэт. Таны үйлдэл бүр чинь бүртгэгдэж байгаа гэсэн үг. Эдгээрийг raw data гэх бөгөөд, хүн ойлгохын аргагүй асар их мэдээллүүд(big data) юм.

BI Analyst нь хэрэглэгчдээс цуглуулсан raw data-г хүн ойлгогдохоор болгож, түүн дээрээ суурилан, шинэ бүтээгдхүүнийг санаачлах болон, одоогийн бүтээгдхүүнийг сайжруулах тал дээр ажиллана.

Data Scientist нь мөн адил хэрэглэгчдээс цуглуулсан raw data-г хүн ойлгогдохоор болгох ба, түүн дээрээ суурилан ирээдүйн төлөвийн prediction(таамаглалт) хийнэ.

Өөрөөр хэлбэл энэ 2 мэргэжил 2-уулаа хэрэглэгчдээс цуглуулсан асар их мэдээлэл дээр ажиллана.

Жаахан тодорхой болгох үүднээс маш энгийн жишээ авъя. Нэг хэсэг бараг хүн болгон тоглож байсан Candy Crash гээд тоглоом байлаа гэж үзье. Тэр тоглоом чинь, таныг хэддүгээр үе дээр хэдэн минут зарцуулж, хэдэн удаа хожигдож, хэр их мөнгө зарцуулж ялсан бүх мэдээллийг тухайн компани руугаа дамжуулна. Эдгээр мэдээлэл дээр үндэслэн, BI Analyst нь game balance(хэтэрхий хүнд level-ын дараа хэтэрхий амархан level байхгүйгээр, бага багаар хэцүү болох)-ийг сайжруулах, эсвэл аль level дээр хүмүүс хэтэрхий их тоглосноосоо болж гэнэт уйдаж, тоглоомыг гэнэт дахин тоглохоо больж байгааг судалж, тэр level-ыг сайжруулах гэх мэт зүйлүүд хийнэ. Харин Data Scientist нь мөн л адилхан мэдээлэл дээр үндэслэн, дараагийн сард хэрэглэгчдийн тоо хэдэн хувиар нэмэгдэж, орлогод ямар өөрчлөлт орохыг таамаглах юм.

Яагаад энэ 2-ыг бичих болсон бэ гэхээр, их сургуулидаа математик болон статистикийн хичээл авч байсан, SQL(R мөн ашигладаг юм шиг байна лээ)-ын бага зэргийн мэдлэгтэй бол ямар ч хүн эдгээр 2 мэргэжил рүү төвөггүй хөрвөж чадах юм шиг санагдаад энэ 2-ын талаар бичлээ. Мөн цалингийн хувьд ч гайгүй тул, одоо хийж байгаа ажлаасаа уйдаж байгаа хүн байвал судлаж үзээрэй.

2017 оны 1-р сарын 17-ны өдөр by Танин мэдэхүй 0

Өгөгдлийг scaling хийх нь

Та нэг энгийн web server болон өгөгдлийн сангаас бүтэх систем хийлээ гэж үзье. Хэрвээ тэр систем чинь ачаалал даахгүй байвал яах вэ?
Хэрвээ web server чинь ачааллаа даахгүй байгаа бол шийдэхэд амархан Яг адилхан 1 instance үүсгэхэд л хангалттай.
Харин өгөгдлийн сан чинь ачааллаа дийлэхгүй бол шийдэхэд нэлээн яривигтай. Мэдээж эхний алхам бол бүх хандалт(query)-аа optimization хийх, хэд хэдэн давхар cache давхарга нэмэх.
Ихэнх системийн хувьд өгөгдөл унших тоо нь бичих тооноосоо хэд дахин, эсвэл хэдэн арав дахин их байдаг. Жишээ нь, хүмүүс Facebook-ын profile-аа сардаа эсвэл бараг жилдээ 1 л өөрчилдөг байх. Харин тэр хүний profile-ыг өдөрт хэдэн арваас, хэдэн зуун хүн харж байгаа. Тиймээс, таны хийж буй систем чинь, яг үүнтэй адил уншилтын тоо нь бичилтийн тооноосоо хамаагүй их бол, master-slave загвар луу шилжүүлж болох юм.

Master Толгой өгөгдлийн сан ба, бүх бичилтүүд ийшээ хийгдэнэ
Slave Дагавар өгөгдлийн сан ба, бүх уншилтууд эндээс хийгдэнэ

Ажиллах зарчим нь маш энгийн. Master луу бичилт хийх болгонд master нь slave-үүд рүүгээ давхар бичилт хийгээд шинэчлээд, бүх server дээрх мэдээлэл яг адил мэдээлэл агуулаад явах юм. Үүнийг replication гэж нэрлэдэг. Харин одоо их хэмжээний унших хүсэлт ирэхэд slave-үүд рүүгээ тэнцүү хуваагаад явуулчихна. Дараах зурганд дүрслэх гэж оролдлоо.

Replication

Ихэнх төрлийн өгөгдлийн сангууд replication хийх чадвартай бөгөөд, ихэнхдээ 2 төрөл байдаг. Sync болон async. Sync replication нь бичих хүсэлт авангуутаа slave-үүдээ шинэчлэх бөгөөд, шинэчилж дууссаны дараа, бичилт амжилттай боллоо гэсэн хариултыг буцаана. Харин async нь, master дээр бичилтээ хийсэний дараа бичилт амжилттай боллоо гэсэн хариуг буцаагаад, дараа нь slave-үүдээ шинэчилнэ.
2 арга нь 2-уулаа сайн ба муу талуудтай бөгөөд, хамгийн гол анхаарах ёстой зүйл гэвэл consistency юм. Async үед inconsistent буюу, нэг агшинд нэг өгөгдөл, 2 өөр утга агуулах боломж үүсч байгаа юм. Өөрөөр хэлбэл дөнгөж бичсэний дараа, уншилт хийвэл хуучин утга уншигдах магадлалтай гэсэн үг.

Харин одоо, бүүр их ачаалаллын талаар ярилцая. 100 сая хэрэглэгчийн мэдээлэл хадгалах ёстой гэж үзье. Урьдчилсан тооцооны дүнд 10 сая хэрэглэгчийн мэдээлэлийг 1 server-т хадгалахад ачаалал даана гэж үзье. Тэгвэл одоо бидэнд 1 биш 10 master хэрэг болно. Өөрөөр хэлбэл 1 том хүснэгтийг 10 жижиг хэсэг болгож хувааж байнаа гэсэн үг. Үүнийг sharding гэх бөгөөд, хуваагдсан хэсгүүдийг shard гэнэ. Дараах зурганд дүрслэв.

Sharding

Янз бүрийн байдлаар хувааж болно. Жишээ нь 1-1000000 ID-тай хэрэглэгчийг Master 1-д, 10000001-20000000 ID-тай хэрэглэгчдийг Master 2-т гэх мэт. Эсвэл 10-т хуваагаад гарах үлдэгдлээр нь 10 master-руугаа хувааж болно. Эсвэл хэрэглэгчийн амьдарч буй улсаар нь гэх мэт, хамгийн гол нь системдээ тааруулаад, яаж хуваавал хамгийн хялбар аргаар хүссэн мэдээлллээ авч чадах вэ, мөн ачаалал болон, мэдээллийн хувьд тэнцвэртэй баланстай байж чадах уу гэдгийг бодох хэрэгтэй.
Жишээ нь Facebook дээрх post-ын comment-ыг хадгалах ёстой гэж үзье. Тэгвэл comment-ынх нь ID-аар биш, post-ынх нь ID-г ашиглан sharding хийвэл, адил post дээрх бүх comment-ууд нэг server дээр хадгалагдах тул, comment-уудыг уншихын тулд, олон server-рүү хандах шаардлагагүй болох юм.

Эцэст нь нэг юм хэлэхэд, энд нэг ч өгөгдлийн сангийн нэр(MySQL, MongoDB гэх мэт) дурдаагүй байгааг анзаарсан байх. Ямар ч өгөгдлийн сан дээр, автомат sharding байсан ч, ард нь нэг иймэрхүү л зүйл явагдаж байгаа гэдгийг ойлгуулах гэсэн юм. KVS төрлийн NoSQL-уудын хувьд, key-ийнхээ hash-аар хуваадаг ба ихэнх нь автоматаар, эсвэл хангалттай их library-ууд байдаг тул хөгжүүлэгч талаас нээх асуудал гараад байхгүй. Харин RDBMS-үүдийн хувьд, системийн шаардлага янз бүр тул, бараг өөрсдөө системдээ тохирсон sharder хөгжүүлж таарах байх.

2016 оны 1-р сарын 24-ны өдөр by Танин мэдэхүй 7

Microservices

Microservices нь нэгэн төрлийн архитектур загвар юм. Microservices-ын талаар ярихын өмнө, эхлээд дараах ойлголтуудыг тайлбарлъя.

Monolithic – Энэ нь, нэг бүхэл гэсэн утгатай бөгөөд, хийж байгаа систем чинь тэр чигээрээ ганцхан хэл дээр бичигдсэн нэг бүхэл код байхыг хэлнэ. Монголд хийгдэж байгаа вебүүдийн ихэнх нь ийм байх гэж бодож байна. Мөн олон startup компаниуд, анх гарч ирэхдээ ийм загвартай байдаг.

Microservices – Энэ нь, систем чинь олон жижиг системээс бүрэлдхийг хэлж байгаа юм. Жишээ нь онгоцны тийз захиалдаг систем байлаа гэж үзвэл, тооцоо хийдэг систем, хайлт хийдэг систем, худалдаж авсан тийзийг илгээдэг систем гэх мэт, бизнес логиктойгоо уялдуулан, хоорондоо харилцах чадвартай олон жижиг систем хөгжүүлэх юм.

Polyglot Microservices – Энэ зүгээр л microservices. Харин, бүх систем чинь адилхан хэл дээр хөгжүүлэлт хийгдсэн байх албагүй, системийн онцлогоос хамааран өөр өөр хэл дээр хөгжүүлэгдсэн байхыг ингэж нэрлэнэ.

Microservices-ын талаар бага зэрэг ойлголттой болсон байх. Хэрвээ жижиг систем хөгжүүлж байгаа бол, зүгээр monolithic-ээр явсан нь дээр байх. Нэг нийтлэл уншиж байхад, “систем хөгжүүлэлтийн сүүлийн шат нь microservices юм” гэсэн байна лээ. Тэгэхээр, системийн чинь хэрэглэгчийн тоо нь ихсээд, scaling шаардлагатай болж ирэх үед, нэгэн төрлийн сонголт болгон харахад гэмгүй болов уу.

Одоо microservices давуу талуудын талаар ярилцъя.

Хялбар код менежмент болон хөгжүүлэлт
Monolithic системийн хувьд, ямар нэгэн шинэ зүйл нэмэх болгонд кодын чинь хэмжээ ихсэнэ. Бүхэл нэг код тул, аль нэг газар алдаа гаргахад л бусад газарт нөлөөлөх болно. Мөн, хөгжүүлэгч бүр тэр код руу хандаж байгаа тул, явцын дунд, хэн нь аль хэсгийг хариуцаж байгаа нь харагдахаа больж эхлэнэ. Харин microservices-ын хувьд, систем тус бүр тус тусдаа кодтой байх тул, кодын хэмжээ замбараагүй өсөж хяналтаас гарахаас сэргийлж чадах юм. Мөн систем бүрийг тусгай багуудад хариуцуулснаар, тэр систем нь өөрийн гэсэн эзэнтэй болж, байнга арчилж, сайжруулахад амар болно. Мөн дараагийн хувилбарыг тэс өөрөөр хийхээр шийдсэн бол, зөвхөн тэр системээ л дахин бичихэд хангалттай. Харин monolithic системийн хувьд, аль хэдийн өөр зүйлүүдтэй хэт уялдаа хамааралтай болчихсон байх тул, өөрчлөлт хийхэд хэцүү байх болно.

Availability
Монгол хэл рүү юу гэж орчуулахаа мэдсэнгүй. Ер нь бол, систем чинь унахгүй, зогсолтгүй ажиллах чадвар л юм уу даа. Monolithic системийн хувьд, нэг газар л алдаа гарахад систем чинь тэр чигээрээ унах магадлалтай. Жишээ нь асар том PHP дээр бичигдсэн систем байлаа гэхэд, нэг semicolon мартахад л систем чинь тэр чигээрээ зогсоно.
Харин microservices-ын хувьд, ямар систем унаснаас хамаарч систем-ын зарим хэсгүүд ажиллах боломжтой юм.

Уян хатан scaling
Одоо бараг ихэнх газрууд auto-scaling хийдэг болсон байх. Серверийн ачааллаас хамаараад, шинэ instance үүсгэх эсвэл устгадаг. Microservices-ын хувьд систем тус бүр дээр scaling хийх боломжтой юм.

Гэх мэт олон давуу талтай юм. Өөр давуу талууд бас байгаа, тэгэхдээ яг одоо санаанд орж ирэхгүй байна.

Жишээ болгож миний блогоо бичиж байгаа WordPress-ыг monolithic болон microservices байдлаар дүрслэх гэж оролдъё.
Monolithic WordPress
Microservices WordPress (2)

Харж байгаачлан, microservices загвар нь жижиг систем болон, цөөн хүнтэй компанид тохиромжгүй байж мэдэх юм. Харин дээр дурьдсанчлан, хэрвээ хэрэгчлэгчийн тоо ихсээд scaling хийх шаардлагатай болсон үед хэрэгтэй загвар юм.
Миний мэдэхээр ямар ч байсан, Amazon, Netflix, LinkedIn гэх мэт бараг бүх их хэрэглэгчтэй компаниуд microservices загварыг ашигладаг. Миний хувьд, өөрөө ийм архитектур гаргаж байгаагүй ч, одоо ажиллаж байгаа прожект дээр, ирээдүйд ийм загвар луу шилжих талаар ярилцаж байгаа болохоор судалж байгаа юм.

За дараагийн бичлэгээр уулзах хүртэй баяртай!

2016 оны 1-р сарын 23-ны өдөр by Танин мэдэхүй 1

Сан Франциско .vs Токио

Сан Францискод ирээд 8 сар болчихлоо. 8 жил амьдарсан Японтойгоо хальт харьцуулж юм бичмээр санагдлаа.
Ер нь бол нэлээн таалагдаж байгаа. Өөрийнхөө мэргэжлийн хүмүүсийн талаас хараад харьцуулж бичье.

Цалин
Дундаж цалин Токиогоос 2-4 их. Хэрвээ үнэхээр чадвартай бол дээд хязгаар бараг байхгүй. Тэгэхдээ өртөг бас адил 2-4 дахин их. Тэгэхээр, цалингаас зардлаа хасаад үлдэх мөнгө(saving) чинь бас 2-4 дахин их гэсэн үг.
Зардлын хамгийн их хэсгийг нь байр эзлэнэ. Токиод бол 1000$ гаран байранд төлдөг байсан бол, энд 4000$ орчим. Хэрвээ гэр бүлтэй бол, suburb-уудад л амьдарсан нь дээр.

Ажиллах орчин
10, 11 гэж ирээд 6, 7 гээд тарна. Токиод бол бараг 9-өөс орой 10, 11 хүртэл ажиллах бол энгийн үзэгдэл байлаа.
Бас эндхийн компаниуд эхнээсээ хязгааргүй цалинтай амралттай болж эхэлж байгаа. Манай эндэх оффис бас хязгааргүй. Менежертэйгээ ярьж тохироод, ажил цалгардхааргүй бол амралтаа дуртайгаараа авна.
Бас гэрээсээ ажиллаж болно. Цаг нь flex time болохоор, ажлаа хийж байвал, дуртай үедээ ирээд дуртай үедээ харьж болно. Тэгэхдээ, мэдээж хурал нтр-дээ суух хэрэгтэй. Япончууд шиг flex time гэчихээд, өглөө 10-т, орой 6-д хурал оруулж новшрохгүй. Ер нь бол life balance сайн.
Хамт ажиллаж байгаа хүмүүс нь үнэн дажгүй. Чадахгүй гарууд нь, эсвэл ядаргаатай зантай гаруудыг халчихдаг болохоор, дандаа гайгүйнүүд нь шигшигдээд үлдчихдэг юм шиг байгаан. Токиод нээх ядаргаатай хүмүүстэй хамт ажиллаж байгаагүй ч, өөр багийн 2, 3 хүнтэй хэрүүл хийж байсан удаа бол байгаа. Тэд нар бол энд 7 хонохгүй халагдана.
Бас ажил дээрээ зүгээр найз нтр ээ дагуулаад ороод ирж болно. Нэг залуу ямар ч байсан, интернетээр танилцсан гээд нэг залууг ажил дээр өдрөөс орой хүртэл байлгасан нь, үнэхээр сонин санагдсанаа нуух юун. Зарим компани, амьтад бас зөвшөөрдөг тул нохой муур нтрээ аваад ирж болно.
Ер нь ажлаа хийж чадаад, мал зан гаргахгүй явж байвал асуудалгүй, эрх чөлөөтэй.
Бас миний мэдэх ихэнх компаниуд хоол нь цаанаасаа болохоор, ажлын өдрүүдэд бараг мөнгө үрэхгүй.

Боломж
Хэрвээ өөрөө ямар нэгэн startup байгуулмаар бол, хөрөнгө оруулагч нар энд хөрөнгө оруулъя гээд сууж байна. Бараг өдөр болгон хөрөнгө оруулагч болон, шинийг санаачлагч нарыг холбох event болно. Мэдээж, хүн болгонд шинээ санаа байгаа болохоор өрсөлдөөн их.
Бас мэргэжил нэгт хүмүүс их болохоор, бүх төрлийн мэдлэгээ солилцох уулзалт болно. Ажлаа солимоор бол, компаниуд чадвартай инженер авах гээд очерлоод байж байна.
Байнга, LinkedIn-ээр чинь, энд тэндхийн компаниудын recruiter-ээс mail ирнэ.
Үе үе, зарим компаниуд, зөвхөн инженерүүдэд зориулсан party зохион байгуулж, LinkedIn-ээр иниженерүүд лүү party-нийхаа урилгыг явуулж, ажилд авахыг оролдоно.
Ер нь юу хиймээр байна, тэр чигэлэлээр чинь ажиллаж байгаа компани бол заалттай байна.

Виз
Виз бол бараг дэлхийд хамгийн хэцүү нь байх. Энэтхэг, Хятадын шилдэг сургуулиудыг төгссөн инженерүүд, энд ирэх гээд очер үүсгэчихсэн байгаа байх. Ажиллахын тулд, H1B гэдэг виз хэрэгтэй.
Тэрийг нь авхын тулд, 4 сараас өмнө offer авах ёстой. Тэгээд, offer авсан компани чинь 4 сараас чиний өмнөөс apply хийнэ. жил бүр 200 мянга гаран хүн apply хийгээд 65 мянган хүн тэнцэнэ. Өөрөөр хэлбэл, чинийн гарал угсаа, чадвар, offer өгсөн компаниас чинь үл хамааран, чиний Америкт ажиллах эрх авах магадлал чинь 30% гэсэн үг. Хэрвээ чи азтай 30%-ын нэг бол, 10сараас эхлэн ажиллах эрхтэй болно.
Харин нэгэнт H1B визтэй бол зүгээр шилжүүлчихэж болно. Тэгэхээр H1B-гүй бол, сонголт бол хэдхээн том компаниуд, эсвэл энд ирж master degree хийхээс өөр аргагүй болно гэсэн үг.
Ямар ч байсан, аймар чадвартай байж, зүгээр л виз авхын тулд, master degree-ээр Америкт ирсэн хүмүүстэй зөндөө таарч байсан.

Аюулгүй байдал
За энэ талаар юу ч харьцуулахав. Бараг өдөр болгон л хүн буудуулж үхдэг юм шиг байгаан, энд.
Тэгэхдээ Токиог бодвол хамаагүй жижигхэн хот, дээрээс нь taxi-ний үйлчилгээ хямд болохоор, хаалган дээрээс машин дуудаад, хаалган дээр буугаад байхад гайгүй.

Эмхэтгээд хэлэхэд, хэрвээ гэр бүл нтргүй бол, энд ирсэн нь л дээр юм шиг санагдсан. Мэдээж хүн хүний бодол, эрхэмлэх зүйл өөр.

2015 оны 12-р сарын 12-ны өдөр by Өдрийн тэмдэглэл 2

DNA ба бидний амьдрал 2

2 жил гарангийн өмнө блог дээрээ DNA ба бидний амьдрал гэдэг post бичиж байсан юм. Тэрнийхээ үргэлжлэлийг бичье гэж бодлоо.

Яагаад computer science-ээр төгсчихөөд DNA сонирхоод байгаагаа эхлээд жаахан тайлбарлая. Миний бодлоор эрүүл мэндийн шинжлэх ухаан нь, бусад шинжлэх ухаануудаас хоцролттой явагдаж байгаа юм шиг санагддаг. Бидэнд одоо болтол эдгээж чадахгүй өвчнүүд, шалтгааныг нь олоогүй шинж тэмдэгүүд(symptoms) байна. Харин сүүлийн жилүүдэд, хүний DNA-г хямд зардлаар бүгдийг нь тайлж унших боломжтой болж, мөн судалгаа хийхэд хангалттай их хэмжээний сан үүсгэгдэж байна. Компьютерийн шинжлэх ухааны хүмүүс ихэнхдээ тоон өгөгдөл дээр ажилладаг. Харин биологичид маань, хүний эсийг тоон хэлбэрт шилжүүлж чадсанаар, бид нарт ч гэсэн түүн дээр ажиллах боломж үүсч байгаа юм. Мөн, компьютерийн шинжлэх ухааны хиймэл оюун гэх мэт ухагдхуунуудыг ашиглавал, DNA судалгааг хүчтэй түрж өгөх юм шиг санагдаад байгаа юм. Миний хувьд учиргүй хувь нэмрээ оруулдаггүй юмаа гэхэд, ядаж хүний хийсэн судалгааны ажлыг уншиж ойлгоод, тэрэнд нь таарсан алгоритм бичих чадвартай болохыг зорьж байгаа болно.

Би мэргэжлийн хүн биш тул, миний бичсэн зүйлүүдэд алдаа байхыг үгүйсгэхгүй. Тиймээс ямар нэгэн зүйлийн эх сурвалж болгож битгий ашиглаарай.
Мөн, алдаатай хэсгийг залруулж өгвөл баярлана.

За гол зүйлдээ оръё. Тэгэхээр DNA-ын талаар бүх хүмүүс бага зэрэг мэдлэгтэй байх. Хүн 23 хос chromosome-той ба, эдгээрийн 22 нь autosomal буюу хүйсээс үл хамааран бүх хүнд байна.
Харин үлдсэн 1 хос нь X болон Y chromosome-оос бүрдэх ба, эмэгтэй хүнд XX, харин эрэгтэй хүнд XY гэж хослон байна. Эдгээр chromosome-ууд нь олон хэмжээний gene агуулна. Gene гэдэг нь, DNA-ын бяцхан хэсэг буюу, олон хэмжээний base pair-үүдийн цуглуулга юм.
Chromosome тус бүрийн gene, болон base pair-ийн тоог эндээс харж болно.

SNP(Single Nucleotide Polymorphism)
Хэрвээ тодорхой байрлалд хүн амын 1-ээс дээш хувь нь ижил утгатай биш байх юм бол, тэдгээрийн утгуудын олонлогийг SNP гэнэ.
Жишээ нь: 1000 хүний мэдээлэлтэй сан байлаа гэж үзье. 900 хүний, 1 дугаарын chromosome-ын 6546 гэсэн байрлалд A гэсэн утга, харин үлдсэн хүмүүсийнх нь G гэсэн утга байвал, энэ нь SNP болно. Харин 999 хүн нь A, үлдсэн нэг нь л G байх юм бол, SNP биш гэсэн үг.
SNP нь эрүүл мэндтэй холбоотой судалгаа шинжилгээ хийхэд маш хэрэгтэй зүйл юм. Харин нэг анхаарах ёстой зүйл бол 1% гэсэн шалгуур байгаа эсэхийг мартаж болохгүй. Тиймээс нэн ховор генетикийн өөрчлөлтүүд дээр SNP ашиглан судалгаа хийх боломжгүй гэсэн үг юм.
Яагаад SNP ашиглах шаардлагатай гэж? бодож магад. Миний ойлгосноор, бүтэн DNA нь хэт том хэмжээтэй тул, тэр их өгөгдлийг тодорхой хэмжээнд багасгахыг зорьсон. Мөн, хүний бүтэн DNA-г гаргаж авсанаас, SNP microarray ашиглан зөвхөн SNP байгаа байрлалуудын утгыг гаргаж авах нь зардлын хувьд хамаагүй хямд юм. Бүтэн DNA гаргаж авахыг DNA sequencing, харин тодорхой байрлал руу чиглэсэн тандалтыг DNA genotyping гэнэ.

MAF(Minor Allele Frequency) болон minor allele
Ихэнх SNP-үүд нь biallelic буюу, 2-хон төрлийн утга авна. Өөрөөр хэлбэл, A, T, C, G-ын аль нэг 2 нь гэсэн үг. Мэдээж энэ нь одоог хүртэл бүрдүүлсэн сан дээр үндэслэж байгаа тул, ирээдүйд triallelic-ууд олноор гарч ирэхийг үгүйсгэхгүй.
Minor allele(эсвэл risk allele) нь, 2 утгын аль бага давтамжтай нь юм. Өөрөөр хэлбэл, зөвхөн A болон G гэсэн утга авдаг SNP байлаа гэж үзье. 100 хүний 90 нь A, 10 нь G бол, G нь minor allele болно. Зарим тохиолдолд minor allele байсан ч эсрдэлтэй байх албагүй юм. Эсрэгээрээ сайн байх тохиолдлууд мөн байна.
Мөн MAF нь, хүний race болон, гарал угсаанаас хамааран бүлэг тус бүрт өөр байх боломжтой болно.

dbSNP
dbSNP нь NCBI(National Center for Biotechnology Information) гээд АНУ-ын биотехнологийн хүрээлэнгийн сан юм. Эндээс хүссэн SNP-ын мэдээллийг авах боломжтой. Жишээ нь rs16942 буюу хөхний хорт хавдар үүсгэдэг BRCA1 гэдэг gene-ы нэг SNP-ыг харвал доорх байдлаар харагдана.
rs16942
RefSNP Alleles гэдэг хэсгийг харвал A болон G гэдэг утга агуулдаг, өөрөөр хэлбэл biallelic гэдгийг харж болно. MAF гэдэг хэсгийг харвал, G-нь minor allele(хүн амын 35% нь G) гэдгийг мэдэж болно. Мөн Ancestral Allele гэдгийг харвал, хүн болж хувьсан өөрчлөгдхөөс өмнө ямар байсныг харж болно. Ancestral Allele нь chimpanzee-ын DNA дээр үндсэлсэн байдаг.

Raw DNA Data
23andme болон AncestryDNA гэх мэт компаниуд нь DNA genotyping аргаар, боломжийн үнээр таны SNP-г тодорхойлж өгдөг юм. Таны DNA өгөгдөл дараа байдлаар харагдах болно.

rsID         chromosome    position    allele1      allele2
rs4477212             1       72017          A            A
rs3094315             1      742429          A            A
rs3131972             1      742584          G            G
rs12124819            1      766409          G            G

Эхний багана нь SNP-ын дугаар, 2 дахь нь chromosome-ын дугаар, 3 дахь нь байрлал, харин 4 болон 5 дахь таны 2 хос chromosome дахь 2 allele болно.

Өнөөдрийн хувьд, энэ хүртэл бичье. Дараа завтай болхоороо үргэлжлүүлнэ ээ.

2015 оны 12-р сарын 8-ны өдөр by Өдрийн тэмдэглэл 1

Монгол хүн гэдгийг яаж тодорхойлох вэ?

Нэлээн дээх нь төмөр замтай холбоотой нэвтрүүлгээр нэг нэгнээ Монгол биш Хятад гаралтай гэж дайрцгааж байх үед, энэ талаар бичмээр санагдсан ч залхуу хүрээд бичээгүй юм. Харин, өчигдөрхөн Карим Абдул гэдэг хүн нэгэн дуудлага худалдаагаар Улаанбаатарт газар авсаныг олон хүн Монгол биш хүнд газар худалдлаа гэж шүүмжилсэн болохоор бичмээр санагдлаа.
Миний хувьд, Карим Абдул-д газар худалдсаныг зөв эсвэл буруу-г, үнэхээр засгийн газрын ордонд ойрхон байрлалтай газрыг худалдахын зөв бурууг шүүхгүй.
Харин энэ дуудлага худалдаа хууль ёсных уу, мөн Монгол хүн гэдгийг яаж тодорхойлох вэ гэдэг талаар бичмээр санагдлаа.

Хүмүүс Монгол цус гэж ярих дуртай. Харин хүнийг цусаар нь Монгол гэж тодорхойлох боломж бий юу? Та бүхэн мэдэж байгаа бол, цус нь 4-хөн бүлэгтэй. Тиймээс цусны бүлгээр тодорхойлох ямар ч боломжгүй гэдэг нь ойлгомжтой. Харин DNA маш өргөн хүрээний мэдээлэл агуулдаг тул, тэр хүний гарал угсааг тодруулж болно.
Ямар аргаар тодруулах вэ гэхээр, эхлээд Монгол хүмүүсийн DNA-уудыг цуглуулаад, нийтлэг шинжэд нь тулгуурлан, Монгол хүн гэдгийн шийдэх алгоритм зохионо. Тэгээд тэр алгоритмоороо, Монгол гаралтай эсэхийг шийдэж болно.
Тэгэхдээ энэ аргад асуудлууд их байгаа. Хэрвээ DNA цуглуулсан хүмүүс маань, хэдэн мянган жил Монголын газар нутагт амьдарсан хүмүүс биш, 500 жилийн өмнө нь ч юмуу өөр газраас ирсэн хүмүүс бол яах вэ? Тэгвэл бидний зохиосон алгоритм алдаатай ажиллана. Мэдээж хангалттай их sample цуглуулж чадвал, мэдээж Монгол хүний DNA-ын онцлогийг гаргаж чадна.
За гаргаж авлаа гэж үзье. Бараг гаргаад авчихсан байгаа байх.
Тэгвэл тэр шалгуураараа, одоо Монголд байгаа 3 сая иргэнийг шүүж үзвэл, хэдэн хувь нь Монгол гэж гарах бол? Харин шалгуурт тэнцээгүй хүмүүсээ яах вэ? Монголчуудын ихэнх нь 3, 4 үеэсээ дээш сайн мэдэхгүй. 3, 4 үеэрээ Монголд амьдраад, өөрийгөө цэвэр Монгол гэдэгт итгэдэг хэрнээ шалгуурт тэнцээгүй байвал яах вэ? Тэдгээр хүмүүс Монгол хүн мөн үү?
Бас өөрөөр ингэж үзье. Хятадын бүх иргэдийг, Монгол DNA-ын шалгалтанд оруулбал хэдэн хувь нь тэнцэх бол? 1.3 тэрбум хүний маш бага хувь нь тэнцэхэд л хэдэн сая хүн болох байх. Тэдгээрийг Монгол цустай, Монгол хүн гэж үзэх үү?

Тэгэхээр, хүний цусыг шинжэлж Монгол эсэхийг тодорхойлох асуудал бол ер нь боломжгүй зүйл юм. Харин, иргэншсэн нийгэмд, хүний иргэншлийг хуулиар шийддэг. Ихэнх улсад, тэр улсдаа төрсөн бол автоматаар иргэн нь болно. Мөн, иргэн болох хүсэлтээ гаргаад иргэн болох боломжтой. Монгол улсын хувьд, дараах 3 шалгуурт тэнцвэл иргэн болох хүсэлтээ гаргаж болно.

1. Амжиргааны зохих чадвар, эх үүсвэртэй байх
2. Монголын ард түмний ёс заншил, төрийн албан ёсны хэл, Монгол Улсын Үндсэн хуулийн талаар зохих мэдлэг эзэмшсэн байх
3. Монгол Улсын нутаг дэвсгэр дээр таваас доошгүй жил байнга оршин суусан байх

Эх сурвалж: http://immigration.gov.mn/new/?p=436

Тэгэхээр Карим Абдул гэдэг хүн 30 гаруй жил Монголд амьдарсан бол, энэ шалгуурт тэнцэх нь бараг ойлгомжтой. Хэрвээ нэгэнт Монгол улсын иргэн болсон бол, үндсэн хуулийн дагуу шашин шүтлэг, гарал угсаа үл хамааран тэгш эрхийг эдлэнэ.
Хэрвээ дуудлага худалдаад орохыг нь түтгэлзүүлбэл, үндсэн хууль зөрчсөн хэрэг болно. Ардчилсан улсад, үндсэн хуулийг хүнд нь тааруулж өөрчлөх асуудал бол байж боломгүй зүйл.

Харин ирээдүйд ийм зүйл болохоос хэрхэн сэргийлэх вэ? Монгол улсад хэрэгжиж буй хуулиар, гадаадын иргэн газар өмчлөх эрхгүй, зөвхөн тодорхой хугацаатайгаар ашиглах боломжтой. Өөрөөр хэлбэл газар өмчлөхийн тулд, заавал Монгол улсын иргэн болох ёстой. Тэгэхээр Монгол улсын иргэн болох шалгуурыг өндөрсгөхөөс өөр арга байхгүй л гэж бодож байна.
Дашрамд дурдахад иргэн нь болоход хамгийн хэцүү 5 улсын тухай доорх линкээс уншаарай.
http://www.investopedia.com/articles/personal-finance/121114/5-hardest-countries-getting-citizenship.asp

2015 оны 12-р сарын 1-ны өдөр by Өдрийн тэмдэглэл 0

A/B Testing

A/B Testing-ын талаар ярья. Энэ удаад, технологийн талаас нь биш, яг юу болох, яагаад хэрэгтэй вэ гэдэг талаас нь ярья.
Нэг жишээ авья. Counter Strike тоглоом анх эхлэхдээ 800$-тай эхэлдгийг бараг бүгд мэдэж байгаа байх. Мөн, нийт мөнгөний хэмжээ 16.000$-оос хэтэрдэггүй.
Тэгвэл эдгээр тоог яаж шийдэх вэ? Counter Strike-ыг бүтээгчид, A/B testing ашигласан үгүйг мэдэхгүй, тэгэхдээ ямар ч байсан нэг нөхөр дуртай тоогоо хэлээд 800$, 16.000$ гэсэн 2 тоог шийдээгүй нь ойлгомжтой. Тэгвэл яаж шийдэх вэ?
Мэдээж судалгаа хийнэ. Тоглоомоо release хийснийхээ дараа, хэрэглэгчдээ хэсэг бүлэг болгож хуваагаад, 400$, 500$, 600$, 700$, 800$, 900$ гэх мэт мөнгийг анх өгнө. Бас бүлэг тус бүрт 14.000$, 15.000$, 16.000$, 17.000$ гэх мөнгүүдийг дээд хязгаар болгон тогтоож өгнө.
Дараа нь тоглогчид 1 удаа тоглохдоо хэр удаан тоглож байна, өдөрт хэдэн удаа тоглож байна, амьдралынхаа турш хэр их тоглож байна, хэр их мөнгө энэ тоглоомонд зарцуулж байна, гээд янз бүрийн үзүүлэлтийг харна.
Үр дүн дээр нь үндэслэн эдгээр тоонуудыг шийднэ. Зөвхөн шинэ бүтээл гэлтгүй, шинэ feature-үүд дээр ч адил өргөн ашиглана.
Ер нь бол ийм л зүйл. Яаж хэрэгжүүлэх нь хөгжүүлэгчдийн сонголт. Жишээ нь user id-ын сүүлийн 2 орон 00-17 бол бүлэг 1, үлдсэн нь бүлэг 2 ч гэх юмуу ангилна гэсэн үг.
Авсан жишээ жаахан авцалдахгүй байсан бол, уучлаарай.
Have a good weekend!

2015 оны 9-р сарын 19-ны өдөр by Танин мэдэхүй 1

DynamoDB-ын талаар, зах зухаас

AWS(Amazon Web Services) гэж мэдээж сонссон байх. Тэрний нэг үйлчилгээ нь DynamDB юм. NoSQL төрлийн database. Яагаад энэ талаар ярих болсон бэ гэхээр, миний ажиллаж байгаа тоглоом, infrastructure-аа аль болох AWS-руу шилжүүлэхээр ажиллаж байгаа юм. Яагаад гэхээр, өөрсдөө зөвхөн тоглоом хөгжүүлэх тал дээрээ төвлөрч ажиллаад, сервер талын асуудлуудаа автоматжуулах үүднээс. Мэдээж AWS ашигласанаар зардал гарах ч, dev ops-уудыг ажлуулах зардал болон, өөрсдөө бас хариуцаж байгаа серверүүдийн зардал багасах юм. Тэгэхдээ хамгийн гол зорилго нь найдвартай, high scaling болгох явдал юм.

DynamoDB
NoSQL database гэж дурьдсан. Маш энгийнээр хэлбэл, advanced KVS(Key/Value Store) юм.
Давуу талууд гэвэл
– Ямар ч их хэмжээний өгөгдөл байсан хамаагүй, auto-scaling.
– 10ms-ын дотор өгөгдлийг чинь буцаана. (Scan болон Query ашиглаагүй тохиолдолд)
– Document-тэй ажиллана. Өөрөөр хэлбэл MongoDB шиг JSON өгөгдлийг хадгалаад, тэрнийхээ нэг хэсгийг дуудах, эсвэл нэг хэсгийг өөрчлөх гэсэн үйлдлүүдийг хийх боломжтой.
– Ямар ч их хүсэлт ирсэн хүлээж авах боломжтой. Хүснэгтэндээ read/write throughput тохируулж өгнө. Мэдээж их тохируулах тусам ихийг төлнө. Тэгэхээр илүү уян хатан болж байгаа юм. Хэрвээ site руу чинь секунданд 10 хэрэглэгч ханддаг бол, throughput-ээ багаар тохируулаад, хэрвээ 10,000 хэрэглэгч ханддаг бол, 1000 дахин ихэсгэхэд л хангалттай.

Сул талууд
– MySQL гэх мэт RDBMS-үүд ACID(Atomicity, Consistency, Isolation, and Durability) гэсэн зүйлийг танд амлаж чаддаг. Харин DynamDB-ын хувьд зөвхөн CD(Consistency and Durability) амлаж чадна.
– DynamoDB-ын consistency нь тэгэхдээ eventually consistency юм. Тэр нь юу гэсэн үг вэ гэвэл, нэг өгөгдлийг database-рүү бичих үед, тэр өгөгдөл чинь яг тэр дороо database-д бичигдсэн гэсэн баталгаа байхгүй. Тэгэхдээ хэзээ нэгэн цагт бичигдэнэ гэсэн үг. Тэр нь тэгэхдээ сайндаа л хэдэн ms болохоор, санаа зовох зүйлгүй ч, тэрийг бодолцож системээ хөгжүүлэх хэрэгтэй. Бас eventually consistency ч гэсэн, өгөгдөл унших үед, consistent унших боломжтой, тэр нь inconsistent уншсанаас 2 дахин үнэтэй тул, аль болох шаардлагатай үед л consistent read-ыг ашиглавал зүгээр юм.
– Atomicity болон isolation байхгүй тул, transaction бичих боломжгүй. Системээ, transaction байхгүйгээр зохион байгуулах, эсвэл тэрийг орлох зүйл бодож олох хэрэгтэй.

DynamoDB-рүү хөрвүүлэх гэж байгаа тоглоом
Тоглоомын хувьд гар утасны тоглоом бөгөөд, тоглогч ихсэх тусам, шинээр нэг ертөнц(world) үүсгэн, тэрэн дээрээ шинэ тоглогчидоо хүлээж авдаг юм. Өөрөөр хэлбэл horizontal scaling.
Ертөнц бүр өөрийн world server(GoLang дээр бичигдсэн), тэрний failover, мөн хэд хэдэн ертөнцүүд дундаа 2-3 MySQL server-тэй.
Тэгэхээр 50 ертөнц байлаа гэхэд 50(master world server) + 50(standby world server) + 10(master MySQL server) + 10(standby MySQL server) = 120 орчим server юмуудаа. Эдгээрийг цөөхөн хүнтэй баг өөрсдөө арчлана гэдэг жаахан ядаргаатай юм. Энэ тоо нь зөвхөн нэг тоглоомны server-ын тоо бөгөөд, компаний хэмжээнд яривал 10,000-аад server юм. Өдөр болгон аль нэг серверийн hard disk шатна, ямар нэгэн юм болохоо болино. Тэгэхээр миний хувьд, үнэхээр л том компани биш бол, өөрсдөө арчлах гэж байхаар AWS-ыг ашиглавал их зүгээр санагдсан.
Энэ тоглоомын хувьд болохоор, MySQL server-тэй ерөөсөө харьцдаггүй, зөвхөн world server-тэйгээ харьцдаг. World server нь in-memory болохоор, асар хурдан хариу өгдөг. Бараг хүссэн өгөгдөл чинь 1ms-ээс бага хугацаанд ирнэ. Харин world server нь тогтмол давталттай, өөр дээрх өөрчлөлтөө, MySQL рүү бичнэ. In-memory тул ямар нэгэн асуудал гарвал, бүх өгөгдлөө алдах тул, MySQL-руу бичиж байгаа юм.
Аз болж, тоглоомын бүх код, world server-тэйгээ харьцахдаа, зөвхөн нэг гарцаар дамждаг байсан юм.
Тэгэхээр миний хувьд, тэр гарцийг world server-тэй биш DynamoDB-тэй харьцдаг болгож өөрчлөхөд л хангалттай.
Гарсан асуудлууд
– World server нь зөвхөн өгөгдөл хадгалахаас гадна, өөр дээрээ логик агуулдаг тул тэдгээр логикуудыг application layer-рүү зөөх
– DynamoDB-ын Query болон Scan нь 10ms-ээс бага хугацуунд ирнэ гэсэн баталгаа байхгүй тул бүх өгөгдлийг GetItem, болон BatchGetItem-аар авч болдог байхаар өгөгдлийн бүтцүүдээ өөрчлөх
– Consistent read гэж байгаа ч, зардал хэмнэх үүднээс ямар үед consistent read, ямар үед inconsistent read ашиглахыг шийдэх
– Манайх зарим хэсэг дээрээ, transaction(world server нь бас transaction-тай) ашигладаг тул тэдгээр хэсгийг DynamoDB дээр асуудалгүй ажилладаг болгох
Transaction-ын хувьд, яг одоогоор шийдээгүй байгаа бөгөөд, application layer дээр кодын логикийг өөрчлөх, эсвэл Redis ашиглан өөрчлөх гэж байгаа өгөгдлүүдээ lock хийж байгаад бичих гэсэн 2 санал дээр ярилцаж байгаа.
Бараг Redis л ашиглаж lock бичих аргаар л хийх байх.

Have a nice weekend!

2015 оны 8-р сарын 16-ны өдөр by Танин мэдэхүй 3

Vagrant болон Docker-ын тухай хальт

Бараг бүх startup компаниуд энэ 2 tool-ыг ашигладаг байх. Startup гэлтгүй томууд нь ч бас ашигладаг байх л даа.
Ямар тохиолдолд ашиглавал зүгээр вэ гэдгийг хальт тайлбарлах гэж оролдъё.
Ямар нэгэн систем хөгжүүлээд дууссаныхаа дараа, бид нар серверрүүгээ кодоо deploy хийдэг. Тэр үед янз бүрийн л асуудалтай тулгарч байсан байлгүй.
Яагаад хөгжүүлж байхад асуудал гараагүй хэрнээ, яг production сервер рүүгээ deploy хийх үед асуудал гарав?
Яагаад гэвэл, хөгжүүлж байгаа орчин(development environment) чинь бүтээгдхүүн болж ажиллах орчин(production environment)-оос чинь өөр байгаа болохоор.
Ихэнх тохиолдолд, Vagrant болон Docker-ыг ашиглахгүйгээр, production-тай яг адилхан орчин үүсгэхэд хэцүү. Ихэнх сервер-үүд Linux based, харин хөгжүүлэгчид ихэвчлэн Mac OS X эсвэл Windows ашигладаг. Mac OS X-ын хувьд UNIX based болохоор, Windows-ыг бодвол арай дээр ч гэсэн, 100% ижилхэн орчин үүсгэхэд бас л хүндрэл гарна.
Ижилхэн орчин гэдгээр би, яг адилхан OS version, яг адилхан PHP version, яг адилхан Ruby version, яг адилхан MySQL version тэй байхыг илэрхийлж байгаа шүү.
MySQL-ын жижиг version-ын өөрчлөлт хүртэл, системээс чинь хамаараад, өөр ажиллах тохиолдол үүсч болно.

Vagrant
Веб хуудас: https://www.vagrantup.com/
Энэ tool нь VirtualBox ашиглан, virtual machine үүсгэн, тэрэн дээр өөрийн чинь хүссэн орчинг бүрдүүлдэг tool юм.
Ашиглахад их энгийн. Vagrantfile дотор, ямар virtual machine үүсгэмээр байгаа, ямар OS ашигламаар байгаа, OS-ээ initialize хийсний дараа юу юу суулгамаар байгаагаа бичиж өгөөд л болоо. Vagrantfile-аа үүсгэсэнийхээ дараа дараах 2 мөр коммандыг бичихэд л хангалттай.

vagrant up // Virtual Machine-ийг initialize хийх
vagrant ssh // SSH-ээр Virtual Machine-рүүгээ орох

Vagrant-ын веб хуудас руу нь ороод харвал, Vagrantfile хэрхэн үүсгэх талаар, их дэлгэрэнгүй тайлбарласан байгаа.
TIP: Synced Folders үүсгэхдээ NFS ашиглавал, мэдэгдэхүйцээр хурдан ажиллана.

Docker
Веб хуудас: https://www.docker.com/
Зорилгын хувьд бол Vagrant-тай бараг төстэй. Тэгэхдээ Docker нь олон Linux based VM үүсгэх үед kernel-ээ share хийдэг юм. Хэрвээ чи Linux ашигладаг бол, чиний ашиглаж байгаа Linux-ын kernel-ийг шинээр үүсгэх OS-ынхээ kernel-ын оронд ашиглана гэсэн үг. Mac OS X болон, Windows-ын хувьд kernel share хийх боломжгүй тул, эхлээд VirtualBox-оор Linux OS-тэй virtual machine үүсгээд, тэрэн дээрээ container үүсгээд явна. Kernel-ээ share хийж байгаа болохоор, Vagrant-ыг бодвол арай хөнгөхөн ажиллана. Тэгэхдээ Mac OS X болон Windows дээр ашиглах гэж байгаа бол, Vagrant-аас ямар ч ялгаагүй. Харин олон container үүсгэх гэж байгаа бол, Docker-нь хамаагүй илүү байх.

Эцэст нь
2-уулаа сурахад нээх хүнд зүйл биш болохоор, завтай үедээ 2-ууланг нь туршиж үзэж байгаад сурсан нь дээр. Манай компаний хувьд, Vagrant-уудаа Dockerize хийж байгаа. Тэгэхдээ “No Silver Bullet”. 2-ууланг нь сурч байгаад, хэрэгцээндээ тохируулж алийг нь ашиглахаа шийдвэл зүгээр.

2015 оны 8-р сарын 6-ны өдөр by Танин мэдэхүй 4