Tag Archives: NoSQL

Martin Fowler at Singapore, June 2012

เมื่อวันพฤหัสฯ ที่ผ่านมา ThoughtWorks ได้ทำการประกาศตัวว่าเปิดสาขาที่ Singapore แล้ว ด้วยการนำ Martin Fowler Chieft Architecture Scientist ผู้ที่มีชื่อเสียงมากที่สุดคนหนึี่งในด้าน Agile มาพูดให้ฟัง งานแบบนี้ส่วนตัวก็ไม่พลาดไปติดตามแน่นอน และยังได้พบพี่ๆจากไทย ทั้งพี่แป๋ม พี่จั๊วและพี่เก๋ ที่สองคนหลังเค้าบินมาเพื่องานนี้โดยเฉพาะ!!

การพูดของเค้าครั้งนี้ แบ่งออกเป็น 3 เรื่อง ซึ่งล้วนแล้วแต่เป็นเรื่องที่เค้าได้เขียนลง blog ของเค้าแล้วทั้งนั้น ใครติดตาม blog เค้าอยู่เป็นประจำคงเคยได้อ่านผ่านตามาบ้าง แต่กับการที่เค้ามาอธิบายให้ฟังก็ทำให้เข้าใจและจับประเด็นสำคัญได้ดีมากขึ้นอยู่เหมือนกัน

เริ่มด้วยเรื่อง NoSQL DATA MODELS

เค้ากำลังเขียนหนังสือที่มีชื่อว่า NoSQL Distilled อยู่ เลยได้ดึงเนื้อหาบางส่วนออกมาพูดให้ฟัง

  • เค้าเรียกการรวมกันของ NoSQL ประเภท Key-Value และ Document Store ว่า Aggregate-Oriented Database ประเด็นของมันคือการเก็บกลุ่มของข้อมูลที่ได้ทำการ denormalize แล้วนั่นเอง ทำให้ถ้าเราเข้าถึงกลุ่มของข้อมูลนั้นผ่าน key ปกติจะทำได้เร็วและถูกกว่า relational database แต่เมื่อไหร่ที่เราต้องการเข้าถึงข้อมูลใน pattern อื่นก็จะทำได้แย่กว่า relational database
  • (จากรูป) งานที่เหมาะมากๆ กับ NoSQL คือ custom fields และ non-uniform data แต่เรื่อง migration ที่หลายคนพูดว่าเป็นข้อดีหนึ่งของ NoSQL นั้น เค้าไม่เห็นด้วย เค้ามองว่าในการเก็บข้อมูลเราก็จะมีการคิดถึงรูปแบบในการจัดข้อมูลซึ่งหมายถึงมี implicit schema อยู่ดี

เรื่องต่อมาคือเรื่อง 2 Kinds of software projects

  • เค้าจัดกลุ่มการพัฒนาซอฟแวร์บนโลกนี้ออกเป็น 2 กลุ่ม คือ strategic software และ utility software
  • Strategic software (S) คือ software ที่สร้างข้อได้เปรียบในเชิงการแข่งขันทางธุรกิจ
  • Utility software (U) คือ software ที่นำมาใช้ช่วยการดำเนินธุรกิจ
  • เป้าหมายของ S คือ innovation และ speed, เป้าหมายของ U คือ ถูก
  • S ควรทำเอง, U ควรซื้อสำเร็จ
  • ความเสี่ยงของ U คือการทำพลาด, ความเสี่ยงของ S คือการไม่ทำ

เรื่องสุดท้ายคือ Continuous Integration และ Continuous Delivery

  • Source code version control ในปัจจุบันยังทำได้แค่การ merge text แต่ยังมีการ merge sematic ที่ทำไม่ได้ หากนึกตัวอย่างไม่ออกลองนึกถึงสถานการณ์ ที่เพื่อนร่วมทีมของเราเปลี่ยนการทำงานของ method ที่เราเรียกใช้อยู่ซึ่งทำให้ผลลัพธ์ของ method นั้นเปลี่ยนไปจากตอนที่เราเขียนโปรแกรมเรียกใช้มัน
  • สิ่งที่พอจะทำให้เราตรวจสอบ sematic merge ได้มีแค่ test เท่านั้น
  • พอการ merge มันสร้างความลำบากทำให้เราไม่อยาก merge กันเท่าไหร่ เลยหนีไปทำ feature branch กัน
  • แต่ feature branch ก็ยังไม่ช่วยให้การ merge มันง่ายขึ้น การแก้ปัญหานี้ที่ถูกต้อง คือควรจะ merge กันบ่อยๆ จากรูปจะเห็นว่าเค้าจำลองเหตุการณ์ของการแก้ไขที่ไม่ตรงกันของ 2 developer ด้วยลูกศร และจุดที่เราพบว่าการแก้ไขของคนสองคนขัดกันด้วยจุดแดง จะเห็นว่าถ้ารวม code กันบ่อยๆ ก็จะเจอจุดบกพร่องเร็วกว่าการแตก branch มาก
  • การรวม code กันบ่อยๆ นั่นคือแนวคิดที่เป็นหัวใจของ Continuous Integration นั่นเอง
  • ส่วน Continuous delivery คือ กระบวนการการนำซอฟแวร์จากจุดที่ dev commit ไปอยู่ในจุดที่พร้อมจะ release แบบอัตโนมัติ เหลือไว้เพียงแค่การกดปุ่ม release จากการเห็นชอบของฝ่าย business เท่านั้น
  • วิธีที่ใช้ในการทำให้เกิด Continuous delivery คือ deployment pipeline คือสร้างลำดับการรัน test หลายๆ ขั้นขึ้นมา เนื่องจาก test แต่ละระดับมีความเร็วช้าและความครอบคลุมต่างกัน จึงวางกลุ่ม test ที่รันได้เร็ว (จากการที่ตัด dependency ออก) ไว้ก่อน เพื่อให้สร้าง feedback ได้เร็วที่สุด หากผ่านชั้นที่เร็วไปได้ ก็ไปสู่ในชั้นที่ test ระหว่างส่วนมากขึ้น แต่รันได้ช้าลงต่อไป
  • ไม่ควร compile code ใหม่ระหว่างขั้น เพื่อลดความผิดพลาดในการ test จากความแตกต่างของสภาพแวดล้อมที่ใช้ในการ test
  • พี่จั๊วถามคำถามด้วยว่า ถ้าไปเจอปัญหาใน test ขั้นหลังๆ ควรทำอย่างไร เค้าก็ตอบว่าให้ไปเพิ่ม unit test ที่ครอบคลุมมากขึ้น
Advertisements

NoSQL CAP Theorem คืออะไร

ในยุดที่ NoSQL กำลังมาแรง มีให้เลือกใช้มากมายหลายยี่ห้อจนเลือกไม่ถูก ก็มีคนได้จัดแต่ละยี่ห้อออกเป็นกลุ่มๆ ด้วยข้อจำกัดของแต่ละยี่ห้อ ตามทฤษฎี CAP ไว้ที่ link นี้ Visual Guide to NoSQL Systems.

ใน blog นี้ผมจะมาอธิบาย CAP ว่าหมายถึงอะไรเป็นภาษาไทยละกันนะครับ

C – Consistent – ความตรงกันของข้อมูล หมายความว่า เมื่อผู้ใช้อ่านข้อมูลจาก node ต่างๆ ของ database ที่กระจายอยู่ จะได้ข้อมูลตรงกันเสมอ

A – Available – ความพร้อมใช้งานของข้อมูล หมายความว่า ผู้ใช้งานสามารถ อ่านหรือเขียนข้อมูล ลงบน database ได้เสมอ ไม่ต้องรอ (ไม่ติด locking)

P – Partition Torelant – ความทนทานต่อการถูกตัดเครือข่าย หมายความว่า database ยังทำงานต่อได้ ถึงแม้ว่าจะไม่สามารถสื่อสารกันระหว่าง node ได้