กระแสระบบฐานข้อมูล NoSQL ทำให้หลายบริษัทพยายามปรับฐานข้อมูลไปมากในช่วงไม่กี่ปีที่ผ่านมา กูเกิลเองในระบบ Google App Engine ก็ใช้ GQL ที่แม้จะคล้าย SQL แต่ก็ไม่สามารถ join ข้ามตารางได้ แต่ในระบบที่เกี่ยวกับการเงินและมีรายการตัดเงินจำนวนมากอย่าง AdWords ก็ทำให้กูเกิลต้องกลับมาพัฒนาระบบ SQL
ระบบ F1 มีเงื่อนไขการออกแบบว่าต้องกระจายโหลดได้แบบเดียวกับ NoSQL ขณะเดียวกันก็ต้องรองรับ ACID เพื่อจะรับประกันได้ว่าการตัดยอดเงินจะแม่นยำ และเนื่องจากผู้ใช้เป็นผู้ใช้ทางฝั่งธุรกิจจึงจำเป็นต้องรองรับ SQL เต็มรูปแบบ
F1 กระจายข้อมูลข้ามศูนย์ข้อมูลได้ โดยตัวกระจายโหลดจะเลือกให้ว่าจะเชื่อมต่อเข้าศูนย์ข้อมูลใด ขณะที่แต่ละศูนย์จะมีเซิร์ฟเวอร์หลายตัว แบ่งงานกันทำ ระบบการเก็บข้อมูลนั้นเก็บผ่านระบบเก็บข้อมูล Spanner ที่รับประกันเรื่องของการสำรองข้อมูล และการกระจายข้อมูล
จุดแปลกอย่างหนึ่งของ F1 คือการเก็บข้อมูลภายในนั้นเป็นเชิงโครสร้าง (hierarchical) แทนที่จะเชื่อมโยงความสัมพันธ์ระหว่างตารางด้วยหมายเลขประจำแถวของตารางต่างๆ กระบวนการ join ในตารางที่อยู่ในโครงสร้างเดียวกันจึงมีประสิทธิภาพที่ดีกว่ามาก
กูเกิลเคยพูดถึง F1 มาตั้งแต่ปีที่แล้ว แต่ในปีนี้เพิ่งตีพิมพ์รายงานการออกแบบเพิ่มเติมเพื่อนำเสนอที่งาน Very Large Database (VLDB) 2013
ที่มา - The Register, F1: A Distributed SQL Database That Scales (PDF)
Get latest news from Blognone
Follow @twitterapi
Blognone Jobs Premium
Cloudnone
- รู้จักอาชีพ Site Reliability Engineer สำคัญยังไง? | Cloudnone EP. 20
- อธิบาย CrowdStrike ทางเทคนิค ทำไมถึงทำพีซีจอฟ้าเป็นล้านๆ เครื่อง | Cloudnone EP.19
- Kubernetes [Part 2] ยี่ห้อไหนดี งานไหนต้องใช้ แล้วเลือกยังไง? | Cloudnone EP.18
- สงคราม AI 2024: OpenAI ชิงปาดหน้า Google วันเดียว | Cloudnone EP.17
- Microsoft, Amazon, Google ประกาศตั้ง Data Center ในไทย แล้วไงต่อ | Cloudnone EP 16
Comments
Big data ยังมึนอยู่เลย VLDB มาอีกแล้ว (ถึงจะเป็น subset ของ Big data ก็เหอะ)
ชอบแนว NoSQL มากแต่ก็จะยังศึกษาไม่ลึกซึ้งมากนัก เพราะวิธีการใช้งงสุดๆครับ ไม่รู้ว่าจะเอามาแทนพวก mysql ได้หรือเปล่าครับ
แทนได้เฉพาะบางงานครับ แต่พวกที่เกี่ยวข้องกับเงินๆทองๆยังไงผมก็ต้องเอาพวก RDB ไว้ก่อน
ตอนนี้สนใจ In-Memory DB มากกว่า เพราะไม่ต้องเปลืองสมองไปกับ Learning Curve ที่ชันโคตรๆ
+1024
งานที่ต้องการพลังประมวล+ความเร็ว ผมก็เอาลง Mem เหมือนกัน
เดี่ยวนี้ Mem ถูก จัดขนาด 32-64 GB User ยอมจ่าย มากกว่าจะต้องมาเรียนรุ้ + เปลี่ยน Engine
อย่างน้อย ๆ ก้ยืด Apps ไปได้ อีกสองสามปี
เพราะอะไรหรือครับ พอดีผมไม่รู้เรื่อง NoSQL เลยไม่เข้าใจครับ
น่าจะเรื่อง transaction รึเปล่า
ถูกต้องครับ พวก Transaction มันจำเป็นมาก แต่ NoSQL บางเจ้าก็น่าจะมีแล้วมั๊ง แต่ก็ไม่อยากทำอยู่ดี เพราะเวลาแก้ไขจะแหกตาอ่านยังยากเลย แบบนี้ขอพบกันครึ่งทาง --> In-Memory ดีสุดๆสำหรับผม(และคนที่จะมาทำต่อด้วย)
transaction นี่หมายถึง transaction ที่มี rollback, commit ใช่มั้ยครับ
แล้ว In-memory ตัวไหนที่น่าสนใจครับ
ขออภัย ถามเยอะหน่อยครับ สนใจแต่ขอย่นระยะเวลาจากประสบการณ์คนอื่นละกัน
ที่ผมสนใจอยู่ตอนนี้คือ SQL Server 2014 ครับ (ยังเป็น CTP1 อยู่) แต่ถ้าเป็น MySQL ที่ดังๆก็ MemSQL ตัวนี้แพงมาก
*อยากลองครับแต่ช่วงนี้ไม่มีเวลา งานล้นมือครับ
สอบถามต่ออีกหน่อย งานที่ใช้เป็นจำพวกไหนครับ
อย่างของผมนี่สนใจเอาไปทำระบบสินค้าคงคลังครับ
สำหรับผมเป็นงานธุรกรรมแบบเน้น Realtime ครับ โดยมากจะเป็น Data ที่สัมพันธ์กับ Record อื่นๆใน Table ตัวเอง (NoSQL รับงานนี้ได้ แต่ไม่เหมาะกับงานธุรกรรม)
แต่ทั้งนี้ทั้งนั้น บาง Table โดนเรียกใช้งานหนัก - หนักชิหาย วิธีดั้งเดิมที่ผมโคตรเสี่ยงคือย้าย data ที่มีความเสี่ยงต่ำๆแต่เรียกใช้บ่อยๆ ไปไว้บนแรมครับ
เยอะไปเดี๋ยวโดนนายด่าครัฟ = =
ขอบคุณครับ
ขอบคุณมากครับ
เชิงโครสร้าง ?
ตามไม่ทันจริงๆ พวกข้อมูลใหญ่ๆนี่
..: เรื่อยไป