By: mk 
on 25 February 2010 - 07:58
Tags:
Ryan King วิศวกรของ Twitter ให้สัมภาษณ์กับบล็อก MyNoSQL ว่า Twitter มีแผนจะเปลี่ยนจากฐานข้อมูล MySQL ไปใช้ Apache Casandra ในเร็วๆ นี้ ด้วยเหตุผลเรื่องการขยายตัวของข้อมูล
ตอนนี้ Twitter ใช้คลัสเตอร์ MySQL ที่ใช้ memcache เข้าช่วย แต่พบว่าต้องใช้คนดูแลรักษามาก แถมอัตราการส่งข้อมูลยังเพิ่มมากขึ้นเรื่อยๆ ล่าสุดขึ้นมาที่ 50 ล้านครั้งต่อวันแล้ว (ข่าวเก่า Twitter มีผู้ส่งข้อความกว่า 600 ครั้งต่อวินาที) เราอาจบอกได้ว่า Twitter โตขึ้นมาถึงระดับที่ relational database เริ่มรับไม่ไหว
ทางออกของ Twitter จึงคล้ายกับรุ่นพี่อย่างกูเกิล (MapReduce/BigTable) ยาฮู (Hadoop) หรือ Facebook ซึ่งเป็นคนทำ Cassandra ฐานข้อมูลแบบกระจายศูนย์ ภายหลังโอเพนซอร์สและยกให้อยู่ในการดูแลของโครงการ Apache แนวทางนี้มีชื่อเรียกอย่างไม่เป็นทางการว่า "NoSQL" ซึ่งหมายถึงวิธีการเก็บข้อมูลแบบอื่นๆ ที่ไม่ใช่ relational database นั่นเอง
นอกจาก Twitter กับ Facebook แล้ว ลูกค้าของ Cassandra ยังมี Digg, Cisco, Rackspace
ที่มา - ComputerWorld
Get latest news from Blognone
Follow @twitterapi
Comments
เห็นเว็บ narisa.com เค้ามี meeting เรื่องนี้กันวันเสาร์ที่ 27 กพ.นี้นิครับ ว่าจะไปแต่ต้องกลับบ้าน
ผมว่านี่แหละศาสตร์ใหม่ที่ คนเรียนวิทย์ควรศึกษาไว้ จะได้ไม่ต้องอยู่ในกรอบของวิชา DBMS อันน่าเบื่อ แล้วถ้าใครรู้เรื่องพวกนี้อนาคตรวยแน่ อีกอย่าง มันจะได้ดูเป็นวิทย์คอมหน่อย
ปล. ตอนนี้เพิ่งเทส cassandra ไป ค่อนข้างแจ่มแต่ก็ใช้เวลาทำความเข้าใจพอสมควร แล้วมันก็ไม่ึครอบคลุมความต้องการทั้งหมด
ปล.2 อย่าใช้คำว่าเลิกใช้ MySQL ดีกว่าครับ ยังไงมันก็เลิกไม่ได้หรอก Relational DB มันยังจำเป็น เพียงแต่ระบบ Friend แล้วก็ระบบ Inbox เท่านั้นแหละที่จะถูกเปลี่ยนไปใช้ Cassandra เพราะถ้าลองมาจับดูจะรู้เลยว่าการ Query ข้อมูลตาม Criteria (WHERE xx=yy and aa=bb) ทำได้ยากมาก Cassandra เหมาะกับระบบ friend และ พวก tweet มากกว่าครับ ใช้ทั้งระบบไม่เวิร์กเท่าไหร่
เสียดายจังเลยผมย้ายหอพอดี ><
เห็นด้วยครับ เคยจะเอามาใช้เหมือนกัน แต่ผมว่ามันเหมาะกับงานบางอย่างเท่านั้นเอง ไม่เหมาะกับงานที่ต้องทำ relate ข้อมูลกันเท่าไหร่นัก
ประกอบกับมันใช้เวลาในการเรียนรู้ค่อนข้างมาก (เพราะเป็นของใหม่ แนวคิดที่ไม่คุ้นเคย) ก็เลยตัดสินใจไปใช้แนวทางอื่นแทนครับ (ข้อมูลไม่มากเท่าไหร่)
ถามนิดนึงครับ ตอนเอามาใช้นี่ ใช้กับภาษาไหน ครับ Build ตัว Thrift ด้วยอะไร ทำยากไหม กว่าผมจะทำ client .net ได้ นานมากเลย
พอมีรายละเอียดเกี่ยวกับ meeting ไหมครับ ยังสมัครเข้าไปฟังได้อยู่หรือเปล่า
นี่ครับ http://www.narisa.com/forums/index.php?showtopic=30503
กำลังเรียน DBMS อยู่พอดีเลย
ฮาาา
ผมมองว่ามันเป็นทางเลือกในการประยุกต์ใช้งานมากกว่า อาจจะไม่ใช้ทั้งระบบน่าจะใช้ในส่วนที่จำเป็นเท่านั้น
อยากรู้ว่า
*SQL มันรับการ query หนักๆ ไม่ไหวเหรอครับ ถึงต้องได้เปลี่ยนไปใช้แบบอื่น
ผมไม่เคยทำฐานข้อมูลใหญ่ๆ ที่ query พร้อมๆ กันหลายๆ คนน่ะครับ
มันเป็นการยอมแลก feature บางอย่างของ database เพื่อให้ได้ประสิทธิภาพในงานเฉพาะอย่างที่ดีขึ้นครับ
จริงๆ แล้วอย่าง MySQL ก็สามารถรับโหลดได้จำนวนมากนะ แต่ต้องทำอะไรกับมันหลายอย่างเหมือนกัน ปัจจุบันเว็บอย่าง Flickr ก็ยังใช้ MySQL อยู่ และยังไม่มีแผนจะเปลี่ยนไปใช้พวก NoSQL พวกนี้
pittaya.com
เห็นด้วย อย่าดูถูก MySQL ไป QQ ที่จีน user เป็นร้อยล้าน ใช้ MySQL รุ่นโมแล้ว ยังเอาอยู่เลยครับ
+1 อย่าดูถูก ตอบได้โดนใจมากครับ
+1
ขึ้นกับการออกแบบมากกว่าครับ
ใช้ MySQL แล้วไม่ทำ relation เลยมันก็ทำได้อยู่นะ
lewcpe.com, @wasonliw
คุณ lew เข้าใจคำว่า relation ในเชิง Database ผิดแล้วครับ
คำว่า relation ในเชิง Database หมายถึง table ครับ
เพราะฉะนั้นใช้ MySQL แล้วไม่มี relation เป็นไปไม่ได้ครับ
ถ้าคุณจะหมายถึงความสัมพันธ์ระหว่าง table นั้น เรียกว่า integrity ครับ
นี้เป็นศัพท์เทคนิคของ database ครับถึงเปิด dictionary ไปก็ไม่ได้ความหมายที่ถูกต้องในเชิง database ครับ
-*-
ผมเข้าใจคุณ lew นะครับ คำว่าไม่มี relation ในความหมายนั้นคือ ไม่ต้อง join อะไรทั้งสิ้น ไอ้เรื่อง normalization 1-5 อะไรพวกนั้นโยนทิ้งไป เก็บข้อมูลเต็มๆ พวก lookup table อย่าง province city sex occupation ก็ไปเก็บเป็น static ที่แอ๊พแทน
เวลาจะใช้งานก็ใช้ Select from table เดียวเท่านั้น ห้าม join หรือ where cross ส่วนการเก็บข้อมูลจากเดิม สมมติ Customer ปกติเราเก็บรวมที่ตารางเดียว แต่เกิดมี customer มากกว่า 5 ล้าน records เราก็แบ่งซอย table เป็นหลายๆอันเช่น Customer_1 Customer_2 ถามว่าถ้าคุณซอย table แบบนี้ SQL มันจะจอยทำงานยังไง แล้วมี Algorithm ให้ จัดสรรข้อมูลแต่ละ record ลงตารางไหน
นี่คือสิ่งที่มหาลัยไม่เคยสอนครับ อาจารย์ทำพวกนี้เป็นไม่กี่คนหรอก
ถ้ามัวแต่ไปอิงวิชาการ เสียดายสมองครับเอาเวลาสมองไปคิดตาม "common sense" ในการออกแบบดีกว่า จะได้ไม่ต้องมัวพะวงแต่กฏของ RDBMS
ผมต้องการจะบอกว่าคำว่า relational database = table database relation = table relation != ความสัมพันธ์ระหว่าง attribute/field ของ relation/table ความสัมพันธ์ระหว่าง attribute/field ของ relation/table = integrity
MySQL เป็น RDBMS ฉะนั้นการที่ RDBMS ไม่มี relation/table มันเป็นไปไม่ได้ครับ
ครับๆ งั้นสมัยก่อนพวก Dbase ที่มันเก็บเป็นตารางมันก็เป็น RDBMS หมดเลยเหรอครับ ก็เห็นมันเก็บเป็น ตารางมาแต่ไหนแต่ไร
"relational database = table database" ก่อนมี RDBMS มันก็มี filesystem มันก็เก็บในรูปแบบกึ่งตารางมาแต่ไหนแต่ไรแล้วนิครับ งั้นอะไรที่มันเก็บเป็น Table มัน = Relation หมดเลยเหรอเนี่ย เพิ่งจะรู้นะครับเนี่ย
อ่านมาจากตำราไหนหว่า หรือสอนอยู่ที่ไหนหว่า
ฉะนั้นการที่ RDBMS ไม่มี relation/table ผมยืนยันว่าเป็นไปได้ มันเป็นแค่เครื่องมือผมอยากใช้มันทำอะไรก็ได้ ทั้ง DB มี Table เดียว มี 2 Column ผมก็ทำได้ครับ
!
วิชาการเชียว ลองๆคุยแบบ DBMA หรือ SA คุยกันบ้างดีกว่าครับ
ผมไม่เก่ง db นะครับ
แต่ผมไม่เคยได้ยินนะว่า relation == table
lewcpe.com, @wasonliw
http://en.wikipedia.org/wiki/Relational_database#Terminology
ลองดูครับ ถ้าความสัมพันธ์ระหว่าง field หรืออีกชื่อหนึ่ง attribute
จะเรียกว่า integrity หรือเรียกว่า Relationship ครับ
ถ้าคนไม่ได้เรียกด้าน database มาส่วนมากจะเข้าใจว่าคำว่า Relation ใน database
คือ ถ้าความสัมพันธ์ระหว่าง field ครับ
ที่มันสามารถเรียกได้หลายอย่างเพราะว่าการ design มันมีหลายระดับครับและแต่ละระดับยังจะมีแยกอีก
โอเคเข้าใจละครับ ถ้าข้อมูลไม่อยู่ในกลุ่มเดียวกันมันอยู่ตารางเดียวกันไม่ได้ มันเลยสัมพันธ์กันทั้งหมด
แต่พวก NOSQL มันไม่ต้องสัมพันธ์กันเลย แต่ละ row อาจจะมี จำนวน column ไม่เท่ากันก็ได้
แต่พวก RDBMS มันต้องมี column ที่แน่นอน จำนวนเท่ากันหมด
ปล. ดีใจที่ไม่ตั้งใจเรียวิชานี้จะได้ลืมง่ายๆ แหะๆ
....
overhead มันสูงน่ะครับ คือ SQL มันออกแบบมาสำหรับงานทั่วๆ ไป ทีนี้พอใช้ทำงานเฉพาะบางอย่าง มันก็เกินความต้องการไปหน่อย
ตัว SQL PARSER ไมไช่ตัวปัญหาครับยังไงมันก็ทำงาน ตัวที่เป็นปัญหาคือ HARDDISK เขียน / อ่าน ข้อมูลไม่ทัน เกิดคิวรอยาวเป็นหางว่าว นั่นคือปัญหาของ DATABASE ขนาดใหญ่ที่แท้จริง
NOSQL หลักๆแตะ Disk น้อยมากเลยพี่โหน่ง ทำงานแทบจะใน memory ทั้งหมด แล้ว Write ของ Cassandra เร็วกว่า Disk เยอะมาก แถมมันขยายออกแนวกว้างได้เยอะกว่า (horizontal) แค่เพิ่มเครื่อง ลงโปรแกรม แล้วรันได้เลย มันง่ายกว่า RDBMS เยอะแถมฟรีอีก
ที link ให้ศึกษาไหมครับ ว่างๆมาสอนพี่ด้วยก็ดีนะครับ ;)
ต้องมีงานอะพี่มันถึงจะเข้าใจ อยู่ดีๆให้ผมมานั่งอ่านผมก็งงเหมือนกัน พอดีมันมีเคสต้องใช้อะครับ
อืม เข้าใจครับ ว่าแต่ เวย์ไปทำอีท่าไหนถึงได้จับมาแนวนี้
ออกแบบ database ดีๆจะไม่เกิด overhead เลยครับ
แต่ถึงอย่างไรผมว่ามันก็ไม่ใช้ประเด็นหลักที่ทำให้ SQL มันช้าครับ
overhead แค่ทำให้ database มีขนาดใหญ่โดยไม่จำเป็นครับ
ผมว่าที่มันช้าเพราะมันใช้การ access แบบ sequential มากกว่าครับ
ถึงจะเป็น index ก็ตามการ access ของ index บางส่วนยังเป็น sequence อยู่ครับ
แต่ก็แก้โดยการออกแบบ database ได้อยู่ดี
เคยไปฟังผู้ว่าการกระทรวงนึงบอกตอน db ช้ามาก "แค่เพิ่ม hardware กับใช้ oracle ก็พอแล้ว"
แฟนพันธุ์แท้สตีฟจ็อบส์ | MacThai.com
อืมมม
เงินแก้ปัญหาได้ทุกอย่าง
และก็สร้างปัญหาได้ทุกเรื่องเช่นกัน ;P
my blog
ผมว่า คนพูดได้ % oracle เยอะพอตัว
5555
ไม่เสมอไปหรอกครับ มีเงิน ซื้อ Server แพง ๆ ซื้อโปรแกรมแพง ๆ แต่ไม่เคยได้ใช้ความสามารถให้เต็มที่ มันก็เท่านั้นแหละครับ
ทุกองค์ความรู้ดีหมดครับ องค์ความรู้เก่าก็เป็นรากฐานองค์ความรู้ใหม่
จริงๆเรื่อง NOSQL มันเก่ากว่า RDMBS นะครับ
ถ้ามีน้องๆคนไหนสงสัยว่า วิชา Data Structure เรียนไปทำไมมากมาย มาเจอพวกนี้แล้วจะเข้าใจ
B-Three, Hashmap, Heap, Dictionary, ฯลฯ
สมัย IBM เข็น SQL ใหม่ๆ ลูกค้าก็บ่นช้าเป็นห่างว่าวครับ
แล้วเครื่องก็เร็วขึ้นๆๆๆ มันก็พอไปวัดไปวาได้พักนึง (เป็นสิบปีเหมือนกันนะ) แต่ทุกวันนี้เจอ massive query เข้าไป RDBMS ก็ไปต่อยากเอาเหมือนกัน
lewcpe.com, @wasonliw
ผมว่าเรื่องนี้สนุกดีครับพอได้จับจริง เหมือนได้เป็น pioneer ให้ไปทำ RDBMS เหมือนเดิมผมว่าสู้รุ่นน้องๆไม่ได้ละ หนีมาด้านนี้ดีกว่า
ผมเคยอ่านเปเปอร์ของ BigTable นี่มันส์มากเลยครับ คือเค้ารู้ว่าจะออกแบบมาเพื่อทำอะไร (ข้อมูลมหาศาลบนคลัสเตอร์ของกูเกิลที่มี 3 ก็อปปี้) แล้วก็อัดให้ throughput มันสูงๆ อย่างเดียวเลย
มันจริงครับ แค่จะ build client ให้ผ่านก็ปาไปสองวันสองคืนแล้วครับ แต่พอใช้จริงๆไม่ยากไปยากตรง Design มากกว่า ว่าโครงสร้างแบบนี้มันเหมาะกับอะไรผมว่า คุณ mk เล่น cassandra น่าจะมันกว่า BigTable นะเพราะมันรวมเอาทั้ง Dinamo กับ BigTable ไว้ด้วยกัน
ใช่ ครับ สูงสุดคืนสู่สามัญ
เหมือนกับเมื่อถึงจุดสุดแล้วก็ล่วงมาเริ่มที่จุดเดิมเนอะ
ช่วงสองสามเดือนที่ผ่านมา ผมศึกษาเรื่องนี้พอดีเลย เพราะเริ่มเห็นปัญหา และช่องทางเหมือนกัน
โครงสร้างพื้นฐานของฐานข้อมูลตอนนี้ (เท่าที่ผมศึกษาคือ MySQL, PostgreSQL แล้วก็ SQLite) มันไม่ได้รองรับจำนวน record มากขนาดนั้นครับ พอ query ทีมันเลยกินเวลาค่อนข้างมาก ปัญหามันอยู่ในระดับ infrastructure การแก้ปัญหาจึงไม่ใช่เรื่องง่าย (เหมือนเขียนฐานข้อมูลใหม่) และยังมีปัญหาอื่น ๆ ที่น่าสนใจอีกมากมาย ผมคิดเหมือนกันครับว่า อาจมาถึงยุคที่เราต้องการ innovation ใหม่ ๆ เกี่ยวกับฐานข้อมูลอีกครั้ง
มันรองรับ RECORD ได้ไม่จำกัดครับ แต่ Query นี่สิ กินเวลามากขึ้นเรื่อยๆ
ไม่เข้าใจเลยเรื่องนี้ ฮ่าๆ นั่งไล่อ่านดู ก็ได้ความรู้เยอะเลย
ว่าไปเอาพวกนี้ไปให้พันทิปใช้จะพอแก้ปัญหาได้บ้างหรือเปล่าหว่า ?
ผมว่าโหลดระดับ pantip ยังไม่ massive ขนาดนั้นนะ ใช้วิธีการเดิมๆ อย่าง sql cluster + memcache น่าจะช่วยได้มากแล้ว
lewcpe.com, @wasonliw
ปัจจุบัน Pantip ใช้ MongoDB แล้ววววว
อัพเดตกระทู้เก่า ฮา
แล้วอันนี้เขาเทียบกันได้ไงอะครับ
MySQL > 50 GB Data
Writes Average : ~300 MS
Reads Average : ~350 MS
Cassandra > 50 GB Data
Writes Average : 0.12 MS
Reads Average : 15 MS
Reference
http://www.slideshare.net/Eweaver/cassandra-presentation-at-nosql