feature-image-cassandra-101
feature-image-cassandra-101

ก่อนจะเริ่มไปพูดถึง NoSQL เราคงต้องย้อนกลับมาก่อนว่า อะไรคือ RDBMS และทําไมถึงเกิด NoSQL ขึ้นมาที่เป็นเทรนใหม่ของ Database

ประวัติอดีตกาล

ข้อมูลของ computer มันแบ่งเป็นสองอย่างคือ Structured Data และ Unstructured Data เท่านั้น

ซึ่งคําว่า Structured Data ก็เป็นข้อมูลจําพวก ข้อมูลทุกอย่างที่มันกรอกลง record file อะ ลองนึกง่ายๆน่ะ excel file อะ อะไรก็ตามที่กรอกเป็นช่องๆๆแบบนั้นลง เรียกว่า Structured Data หรือจริงๆมันก็คือพวก Realation Databases นั้นเองแหละ

ส่วนเจ้า Unstructure Data เป็นอย่างอื่นทั้งหมดที่ไม่ใช่ Structured ฟังดูกวนประสาท แต่ไม่ใช่น่ะ มันหมายความอย่างงั้นจริงๆ เช่น graphic,images,video,streaming instrument data, webpages, PDF บลาๆๆๆ เยอะแยะทุกอย่าง ที่ไม่อยู่ในตารางนั้นแหละ

unstructured-vs-structured-data
unstructured-vs-structured-data (http://www.datasciencecentral.com/profiles/blogs/structured-vs-unstructured-data-the-rise-of-data-anarchy)

จากตารางจะเห็นว่า IDC ประเมิณการให้ดูเลยว่าอีก ไม่กี่ปี 202 ข้อมูลจะเติบโตแบบ 40-50% แบบซึ่งเยอะมากๆๆๆ สาเหตุนึงมันมาจาก Internet เนี่ยแหละ

ในช่วงหลายสิบปีก่อน มันไม่มี Internet แรงๆๆๆยังงี้ไง เรานั่งต่อ modem กันอยู่อะ 56kb ตู๊ดๆๆๆกันอยู่นั้นอะ ไอ้เว็ปพวก Youtube มันจะไปดังได้ไง ถ้าโหลดทีนึงกระตุกทีนึง 🙂 ที่นี้พอ Internet เริ่มเติบโต และ เร็วมากขึ้นข้อมูลมันก็มากขึ้น พวก digital file แบบ Unstructured มันก็ขยายตัวตามมม ยิ่งพอมี IoT ที่ทุกอย่างสามารถรับ-ส่งข้อมูลกันได้อีก ทีนี้ข้อมูลกระจัดกระจายมาก พวก Unstrctured ยิ่งทะลุมิติ ตามกราฟเลยล่ะ

บู๊มมมมม กําเนิด NoSQL

เมื่อ Beahivor เปลี่ยน ก็ทําให้ข้อมูลเปลี่ยน ข้อมูลทุกวันนี้ไม่ใช่สร้าง Table ขึ้นมานั่งกรอกๆๆๆลง field อีกแล้ว เราต้องการออะไรที่มัน flexible data models มากกว่าเป็นตารางๆๆล่ะ ที่นี้ก็เลยสร้าง NoSQL ขึ้นมา หรือ อีกชื่อคือ “Not only SQL” นั้นเอง ที่มีความพิเศษคือเรื่อง ยืดหยุ่นในการเก็บ Data Models ไว้เก็บพวก Unstructured มันได้ทุกอย่างเลย พวก log data, messaging, timeseries, video, images, etc.

แล้ว NoSQL มีอะไรบ้าง?

ประเภทของ NoSQL มีแบ่งออกมาชัดเจน 4 อย่างคือ ซึ่งแต่ละตัวก็มีความแตกต่างกันแตกออกไปตามการใช้งาน

  1. Key-Value stores
    • Couchbase
    • นึกถึงพวก Json File ไว้น่ะ ที่ 1 key – 1value แบบนั้น ลักษณะมันแบบนั้นแล้วเรียบง่ายมากๆ
  2. Document stores
    • MongoDB
    • มีความคล้ายคลึงกับ Key-Value แหละ คือการเก็บเป็น Key แบบ Json นั้น แต่แตกต่างกันที่มันสามารถเก็บ Document Object ทั้งก้อนลงไปเลยโดย specifics กับ Key นั้นๆเลยอะ (คิดภาพมี Key: GirlFriend แล้วรวมทุกอย่างไว้ใน Key นี้ เช่นสีที่ชอบ อาหารที่ชอบ อายุ นํ้าหนักเป็นต้น)
  3. Column stores
    • Cassandra
    • มีลักษณะการเก็บข้อมูลคล้ายกับ RDBMS นั้นแหละ คือเป็น column แต่ที่แตกต่างก็คือ NoSQL แบบ Column Stores มันไม่ได้เก็บทุกอย่างไว้ใน Tabel เดียว คืออีกความหมายว่า มันต้องนั่งไล่อ่านทุกๆ column ที่เราต้องการเพื่อหาค่าๆเดียว (สมมุติ row นึงมี 1,000 column ต้องการจะหาที่ 999 column ลองคิดดูว่าต้องใช้ Performance เท่าไร) แต่ในทางกลับกันมันแยก column ออกเป็นส่วนๆ แล้วทํา index นั้นเอง เป็นสิ่งที่เราเรียกว่า Column Family (ตัวอย่างของ Cassandra)
    • cassandra_column_family
      cassandra_column_family (https://www.tutorialspoint.com/cassandra/cassandra_data_model.htm)
  4. Graph stores
    • Neo4J, InfiniteGraph
    • เป็นโครงสร้างซับซ้อนสุดๆ ที่ใช่เรื่องของ Node กับ Edge และ Direction มันจะแสดงถึง Relation ของแต่ละส่วน โดยไม่ได้ใช้ Index น่ะ

ลองอ่านอีกเวอร์ชั่นของพี่ปุ๋ยได้ที่นี้ น่าจะพอเห็นภาพมากขึ้นล่ะ

มาดูพระเอกของวันนี้ Cassandra

เกริ่นนําเรื่องของ NoSQL ไว้แล้วมาดูกันว่า cassandra เจ้าหมอนี้มีดีอะไร? ทําไมถึงเราควรใช้?

Apache Cassandra ในบรรดาเจ้า NoSQL ทั้งหลาย เจ้าตัวนี้โผล่มาด้วยจุดเด่นที่ชัดเจนคือเรื่องของ highly scalable, distributed !!! ด้วยความที่ว่าเค้าโฆษณาว่าเป็น No Single Point Of Failure !!!

เพราะอะไรกันล่ะ? เค้าถึงกล้า โฆษณาแบบนั้น?

cassandra-architecture
cassandra-architecture (https://www.tutorialspoint.com/cassandra/cassandra_architecture.htm)

ที่เค้ากล้าโม้ขนาดนั้นเป็นเพราะว่า การออกแบบ distributed architecture ของ Cassndra ถูกออกแบบมาให้เกิดการ Data Replication ภายใต้ Node กันอยู่เสมอ (ผ่าน Gossip Protocol) โดยใช้เรื่องของ replication factor เป็นตัวชี้วัดว่าจะทําการ replicate มั้ย

ในทางกลับกันเจ้า Architect ของ NoSQL สุดดังอย่าง MongoDB ไม่ได้ออกแบบมาอย่างนั้น MongoDB ถูกออกแบบมาในรูปแบบ Master-Slave Replication นั้นแปลว่าถ้าเกิด ตัว Master ของ MongoDB ล้มหายตายจากไป มันจะเกิด Dead Air ราวๆ 10-40 sec. ในการที่จะหาตัว Slave ขึ้นมาเป็น Master แทนนั้นเอง

แล้วลองคิดดูน่ะครับ ถ้าเว็ปเรามี Transaction ราวๆ 10,000 txn/sec ซึ่งจะก่อให้เกิดรายได้ล่ะอย่างตํ่า 100 baht ถ้าเกิดเว็ปเกิดไม่สามารถ read-write ได้เป็นเวลา 30 วินาที จะก่อให้เกิดเงินหายไปอย่างน้อย 30* (100*10,000) = 30,000,000 baht นั้นเอง ….. เข้าใจยังว่าทําไมเวลาเกิดเหตุเว็ปล่มเลยเสียหายเยอะมาก นั้นเป็นเหตุผลที่ Retail ส่วนใหญ่เลือกใช้ Cassandra เป็น Database นั้นเอง (เพราะ txn ต่อวิเยอะมาก กันความเสียหาย)

ที่นี้ย้อนกลับไปดูรูปข้างบน การออกแบบของ Cassandra จะเห็นว่า Node แต่ละ Node ต่อกัน และ Replicate โดยใช้ Replicate factor เสมอ เพราะฉะนั้นถ้าตัวไหนตายไป ตัวอื่นก็ทํางานได้ปกติ เสมือนว่าไม่เกิดเหตุอะไรขึ้น หรืออีกนัยนึงเมื่อเทียบกับ MongoDB ก็คือ ทุกตัวเป็น Master หมดนั้นเอง

พื้นฐานของ Cassandra

จริงๆก็อยากจะเขียนรายละเอียดลึกกว่านี้ เช่นพวก Syntax, Create Table ต่างๆ แต่คิดๆแล้วไม่จําเป็นเพราะหาอ่านง่ายมาก เราควรจะเข้าใจ concept มันมากกว่า เพราะฉะนั้นเรามาเรียนเรื่อง Write – Read Operation ของ Cassandra กัน พื้นฐานในการ query ดีกว่า

Write Operation

cassandra-write-operation
cassandra-write-operation (http://www.guru99.com/cassandra-architecture.html)

ขั้นตอนการ write file ของ Cassandra ที่มันเร็วน่ะ ไม่ใช่อะไรหรอก แค่มันไม่ได้ลง Table ก่อนนนน!!! มันไป write ลง memtable ทําหน้าที่เหมือน write memory นั้นแหละ ถ้าไฟดับก็ข้อมูลหาย แล้วพอมันเต็มมันถึง flushed data ไปลง SSTable ที่เก็บข้อมูลนั้นเอง

แต่ทุกการ write ของมันเนี่ยมันจะเกิดสิ่งที่เรียกว่า Commit log เพราะฉะนั้นเราสามารถมาตรวจสอบ log ในการ write ได้ที่นี้ ทุกการ write เลยน่ะ 🙂 เป็น transaction record หรือจะสรุปง่ายๆคือ

  1. Logging data in the commit log
  2. Writing data to the memtable
  3. Flushing data from the memtable
  4. Storing data on disk in SSTables

จบเลย หลักการ write ของ cassandra (อ่านฉบับเต็มได้ที่นี้น่ะ)

Read Operation

cassandra_read_path
cassandra_read_path (https://www.toadworld.com/platforms/nosql/w/wiki/11727.a-deep-dive-into-cassandra-s-readwrite-path)

แต่การอ่าน Data ของ cassandra มีความแตกต่างกันนิดหน่อยคือ มันจะมีส่วนที่มาเกี่ยวข้องคือ

  • Row Cache (คือ mem cache นั้นแหละ)
  • Bloom Filters (ตัว filter switch เราไป parittion ต่างๆ ที่อยู่ใน SSTable)
  • Partition Key Cache
  • Partition Index
  • Partition Summaries
  • Compression offset

คือให้อธิบายง่ายๆสั้นๆก็คือ ถ้ามันไม่เจอใน cache เราก็จะไปหาใน SS Table โดยการหาเนี่ย Bloom Filters จะเป็นคนส่งเราไป Partition ต่างๆนั้นเอง โดยการอ่าน Block ไหนๆมันจะใช้ Compression offset ในการอ่าน compressed block ต่างๆๆในนั้น 🙂 จบ ง่ายๆแค่นั้นแนหละ (อ่านตัวเต็มได้ที่ Toadworld และ Datastax)

การ Query ข้อมูล

อย่างที่เราเรู้กัน MongoDB เป็นการเก็บแบบ Document Based ที่มีรูปร่างคล้ายกับ JSON เพราะฉะนั้นเวลาเราจะดึงข้อมูลจาก MongoDB มันจะไม่แตกต่างอะไรกับการใช้ JSON fragments เลย แต่ในทางกลับกัน

Cassandra เก็บข้อมูลแบบ column ทําให้มีความค้ลายคลึงกับ RDBMS นั้นเอง และมันมีภาษาของมันเองที่เรียกว่า Cassandra ที่มี CQL นั้นเอง~ เหมือน SQL มาก เรียนรู้น้อยมากๆๆ 🙂 Learning curve จะตํ่ากว่า อ่านได้ที่นี้เลย guru99

เราคิดได้เลยว่ามันเหมือน SQL เกือบทุกอย่าง แต่จะมีข้อที่มันไม่มีคือ

  1. ไม่ Support aggregation queries: max,min,avg
  2. JOINS
  3. GROUP BY
  4. OR
  5. Wildcard
  6. Union,Intersection
  7. Greater than and Less than
  8. Table columns cannot be filtered without creating the index

เอาง่ายๆคือ feature เสริมอื่นๆๆนั้นแหละ 🙂

สรุปปปปปป

ฟังดูแล้วเหมือนเจ้า cassandra จะดีกว่า NoSQL เจ้าอื่นๆมากมายน่ะ แต่ไม่ใช่น่ะ อย่าเข้าใจผิด เจ้า Cassandra เก็บข้อมูลเป็น Column เพราะฉะนั้น Data Model ของมันไม่สวยงามเท่า Document แบบ MongoDb เลย จริงๆเวลาเราเลือก Database เนี่ยมันขึ้นอยู่กับรูปแบบธุรกิจของเรามากกว่าคิดว่าอันไหนดีสุดน่ะ ถ้าเราจะเลือกโดยยึดว่าจะเอา Scalability และ High Availability นี้ เจ้า cassandra เป้นตัวเลือกที่ดีเลยล่ะ

0 0 vote
Article Rating
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments