Introduction to High Performance Enterprise Applications

เกริ่นนำ

บทความที่ผมเขียนเริ่มเยอะ คงต้องจัดหมวดหมู่กันใหม่ ไม่งั้นงงแย่ ดังนั้นจากบทความนี้ไป ผมขอจัดหมวดหมู่ของบทความที่ผมเขียนเป็นสองระดับคือระดับหมวดและย่อยลงเป็นเป็นระดับชุด ในบทความนี้เป็นหัวของบทความหมวดใหม่ชื่อว่า High Performance Enterprise Applications แน่นอนว่าจะแบ่งออกเป็นชุดย่อยๆ หลายชุด ผมจะเขียนสลับกับบทความในหมวดอื่น จะสลับก่อนหลังอย่างไรก็ขอเป็นตามอารมณ์ของผมในตอนนั้นก็แล้วกัน

ทำไมถึงเขียนบทความหมวดนี้

ในตอนแรกผมไม่ได้นึกจะเขียนบทความที่มีเนื้อหาทำนองนี้เลย ที่ผ่านมา เมื่อผมเขียนบทความชุด Intro HPC เสร็จ ก็ตั้งใจไว้ว่าจะเขียนบทความแนว HPC ต่อ โดยจะนำเสนอการเขียนโปรแกรมเพื่อประมวลผลบน graphic card โดยใช้ CUDA และ OpenCL แต่จังหวะมันไม่ได้ครับ Khronos ผู้ออกแบบ OpenGL/OpenCL ก็ประกาศเมื่อเดือนมีนา 15 ว่าจะรวบเอา OpenGL/OpenCL เป็นตัวเดียวกันเรียกว่า Vulkan ซึ่งปัจจุบันที่ผมเขียนบทความนี้ ก็เป็นวันโกหกโลกปี 15 Vulkan ยังออกแบบไม่เสร็จ และถึงออกแบบเสร็จแล้วก็คงอีกระยะครับกว่าจะทำ API ให้เราใช้กัน ผมเลยคิดว่ารอก่อนดีกว่า ไม่อยากจะเขียนอะไรที่มันกำลังล้าสมัย

มานึกถึงบทความที่ผ่านมาดูเหมือนว่าคนสนใจเรื่อง function programming มากกว่า Intro HPC แต่ก็มีหลายเสียงที่ติมาว่าผมติสต์เกิน ไปเลือกภาษาตัวอย่างเป็น Haskell ที่ไม่มีค่อยมีใครใช้ในงานจริง เข้าถึงได้ยาก เลยอยากให้ผมปรับให้เป็นภาษาแบบตลาดๆ หน่อย ขอมาก็จัดให้ครับ (ถ้าทำได้) ผมเลยมานั่งคิดดูว่าจะเอาภาษาอะไรดี ภาษานั้นต้องเป็นภาษาที่นิยมใช้กัน และต้องใช้ FP เป็นหลักในการเขียนโปรแกรม นึกไปนึกมาก็ได้สองภาษานี้ครับคือ Ruby และ JavaScript  สุดท้ายก็เลือกเอา JavaScript ดีกว่า ด้วยเหตุผลถึงจำนวนผู้ใช้ที่มากกว่า พอยึดหลักว่าเป็น JavaScript ได้ ผมก็คิดว่าจะเขียนอะไรบ้าง คิดไปคิดมามันก็บาน ลามจากชุดกลายเป็นหมวดดังที่เห็น

ด้วยชื่อของเว็บ ทำให้เนื้อหาจำกัดอยู่ในเรื่องการเร่งประสิทธิภาพเป็นหลัก เนื้อหาอะไรก็ตามที่เขียนอยู่ในเว็บนี้นั้นต้องเป็นไปเพื่อสนับสนุนการประมวลผลประสิทธิภาพสูง (HPC) แม้แต่ในบทความชุด FP ดูเหมือนว่าจะไม่เกี่ยวกับงาน HPC แต่ที่จริงก็เกี่ยวครับ เพราะ FP นั้นถูกใช้เป็นเครื่องมือสำคัญในการค้นหาข้อมูลขนาดใหญ่ พอมาถึง JavaScript ถ้าจะเอาเข้ามาในเว็บนี้ ผมก็ต้องตอบคำถามของตัวเองให้ได้ว่ามันสนับสนุน HPC อย่างไร ดังนั้นที่มันลามกลายเป็นหมวดนั้นก็ด้วยประเด็นนี้เองครับ

ถ้าว่ากันในบริบทของ HPC จริงๆ ที่เน้นไปทางวิทยาศาสตร์ JavaScript นั้นสู้ Python ไม่ได้แน่ๆ ครับ ผมก็เลยขอเลี่ยงบาลีประยุกต์เป็นงาน high performance enterprise applications แทน  ดังนั้นก่อนที่จะคุยอะไรกันต่อ ผมขอทำความเข้าใจถึงนิยามของ enterprise applications ให้ตรงกันก่อนดังนี้

Enterprise Applications คืออะไร

Enterprise Applications (EA) ก็คือโปรแกรมระบบงานธุรกิจขนาดใหญ่ บางท่านก็เรียกมันว่างานฐานข้อมูลนั่นเอง งาน CRUD ก็เรียกกัน (แต่ต้องขนาดใหญ่นะครัย) เชื่อว่าท่านก็น่าจะรู้จักเป็นอย่างดี ผมเชื่อว่าโปรแกรมเมอร์มากกว่าครึ่งไปมากอยู่ในสายงานนี้

EA นั้นถ้าพูดถึงความยากเมื่อเทียบกับงานเขียนโปรแกรมแบบอื่นๆ ถือว่าเขียนไม่ยาก ใช้เวลาไม่นานก็ได้งานแล้ว แต่ก็ดูถูกไม่ได้ ความใหญ่ของมันทั้งด้านปริมาณโปรแกรมและขนาดของฐานข้อมูลนี้เป็นอาวุธหนักของบอสตัวนี้ แต่ท่าไม้ตายของมันจริงของมันคือความไม่นิ่งเปลี่ยนแปลงตลอดเวลา มันแปลงร่างได้ครับ แต่ละร่างแปลงก็มีอาวุธและความสามารถใหม่ๆ ยากที่จะรับมือครับ

เรื่องแปลงร่างได้นี้ ผมขอขยายความหน่อย ในระบบธุรกิจนั้นการแข่งขันสูงมาก ผู้บริหารต้องเก่งสามารถปรับเปลี่ยนกลยุทธ์ตลอดเวลา เพื่อนำพาองค์กรทะยานไปข้างหน้า ในฐานะของฝ่าย IT นั้นทำหน้าที่เป็นกองหนุน ผู้บริหารไปได้เท่าไหน IT ก็ต้องไปให้ได้เท่ากัน ดังนั้นการเปลี่ยนแปลงจึงเกิดตลอดเวลา ความใหญ่ของ EA จึงกลายเป็นปัญหา มดหนึ่งตัวจัดการง่าย แต่ถ้ามดเป็นล้านตัวจะสู้อย่างไรไหว เมื่อต้องเปลี่ยนแปลงอะไรบางอย่างในระบบ ถ้าว่าโครงเอาไว้ไม่ดี จะกระทบต้องแก้โปรแกรมเป็นลูกโซ่อย่างหนัก นี่ยังไม่นับปริมาณมหาศาลของข้อมูลที่ไหลเข้ามาสู่ระบบอีก ที่ทำให้การประมวลผลช้าลงๆ จนเกินขึดความอดทนของใครบางคนอีกต่างหาก และต้องทำภายใต้ข้อจำกัดของเวลาอย่างหนัก ผมคงไม่แจงอะไรมากไปกว่านี้ เชื่อว่าท่านคงเข้าใจดีกันอยู่แล้ว เอาเป็นว่าเราเข้าใจตรงกันแล้วนะครับ

High Performance Enterprise Applications?

ถ้าเอานิยามของ HPC ที่เว็บนี้ใช้มาโดยตลอดมาจับ  งาน EA ก็จะไม่เข้าพวก ในงาน HPC นั้น เรามุ่งเน้นที่จะรีดกำลังเครื่องคอมพิวเตอร์มาให้มากที่สุดเท่าที่ทำได้ ดังนั้นการเขียนโปรแกรมแต่ละบรรทัดต้องคำนึงถึงประสิทธิภาพที่ทำได้ เราอาจยอมเสียเวลาเป็นเดือนหรือเป็นปีเพื่อคิดค้นอัลอกริทึมใหม่ๆ ที่ตอบโจทย์ที่ยังไม่เคยมีใครแก้ได้หรือแก้ได้แต่ยังไม่ดี อย่าลืมนะครับงานบางงานนั้นซับซ้อนมากจนถ้าใช้อัลกอริทึมที่ไม่ดีพอ คำนวณกันจนโลกแตกก็ไม่ได้คำตอบ ดังนั้นมันคุ้มครับที่เรายอมเสียเวลาในการคิดค้นอัลกอริทึมหรือเขียนโปรแกรมแบบเน้นเก็บประสิทธิภาพให้เต็มที่ทุกบรรทัด

แต่สำหรับงาน EA นั้นเรามักใช้เงินแก้ปัญหาครับ มันช้าก็เปลี่ยนเป็นตัวใหม่ที่เร็วขึ้น การเขียนโปรแกรมก็ไม่ได้คำนึงถึงประสิทธิภาพอะไรมากนักในขั้นแรก รันให้ได้ก่อน เพราะเวลาทำงานนั้นบีบเหลือเกิน ส่วนเวลาตอนรันถ้ามันช้าก็ค่อยแก้เป็นจุดๆ ไป ยึดหลักตามฝรั่งว่า “ถ้ามันไม่เสีย ก็อย่าไปซ่อมมัน” โปรแกรมที่เขียนก็จะเน้นให้อ่านง่ายแก้ง่ายต่อเติมสะดวกมากกว่าการรีดประสิทธิภาพ

ดังนั้นคำว่า high performance ในที่นี้ก็ไม่ใช้ให้ท่านเปลี่ยนวิธีการเขียนโปรแกรมมาเป็นแบบรีดประสิทธิภาพหรือใช้อัลกอริทึมที่ซับซ้อนแต่อย่างได แต่หากเป็นการลดปัญหาคอขวดต่างๆ ที่มี ทำอย่างไรจึงพัฒนาโปรแกรมให้เร็วขึ้น ติดขัดน้อยลง ทำอย่างไรจึงจะโปรแกรมที่เราเขียนจะทำงานเร็วขึ้น โดยไม่ต้องเหนื่อยเพิ่ม และที่สำคัญเลยครับ คือให้เงินมันทำงานให้เรา บ่อยครั้งที่เครื่องมือที่เราใช้มันเป็นคอขวด เพิ่มทรัพยากรทั้งคนทั้งเครื่องทั้งเงินเข้าไป ก็ไม่ได้ช่วย เงินมีแต่เทคโนโลยีมันตัน บทความนี้ครับ จะหากลยุทธ์ให้เงินทำงานให้เรา โดยนำเสนอเทคโนโลยีที่ใช้เงินขยายได้และเป็นเทคโนโลยีที่ประหยัดเงินในคราวเดียวกัน

Platform ไหนดี

จะทำงาน EA ก็ต้องพิจารณาเลือก platform ผมพูดถึงในกรณีที่ท่านเลือกได้นะครับ ไม่ได้ถูกบังคับโดยลูกค้า ถ้าลูกค้าบังคับก็ต้องตามลูกค้า มิฉะนั้นเงินในกระเป๋าของเขาคงจะไม่ได้เข้าสู่กระเป๋าของเรา จากนี้ไปถือว่าท่านเลือกได้นะครับ เราจะได้ไปกันต่อ

ในอดีตที่ย้อนไปไม่ไกลนัก เมื่อก่อนงาน EA เกือบทั้งหมดเป็น native applications หรืออาจเรียกได้ว่าเป็น desktop applications นั่นเอง ในยุคก่อนปี 2000  ที่ดังๆ เมื่อก่อนก็มี Visual Basic เชื่อมต่อกับ SQL Server ทำงานได้ดีครับ แต่ก็มีข้อเสียหลักก็คือ ใช้งานได้ในวง LAN เท่านั้น พนักงานที่ไปจิบกาแฟอยู่ร้านกาแฟหรูเข้าถึงระบบได้ค่อนข้างยาก อาจจะใช้ VPN ได้แต่ก็ไม่ค่อยสะดวกนัก

ต่อมาก็เป็น web application เริ่มจาก PHP, ASP อะไรทำนองนี้ ก็ใช้งานได้ดีครับ พนักงานสามารถใช้งานได้จาก internet cafe หรือแม้แต่เข้าระบบจากต่างประเทศก็ยังได้ แถมยังรองรับลูกค้าภายนอกองค์กรได้ ทำให้เทคโนโลยีด้านนี้ได้รับการพัฒนาอย่างรวดเร็ว จนกลายมาเป็น full-stack web framework ที่ทำงานได้ครบวงจร อย่าง ASP.NET, JavaEE, Ruby on Rails หรือทางฝั่ง Python ก็มีตัวกลั่นอย่าง django เป็นต้น

มาในยุคปัจจุบันเป็นยุค BYOD  (Bring Your Own Device) เป็นยุคที่เราพึ่งพาคอมพิวเตอร์ขององค์กรน้อยลง ทุกคนมี smartphones มี tablets เป็นของตัวเองหรือองค์กรซื้อให้ก็ตาม มันสะดวกกว่าแบบเดิมๆ เยอะครับ เพราะอุปกรณ์เหล่านี้ติดตัวเราตลอดเวลาตั้งแต่ตื่นไปจนเข้านอน ทำให้เราเข้าถึงระบบได้ตลอดเวลา อุปกรณ์เหล่านี้ ถ้าจะให้ใช้งานสะดวกจริงๆ ก็ต้องสร้างเป็นแอพ ลองพิจารณาดูครับ เมื่อมันเป็นแอพ มันกระทบกลับไปที่ full-stack web framework เพราะแอพมันมีงานบางส่วนที่ทับซ้อนกับ frameworks ที่กล่าวมาค่อนข้างมาก ดังนั้นถ้าใช้แอพ ก็ไม่จำเป็นต้องใช้ web framework ที่มัน full-stack ขนาดนั้น

เห็นได้ว่าทางเลือกทางเทคโนโลยีสำหรับงาน EA มีหลายทาง แต่ปัจจัยหลักที่ชาว EA นำมาพิจารณาในการเลือก platform นั่นก็คือ การรองรับอุปกรณ์ที่กว้างที่สุด ซึ่งแน่นอนครับ web applications อาจเป็นคำตอบเดียวที่รองรับอุปกรณ์ได้กว้างที่สุด แถมยังไม่ต้องมีการติดตั้งลงในอุปกรณ์แต่ละตัวอีกด้วย เราใช้งานได้เลย และยิ่งมี framework อย่าง Bootstrap ซึ่งสามารถทำ responsive design โดยปรับหน้าเว็บงานของเราให้สวยงามรองรับขนาดจอภาพที่แตกต่างกันในแต่ละอุปกรณ์ได้โดยไม่จำเป็นต้องออกแบบหน้าจอเฉพาะกิจสำหรับอุปกรณ์ตัวใดตัวหนึ่ง ทำให้ web applications นั้นสำหรับงาน EA จึงเหมาะสมเป็นอย่างยิ่ง และผมก็จะใช้ platform ดังกล่าวในบทความหมวดนี้ทั้งหมดที่ผมจะเขียน

สิ่งที่ทุกคนกังวลเกี่ยวกัน web application คือเรื่องความเร็วครับ ทำอะไรผ่าน internet มันก็ต้องช้า มันต้องเกิด round-trip ต่อให้ server อยู่วง LAN เดียวกัน การทำงานของ web applications อย่างไรเสียก็ย่อมช้ากว่า native applications อยู่ดี นั่นจึงเป็นเนื้อหาของบทความหมวดนี้ครับ ว่าจะใช้เทคโนโลยีอะไรและเขียนโปรแกรมอย่างไรให้มันมีประสิทธิภาพสูง ไม่ช้า

สรุปว่าผมเลือก web application มาเขียนเป็นบทความในหมวดนี้นะครับ

Thin Client / Fat Client

ผมขอพักยกมาคุยอะไรนอกเรื่องหน่อยก่อนที่จะตบเข้าเรื่องในท้ายที่สุด ยังจำเครื่อง mainframe กันได้ไหมครับ ผมไม่ได้ยินใครพูดถึงคำนี้มานานหลายปีแล้ว เมื่อก่อนนี้เป็นคำยอดฮิตมาก mainframe เป็นเครื่องคอมพิวเตอร์ขนาดยักษ์เครื่องหนึ่ง เขาจะต่อ dumb terminals  ซึ่งเป็นเครื่องคอมพิวเตอร์อย่างง่าย มีจอภาพมีแป้นพิมพ์ มี CPU เล็กๆ ที่ทำหน้าที่เพียงเชื่อมต่อกับสายสื่อสาร พูดง่ายๆ ว่า mainframe ส่งอะไรมา มันก็เอามาแสดงที่หน้าจอ ส่วนเราพิมพ์อะไรเข้าไปมันก็รับหน้าที่ส่งกลับไปให้ mainframe งานของมันมีแค่นั้นครับ การประมวลผลทั้งหมดอยู่ที่ตัว mainframe ผู้ใช้งานก็แย่ง CPU time ของ mainframe ผ่าน dumb terminal ของตน ตัว dumb terminals  มันจึงเป็นเครื่องคอมพิวเตอร์แบบผอมๆ ตัวหนึ่งหรือที่เรียกว่า thin clients นั่นเอง ซึ่ง thin clients นั้นราคาถูก เพราะใส้ในไม่มีอะไรเท่าไหร่นัก

ปัญหาของ mainframe ก็คือคุณต้องทุ่มสรรพกำลังเพื่อเลี้ยงดู mainframe ให้มันเติบใหญ่ เพียงพอที่จะรับมือผู้ใช้และงานที่เพิ่มขึ้นทุกวัน มันยิ่งโตขึ้นเท่าไหร่ค่าตัวของมันก็ยิ่งแพงขึ้นเป็นอัตราเร่ง สุดท้ายก็จะมาถึงจุดหนึ่งที่กำลังเงินไม่พอสู้ไม่ไหว ต้องไปหาทางเลือกทางอื่นแทน

เมื่อแนวคิดของ network ได้รับการพัฒนาขึ้น จึงมีการพัฒนา ระบบ client/server ขึ้นมาโดยอาศัยความสามารถในการเชื่อมต่อ ถือว่าเป็นดาวข่มของ mainframe ก็ว่าได้ หลักการทำงานก็ไม่ยาก โดยใช้เครื่องคอมพิวเตอร์ทำหน้าที่เป็น server ให้บริการ และ clients ต่อเข้ามาใช้ทรัพยากรโดยใช้ network  ราคาค่าตัวของเครื่อง server นั้นมีราคาเป็นเพียงแค่เศษเสี้ยวของ mainframe server  เท่านั้น เพราะมันไม่ได้ทำงานทั้งหมด มันทำงานเฉพาะกิจเท่านั้น เช่นงานฐานข้อมูลเป็นต้น อาศัยเครื่องคอมพิวเตอร์ที่เป็นตัวลูกข่ายที่มีกำลัง CPU พอสำควร ดึงงานส่วนใหญ่ไปประมวลผล ทำให้แบ่งเบาภาระของ server ไปได้มากโข เครื่องคอมพิวเตอร์ลูกข่ายจึงเป็น fat client นั้นเอง

จากศึกมาสุข จากสุขกลายเป็นศึก โลกเทกลับไปหา thin client อีกรอบ โดยผ่าน web application  ซึ่งมีตัว browser ทำหน้าที่เป็น thin client ใช้ได้แม้กระทั่งใน feature phones รุ่นเก่าๆ  งานเกือบทั้งหมดจะไปอยู่ในส่วนของ server ประมวลผลงานจนสำเร็จ ให้ได้เป็น html จากนั้นส่งไปให้ browser เพื่อแสดงผล

และในยุคปัจจุบันโลกก็ได้ปรับมาสู่ fat client อีกครั้ง fat client กำเนิดใหม่อีกรอบ มาในรูปแบบของ tablets และ smartphones แอพต่างๆ ใน iOS หรือ Android ก็ล้วนแล้วแต่เป็น fat client ด้วยกันทั้งสิ้น เนื่องจากกำลังของอุปกรณ์ตัวจ้อยที่เราใช้กันอยู่ทุกวันนี้มันแรงขึ้นทุกวันทุกคืน จนเทียบเคียงกับเครื่องคอมพิวเตอร์ได้แล้ว

web เองก็เช่นกันครับ ก็มีการปรับตัวให้กลายเป็น fat client เช่นกัน โดยใช้แนวคิดของ SPA ซึ่งผมจะอธิบายต่อไป เอาเป็นว่าเรามาพิจารณาในแง่ผลกระทบกันก่อน งานที่เคยเป็นของ full-stack web framework เช่น asp.net, ruby on rails เป็นต้น งานหลายส่วนเช่น การ routing, render template และอีกหลายอย่าง ปัจจุบัน browser ก็ทำได้ และถ้าย้ายงานส่วนนั้นมาอยู่ที่ browser ส่งผลให้ server เบาลงมาก ในทางกลับกัน browser ก็จะทำงานหนักขึ้น แทนที่จะเพียงแค่ render หน้าจอ แต่หากต้องทำงานที่เคยเป็นส่วนของ server เดิม กลายเป็น fat client  แต่นั่นก็ไม่ใช่ปัญหาครับ เพราะไอ้จ้อยที่เราพกติดตัวกันทุกวัน กำลังมันเหลือเฟืออยู่แล้ว และมันประมวลผลเฉพาะงานของเราก็จะไม่กินกำลังเครื่องมากนัก

นิทานเรื่องนี้สอนให้เรารู้ว่า เทคโนโลยีเป็นสิ่งที่ที่เอาแน่เอานอนไม่ได้ จะมาบอกว่าสิ่งนี้คือดีที่สุดไม่มีหรอกครับ มันจะมีคำว่าดีกว่าเสมอ และที่บอกว่าไม่ดีในวันนี้ วันข้างหน้าอาจจะกลายเป็นดีก็ได้ สูงสุดมักจะกลับสู่สามัญ เหมือนกับตัวอย่างข้างบนครับเป็นโยโย่เลย เดี๋ยวดีเดี๋ยวเลย เดี๋ยวอ้วนเดี๋ยวผอม

SPA – The fat web browser

เมื่อพูดถึง fat web browser ก็ต้องนึกถึงคำว่า SPA คำนี้ฮิตติดหูในวงการเขียนโปรแกรมของเรามานานพอดูแล้ว แน่นอนครับคนละเรื่องกับนวด spa ที่มีพริ้ตตี้นางแบบ คำว่า SPA ในที่นี้ย่อมาจาก single page application แปลตรงตัวว่าแอพพิเคชันที่มีหน้าเดียว ยิ่งงงไปใหญ่ใช่ไหมครับ แอพอะไรจะมีแค่หน้าเดียว หรือจะเป็นแอพง่ายๆ เช่นแปลงหน่วยที่มีอยู่ใน smartphones ไม่ใช่นะครับ

SPA ในที่นี้ ถ้านิยามแบบมั่วๆ ตามสไตล์ของผม ก็จะได้ว่า มันคือ “แอพพิเคชันที่เป็น web แต่ให้ความรู้สึกลื่นไหลเหมือนกันใช้งานบนแอพพิเคชันแบบ native” จากนิยามที่ผ่านมาผมแยกประ เด็นออกมาได้สองประเด็นคือ เหมือน native และความลื่นไหล ซึ่งผมขอขยายความประเด็นหลักทั้งสอง โดยเริ่มจากความเหมือน native ก่อน

หน้าเดียวเหมือน native

โปรแกรม EA บน native นั้นปกติแล้วไม่ว่าเรากำลังทำงานอะไรอยู่ก็ตาม จะแตกต่างเฉพาะใส้ในเท่านั้น ส่วนบนที่เป็นเมนูหรือส่วนล่างที่เป็นสถานะ จะคงรูปแบบเดิมไปตลอดการทำงาน ให้คนนอกมาดูก็จะรู้สึกเหมือนกับว่าทั้งแอพพิเคชันมันมีแค่หน้าเดียว เปลี่ยนไปกี่งานมันก็มีหน้าตาคล้ายๆ กันหมด

นับว่าเป็นข้อดีอย่างมาก งาน EA นั้นใหญ่มาก บางระบบอาจมีหน้าจองานถึงหลักพันหลักหมื่นเลยทีเดียว ถ้าเราสามารถทำให้หน้าจอมันเป็นทำนองเดียวกันได้ การเรียนรู้จะเร็วขึ้นมาก เปลี่ยนงานเป็นงานอื่นก็เปลี่ยนแต่รูปร่าง แต่ลักษณะ  interface ยังเหมือนเดิม ผมใช้ก็ไม่ต้องเรียนใหม่ ไม่ต้องดูไกลครับ ชุด office ของ Microsoft (หรือเจ้าอื่นด้วย) เป็นตัวอย่างที่ดีเลยครับ ถ้าเราใช้ Excel เป็น เมื่อมาใช้ Word แทบไม่ต้องเรียนอะไรใหม่เลย เพราะระบบเมนูหรือหน้าตาอื่นๆ รวมทั้งการใช้ mouse และ keyboard นั้นมันไปทำนองเดียวกัน

ในงาน SPA เราก็จะแบ่งหน้าจอออกเป็นสองส่วนคือส่วนหัว อาจจะเป็นแถบเมนู และก็ส่วนล่างเปลี่ยนแปลงไปตามแต่ละงาน เมื่ออ่านมาถึงตรงนี้อาจจะงง งานเว็บที่เป็น EA ส่วนมากมันก็พยายามทำให้เป็นรูปนี้อยู่แล้วนี่ มันก็เป็น SPA อยู่แล้วใช่ไหม ก็ถ้ามันแยกส่วนระหว่างหน้า SPA หลัก ออกจากหน้างานต่างๆ ก็อาจกล่าวได้ว่าเป็น SPA แต่ก็ยังไม่ใช่ SPA ในยุคปัจจุบัน เพราะ SPA ในยุคปัจจุบันต้องมีความสามารถข้อที่สองนี้ด้วยครับ

ลื่นไหลไม่สะดุด

จะเรียกว่า SPA ตามนิยามสมัยใหม่ได้นั้น ก็ต้องมีความสามารถนี้ครับ ลื่นไหลไม่สะดุด ลำพังหน้าเดียวแบบข้างต้นยังไม่พอครับ ในเว็บ EA แบบปกติทั่วไปนั้น เมื่อเรา submit form ที่เรากรอกไปนั้น จะเกิดอาการเงียบไปพักหนึ่งขึ้นอยู่กันความเร็วของ network และความเร็วของตัว server ถ้าการประมวลลสำเร็จ จะกระพริบเพื่อแสดงผลหน้าใหม่ นั่นก็ไม่ลื่นไหลแล้วครับ สะดุดกึก

สำหรับงาน SPA แล้วจะไม่เกิดการกระพริบเช่นนั้น เพราะมันมีเพียงหน้าเดียว การกระพริบจะเกิดเพียงการดึงหน้า SPA ครั้งแรกเพียงครั้งเดียวเท่านั้น จากนั้นทำงานไปทั้งวัน ก็จะไม่มีการกระพริบ ไม่ว่าจะเปลี่ยนการทำงานไปกี่หน้าก็ตาม ที่ว่ามีหน้าจองานหลักพันหลักหมื่นจอนั้น แท้ที่จริงแล้วเป็นเพียงส่วนเติมเต็มของหน้า SPA เท่านั้น ว่าไปแล้วก็เหมือนกับเวลาเขียน native ไม่มีผิด ลองดูง่ายๆ ครับถ้าเราเอาหนัง Youtube มาเล่นบนหน้า SPA เราก็ทำงานไปจะบันทึกงานทางธุรกรรมกี่งาน เปลี่ยนหน้ากี่ทีก็ตาม งานท่านก็ทำไป พี่โจวเหวินฟะแกก็ยังคงสาดกระสุดไม่หยุด ไม่มีสะดุดเลยครับ (ภายใต้เงื่อนไขว่า เน็ตท่านต้องแรงนะครับ)

ทำไมไม่สะดุด ลองดูตัวอย่างนี้ครับ ถ้าเราต้องการทำงานหน้าใหม่เช่นบันทึกสินค้าคงคลัง เมื่อข้อมูลของหน้านี้ยังไม่เคยถูกเรียกใช้มาก่อน SPA จะติดต่อไปยัง web server เพื่อขอดึงหน้านั้นมา ซึ่งหน้าที่ดึงมานั้นเป็นแฟ้มแบบ static ทั่วไป web server ไม่ต้องมีการประมวลผลอะไร ดึงมาตรงๆ ได้เลย เมื่อได้หน้านั้นมาแล้ว SPA จะนำมาประมวลผลครับ โดยเติมหน้านั้นเข้าไปยัง SPA โดยเติม elements เข้าไปใน DOM โดยตรง ผลลัพธ์ก็คือ หน้าของเราจะแทรกเข้าไปอยู่ในหน้า SPA นั่นเอง และการการทำเช่นนี้ไม่เกิดการกระพริบแต่อย่างใด ลื่นไหลมากครับ

ประสิทธิภาพ #1: การทำงานที่ลื่นไหลไม่สะดุด ไม่มีกระพริบ

ว่าด้วยเรื่องประสิทธิภาพ

พิจารณากันต่อไป หน้าเราดึงมานั้นเป็นเพียงส่วนของหน้าเท่านั้น ไม่ใช้หน้าเต็ม ถ้าเป็นหน้าเต็มนั้นต้องมีการตกแต่งความสวยงามโดยใช้รูปภาพหรือกราฟฟิคต่างๆ มากมาย ทำให้การดึงข้อมูลนั้นช้ามาก ถ้าเป็น SPA ของดังกล่าวก็จะอยู่ในหน้าหลักหรือหน้า SPA นั่นเอง ดังนั้นจึงดึงเพียงครั้งแรกครั้งเดียวเท่านั้น ในส่วนที่เหลือกที่เป็นหน้างานต่างๆ นั้น แต่ละหน้ามีขนาดเล็กมาก การส่งผ่าน network จึงทำได้รวดเร็ว

เท่านั้นยังไม่พอ สมมุติว่าท่านกำลังทำงานหน้าบันทึกสินค้าคงคลังอยู่ แต่ก็มีงานอื่นแทรกเข้ามา เช่นลูกค้าถามถึงสถานะของสินค้า ท่านก็ต้องกระโดดไปยังหน้าสถานะของสินค้าเพื่อแจ้งสถานะปัจจุบันให้แก่ลูกค้าที่โทรมาทราบ เมื่อวางสายจากลูกค้า ท่านก็ต้องกลับไปยังงานเดิมสินค้าคงคลัง ถ้าเป็นงานเว็บปกติ ผู้ใช้ก็ต้องสั่งไปยัง web server เพื่อดึงหน้าสินค้าคงคลังมาใหม่ทั้งหน้า แม้ว่าระบบเว็บปัจจุบันจะมีกลไกในการลด bandwidth ของการส่งโดยปฏิเสธการส่งถ้าข้อมูลนั้นซ้ำ ถ้า browser cache เก็บเอาไว้แล้ว อย่างเช่นการใช้ ETAG ก็ตาม แต่ round-trip การสื่อสารยังคงต้องเกิดและการคำนวณ ETAG ก็ยังอาจต้องเกิด แต่สิ่งที่จะลดได้ก็คือปริมาณการส่งข้อมูลลดลง แต่ถ้าเป็น SPA แล้วทุกหน้าที่เคยดึงมาแล้วจะ cache เก็บไว้ใน browser ไม่มีการขอไปยัง server อีก มันจึงทำงานเร็วมาก ไม่เกิดการเชื่อมต่อ network และไม่ต้องกลัวว่าจะได้ข้อมูลที่ไม่ทันสมัย เพราะหน้าเหล่านี้มันเป็น static ไม่มีการเปลี่ยนแปลงอยู่แล้ว

ยังครับยังมีอีก ท่านสามารถรวบเอาหน้าจอหลายๆ หน้าจอเป็นแฟ้มเดียวกัน เพื่อส่งในคราวเดียวกันได้เลย แน่นอนครับประหยัดเวลาที่เสียไปในการเริ่มเปิดการสื่อสาร ขอสิบครั้งก็ต้องเริ่มเปิดการสื่อสารสิบครั้ง เร็วสู้เปิดครั้งเดียวไม่ได้ครับ แถมเรายังสามารถย่อข้อมูลในการส่งเพื่อลดขนาดของข้อมูลระหว่างการส่งอีก ยิ่งลด bandwidth เหล่านี้นับเป็นจุดเด่นของ SPA ครับ

ประสิทธิภาพ #2: ดึงเพียงส่วนของหน้าประหยัด bandwidth

ประสิทธิภาพ #3: หน้าที่ดึงแล้วมีการ cache ประหยัด bandwidth

ประสิทธิภาพ #4: รวบหลายหน้าส่งที่เดียว ประหยัด bandwidth

Web API and Asynchronous communication

ถ้าเราใช้งาน SPA แล้ว ซึ่งอยู่ฝั่ง browser งานส่วนใหญ่จะย้ายไปอยู่ที่ฝั่ง browser และตัว server หละ จะเหลืออะไรทำ

ในงานเว็บแบบดั้งเดิมนั้น การสื่อสารจะผูกกับการ submit form เป็นหลัก เมื่อ submit form แล้วทาง server จะ render หน้าใหม่ กว่าจะ render หน้าก็มีกระบวนการมากมากมาย ตั้งแต่การ routing เพื่อเลือกหน้า ไปจนถึง การดึง template และ ก็เอาข้อมูลจากฐานข้อมูล มายำรวมกัน เรียกว่าการ rendering นั่นเอง ผลลัพธ์ได้เป็นหน้า HTML เพื่อส่งไปให้ browser แสดงผล web framework ที่ทำงานเหล่านี้ทั้งหมดครบถ้วน เราเรียกว่า full-stack web framework นั่นเอง ส่วนมากภายในแบ่งเป็นส่วนย่อยๆ สามส่วนเรียกว่า MVC หรือ Model-View-Controller ที่เรารู้จักกันเป็นอย่างดีอยู่แล้ว

ส่วนในงาน SPA นั้น ในทางเทคนิคจะไม่มีการ submit form เหมือนในงานเว็บทั่วไป แต่หากฝั่ง browser  นึกอยากจะไปคุยกับ server เมื่อไหร่ก็ไปคุย คุยได้ตลอดเวลา ไม่จำเป็นต้องรอกดปุ่ม submit แต่อย่างใด เราเรียกว่าเป็นแบบ Asynchronous นั่นเอง เทคโนโลยีที่ใช้ก็เป็นแบบมาตรฐานครับผ่าน HTTP protocol ดังนั้นในฝั่ง server นั้นเราก็ตั้ง Web API ขึ้นมารับ ส่วน Web API คืออะไร และทำไมต้องใช้ ผมขออธิบายดังนี้ครับ

อย่างที่กล่าวไว้ข้างต้น SPA ที่ผมอธิบายนั้น มีความสามารถหลายส่วนที่ทับซ้อนกับ full-stack web frameworks  ตัว SPA นั้นสามารถทำ routing เองได้ ทำการ rendering ข้อมูลกับ template ก็ทำได้เป็นอย่างดี ยิ่งทำการตรวจสอบความถูกต้องของข้อมูลก่อนการบันทึกที่เรียกว่า validation นั้นการใช้ JavaScript ย่อมเหนือกว่าเครื่องมือตัวอื่นที่ทำฝั่ง server อยู่แล้ว ว่าไปแล้วสิ่งหลักสิ่งเดียวที่ SPA ทำไม่ได้ก็คือการเข้าถึงทรัพยากรของฝั่ง server ก็จำพวกแฟ้มข้อมูลต่างๆ หรือฐานข้อมูลนั่นเอง

ดังนั้นเมื่อเราใช้งาน SPA แล้ว ทางฝั่งของ server ก็ไม่จำเป็นต้องใช้ full-stack web frameworks อีกต่อไป browser แย่งงานไปหมด จะเหลืองานฝั่ง server จริงๆ ก็เพียงเป็น Web API เท่านั้น ซึ่งก็จะเป็นส่วนงานของ business logic และการเชื่อมต่อฐานข้อมูลเท่านั้น ในส่วนของ business logic นั้น ถ้าไม่เป็นความลับกันเกินไป บางส่วนก็สามารถฝากให้ SPA ทำงานที่ฝั่ง browser ได้อีกต่างหาก ดังนั้นงานจริงๆ จึงเหลือเพียง Web API ที่เชื่อมต่อกับฐานข้อมูลเท่านั้น ทำให้งานทางฝั่ง server ซับซ้อนน้อยลงมาก ซึ่งท่านอาจจะใช้ full-stack web frameworks ที่ท่านชื่นชอบทำหน้าที่เป็นเพียง Web API เพื่อติดต่อกับ SPA ก็ได้เช่นกัน

จะว่าไปแล้ว Web API ที่ผมพูดมันก็คือ web services นั่นเอง คำนี้เป็นคำยอดฮิตของเมื่อสิบปีที่แล้ว ชื่อ web services มันก็บอกชัดว่าเป็นคำกริยา มันก็คือฟังก์ชันงานมักจะเป็นการกระทำงานขนาดใหญ่ ทำงานตามคำขอของฝั่ง client  จะพูดว่า web API เป็น web services ก็คงไม่ค่อยเต็มปากนัก เพราะงานส่วนมากของ  web API เป็นงานขนาดเล็กๆ เช่นขอข้อมูลจากฐานข้อมูลก็ส่งให้ โดยมากในแต่ละ web API จะมีโค๊ตโปรแกรมนิดเดียว อาจจะ 10-15 บรรทัดเท่านั้น ในวงการจึงนิยามคำว่า  microservices ขึ้นมาใช้ ซึ่งมีรายละเอียดเยอะมากครับ  เอาไว้โอกาสเหมาะๆ จะค่อยเล่าเรื่อง microservices ให้ฟังฟังอีกที

JavaScript – หลีกไม่ไกล ไปไม่พ้น

ดังที่กล่าวไปแล้วข้างต้น ถ้าใช้ SPA นั่นหมายถึงการเขียนโปรแกรมนั้นต้องทำงานบน browser เท่านั้นซึ่งตัวเลือกของท่านจะตีบมาก ภาษาที่ท่านใช้งานได้จะเหลือเพียง JavaScript เท่านั้น ผมพูดอย่างนี้มันก็ไม่ถูกต้องเสียทีเดียว ยังมีภาษาอื่นอีกมากครับที่ทำงานบน browser ได้ เช่นอยากจะใช้ Python ให้ทำงานบน browser ก็ย่อมทำได้ แต่ประสิทธิภาพที่ได้นั้นอาจมีปัญหา ผมขอขยายความอย่างนี้ก็แล้วกัน

ในเชิงเทคนิคนั้น JavaScript นั้นได้รับอิทธิพลมาจากภาษา C โดยตรง รองรับโครงสร้างแบบภาษา C มาได้เกือบทั้งหมด ยังผนวกเอาแนวคิด object มาใช้ได้อย่างมีประสิทธิภาพอีกด้วย JavaScript นั้นปัจจุบันทำงานบน browser เป็นแบบคอมไพล์ ว่ากันว่าประสิทธิภาพที่ได้นั้นจึงสูสีกับ C++ กันเลยทีเดียว จะเสียเวลาคอมไพล์เพียงเล็กน้อยเมื่อเริ่มรันครั้งแรกเท่านั้น

คราวนี้ถ้าท่านต้องการใช้ภาษาอย่างเช่น Python บน browser ท่านก็สร้างหรือไปหา Python interpreter ที่ทำงานบนเว็บมาใช้งาน การทำงานก็เหมือนกับ CPython แบบปกติ ซึ่ง CPython นั้นเขียนด้วยภาษา C เมื่อคอมไพล์ด้วย C คอมไพเลอร์ก็จะได้เป็นภาษาเครื่อง เราใช้เป็นตัว runtime โปรแกรมภาษา Python

ฉันใดก็ฉันนั้น ถ้าเราเขียน Python  interpreter แทนที่จะเขียนด้วยภาษา C แต่หากไปเขียนด้วยภาษา JavaScript แทน Interpreter ตัวนั้นก็จะสามารถรันโปรแกรม Python บน browser ได้  มีคนเขียน interpreter ลักษณะนี้มาแล้วหลายตัวหลายภาษาครับ ส ท่านลองไปคนใน internet ดู หาไม่ยาก แต่แน่นอนครับ ประสิทธิภาพที่ได้ย่อมช้ากว่าเขียนโดยใช้ภาษา JavaScript โดยตรงอย่างเห็นได้ชัด เพราะทำงานเป็นแบบ interpreter แถมยังมีประเด็นเรื่องความไว้ใจด้วยครับ เราจะไว้ใจได้แค่ไหนว่าผู้สร้าง interpreter จะพัฒนาอย่างต่อเนื่อง ส่วนมากที่ทำเพราะคันครับ พอหายคันก็เลิกทำ ลักษณะนี้เห็นกันอยู่บ่อยๆ ดังนั้นวิธีนี้จึงไม่ค่อยนิยมครับ

มาถึงวิธีที่สอง เนื่องจากภาษา JavaScript มีชื่อเสียอย่างมากว่าภาษาสับสน (อารมณ์เหมือนว่าภาษา C นั่นแหละ แต่หนักกว่า) ว่ากันว่าเก้าในสิบคนของผู้ใช้ครั้งแรกนั้นส่ายหน้ากันเลยทีเดียว ซึ่งจริงๆ ภาษามันไม่ได้แย่ขนาดนั้น ในความคิดผมกลับตรงกันข้ามเสียอีก รายละเอียดส่วนนี้ค่อยไปหาอ่านในบทความต่อๆ เรื่อง JavaScript นะครับ ตอนนี้วกกลับมาก่อน ด้วยชื่อที่เสียนั้น ทำให้มีคนคิดค้นทำให้หายงง โดยแก้จุดอ่อนต่างๆ (ที่เชื่อว่าเป็นจุดอ่อน) เช่นเพิ่มเติม static-typed เข้าไป หรืออาจจะทำให้สร้าง class ได้ กลายเป็นการต่อยอดภาษา JavaScript ไป

ภาษาแนวคิดดังกล่าวมีหลายตัว เช่น DART, CoffeeScript หรือ TypeScript เป็นต้น ภาษาเหล่านี้ จะเอา source code มาคอมไพล์โดยใช้คอมไพเลอร์ของภาษานั้นๆ  แต่แทนที่ผลลัพธ์จะคอมไพล์กลายเป็นภาษาเครื่อง แต่หากกลายเป็นเป็นภาษา JavaScript แทน ดังนั้นเราจึงสามารถใช้ JavaScript คอมไพเลอร์ปกติ เพื่อคอมไพล์ให้เป็นภาษาเครื่องปกติต่อไป ทำให้ประสิทธิภาพนั้นลดลงเพียงเล็กน้อยเท่านั้นจากการคอมไพล์ในรอบแรก

การทำงานแบบนี้จึงเป็น source-to-source compiler บางครั้งเรียกว่า ทรานส์คอมไพเลอร์ (transcompiler) หรือบ่อยครั้งที่เรียกกันสั้นๆ ว่า ทรานส์ไพเลอร์ (transpiler) แนวคิดของการ ทรานส์ไพล์มีมานานแล้วครับ ในอดีตนั้น  การมีการแปลง source code ไปกลับระหว่าง Pascal กับ C,   VB.NET กับ C# เป็นต้น หรือแม้แต่ภาษา C++ เองก็ตาม ในยุคแรกที่ยังไม่มีคอมไพเลอร์ C++ โดยตรง ต้องใช้ CFront ทำหน้าที่เป็นทรานไพเลอร์แปลง source code จาก C++ มาเป็นภาษา C เพื่อให้ใช้คอมไพเลอร์ภาษา C ปกติ คอมไพล์เป็นภาษาเครื่องอีกที

ภาษาในกลุ่มที่ 2 นี้ก็มีภาษา TypeScript ที่มาแรงแซงทางโค้ง ซึ่งเพิ่งมาดังจริงจังก็ตั้งแต่เดือน มีนา 15 นี่เอง ทำไมถึงดังเดี๋ยวผมจะเฉลยให้ฟังในส่วนถัดไปครับ เรามาดูตัวภาษา TypeScript กันก่อน จะว่าไปแล้วมันเหมือนกับ C++ อย่างหนึ่งครับ ถ้าเราเอา source code ภาษา C  ไปคอมไพล์โดยใช้ C++ คอมไพเลอร์จะผ่านฉลุย ทำงานได้โดยไม่ต้องแก้ไขเลย เนื่องจาก C เป็น subset ของ C++ นั่นเอง  TypeScript ก็เช่นกัน มอง JavaScript เป็นซับเซ็ท ดังนั้นจึงเอา source code ภาษา JavaScript ไปคอมไพล์ก็จะผ่านได้โดยไม่ต้องแก้เช่นกัน ดังนั้นพูดในอีกแง่หนึ่งก็คือ TypeScript นั้นเพิ่มเติม syntax ของ JavaScript นั่นเอง ดังนั้นในบทความทั้งหมวดนี้ผมจะเน้นเอาทั้งสองภาษาคือ JavaScript และ TypeScript

รัก SPA ก็ต้องรัก JavaScript ครับ

จบได้ในหนึ่งภาษา

พี่ศักดิ์แกเก่ง Java ครับ แกเป็นกูรูของบริษัทเลย ติดอะไรเรื่อง Java ไม่ว่าจะเป็น Spring,  EJB หรืออะไรก็ตามเทคโนโลยีอะไรที่ขึ้นด้วย J (ยกเว้น JS) ถามแกเถอะ ดวงตาแกเห็นธรรม รู้เจนจบทั้งหมด ส่วนพี่ศรี เธอก็มีดีทางฝั่งของ Microsoft ตระกูล .NET อะไรแกก็รู้หมดเช่นกัน โปรแกรมเมอร์มือใหม่มีอะไรก็ต้องถามแกทั้งนั้น มีบริษัทไม่น้อยครับที่ทำงาน EA แล้วอยู่ในลักษณะนี้ คือเป็นเบี้ยหัวแตก เทคโนโลยีมากมายเต็มไปหมด บางบริษัทยิ่งไปกันใหญ่ ผสมหลายเทคโนโลยีในงานเดียวกันอีก เช่นใช้ Java เป็น backend และใช้ ASP.NET เป็น Frontend หรืออาจผสมอย่างอื่นเข้ามาอีกเช่น PHP, Ruby on Rails, django เป็นต้น วุ่นวายมาก กลายเป็นหอคอยบาเบลกันเลยทีเดียว การดูแลเทคโนโลยีที่หลากหลายนี้ ยุ่งยากมาก ค่าใช้จ่ายสูง และเสี่ยงต่อการขาดแคลนทรัพยากรบุคคลมากครับ

แม้ว่าบริษัทไม่น้อยจะฟันธงใช้จะเลือกเพียงเทคโนโลยีตัวใดตัวหนึ่งเพียงตัวเดียวที่เป็น full-stack web framework ก็ตาม แต่อย่าลืมพี่ศรนะครับ พี่ศรแก่เป็นเซียน JavaScript ตระกูลที่มีคำว่า JS นี่แกช่ำชองนัก  ไม่มีพีศรก็แย่เหมือนกัน พี่ศรแกเขียน JavaScript ใช้ในการตรวจสอบความถูกต้องของข้อมูล แทนที่จะส่งกลับมาตรวจสอบที่ฝั่ง server ทำให้ได้ประสิทธิภาพดีขึ้นมาก แถมลูกเล่นปรู๊ตปร๊าดสวยงามบนเว็บก็ต้องพึ่งฝีมือของแกครับ ไม่ว่าจะใช้อะไรเป็น backend ก็ตาม แต่ถ้าเป็น frontend ก็ต้องพี่ศรเท่านั้นครับ

มันจะดีกว่าไหม ถ้าการพัฒนาระบบทั้งระบบใช้เพียงภาษาเดียว หนึ่งภาษาใช้มันทุกส่วนทั้ง frontend และ backend ไปเลย ทางฝั่ง server ไม่มีปัญหาครับ .NET, Java, Ruby, PHP, Python แค่หนึ่งเดียวตัวใดตัวหนึ่งเอาอยู่แน่นอน แต่ที่กล่าวมาทั้งหมดนี้ใช้เขียนโปรแกรมบนฝั่ง browser ไม่ได้ สุดท้ายก็ยังคงต้องพึ่งพี่ศรอยู่ดี มองดูเหมือนว่าระหว่าง browser และ server มันมีห้วยกั้น ทำให้ต่างฝ่ายต่างมีโลกเป็นของตัวเองที่แตกต่างกันโดยสิ้นเชิง งานเขียนโปรแกรมเว็บที่ใช้แนวคิด MVC นั้นแบ่งทีมการเขียนออกเป็นสองกลุ่มโดยอาศัยห้วยนี้เป็นเส้นแบ่งคือ พวก front-end developers พวกนี้จะศึกษาสามประสานคือ HTML, CSS และ JavaScript และอีกพวกก็คือ back-end developers ก็คือเรียนรู้ full-stack web frameworks ต่างๆ โดยใช้ภาษาคอมพิวเตอร์และเครื่องมือที่กล่าวมาแล้วข้างต้น และกลุ่มหลังนี้มักจะรวบงาน SQL Server เอาไว้กับตัวด้วยเลย

แต่ในทางกลับกัน JavaScript เป็นเสืออยู่บน browser จะมาทำงานบนฝั่ง server ก็ดูไม่น่าจะได้ แต่ที่จริงแล้ว ไอ้เสือ JavaScript มันข้ามห้วยมาฝั่ง server มานานพอสมควรแล้วครับ

 Node.js ไอ้เสือข้ามห้วย

ถ้าเปรียบ JavaScript เป็นเสือ มันเป็นเสือที่ถูกถอดเขี้ยวเล็บหมดแล้ว จะว่ามันพิการก็ไม่ผิดนัก เทียบกับภาษาอื่นๆ JavaScript นับว่ามีประสิทธิภาพสูง แต่ความสามารถต่ำ ที่เป็นอย่างนี้เพราะความตั้งใจให้มันเป็นเช่นนั้น ก็ท่านเลี้ยงเสือเอาไว้ใน browser ซึ่งอยู่ในเครื่องของท่านเอง ท่านเลี้ยงเสือในบ้านท่านนะครับ ถ้ามันไม่เชื่องขึ้นมา รับโปรแกรมภายนอกที่อันตรายมารัน มันอาจจะแว้งกัดท่านได้ เช่นขโมยรหัส password แอบลบแฟ้ม หรือแม้กระทั่งเปิดประตูให้โจรเข้า เกิดได้ทั้งนั้นครับ ดังนั้น JavaScript บน browser จึงถูกตัดความสามารถหลายอย่างออกไป โดยเฉพาะอย่างยิ่ง I/O นั้นแทบไม่มีเอาเสียเลย (แต่แม้ว่าถอดเขี้ยวเล็บหมดแล้ว แต่เสือก็ยังคงเป็นเสืออยู่วันยังค่ำ พิษสงยังรอบตัวอยู่ ทุกวันนี้ JavaScript ยังถือว่าเป็นตัวอันตรายอยู่บน browser อยู่ดี)

ในปี 2009 มีบริษัทหนึ่งชื่อว่า Joyent มีความคิดที่จะปล่อยเสือเข้าป่า ไม่ต้องโดนกักขังอยู่แต่ใน browser อีกต่อไป โดยเติมเขี้ยวเล็บที่เคยขาดหายมาให้ ผลลัพธ์ก็คือ Node.js นั่นเอง มอง Node.js  นึกถึง Node.js ก็ให้นึกถึง Python หรือ Ruby interpreters ก็ได้ครับ ทุกอย่างเกือบเหมือนกันหมด ต่างกันแต่ตัวภาษาเท่านั้น  เวลาใช้เราพิมพ์คำว่า node ตามด้วยชื่อแฟ้มของโปรแกรม JavaScript ของเรา มันจะเอาไปคอมไพล์ในหน่วยความจำแล้วรันทันที มันจึงเป็นทั้งคอมไพเลอร์และตัว runtime ในตัวเดียวกัน แม้ว่าความสมบูรณ์ของ library ยังไม่อาจเทียบเท่ากับทาง Python หรือ Ruby แต่ก็ยังคงเพิ่มขึ้นอย่างต่อเนื่อง แรงดีไม่มีตกจากปี 2009 จนถึงปัจจุบัน

เมื่อ node.js มีเขี้ยวเล็บครบ มันจึงสามารถข้ามห้วยไปไล่งับเครื่องมือตัวอื่น จริงๆ แล้วเป็นความตั้งใจของ Joyent ตั้งแต่แรก เขาตั้งใจทำให้มันข้ามห้วย เมื่อแนวคิดมันเหมือนกับ Python และ Ruby ดังนั้นมันจึงสามารถเพิ่ม libraries หรือ frameworks ต่างๆ เข้าไปได้ ในแง่ของ web frameworks มันก็มีตัวง่ายๆ อย่าง express.js หรือจะเอาแบบ full-stack web framework ที่พอสูสีกับ Ruby on Rails หรือ django ก็มีใน Node.js เช่น Sails.js, Krakenjs เป็นต้น ถามว่า frameworks ต่างๆ หลายภาษาที่มีตามท้องตลาดปัจจุบันมันก็มีมากแล้วและดีๆ ทั้งนั้น แล้วทำไมเราต้องมาสนใจ Node.js ที่เป็นของค่อนข้างใหม่ ทั้ง nodes.js กับ frameworks ก็ยังถือว่าใหม่ ทำไมไม่ใช้ Python, Ruby หรือเครื่องมืออื่นๆ ที่คนใช้กันอย่างแพร่หลายกว่า

คำตอบของคำถามดังกล่าวอยู่ข้างบนแล้วครับ จบได้ในหนึ่งภาษา  ผมกำลังพูดถึงในเชิงธุรกิจครับ ถ้าบริษัทใดก็ตามใช้เพียงภาษาเดียว ต้นทุนการผลิตจะลดฮวบเลยครับ ทั้งในแง่ทรัพยากรบุคคล  การเรียนรู้ที่สั้นลงมาก ขนาดทีมที่เล็กลง ทรัพยากรบุคคลทางด้านการเขียนโปรแกรมนั้นก็รู้ๆ กันอยู่ครับ ว่าหายากมาก แย่งชิงตัวกันอย่างกับนางงามในหนังจีน ปัญหาเหล่านี้ท่านก็คงทราบดีอยู่แล้ว

ในมุมมองของค่าใช้จ่ายเรื่องเครื่องมือที่ใช้ในการพัฒนาก็เช่นกัน ถ้า จบได้ในหนึ่งภาษา ต้นทุนจะถูกลง runtime ไม่ต้องเสียเพราะทำงานบน browser ฟรีอยู่แล้ว ส่วนเครื่องมือในการพัฒนาก็ราคาถูกมาก หรือแม้กระทั่งของฟรีคุณภาพดีมีหลายตัว ผมไม่สนับสนุนการละเมิดลิขสิทธิ์นะครับ เราใช้ของฟรีดีกว่า ซึ่งเมื่อใช้ภาษาเดียว ในแง่เวลาในการพัฒนาจะใช้เวลาในการพัฒนาที่สั้นกว่า และแก้ไขสามารถปัญหา impedance mismatch ได้ ซึ่งถ้าท่านไม่รู้ว่าคืออะไร เดี๋ยวลองอ่านบทความนี้ให้จบแล้วท่านจะทราบครับ

ผมขอพาท่านแวะออกนอกทางอีกเล็กน้อยครับ ถ้าพูดถึง Node.js แล้วจะไม่พูดถึง V8 ของ Google ก็คงไม่ครบถ้วนนัก V8 ก็คือ JavaScript Engine หรือ JavaScript compiler ของ Chrome นั่นเอง ในอดีตนั้นก่อนที่จะมี chrome เกิดขึ้นมา browser ต่างๆ ทุกยี่ห้อ ก็จะรัน source code ของ JavaScript โดยใช้ interpreter ในตอนนั้นเป็นอันรู้กันว่า การคอมไพล์ภาษาที่เป็น dynamic นั้นเป็นไปได้ยากมาก เพราะภาษามีความซับซ้อนสูง

แต่สุดท้าย Google ก็ทำลายข้อจำกัดได้เป็นผลสำเร็จครับ เนื่องมาจากศาสตร์ในการสร้างคอมไพเลอร์มีการพัฒนาขึ้น ความยากระดับ JavaScript ปัจจุบันเอาอยู่แล้ว  ดังนั้นในปี 2008 ตอนที่ Google ปล่อย Chrome รุ่นแรกออกมา ก็มาพร้อมกับ V8 เลย สิ่งที่ผู้ใช้สัมผัสได้ก็คือ ความเร็วที่ลื่นไหลกว่า browser ยี่ห้ออื่นอย่างเห็นได้ชัด นั่นก็เพราะ V8 ที่ทำงานเป็นแบบคอมไพล์แทนที่จะเป็นแบบ interpret นั่นเอง และก็เพราะ V8 ทำให้ Chrome เป็น browser ที่มียอดผู้ใช้สูงสุด มีส่วนแบ่งการตลาดปัจจุบันถึงประมาณ 50% เลยทีเดียว แม้ว่าในปัจจุบัน JavaScript Engine เกือบทุกยี่ห้อ น่าจะเป็นคอมไพเลอร์กันหมดแล้วก็ตาม

V8 เป็น OpenSource ครับ ก็ Joyent นี่แหละ เอา V8 ของ Google ไปเสริมเขี้ยวเล็บกลายเป็น Node.js ในทุกวันนี้

AJAJ และ JSON

ดังที่กล่าวไปแล้วนั้นว่า เมื่อเราใช้ SPA นั้น ทางฝั่ง server จะเหลืองาน Web API เท่านั้น ซึ่งท่านใช้ full-stack web framework ของที่ท่านคุ้นเคยอยู่แล้วก็ได้ แต่ถ้าท่านใช้ node.js หละ ไม่ต้องห่วงว่าทำได้หรือเพราะ เพราะขนาด full-stack web framework มันยังทำได้เลย นับประสาอะไรกับแค่ Web API ทำได้สบายอยู่แล้วครับ  ถ้าท่านใช้ node.js เป็น Web API สิ่งที่ท่านจะได้ก็คือ จบได้ในหนึ่งภาษา นั่นเอง ท่านไม่ต้องห่วงว่า Node.js จะไม่สามารถเชื่อมต่อกับฐานข้อมูลของท่านได้ เพราะ Node.js รองรับการเชื่อมต่อกับฐานข้อมูลตัวที่นิยมใช้กันได้ครบทุกตัวอยู่แล้ว

node นั้นไม่เพียงทำหน้าที่เป็น Web API เท่านั้น ในส่วนของแฟ้มข้อมูลต่างๆ นั้นที่ล้วนแล้วแต่เป็น static files Node.js ก็ส่งให้ได้ มันจึงสามารถทำหน้าที่เป็น web server ภายในตัวได้เลย เราก็ไม่จำเป็นต้องเปลืองทรัพทยากรเพื่อรัน web server แต่ถ้าท่านไม่ไว้ใจเรื่องประสิทธิภาพ ก็สามารถไปใช้ web server ตัวกลั่นอย่าง Apache, NGINX หรือ IIS เป็นต้น ก็ย่อมได้

ผมขอขยายความการเชื่อมต่อ SPA ฝั่ง browser กับ Web API ฝั่ง node.js (หรือ web framework ตัวอื่นก็ไม่ต่างกัน) เสียหน่อย การติดต่อแบบ Asynchronous ระหว่าง SPA และ web API นั้น เป็นการรับส่ง object หรือเรามองว่าเป็น record/struct ก็ได้ เพราะมันมีแค่เนื้อหา ไม่ได้มี code โปรแกรมแต่อย่างใด ระหว่างการส่งนั้น จะต้องมีการแปลงข้อมูลที่ต้องการส่งนั้นให้กลายเป็น text เสียก่อน รูปแบบที่นิยมใช้กันก็มี 2 รูปแบบ นั่นก็คือ XML และ JSON  ซึ่งโดยส่วนตัวแล้วผมไม่ชอบ XML เอาเสียเลย เวิ่นเว้อ รุงรัง ดีนะครับที่ปัจจุบัน ชาวโปรแกรมเมอร์ JavaScript หันมาใช้ JSON เป็นมาตรฐาน สั้น กระทัดรัด อ่านรู้เรื่องกว่ามาก  เทคโนโลยีการส่งถ้าเป็น XML ก็จะเรียกว่า AJAX (Asynchronous JavaScript and XML) ส่วนถ้าใช้ JSON ก็เรียกว่า AJAJ (Asynchronous JavaScript and JSON)

ระหว่าง SPA และ Web API นิยมสื่อสารกันด้วย JSON โดยใช้เทคโนโลยี AJAJ

NoSQL ฐานข้อมูลทางเลือก

มาถึงข้อต่อตัวสุดท้ายที่ผมจะเร่งประสิทธิภาพ นั่นก็คือฐานข้อมูล เมื่อพูดถึงฐานข้อมูลแล้ว หลายคนรวมทั้งผมก็จะนึกถึง SQL Server ที่ใช้ Relational Database (RDBMS) model  มาเป็นอันดับแรก ก็มันมีอายุมากว่า 40 ปีแล้ว และก็ยังคงกระพันอยู่ แต่ในระยะหลังมาก็เริ่มมีแนวคิดฐานข้อมูลทางเลือกขึ้นมา แต่ก่อนที่บรรยายสรรพคุณ เรามาดูประวัติกันก่อนตามธรรมเนียมครับ

จากนี้ไป ผมขอใช้คำว่า SQL Server ให้มีความหมาครอบคลุมไปถึง RDBMS ด้วย ถือว่าคำทั้งสองมีความหมายเดียวกันในบทความนี้ครับ

เรื่องของ NoSQL นั้นเริ่มมาจากในแวดวง Big Data ครับ ก็ตรงตัวครับมันคือข้อมูลขนาดใหญ่ยักษ์นั่นเอง ใหญ่มากใหญ่เกินเครื่องคอมพิวเตอร์เพียงเครื่องเดียวจะเอาอยู่ ลักษณะนี้ดูแล้วไม่ค่อยเหมาะกับ SQL Server ประเด็นหลักก็คือ SQL Server นั้นไม่ได้รับการออกแบบในระดับโครงสร้างพื้นฐานให้สามารถกระจายข้ามเครื่องได้ แม้ว่าปัจจุบัน SQL Server หลายยี่ห้อสามารถกระจายข้ามเครื่องได้ แต่ก็ทำได้ไม่ดีนัก

คนที่มีปัญหานี้เดาไม่ยากใช่ไหมครับ ก็พวกทำ search engine นั่นเอง โดยเฉพาะอย่างยิ่ง Google นั่นเอง เมื่อ SQL Server ไม่ตอบโจทย์ ดังนั้น Google จึงออกแบบ DBMS เป็นของตัวเอง ไม่ได้ใช้แนวคิดแบบ SQL Server แต่หากใช้ key-value indexing  แบบสองแกนและเผยแพร่เป็นเอกสารชื่อ Bigtable : A Distributed Storage System for Structured Data ส่วน Amazon ก็ทำคล้ายๆ กันชื่อ Dynamo: Amazon’s Highly Available Key-Value Store ความซับซ้อนในการ query ของ DBMS ทั้งสองตัวนี้คงเทียบกับ SQL Server ไม่ได้ครับ แต่ปรัชญาที่สามารถกระจายข้ามเครื่องได้นั้น เป็นโครงสร้างพื้นฐานของ DBMS ทั้งสองตัวนี้ครับ รวมทั้ง NoSQL DBMS ตัวอื่นๆ เกือบทุกตัวด้วย ดังนั้นมันจึง scale out ออกได้มากเท่าที่ต้องการ นับได้ว่าเป็นจุดเด่นอย่างมาก

คราวนี้เรามาดูที่มาของคำว่า NoSQL กันบ้าง บิดาผู้ให้กำเนิดคำนี้ในความหมายที่ปัจจุบันที่เราเข้าใจตรงกันก็คือ Johan Oskarsson ในปี 2009 หลังจากที่เขาเรียนรู้เกี่ยวกัน Bigtable และ Dynamo ก็เกิดความสนใจศาสตร์ด้านนี้ จึงสร้างชมรม online มาชมรมหนึ่ง ใน meetup (มองเป็น facebook ก็ได้ แต่จริงจังกว่า) และก็ตั้งชื่อเรียกสั้นๆ ว่า NoSQL  โดยนัยยะหมายถึง DBMS แนวคิดไหนก็ได้ที่ไม่ใช่ SQL Server หรืออาจจะเรียกว่า DBMS ทางเลือกก็คงไม่ผิดนัก กลุ่มนี้โด่งดังมากครับ มีคนเข้าร่วมมากมาก กลายเป็นชุมนุมมังกรซ่อนพยัคฆ์ เป็นเวทีที่ถกกันถึง DBMS ทางเลือก และเมื่อมีการถกกัน การพัฒนาก็เกิด ทุกวันนี้เราจึงเห็น NoSQL เติบโตขึ้นเรื่อยๆ ครับ

คนไม่น้อยครับที่ลงความเห็นว่าชื่อ NoSQL นี่ตั้งมาได้แย่มาก เพราะมันทำให้มือใหม่หลายคนเข้าใจผิดว่า DBMS เหล่านี้จะต้องไม่ใช้ภาษา SQL ซึ่งไม่ใช่เลยนะครับ มันจะใช้หรือไม่ใช้ก็ได้ NoSQL บางกลุ่มก็พยายามโปรโมตว่าการ join ใน SQL Server นั้นกินทรัพยากรมาก ไม่น่าเอามาใช้งาน ทำให้บางคนเข้าใจคลาดเคลื่อนว่า DBMS ทางเลือกแบบนี้ต้องไม่มีการ join  ซึ่งก็ไม่ใช่อีกนั่นแหละครับ จะ join ได้หรือไม่ได้ขึ้นอยู่กับผู้ออกแบบครับ จนหลังๆ มีคนพยายามแก้นิยามใหม่ว่า NoSQL = Not only SQL ซึ่งถ้าอย่างนั้นตัว O ต้องเป็นตัวใหญ่ครับ เรื่องชื่อช่างมันเถอะครับ เอาให้เข้าใจตรงกันก็พอ

มี  NoSQL ตัวใหม่ๆ เกิดขึ้นมาเรื่อยๆ ครับ  แม้ว่ามีความหลากหลาย รายละเอียดปลีกย่อยต่างกัน แต่ถ้าแบ่งออกเป็นกลุ่มก็จะได้เป็นกลุ่ม 4 กลุ่มหลักดังนี้ครับ

Column-based Store

คือการใช้ key 2 แกนในการเก็บข้อมูล ซึ่ง Bigtable ก็ใช้แนวนี้

Key-Value Store

อันนี้เราคุ้นเคยกันดีเมื่อตอนใช้ Hash  มี key ตัวตัวสามารถเรียกข้อมูลทั้งก้อนได้อย่างรวดเร็ว Dynamo ของ Amazon จัดให้อยู่ในกลุ่มนี้

Document Store

รูปแบบนี้เก็บเอกสารทั้งเอกสารเป็นข้อมูลหนึ่งตัว คำว่าเอกสารในที่นี้ ถ้าเอา table ใน SQL Server เป็นตัวตั้ง ก็บอกได้ว่าสิ่งที่ Document Store มีเพิ่มเติมนั้น ก็คือสามารถเก็บข้อมูลซ้อนลงไปเป็นชั้นๆ ไม่ใช่ระนาบเดียวกับ table ลองนึกถึงความสัมพันธ์ของประเทศและจังหวัดดูครับ  ถ้าเป็น SQL Server ก็จะแยกเก็บเป็นสองตาราง ตารางประเทศและตารางจังหวัด แต่สำหรับ Document Store นั้นจะมีแค่ Document ประเทศเท่านั้น ส่วนจังหวัดจะซ้อนเข้าไปอยู่ใน field ของ cities ซึ่งภายในก็จะเป็น array ของ document ย่อย แต่ละ document ก็คือจังหวัดในประเทศนั้นเอง เมื่อดึงประเทศออกมาประเทศหนึ่ง จะได้จังหวัดในประเทศนั้นแถมมาทั้งหมด ไม่ต้อง join

ตัว DBMS ทางเลือกที่โด่งดังในกลุ่มนี้ก็คือ MongoDB ที่นับได้ว่าเป็น DBMS ทางเลือกที่มีผู้นิยมใช้มากที่สุดในโลก

Graph Store

แนวคิดของ Graph นั้นตรงไปตรงมาครับ ถ้านึกตามเรื่องของ Object-Oriented ดูนะครับ สมมุติว่าเรามี Object Person คนหนึ่ง เราเก็บจังหวัดบ้านเกิดของเขา ซึ่งจังหวัดนั้นก็เป็นอีก object หนึ่ง object ทั้งสองมีความสัมพันธ์กันแบบ aggregation ใช่ไหมครับ ถามว่า person คนนี้เกิดที่จังหวัดอะไร นี่ต้อง join ไหมครับ ไม่ต้องใช่ไหม ก็แค่ตาม reference เข้าไปก็เจอเลย DBMS แบบ graph นี้ก็ใช้แนวทางนี้ในการ hard-link ระหว่างข้อมูลสองชุด เราจึงสามารถดึงข้อมูลได้อย่างรวดเร็วโดยไม่ต้อง join

ตัว DBMS ทางเลือกที่ดังในกลุ่มนี้คือ Neo4j

NoSQL กับงาน EA

มีคนเข้าใจผิดว่า NoSQL นั้นผูกตายกับงาน Big Data จริงๆ แล้วไม่ใช่ครับ จริงอยู่ที่ NoSQL เกิดขึ้นมาจาก Big Data เกิดขึ้นเนื่องจากะความไม่เหมาะสมของ SQL Server เมื่อต้องกระจายข้อมูลข้ามเครื่อง แต่ก็ใช่ว่าต้องใหญ่ๆ เท่านั้นจึงจะเหมาะสม งานเล็กๆ ก็มีประสิทธิภาพดีครับ อย่างที่บอกครับอยากให้มอง NoSQL เป็น DBMS ทางเลือกมากกว่ามองว่าเป็น DBMS สำหรับ Big Data

มาลองพิจารณาดู MongoDB ที่เป็น NoSQL ที่นิยมใช้สูงสุด มีคนทำ benchmark พบว่าเมื่อเทียบกับ MySQL พบว่า MongoDB นั้นเร็วกว่ามาก แต่อย่าไปเชื่อร benchmark มากเกินไปครับ เวลางานจริงมันอาจแตกต่างออกไป เมื่อ MongoDB ไม่อาจทำ Query ซับซ้อนได้ดีเท่า SQL Server และถ้าำ query ที่ซับซ้อนมากไม่ได้ ก็ต้องดึงข้อมูลหลายรอบ แบบนี้อย่างไรเสียก็ไม่น่าจะเร็วกว่า SQL Server ได้ครับ แต่อย่างที่ว่าจุดเด่นขอ NoSQL คือความสามารถในการกระจายข้ามเครื่อง ใช้หลายเครื่องมาช่วยกันทำได้ กลายเป็นการประมวลผลแบบขนาน ถ้ามันจะชนะ SQL Server มันจะคงชนะได้จากความสามารถนี้เองครับ

เอาหละผมตีมั่วๆ  NoSQL อย่างไรเสียประสิทธิภาพก็อยู่ในเกณฑ์ที่ยอมรับได้ก็แล้วกัน แต่คำถามของผมก็มีอยู่ว่า ทำไมผมต้องเปลี่ยนมาใช้ NoSQL ระบบมีฐานข้อมูลขนาดใหญ่เกิน 1 TB ไม่น่าจะมีเยอะนักครับ ซึ่งหน่วย และข้อมูลขนาด 1TB SQL Server ถือว่าเป็นงานขนมอยู่แล้ว และอย่าลืมนะครับ SQL Server นั้นผ่านร้อนผ่านหนาวมากว่า 40 ปีแล้ว ความสามารถ ประสิทธิภาพ ความเสถียร นี้ไม่ต้องพูดถึงกันแล้ว ส่วน NoSQL เองประเด็นเหล่านี้สู้ได้หรือไม่ ถ้าถามผมนะ ผมตอบตรงๆ เลยว่า ผมไม่เชื่อว่า NoSQL จะมาเทียบเท่ากับ SQL Server ในประเด็นเหล่านี้ อย่างน้อยก็ระยะเวลาอันใกล้ แต่มีประเด็นหนึ่งครับที่เรียกว่าเป็นหมัดเด็ดของ NoSQL หลายตัวเลย ที่ทำให้หลายคนเปลี่ยนใจ เรามาลองดูกัน

ประเด็นเรื่อง Impedance Mismatch

ผมค้างประเด็นเรื่อง Impedance Mismatch เอาไว้ในตอนต้น ขอขยายความตรงนี้เลยครับ คำนี้เป็นคำที่ใช้ในวงการไฟฟ้าอิเล็คทรอนิกส์ ที่มาก็มาจากแหล่งจ่ายไฟครับ ภายในแหล่งจ่ายไฟในอุดมคตินั้นจะไม่มีความต้านทานภายในเลย แต่ในโลกนี้ไม่มีอุปกรณ์ที่ว่าครับ อย่างไรเสียก็ยังต้องมีความต้านทานหลงเหลืออยู่บ้าง ยิ่งแพงยิ่งเหลือน้อย แต่ก็ไม่ศูนย์ ความต้านทานตัวนี้เรียกว่า impedance นั่นเอง ดังนั้นในห้องทดลอง ถ้าเราต้องการรีดกำลังไฟฟ้าสูงสุด เราก็ต้องออกแบบให้โหลดของเรามีความต้านทานให้เท่ากับความต้านทานภายในของแหล่งจ่ายไฟ ถ้าทำได้อุปกรณ์นั้นก็จะได้กำลังไฟฟ้าสูงที่สุด แต่ถ้าตัวต้านทานน้อยกว่าหรือมากกว่า กำลังไฟฟ้าที่ได้จะลดลง หรือเรียกว่าเกิดการสูญเสียหรือลดทอนเกิดขึ้น

เรื่องของ Impedance นี้เรามักจะใช้กับในการสื่อสารแบบใช้สายครับ ถ้าปลายสายทั้งสองข้างมีความต้านทานเท่ากัน กำลังส่งจะได้สูงสุด เราจึงต้องมีการถ่วง impedance สองข้างให้เท่ากัน อาจจะเป็น terminator 50 ohms หรือ 75 ohms เป็นต้น

คำนี้ก็มีการนำเอามาใช้กับการเขียนโปรแกรมเหมือนกันเช่น ในโปรแกรมเราอาจเขียนด้วยภาษา Java เราถือว่าเป็น impedance ข้างหนึ่ง ซึ่งข้อมูลต่างๆ อยู่ในรูปของ objects และ impedance อีกข้างหนึ่งอยู่ใน SQL Server อยู่ในรูปของตาราง มันเข้ากันไม่ได้เลยใช่ไหมครับ เกิด impedance mismatch ขึ้น เรามีทางเลือกอยู่สองทางหลัก ทางแรกก็คือใช้พวก เราปรับ impedance โดยยอมเขียน SQL ใน code  เหนื่อยแน่นอนครับ อาจจะมีเครื่องมือช่วยบ้าง แต่อย่างไรเสียก็ไม่สมบูรณ์ หรือทางที่ 2 เราสร้างตัวกลางในการปรับ impedance Hibernate หรือ EJB  ทำ OR-Mapping โดยการทำ annotation หรือไม่ก็ทำ mapping files แต่ทำอย่างไรเสียมันก็ยังยุ่งยากและไม่สมบูรณ์อยู่ดี

จะเห็นว่าทั้งสองวิธีแรกที่นิยมใช้กันนั้น เรายอมปรับ impedance ของฝั่งการเขียนโปรแกรมให้เข้าได้กับ SQL Server แต่เราก็มีทางเลือกที่ 3 ครับ คือปรับ impedance ของฐานข้อมูลให้เข้า code โปรแกรมที่เขียน แน่นอนครับสำหรับ  SQL Server ไปปรับเขาไม่ได้แน่  จึงมีคนคิดสร้าง DBMS ทางเลือกใหม่ขึ้นมา แทนที่จะมองข้อมูลเป็นตารางเหมือน SQL Server แต่กลับมองเป็น objects แทน เราสามารถบันทึก objects เข้าไปตรงๆ ได้เลย ในการดึงออกก็เช่นกัน แบบนี้ทั้งสองข้างมี impedance เดียวกัน จึงไม่เกิด impedance mismatch  DBMS ทางเลือกที่ว่าก็คือ  ODBMS (Object DBMS) นั่นเอง ผมเคยนำเสนอไปบ้างแล้วในบทความเดิมๆ สมัย TwoGuru ไปลองหาอ่านดูได้ครับ แต่น่าเสียดายที่ ODBMS นั้นไม่ประสบผลสำเร็จ คือทางเทคนิคมันยังติดขัดอยู่ครับ มีข้อจำกัดอยู่มาก ในช่วงที่ผ่านมาเราจึงเห็นเพียงสองวิธีข้างต้นเป็นหลักในพัฒนา

เหตุการณ์มันเปลี่ยนไปก็ตั้งแต่ meetup กลุ่ม NoSQL เกิดขึ้น พลังของคอมมูนิตี้มันน่ากลัวจริงๆ ทางเทคนิคอะไรที่เคยติดเมื่อสิบปีที่แล้ว ก็ถูกพลังมดเหล่านี้ช่วยกันคิดช่วยกันสะสางให้เรียบร้อย วันนี้การเก็บ object ลงฐานข้อมูล ทำได้ตรงแบบไม่ต้องกำหนด schema ด้วยซ้ำไป ดังนั้นในแต่ละ object จึงไม่ต้องมี โครงสร้างเหมือนกันทั้งหมด ทำให้แนวคิดที่ 3 ในการกำจัด impedance mismatch นั้นทำงานได้จริง

ในส่วนของฝั่ง JavaScript นั้น คำว่า object กับ data ให้เทียบเท่ากันอยู่ ถือว่าเข้ากันได้เป็นอย่างดีกันกับ NoSQL ทำให้ เราสาามารถใช้ JSON เป็นสื่อกลางในการรับส่งข้อมูลระหว่าง JavaScript และ NoSQL ทำให้การทำงานไหลลื่นให้ความรู้สึกเหมือนกับเป็นเนื้อเดียวกัน

ผมอาจะเรียก NoSQL ว่าเป็นกำเนิดใหม่ของ ODBMS ก็ไม่น่าจะผิดนัก สำหรับผมแล้วความสามารถข้อนี้เพียงข้อเดียวก็มาพอที่ผมยอมเสี่ยงทิ้ง SQL Server มาตายเอาดาบหน้ากับ NoSQL ครับ งานเขียนโปรแกรมของเราจะเสร็จเร็วขึ้นมาก และข้อผิดพลาดน้อยลงเยอะครับ

สรุปภาพรวม และจุดอ่อน

ดังนั้นก็ครบสูตรแล้วนะครับ SPA ทำงานบน browser มี Node.js ทำหน้าที่เป็น web API เพื่อเชื่อมต่อกับ NoSQL อีกที การพัฒนาระบบ EA ทั้งระบบ ถ้าใช้เทคโนโลยีชุดนี้ จะใช้ภาษาคอมพิวเตอร์เพียงภาษาเดียวคือ JavaScript (หรือ TypeScript) ทั้งนี้ไม่นับภาษาที่เชื่อมต่อกับฐานข้อมูล เช่น SQL หรือภาษา markup อย่าง HTML และ CSS อันนั้นต้องมีแต่ผมไม่นับเป็นภาษาคอมพิวเตอร์

จุดอ่อนของ Framework ข้างต้น

สิ่งที่ผมไม่ชอบเวลานำเสนอเทคโนโลยีใหม่ นั่นก็คือผู้นำเสนอมันจะนำเสนอไปทำนองว่าเทคโนโลยีที่ตัวเองนำเสนอนั้นดีเลิศราวกับฟ้าประทาน แก้ปัญหาเดิมได้อย่างเบ็ดเสร็จ จริงๆ แล้วไม่มีอะไรที่วิเศษขนาดนั้นครับ ทุกอย่างมีข้อดีข้อเสียด้วยกันทั้งนั้น แนวคิดที่ผมคุยไว้ข้างต้นก็เช่นกันครับ มีข้อเสียแน่นอนเรามาลองพิจารณากันเป็นข้อๆ ไป

SPA Security

ปกติแล้ว ในงานเว็บปกติ ผู้ใช้ส่ง request มา เราก็เอา request นั้นมาขยำยำกันเป็นหน้า HTML ก่อนค่อย response ออกไป user จะไม่เห็น code โปรแกรมของเรา แต่ลองนึกภาพดูครับ ในงาน SPA นั้น โปรแกรมเกือบทั้งหมดอยู่บน browser ซึ่งผู้ใช้งานจะเห็นทั้งหมด ในแง่ security ของ business logic ก็จะมีโอกาสรั่วได้ง่ายขึ้นมาก

ความเสถียรและรองรับการทำงานที่ซับซ้อน

NoSQL จะต้องฝ่าด่านเรื่องความเสถียรและการทำงานที่ซับซ้อนให้ได้ เนื่องจาก SQL Server นั้นมันทำได้และได้ผ่านบทพิสูจน์มาแล้วนับไม่ถ้วน พวก NoSQL ยังค่อนข้างใหม่ บางตัวก็มีเสียงบ่นออกมาว่า พอข้อมูลเยอะขึ้น ก็จะทำงานอืดลงอย่างเห็นได้ชัด นี่ยังไม่นับรวมถึงเรื่อง transaction ซึ่งในงาน EA จำเป็นต้องใช้เป็นอย่างยิ่ง NoSQL ส่วนมากก็ยังรองรับ transaction ได้ไม่ค่อยสมบูรณ์นัก

Database Security

ปกติแล้ว ผู้ใช้กับ DBMS นั้นเปรียบเหมือนมีกำแพงหนาๆ กั้น ผู้ใช้ไม่สามารถเข้าถึงได้โดยตรงอย่างแน่นอน ผิดกับ Web API ซึ่งตัวกั้นไม่ใช่กำแพงแล้ว แต่หากเป็นกระจก โอกาสที่ถูกเจาะระบบเป็นไปได้ง่ายกว่ามาก

NoSQL Schemaless

NoSQL DBMS ส่วนมาก เราไม่ต้องกำหนด schema ก่อน อยากจะเก็บข้อมูลก็ส่ง JSON ไปเก็บเลย แต่ละ object ก็ไม่จำเป็นต้องมี field เหมือนกัน ดูเหมือนว่าสะดวกดี แต่ในเวลาใช้งานเราต้องตรวจสอบตลอดเลยหรือว่า object ที่เราดึงมาได้นั้น มี field ที่เราต้องการหรือไม่ ถ้ามีจึงค่อยประมวลผล หรือในทางกลับกัน เราควรไปเติมให้มันมี fields เหมือนกันหมด ถ้าอย่างนั้นมันก็กลับไปเหมือนกับ SQL Server ใช่ไหม

NoSQL Anomaly

ใน Document Model เราเพิ่มประสิทธิภาพของการ query โดยการเอาข้อมูลที่ต้องการใส่ไว้ใน document นั้นแล้วดึงในทีเดียว ดึงครั้งเดียวให้ได้ครบถ้วน ดูเหมือนจะดี แต่ทำแบบนี้ Dr. Codd ผู้คิดค้น RDBMS บอกว่านี่คือ Anomaly น่ากลัวมากเพราะมันทำลาย integrity ดังนั้นเวลาที่ใช้งานลักษณะนี้ต้องมั่นใจว่าเอาอยู่

JavaScript กับงาน EA ขนาดใหญ่

บางท่านอาจไม่มั่นใจภาษา script โดยเฉพาะอย่างยิ่ง JavaScript ที่ออกแบบมาเป็นโครงเล็กทำงานเฉพาะกิจบน browser เท่านั้น จะรองรับงานใหญ่อย่าง EA ไหวหรือ

NoSQL ยังต้องการเวลาที่พิสูจน์ตัวเอง

NoSQL นั้นยังนับว่าใหม่มาก การที่จะเอามาใช้กับงาน mission critical นั้นคิดดีกันแล้วหรือ แม้ว่าดูแนวโน้มดูเหมือนเติบโต แต่จะมั่นใจได้อย่างไรว่ามันจะรองรับงานเราไหว ใช้แล้วไม่ติดขัด และที่สำคัญคือ ไม่ชิงปิดบริษัทหนีเราไป

ผมคงไม่ตอบปัญหาเหล่านี้ในตอนนี้ครับ  เพราะบางข้อผมเองก็ตอบไม่ได้ ผมชวนท่านมาช่วยคิด ไม่ใช่ชวนท่านให้มาเชื่อ ท่านต้องตัดสินใจเองว่าท่านจะใช้หรือไม่ใช้ ส่วนบางข้อผมจะนำเสนอทางออกในบทความต่อๆ ไปครับ

เทคโนโลยีที่ใช้

ผมได้เกริ่นนำไปหมดแล้วถึงแนวคิดที่ผมจะใช้ในเรื่องของ EA คราวนี้ผมจะนำเสนอเครื่องมือและ software ที่ผมจะใช้ตลอดในบทความหมวดนี้ ซึ่งแนวคิดในการเลือกของผมนี้อยู่บนพื้นฐานของของฟรี ไม่ต้องมาคุยกันว่าฟรี speech หรือ ฟรี beer เอาเป็นว่าฟรีแบบภาษาไทยนี่แหละครับไม่งงดี ฟรีนี่คือต้องฟรีจริงๆ เอาไปต้มยำทำแกงอะไรก็ได้ โดยที่ผมไม่ค่อยสนใจเรื่อง Open Source เท่าไหร่ open ไม่ open ก็ช่างมัน ขอให้ฟรีก็แล้วกัน เรื่องนี้ต้องระวัง Open Source อาจจะไม่ฟรีก็ได้ ต้องดู license ให้ดี

JavaScript

แน่นอนครับตามแนวคิด จบได้ในภาษาเดียว ภาษาที่ทำได้ทั้ง frontend และ backend ได้นั้นมีภาษาเดียว นั่นคือ JavaScript ซึ่งผมถือว่าเป็นกาวที่เชื่อมส่วนอื่นเข้าด้วยกัน ดังนั้นบทความชุดที่กำลังเขียนจะเป็นเรื่องราวของ JavaScript เต็มๆ และแถมด้วย TypeScript ดังที่กล่าวมาแล้วข้างต้น

AngularJS

SPA  framework ที่ทำงานบน browser มีหลายตัวครับ เช่น Ember.js, Backbone.js เป็นต้น แต่ตัวที่ดังที่สุด  แต่ตัวแรกและที่ดังที่สุดเป็นของ Google ชื่อว่า AngularJS ตัวนี้มีมาตั้งแต่ปี 2009 แล้ว นับได้ว่าเป็นตัวปฏิวัติวงการอีกตัวหนึ่งเลยทีเดียว

AngularJS นั้นผมใช้เป็นเครื่องมือในการทำ SPA ซึ่งเขียนด้วย JavaScript เต็มรูป ซึ่งปัจจุบันทีมที่พัฒนานั้นเป็นลูกจ้างของ Google จึงถึอว่า Google นั้นเป็นเจ้าของ AngularJS นั้นมีความสามารถของการทำ SPA ที่ผมกล่าวถึงข้างต้นอย่างเต็มเปี่ยม และที่สำคัญที่นับเป็นจุดเด่นอย่างมากนั่นคือ AngularJS สามารถกำจัด impedance mismatch ในการเขียนโปรแกรมกับภาคแสดงผลได้ครับ คืออย่างนี้ ถ้าเรามี object person เพื่อนำแสดงขึ้นจอ เราก็ต้องแกะแต่ละ field และ assign มันเข้าไปบนหน้าจอ และในทางกลับกันก็เช่นกัน ซึ่งว่าไปแล้วก็เหมือนกัน impedance mismatch ระหว่าง code กับ SQL Server นั่นเอง

AngularJS สามารถกำจัดปัญหานี้โดยการทำ two ways communication เราสามารถผูกหน้าจอกับ object ได้เลย ถ้าหน้าจอเปลี่ยน object จะเปลี่ยนอัตโนมัติ และในทางกลับกันถ้า object เปลี่ยน หน้าจอจะเปลี่ยนตาม จะไม่มีการเขียนโปรแกรมรับส่งตัวแปร field ต่อ field อีก ทำให้สะดวกขึ้นมาก ลองนึกดูสิครับ  แก้บนจอเสร็จแล้ว ได้เป็น object โดยอัตโนมัติ จากนั้นก็ส่ง object นั้นไปเก็บยัง NoSQL โดยใช้เพียงคำสั่งเดียว สะดวกดายอะไรจะขนาดนี้

AngularJS ยังใส่ Best Practices / Design Patterns เพื่อรองรับงานขนาดใหญ่ได้ นับได้ว่าเป็นข้อดีมากครับ ผมไม่ค่อยห่วงเรื่อง scalability ของ AngularJS ครับ เพราะทำได้ดีมาก อุดจุดอ่อนของ JavaScript ได้เกือบหมด

AngularJS ยังมีคอมมูนิตี้ขนาดใหญ่ อยากได้ความสามารถอะไร เช่น User Interfaces ต่างๆ ก็มี repository ที่เราไปดึงเอามาใช้ได้เลยไม่ต้องเขียนเอง เหล่านี้ทำให้ AngularJS เหนือกว่า SPA ตัวอื่นครับ

ณ วันที่ผมเขียนบทความนี้ AngularJS รุ่นล่าสุดคือ 1.3 ส่วน 1.4 ยังคงเป็น Beta เมื่อปีที่แล้วทางทีมบอกว่ากำลังวางแผนจะเขียน AngularJS 2.0 โดยรื้อเขียนใหม่ทั้งหมด ทั้งนี้ทางทีมก็อยากได้ syntax ของ JavaScript ที่มันดีหน่อย เท่าที่มันเป็นอยู่ยังไม่ค่อยชอบ ครั้นจะรอ JavaScript รุ่นใหม่ที่กำลังจะออก ก็ดูแล้วความสามารถยังไม่ถึงที่อยากได้ ก็เลยคิดว่า มันมีภาษา TypeScript ของ Microsoft ที่ต่อยอด JavaScript รุ่นใหม่อยู่แล้ว ก็เลยคิดจะเอา TypeScript เป็นต้นแบบแล้วต่อยอดไปเป็นภาษาใหม่ที่ชื่อว่า ATScript แต่เมื่อเดือนที่แล้ว ทีม AngularJS ประกาศปิดโครงการ ATScript และประกาศว่า AngularJS 2.0 นั้นจะใช้ TypeScript ในการเขียน เล่นเอางงกันไปหมดครับ  Google กับ Microsoft จับมือกัน โลกเรายังกลมอยู่ไหมนี่

แต่ Google มีข้อเสียข้อหนึ่งครับ เพื่อเข้าไปในหัวข้อจุดอ่อนได้เลยครับเมื่อเจอคำว่า Google นั่นคือโครงการไหนดูแล้วไม่ทำกำไร ก็จะตัดโครงการนั้นทิ้งอย่างรวดเร็ว software กี่ตัวแล้วครับของ Google ที่เราใช้จนติด พอมาวันหนึ่งก็ประกาศยกเลิกเสียดื้อๆ AngularJS ก็ไม่น่าจะต่างกันครับ ผมว่านะถ้ามีรุ่น 2.0 มาเมื่อไหร่ 1.x ก็จะเลิกทันที ผมเองก็ไม่อยากจะเขียนอะไรที่มันกำลังล้าสมัยในอีกไม่นาน ผมเลยคิดว่าให้ 2.0 ออกมาก่อน แล้วผมค่อยเขียน ระหว่างนี้ยังมีอย่างอื่นที่อยากเขียนอีกเยอะครับ

Node.js

อันนี้ก็น่าสนใจครับ ผมอธิบายถึง Node.js ไว้เยอะแล้ว ก็คงไม่ซ้ำในที่นี้นะครับ

NoSQL

อันนี้ผมรักพี่เสียดายน้องมากครับ NoSQL มีแปลกความแปลกใหม่ แต่ละตัวไม่เหมือนกัน ไม่เหมือนกันพวก SQL Server โครงสร้างอะไรมันก็คล้ายๆ กันไปหมด ผมมองเอาไว้ 3 ตัวครับ ซึ่งก็คือ

MongoDB

ตัวนี้ไม่พูดถึงคงไม่ได้ครับ ด้วยความยอดนิยมของมัน ก็คงต้องพูดถึงอยู่แล้วครับ

OrientDB

OrientDB นั้น เป็นลูกผสมหลาย Model เป็นทั้ง Key-Value,  Graph และ Document Store ในตัวเดียวกัน ตัวนี้แปลกกว่าเพื่อนตรงที่ให้เราสร้างโครงสร้างของฐานข้อมูลได้ Web-based admin ทำได้ดีเยี่ยมมากครับ จุดเด่นคือรองรับคำสั่งภาษา SQL ครับ ใครคุ้น SQL อยู่แล้วจะใช้งานได้เลย แต่ join ไม่ได้นะครับ ใช้แนวคิดในการเชื่อมต่อแบบ graph แทนการ join ได้ครับ และที่เหนือกว่าคู่แข่งอย่าง ArangoDB ที่ผมจะกล่าวถึงถัดไปก็คือระบบการจัดการสิทธิของผู้ใช้ครับ ทำได้ดีมาก รองรับ authentication และ authorization  โดยรวมแล้วผมชอบมาก แต่ถ้าถามถึงความนิยมแล้ว ยังห่าง MongoDB มากครับ

ArangoDB

ตัวนี้น้องใหม่เอี่ยมเลยครับ กำลังไล่จี้ OrientDB มาติดๆ เป็นลูกผสมระหว่าง Key-Value, Graph และ Document Store เหมือนกัน แต่มีจุดเด่นที่ผมว่าสุดยอดก็คือ join ได้ครับ แม้ว่าจะไม่รองรับ SQL มันก็มีภาษา Query เป็นของตัวเองชื่อว่า AQL อาจจะแปลกใหม่หน่อย แต่ใช้ง่ายครับ และที่กล่าวไว้แล้วคือ join ได้ ผมว่านะทีมไหนที่ยังไม่ค่อยคุ้นเคยกับ NoSQL ถ้ามาใช้ ArangoDB จะได้เปรียบมาก เพราะ join ได้ อะไรที่เคยใน SQL Server ก็จะมีวิธีเขียนโดยใช้ AQL เกือบหมดครับ

เท่านั้นยังไม่พอ ArangoDB มี foxx ครับ เทียบได้กับ express ของ node.js ให้มาในตัว ซึ่งภายในก็คือ V8 ของ Google นั่นเอง ดังนั้นเราจึงสามารถตัด tier ของ  Node.js ทิ้งได้ กลายเป็นการเขียนโปรแกรมแบบ Two-Tier เหมือนสมัย Visual Basic เลยครับ   เรามอง foxx เป็น microservice หรือถ้าพูดแบบภาษา SQL Server ก็คือ Stored Procedure นั่นเอง (OrientDB ก็มีลักษณะ Stored-Procedure เหมือนกันแต่ก็ยังสู้ foxx ไม่ได้ครับ) แต่จุดอ่อนของ ArangoDB อยู่ที่ authorization ครับ มันไม่มี ต้องทำเอง แต่เมื่อถัวเฉลี่ยดูแล้ว ผมชอบเลือก ArangoDB มากกว่า OrientDB อยู่เล็กน้อยครับ

MongoDB นั่นรุ่งแน่ แต่ OrientDB และ ArangoDB นั้นฐานผู้ใช้ยังถือว่าต่ำมาก แต่ก็มีแนวโน้มเติบโตขึ้น รักพี่เสียดายน้องครับ เลยว่าจะเหมาหมดทั้งสามตัว ผมจะค่อยๆ ทะยอยเขียนให้อ่านกับครับ

 สรุป

แนวคิด SPA อาจไม่ใช่แนวคิดใหม่นัก แต่มันกำลังกลายเป็นกระแสหลัก ความนิยมเพิ่มขึ้นเรื่อยๆ เพราะมีจุดเด่นหลายอย่างที่หาไม่ได้จากเทคโนโลยีตัวอื่น เมื่อผนวกกับ Node.JS ทำให้การเขียนโปรแกรมด้วยภาษา JavaScript เพียงภาษาเดียวนั้นเป็นไปได้ และประหยัดต้นทุนอย่างมาก และยิ่งเมื่อผนวกกับ NoSQL แล้วทำให้การเขียนโปรแกรมง่ายขึ้นมาก เพราะลด Impedance Mismatch ลงไป ดังนั้นบทความในหมวดนี้จึงข้อกล่าวเรื่องราวเกี่ยวกับเรื่องดังกล่าวด้วยประการฉะนี้

 

 

 

 

 

 

 

 

 

  • ภาษาเดียวทั้งระบบ
  • บัง DOM
  • Two-way Data-binding
  • Clean Programming by Injecting
  • SPA

 

MongoDB

  • Tables are Collections   –  no schema
  • Rows are Documents    –  need not to be same in term of field names

ปัญหา RDBMS

impedance mismatch   ระหว่าง object ในโปรแกรม และ RDBMS

ระบบทุกระบบเข้ามารวม ทำหน้าที่เป็น Interator  (Integration Databases)

ข้อดีคือ เชื่อมต่อทุกระบบได้ แต่ข้อเสียคือ ซับซ้อน ปรับแล้วกระทบระบบอื่น Index boom

ถ้าทำหน้าที่เป็น Application Database ของใครของมัน วิธีการทำ Integration คือ ถ้าระบบอื่นมาขอใช้ก็จะต้องทำ Service ให้เข้าถึง กลายเป็น SOA และ Web Service   ระบบแต่ละระบบเขียนด้วยเครื่องมือคนละตัว ดังนั้นการรับส่งจึงกำหนดมาตรฐาน เรียกว่า XML และ JSON ในที่สุด

บริษัทใหญ่ แต่ละแผนกอาจมีทีม IT เป็นของตัวเอง จึงมีอิสระในการเลือก RDBMS และเครื่องมือในการพัฒนา

การเข้ามาของ Web นั้นทำให้เกิด client boom เราอาจ scale up คือเพิ่มกำลังเครื่องคอม ยิ่งกำลังสูง ยิ่งแพงเป็นอัตราเร่ง แต่สุดท้ายก็ต้องตัน อีกทางคือ scale out คือเพิ่มเครื่อง ถูกและแก้ปัญหา Single Point of Failure ได้

Web ขยายเครื่องได้ แต่ธรรมชาติ RDBMS ไม่ได้รับการออกแบบมาให้ scale out โดยมากเราจะ scale out โดยการทำ cluster SQL Server แต่ข้อมูลก็ต้องเอามาจาก storage ตัวเดียวกันอยู่ดี

หรือเราอาจจะแยก RDMS ออกเป็นหลายเครื่อง แต่ละเครื่องมีข้อมูลคนละส่วน เราเรียกว่า sharding โดยที่ โปรแกรมของเราต้องรู้เองว่าเราอ่านเขียนอะไรจาก database ไหน ทำแบบนี้ ค่า licenses บาน

Amazon สร้าง Dynamo และ Google สร้าง BigTable  เพราะดูแล้ว RDBMS ไม่ไหว

ปี 2009  Johan Oskarsson ได้รับแรงบันดาลใจจาก BigTable กับ Dynamo มี idea ในการสร้าง DBMS ตัวใหม่ opensource, distribute และ non-relational จึงประกาศหาแนวร่วมผ่าน Internet โดยใช้ช่อง #NoSQL ใน IRC เพื่อจัด meeting สักครั้ง แต่สุดท้ายคำนี้กลายเป็นศัพท์ในวงการไปเลย

การบูมของ NoSQL ทำให้เกิดหลายค่ายหลายสำนักคิดค้น NoSQL Database บ้างก็เป็น indy DBMS ที่ทำมาก่อนคำ NoSQL เกิด แต่เมื่อไล่ดูจริงๆ ก็พบว่ามี 4 วิธีหลักในการจัดเก็บข้อมูล ได้แก่

  • column
  • graph
  • document
  • key-value

เมื่อรวม RDBMS เข้าไปก็กลายเป็น polyglot persistent

ประเด็นสำคัญคือ NoSQL ไม่เหมาะเป็น integration database เหมาะที่จะเป็น application database มากกว่า

 

 

 

 

 

 

 

 

[Total: 7    Average: 4.3/5]

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *