🎞️ Videos → OLTP vs OLAP: Why Choose? Modern Database Evolution Through Web3 Lens

แนะนำตัวและ Cleverse: Venture Builder ด้าน Blockchain/Web30:00

สวัสดีทุกคนนะครับ เอ่อ ผม ชื่อฟา เนาะ ก็ทำงานอยู่ที่ Cleverse ครับ ตอนนี้ก็ดูแลทีม เอ่อ Development เนาะ แล้วก็ หลักๆ เลยคือ Cleverse คืออะไร Cleverse คือ Venture Builder ครับ และ เราทำเกี่ยวกับ Blockchain Web3 หรือ Crypto อะไรเงี้ยครับ ซึ่งก็

ความท้าทายของ Data ในโลก Blockchain/Web30:16

มี challenge ด้าน data หลายอย่างที่แบบ เออ อาจจะเอามาแชร์ได้ ก็ต้องเกริ่นก่อนว่า เออ ผมเป็นจริงๆ เป็น software engineer เนาะ พื้นฐานหลักๆ เป็น software engineer เลยครับ แล้วก็ งานที่ Cleverse เนี่ยไม่ได้มีงาน data engineer แบบ

จ๋าๆ อย่างงั้น แต่ว่าถ้ามองจริงๆ อ่ะ Blockchain ก็เป็น data warehouse อันหนึ่งที่ใหญ่มากๆ เหมือนกันที่เราสามารถ index ข้อมูลแล้วก็ใช้งานข้อมูลของมันได้ครับ

OLTP vs OLAP: ความแตกต่างและข้อจำกัด0:39

เกริ่นก่อนว่า OLTP คืออะไรสำหรับ just in case เค้าจริงๆ แต่ว่าทุกคนก็น่าจะรู้อยู่แล้ว หลักๆ คือมันต่างกันแค่นิดเดียวก็คือ transaction กับ analytic เนาะ ก็คือเป็น database สองชนิด ที่ถูกออกแบบมาเพื่อให้ตอบโจทย์ ด้วย requirement ที่แตกต่างกัน อันนึงเป็นเชิงของ transaction ก็คือ day-to-day operation เนาะ เอ่อ ซื้อของ จ่ายเงิน ชำระเงิน ซึ่ง transaction มันสูงมาก อ่า กับอีกอันนึงก็คือเป็นเชิง analytic ก็อะไรอย่างเงี้ยครับ ไว้ตอบคำถามใน business ต่างๆ โดยที่ characteristic ต่างๆ ของมันจะต่างกัน เยอะมาก แต่ยกตัวอย่างอันสำคัญสำคัญก็คือ storage เลยนะ OLTP ก็จะเป็น เป็น row database อย่างเช่น MySQL, Postgres อะไรเงี้ยใช่มั้ยครับ แต่ว่า OLAP เนี่ย ด้วยความที่เราเวลาเราอ่านเนี่ย เรา read data เป็นจำนวนหลาย gig หลาย terabyte แบบ เออ คือเยอะมาก มันก็เลยต้องเก็บเป็นรูปแบบของ column database ครับ ซึ่ง เอ่อ อีกอย่างนึงก็คือเรื่องของ data freshness เนาะ คือสมมุติว่า OLTP เนี่ย เราคาดหวังว่าเราอัพเดตข้อมูลลง database ปุ๊บ อ่านซ้ำอีกรอบนึงเนี่ย ต้องเห็นชัดเจนเลย มันก็จะมีเรื่องของ ACID isolation อะไรต่างๆ เยอะแยะ ซึ่ง ในส่วนของ software จริงๆ เนี่ยก็จะใช้ฝั่งซ้ายเยอะมาก แล้วก็ metric เนี่ยก็จะต่างกันคืออันนึงคือเราเน้นจำนวน transaction per sec กับอีกอันนึงเราเน้นว่า เอ่อ response time ของ query เนี่ยมันช้า หรือเร็วแค่ไหน ถ้ายิ่งยิ่ง query จำนวนใหญ่ เอ่อ ยิ่ง query ยากมากๆ ใหญ่มากๆ เนี่ยก็ควรจะยิ่งได้เร็วอะไรเงี้ยครับ

ซึ่ง general usage ต่างๆ ก็จะเป็นประมาณนี้เนาะ ก็คือ user เอ่อ ใช้งาน web app ใช่มั้ย ที่ต้องการ real-time transaction ก็จะใช้ database ที่เป็น OLTP ครับ แต่ว่าถ้าเป็น business people ที่ต้องการจะ ทำ data analysis ก็จะใช้ OLAP

ความต้องการ Real-time Analysis ใน Web3 และปัญหาที่ต้องแก้2:18

ทีนี้ คำถามสำคัญเลยก็คือ แล้วถ้า user อยากใช้ analysis แบบ real-time ล่ะ ต้องทำยังไง เพราะว่าเป็น user เนาะ เค้า ถ้าเค้าอยากใช้อะไรสักอย่างอ่ะ ไม่ real-time เค้าก็ไม่ใช้หรอก ซึ่งสิ่งเนี้ยครับ ในวงการ Web3 เนี่ย เป็น เป็นโจทย์หลักที่เราต้องการจะตอบ ตอบให้ได้มาเสมอ ใครตอบได้ก็คือชนะทันที ก็คือเป็น startup เป็น unicorn ในวงการได้เลยอะไรเงี้ยครับ โดยที่ก็จะมี product หลายอย่างมากที่ต้องการจะ serve สิ่งเหล่านี้ ส่วนใหญ่ก็จะเป็นเว็บที่เอาไว้ analyze เหรียญ crypto อะไรเงี้ย ให้ ให้ user ไป ดู metric user มาดู แล้ว analyze แบบ real-time เค้าจะได้กดซื้อได้เลย ซึ่ง product ด้านซ้ายเนี่ยก็จะเป็น product ต่างๆ ที่ เบื้องหลังเนี่ย ยังไงก็ต้องใช้ OLAP แน่ๆ ครับ แล้วก็ serve metric ต่างๆ

Technology stack ทั่วไปและช่องว่างที่ต้องเติมเต็ม3:05

ที่ real-time ให้กับ user ครับ โดย technology ต่างๆ เนี่ย

ถ้าเรารู้จักกันแบบมองแบบผิวๆ เนี่ย มันก็มีอยู่แค่นี้เนาะ ก็คือใช้ GoLang ใช้ Postgres หรือถ้า ถ้าซับซ้อนหน่อยก็คือใช้ Parquet ขึ้นมาเกี่ยวข้องด้วย แต่ว่าดูแล้วมันจะมีแบบ บางอย่างหายไป ซึ่งตรงเนี้ยแหละเป็น challenge ที่ผมรู้สึกว่า

มันจะค่อยๆ ปิด gap ระหว่าง OLTP กับ OLAP มากขึ้นเรื่อยๆ ครับ ซึ่งเดี๋ยวนี้ก็จะมี database ยุคใหม่ที่แบบตอบโจทย์ตรงนี้มากๆ คือเกิดขึ้นมาเยอะเหมือนกัน ครับ

ตัวอย่าง Use Case: การวิเคราะห์ Wallet ใน Cleverse3:39

ยกตัวอย่างเนาะ สมมุติว่านี่เป็น product หนึ่งของของ Cleverse เองเนี่ยแหละ ก็คือโจทย์คือเราอยาก เราอยากรู้ว่า wallet wallet เนี่ย เขาเทรดเก่งไหม มันก็จะมี metrics หลายๆ อย่างเลย ไอ้ metrics ในที่โชว์ตรงนี้อาจจะยังง่ายอยู่ แต่ว่า เอ่อ ข้อมูลหลังบ้านเนี่ยก็ต้องเตรียมความพร้อมไว้ สมมุติว่า user อยากทำ custom metrics อะไรบางอย่างหนึ่ง อยากทำ alert ในรูปแบบที่มันซับซ้อนขึ้น ถ้าสมมุติว่ามีคนเทรดแพทเทิร์นนี้อย่างนี้อย่างนี้ เหรียญนี้ขึ้นอย่างนี้ โดยด้วยแพทเทิร์นที่ เฉพาะเจาะจงเนี่ย ให้ส่ง noti เข้า telegram ได้เลย ฉะนั้นมันจะมี requirement เยอะมากๆ ที่เราต้องการจะยุ่งเกี่ยวกับ data แล้วเราต้องการ index ข้อมูลแล้วก็ aggregate ข้อมูลแล้วก็สรุป ผลต่างๆ เนี่ย ให้ user แบบ real time ที่สุดเท่าที่จะเป็นไปได้ ซึ่งตรงเนี้ยในตลาดก็มีคนทำได้เร็วมากๆ แล้ว เออ

ด้วยราคาที่ถูก ครับ

Vertical Scaling กับข้อจำกัดของ Blockchain Data4:27

อ่า ซึ่งถ้าเป็นแบบ no vendor เลยแบบ AWS Google คือแล้วก็ vertical scale OLTP ก็ได้เนาะ ก็คือทำให้มันใหญ่ขึ้น จริง เพราะจริงๆ อ่ะ อย่าง Postgres เนี่ย เอ่อ ถ้าเราลองไป benchmark มันจริงๆ อ่ะ ถ้าเรา push มัน to the limit อ่ะ จริงๆ มันเก่งมากเลยนะ แล้วมันแรงมาก เออ ทุกคนลองไปเล่นกันดูวะ ถ้าเรา load test มันทำอะไรคือมันแรงมาก เนาะ ซึ่ง

อาจจะไม่ตอบโจทย์มากเพราะว่า เอ่อ ข้อมูล transaction ใน blockchain น่ะครับ อย่างเช่น chain Bitcoin, Solana, Ethereum อย่างเงี้ย แต่ละ chain ก็มี ขนาดไม่เท่ากัน อย่างเช่นของ Solana เนี่ย จำนวน transaction ทั้งหมดเนี่ย น่าจะเกิน

ว่าน่าจะเกิน 200 terabyte ไปได้ ไม่แน่ใจ ไม่ได้เช็คตัวเลขมา แต่ว่าเยอะมาก ครับ ซึ่งเราต้องการเอาข้อมูลเหล่านั้นน่ะมา index ในรูปแบบต่างๆ อะไรเงี้ยครับ

Real-time OLTP: ทางออกสำหรับ Real-time Analysis5:17

มันก็เลยทำให้เรามันเกิด paradigm ใหม่ที่เป็น เราเรียกว่า real time OLTP ขึ้นมาเนาะ ทำยังไงให้เรา user เนี่ยครับ สามารถ ยิ่งตรงเข้ากับ database ที่เป็น OLAP ได้เลย แต่ในขณะเดียวกันน่ะ มันก็ต้องตอบโจทย์หลายๆ อย่างที่ มันๆ เคยมีเหตุผลเนาะ ที่เราทำไมเราต้องแยก OLTP กับ OLAP มันก็ต้องปิด gap ตรงนั้นก่อน ครับ เพื่อที่จะทำให้เรา user สามารถใช้งานตรงนี้ได้โดยที่แบบไม่ frustrated เกินไปแล้วก็ มองว่า product ของเราเป็นแบบที่ดี

CDC: การดึงข้อมูลจาก OLTP ไปยัง OLAP5:44

Anyway เลยอ่ะ ยังไงก็ตามอ่ะ เราก็สามารถมี CDC เนาะ Change Data Capture คอย capture ข้อมูลเก่า ของเราที่อยู่ใน OLTP นะครับ มายัดใส่ OLAP ได้เช่นกัน ก็ขึ้นอยู่กับ use case ต่างๆ อย่างเช่นของถ้าเป็น blockchain นะครับ เราก็สามารถ ไอ้ blockchain เนี่ยเป็น เอ่อ เป็น single source of truth ไปเลยเนาะ แล้วเราก็ ทำ CDC ตัวนึง extract ข้อมูลจาก blockchain นะครับ มาเก็บลง snapshot ตัวนึง ซึ่งผมจะใช้เป็นไฟล์ parquet แล้วก็ทำ indexer เขียนโค้ดขึ้นมาเพื่อ index ข้อมูลในรูปแบบต่างๆ แล้วก็ยัดใส่ OLAP อีกทีนึง เนี่ยครับ นี่ก็จะเป็นท่าพื้นฐานที่ product ทุก product ที่ ที่เปิดให้ดูเมื่อกี้เขาใช้กัน ครับ

ClickHouse: ตัวอย่าง Database ยุคใหม่ที่ตอบโจทย์ Real-time OLTP6:26

ซึ่ง มันยกตัวอย่าง feature Cloud ว่าถ้า OLAP อยากอยาก real time เนี่ย มันก็ต้องมีความสามารถของ OLTP เข้ามาเกี่ยวข้องด้วยเนาะ อย่างเช่น ส่วนใหญ่แล้ว OLAP ที่เราคุ้นเคยกันอาจจะเป็นเรื่องของ time series database ครับ ซึ่งมันก็จะ index ได้แค่ primary key ซึ่งเป็น time series อะไรเงี้ยเนาะ ก็จะไม่ ไม่ได้คล่องตัวขนาดนั้น ทีนี้เราอยากได้ column indexing คือเรา index ได้ทุก column เลย เวลา search เวลา เอ่อ เลือก เอ่อ เวลา search ด้วย column อื่นเนี่ยมันจะได้มี indexing ได้เนาะ หรือเราอยากมี atomic write อยากทำให้มันเป็นเหมือนครึ่งๆ transaction อะไรเงี้ยครับ ว่าเขียนทีเดียว ถ้าเขียนไม่สำเร็จก็ abort ทิ้งทั้งหมด อะไรเงี้ยเนาะ หรือ อ่ะ เราอยากทำให้มัน read after write ได้ด้วยแบบ เขียนปุ๊บอ่านแล้วได้เลย แบบ

แบบไม่มีดีเลย์เลยอ่ะ ศูนย์มิลลิเซก ทำได้มั้ย อะไรเงี้ยครับ แล้วก็สุดท้ายก็ต้อง high throughput เนาะ ก็คือถึงแม้ว่า เราอยากได้ complex query มากๆ แต่เราก็อยากให้มันมี high throughput ที่สูงอยู่ดี เพราะว่าข้อมูลมันก็เข้ามาเยอะ อะไรเงี้ยครับ อย่างเช่น use case หลักๆ ของ ของผมเนี่ย ก็คือทำ blockchain เนาะ วินาทีนึงก็มี transaction เข้ามาหลายๆ พัน transaction เหมือนกัน ครับ ซึ่ง ไม่แน่ใจทุกคนเคยได้ยินมั้ย แต่ว่า ClickHouse เนี่ย เป็น tool ที่ค่อนข้าง เก่ง จริงๆ ผมเคยลองมาหลาย tool แล้ว ในอดีต แล้วก็ อย่างเช่น QuestDB TimescaleDB คือลองมาเยอะมาก เอ่อ

บางเจ้าเค้าก็พยายามจะ แก้ปัญหาคล้ายๆ กันเนาะ อย่างเช่น QuestDB ก็อาจจะมีเรื่องของ read after write ให้เหมือนกัน อะไรเงี้ยครับ เอ่อ แต่ว่าโจทย์หลักๆ ที่ โจทย์หลักๆ ที่

เรียกว่าไง คือ ClickHouse ว่าเค้าพยายามทำตัวเองให้เป็น real-time OLTP เลย ฉะนั้น feature เค้าก็ค่อนข้างจะครบกว่า ครับ แต่ทั้งนี้ทั้งนั้นเนี่ย ผมแค่อยากยก ClickHouse มาเป็นตัวอย่างเฉยๆ ไม่ได้บอกว่า ClickHouse ดีที่สุดเนาะ เพราะว่าอย่างตอนผมใช้ QuestDB อ่ะ บัคเยอะมาก ทุกวันนี้ใช้ ClickHouse อ่ะ ก็เจอบัคบ้างเล็กน้อย แต่ว่าไม่ได้เยอะ อะไรเงี้ยครับ ซึ่งๆ มันอยู่ใน เอ่อ ระดับ ระดับที่โอเค ครับ

Materialized View และ Column Indexing ใน ClickHouse8:22

feature แรกเลยที่ เอ่อ อยากมาเล่าให้ทุกคนฟัง น่าจะฟังดู basic เนาะ อืม ก็คือเรามี มีข้อมูลการขายใช่มั้ย เราอยากทำเป็น materialized view ที่คอย aggregate ข้อมูลไว้ให้แล้ว นี่ก็คือ basic ที่ OLAP ควรจะมี แต่ประเด็นก็คือ ด้วยเทคนิคที่

ClickHouse เค้าพยายาม optimize อ่ะ ทำให้ storage ของเค้าน่ะถูกมาก ในการใช้งาน อะไรเงี้ยครับ มันก็มีจะ มันจะมี feature ของเค้า background task อะไรต่างๆ เนี่ย ทำให้ตัวเลขของเค้าค่อนข้างถูก ฉะนั้นเราสามารถ spam materialized view อ่ะ ไม่อั้น แล้วก็ทำเป็น column indexing ได้เลย ตัวอย่างเช่นกรณีเนี้ย ผมมี user ใช่มั้ยครับ user table ผมอยาก search ด้วยอีเมลอ่ะ ผมก็ทำได้ ผมอยาก search ด้วย username ผมก็ทำได้ ก็แค่สร้าง materialized view ขึ้นมาแยกกันไปเลย อะไรเงี้ยครับ ซึ่ง ลองจริงแล้วก็ใช้งานได้จริง แต่ว่าเราคงไม่ทำอย่างงี้กับแค่ user เนาะ อันนี้แค่ยกตัวอย่าง ครับ

เอ่อ

แล้วก็ search ได้ปกติ อะไรเงี้ยครับ ก็เลือก table ให้มันถูกต้อง ครับ

Read After Write และ Buffer Table ใน ClickHouse9:22

อีกอย่างนึงก็คือ สมมุติว่าเราอยากทำ read after write เนาะ มันก็จะมี challenge หลายอย่างที่ ถ้าสมมุติเราใช้ column DB column database นะครับ มันจะ มันจะ มันจะเป็น constraint อาจจะปูพื้นฐานนิดนึงก็คือ หนึ่งเลย column database เนี่ย เป็น append only มันไม่สามารถอัพเดตข้อมูลของบรรทัด บรรทัดนั้น ที่เราเคยอัพเดตไปแล้วได้ อาจจะรัด detail ไว้ก่อน อะไรอย่างเงี้ยนะครับ แล้วก็ การ insert อะไรที่เป็น out of order เนี่ย มันจะทำได้ช้า แล้วก็จะมีดีเลย์ ทำให้มันไม่ได้ instant แบบ immediate consistency อะไรเงี้ยครับ สมมุติว่าบางทีเนี่ย เราอยากได้ at least once guarantee เนาะ ข้อมูลก็ dupe เป็นอีก ทำให้สมมุติว่าตอนเรา query มา ตอนเรา aggregate มา มันก็ อาจจะไม่ตอบโจทย์ อะไรเงี้ยครับ ซึ่ง สิ่งเนี้ย

เอ่อ ตัว ClickHouse เนี่ยก็มี solution ให้เยอะมาก ไม่ว่าจะเป็น deduplication ที่กระทบ performance แค่เล็กน้อย หรืออะไรเงี้ย หรือว่ามีการทำ background task ที่คอย de-dupe ทิ้งให้ แล้วก็สามารถ บังคับให้มันเร็วขึ้นได้ ทุก 5 นาทีคอย de-dupe คอย de-dupe อะไรเงี้ย แต่อันนึงที่ผมว่าเจ๋งมากเลยก็คือ buffer table สมมุติผมบอกว่าผมสร้าง table ขึ้นมาใช่มั้ย เป็น transaction table transaction แล้วผมสร้าง buffer table ขึ้นมาครอบ ตัว buffer table เนี่ยผมสามารถ เอ่อ เรียกว่า ก็คือเป็น OLAP เอ้ย OLTP เลยอ่ะ เป็น layer OLTP ที่ก่อนที่มันจะไป write ของทั้งหมดนะครับ ลง OLAP เนาะ มันจะมา write ลงตรงนี้ก่อน แล้วมันก็จะเป็น buffer เลย สมมุติว่าเขียนไปจนถึง 100 row เอาทั้ง 100 rows นั้นนะครับ มาเรียงลำดับ ให้ ให้เป็นตาม order เนาะ แล้วค่อยไป merge เข้ากับข้อมูลเก่า แก้ปัญหาเรื่อง out of order ได้เนาะ แล้วก็แก้ปัญหาเรื่อง at least once ได้ ใน พอมันเป็น OLTP เนี่ย มันก็มี primary key จริงๆ ได้ ฉะนั้นมันก็สามารถ อะไรที่ duplicate กัน มันก็ filter out ให้เลย ครับ

แล้วสุดท้ายถ้าสมมุติว่าเรา query ตรงกับตัว transaction buffer เลยเนี่ย เราก็จะ ได้ข้อมูลทันที แบบ immediately อะไรเงี้ยครับ อืม นี้ก็เป็นตัวอย่างหนึ่งที่ดีอะไรเงี้ยครับ

Denormalization ใน OLAP ด้วย Dictionary11:20

ทีเนี้ย พอเราทำ OLTP เนาะ ส่วนใหญ่เราจะคุ้นชินกับการที่เราทำ Snowflake Schema ใช่มั้ยครับ เอ่อ ซึ่งสมมุติเรามี transaction เราก็ ค่อยๆ join เอา ถ้าสมมุติเราอยาก query ข้อมูล ซึ่ง การ การ join เนี่ย มันทำให้ performance มัน drop สมมุติว่าเรา เราให้ อยากให้มันสิ่งนี้มัน real time แล้วก็ serve ให้กับลูกค้า ให้ ให้ user โดย โดยตรงเนี้ย มันทำให้ มัน complex เกินไป ถ้าสมมุติว่า มันเป็น real time เนี่ยครับ ลองจินตนาการดู เว็บ เว็บ เว็บหนึ่งเนี่ย user ใช้ 1 เว็บใช่มั้ยครับ ยิ่ง ยิ่งอาจจะเป็น polling ก่อนเนาะ ยิ่ง polling มา get ข้อมูลจาก database เนี่ย ทุก ครึ่งวิ ครึ่งวิ ยิ่ง 1 ครั้ง แล้ว D แบบ MAU เนี่ยก็คือ

monthly active user เนี่ย แตะหลักหมื่นหลักแสนเนี่ย database ก็แตกพอดี ถูกมั้ย เพราะฉะนั้น Snowflake ก็อาจจะไม่ ไม่ ไม่เวิร์กในกรณีนี้ คือมันต้อง join table อะไรเงี้ย ถึงแม้เราจะทำ materialize view ได้อะไรได้ แต่ว่า บางทีมันก็อาจจะไม่ครอบคลุมทุก case

มันก็เลยเริ่มมีแพทเทิร์น การ denormalization เข้ามาในโลกของ OLAP เหมือนกัน นะ อันนี้ผมยกตัวอย่างง่ายๆ คือเราสามารถใช้ dictionary ก็ได้ คือสมมุติว่าเราบอกว่าเราอยาก แค่อยาก look up บาง field เอาไปโชว์ให้ ให้ ให้ front end อะไรเงี้ยครับ เราก็ ไม่ต้อง join ก็ได้ แล้วเราก็สามารถ look up table ได้ ถ้าสังเกตว่า ถ้าวิธีการ create dict ด้าน ด้านซ้ายใช่มั้ย ลองสังเกตดูคือเราสามารถ ไป ทำ CDC แบบดึงข้อมูลมาจาก Postgres ได้เหมือนกัน ถ้าสมมุติเรามี OLTP database อยู่แล้ว เราก็แค่ ทำให้ dictionary เนี่ยเป็นเหมือน cache layer นึงที่ไปดึงข้อมูลมาจากตรงนั้น ทำให้เราไม่ต้องดึงข้อมูลทั้งก้อน แล้วก็ join table โดยไม่จำเป็นอะไรเงี้ยเนาะ เออ ก็คือ มีโอกาสใช้ สามารถเลือกใช้แล้วกันว่า join น้อยลงได้อะไรเงี้ยครับ แล้วก็ เป็น เป็นหนึ่ง key หลักที่ทำให้การ denormalization เนี่ยเริ่ม adopt มากขึ้นใน OLAP ครับ

ประสิทธิภาพและ Scalability ของ ClickHouse13:05

อ่ะ ทีเนี้ย มันดูแบบ มี feature เยอะมาก ถูกมั้ย คำถามก็คือแล้ว

มันเป็นไปได้จริงๆ เหรอ ในการที่แบบมี feature เยอะขนาดนี้ แล้ว performance มันจะดีจริง หรือเปล่า อย่างเงี้ยครับ สุดท้ายแล้วมันจะเป็นแบบ เป็น OLAP ก้อนใหญ่ๆ ที่เราต้อง vertical scale อีกมั้ย อะไรเงี้ย จริงๆ มันมี feature เยอะกว่านี้อีก แต่ผมอาจจะแบบ ไม่ได้หยิบมาเล่าเพราะว่า เอ่อ อาจจะค่อนข้าง niche เกินไป แล้วก็อาจจะ ใช้ ใช้ ใช้เวลาในการขยายความเรื่อง use case อ่ะ นาน อะไรเงี้ย แต่ว่าอาจจะเปิดเป็น Q&A ให้ ให้ถามกันได้เนาะครับ

อืม ครับ ก็ เอ่อ คำถามคือมันต้อง vertical scale มั้ย อ่า ซึ่งจากที่ ตัวเราลองกันอยู่เนี่ยคือ จริงไม่จำเป็นเลย ครับ เพราะว่า อย่างของ ClickHouse เนี่ย เขาออกแบบมาค่อนข้างดีเนาะ คือ นึงเลยคือเขาแยก layer ระหว่าง object storage กับ ตัว database engine เนาะ แยกระหว่าง DBMS กับ database จริงๆ ออกจากกันชัดเจน แล้วก็สามารถ horizontal scale ได้ แล้วก็เลือกได้ด้วย custom ได้ด้วยว่า แต่ละ node จะ vertical scale มั้ย ครับ ซึ่งตรงเนี้ยมัน มัน flexible ขึ้นเยอะเพราะว่า เอ่อ จริงๆ มันก็เป็น ผมมองว่าเป็น OLAP สมัยใหม่อ่ะ มันเริ่ม adopt สิ่งนี้มาแล้ว คือมันสามารถทำ partition ได้ค่อนข้างดี คือเราสามารถ partition ด้วยหลายวิธีได้อะไรเงี้ยครับ แล้ว เนื่องจากพอมันมี materialize view มีอะไรนี้อีกอ่ะ เราก็สามารถระบุไปได้เลยว่า node node นี้ คือข้อมูลแค่จาก ข้อมูลพาร์ทิชั่นนี้เท่านั้น กรุ๊ปไหนเท่านั้นอะไรอย่างเงี้ยครับ มันก็สามารถช่วยแบ่งเบาภาระได้เนาะ

Tech Stack อื่นๆ ที่ Cleverse ใช้: InfluxDB, Postgres, Parquet14:39

ซึ่ง จริงๆ อ่ะมีอีกหลายๆ database ที่ผมมองว่าเจ๋งครับที่

เราเคยใช้งานกันแล้วเราก็ access เรื่อยๆ อะไรเงี้ยครับ อย่างเช่นของที่ Cleverse ใช้เป็นประจำมันก็จะเป็น influx กับ Postgres เนาะ แล้วก็ใช้ parquet เยอะมาก คือ parquet นี่ผมว่าแม่งเป็น ของแบบโคตรเจ๋งอ่ะ เพราะว่า ClickHouse ก่อน

ไม่ได้ ClickHouse ซัพพอร์ต parquet โดยตรงนะ แต่ว่า parquet เนี่ยซัพพอร์ต หลายอย่างมาก เยอะมาก แล้วก็เป็นไฟล์ฟอร์แมตที่ดีมากๆ อะไรเงี้ยครับ เอ่อ

มันก็จะมี tools หลายอย่างที่เรา index ข้อมูลมาแล้วเราจะเก็บ พักไว้ในไฟล์ parquet ก่อน แล้วค่อยโหลดใส่ database engine ที่เหมาะสม ทำให้เราสามารถมี data source 1 อันที่ ไปใส่ engine ที่แตกต่างกัน ใส่ DBS ที่แตกต่างกันเพื่อ ตอบโจทย์รูปแบบที่แตกต่างกันได้ อันนี้ก็เป็น เป็นพอยต์นึงที่ Cleverse adopt ใช้เหมือนกัน InfluxDB เราใช้เยอะมาก ซึ่ง มันก็เป็น time series database เนาะ ฉะนั้นมันก็จะมีข้อจำกัดเยอะอะไรอย่างเงี้ยครับ ช่วงหนึ่ง QuestDB มาแรงก็ แต่มันก็ยังเป็น time series database อยู่ มันก็ยังมีข้อจำกัดในเรื่องของ indexing ต่างๆ อะไรอย่างเงี้ยครับ ซึ่ง ClickHouse ก็เลยตอบโจทย์มากครับผม

Q&A: แนะนำ Cloud ของ ClickHouse และ PeerDB15:54

โอเค ก็เนื้อหาได้จะประมาณนี้ ผม พูดเร็วไป เหลือเวลาเยอะก็อาจจะ ให้เป็นถามตอบก็ได้ครับ หรือ หรือว่ามีใครอยากฟังเรื่องไหนเพิ่มขึ้นมั้ย ที่ไม่ได้ใส่มาในสไลด์ ถ้า ว่าง่ายสุดก็จะแนะนำเป็น cloud ของเขาเลยครับ เพราะว่ามันถูกมากๆ อยู่แล้ว แล้วก็ cloud ของเค้าจะมีฟีเจอร์พิเศษเยอะ เป็นพิเศษอะไรอย่างเงี้ยครับ ก็ ก็ไม่แนะนำให้ deploy หรือว่า maintain เอง ยกเว้นแต่ว่ามีเหตุผล จำกัดมากๆ อย่างเช่น เอ่อ data dataset ของเรามันอยู่ในที่ๆ แบบ เอ่อ มันไม่ควรจะ expose อะไรอย่างเงี้ยครับ แต่ว่า ใช้ cloud ของเขาก็ดี ซึ่ง อ๋อ มันมี มันมี มันมีอันนึงที่น่าสนใจครับ ก็คือ เข้าใจว่า ClickHouse น่าจะเพิ่ง integrate กับ PeerDB ด้วย PeerDB เป็น Change Data Capture ตัวนึงที่เจ๋งมากๆ อะไรเงี้ยครับ ก็ ก็ ถ้า ถ้าใช้ cloud เค้าก็น่าจะได้ PeerDB มาใช้ได้เลยโดยที่เราไม่ต้องแบบปวดหัวครับ

Q&A: Multi-version Control ใน ClickHouse16:46

จริงๆ มีคำถามในส่วนของ ClickHouse อ่ะครับ อยากรู้ว่ามันรองรับตัว ตัว multi-version control มั้ยครับ เวลาเรา เรากำลังเขียน data อยู่อ่ะ แล้วมี user ต้องการ query อย่างเงี้ยครับ ว่ามันจะแบบติดอะไรมั้ย หรือว่ามัน query ได้ปกติ

spec มันคือ MVCC ถ้าผมจำไม่ผิดนะ

multi-version control สักอย่างในการ query ข้อมูลระหว่างที่ database กำลัง กำลังอัพเดตอยู่อ่ะครับ อืม ครับ ก็ อืม อย่างแรกเลยมัน มันเป็น OLAP เนาะ ฉะนั้นมันไม่ได้มี isolation layer แข็งแรงเท่ากับ OLTP พวก Postgres พวกอะไรอย่างงี้ถูกมั้ยครับ แต่ว่า อ่า คือ คือ ถ้า ถ้ากำลังเขียนเนี่ย ยังไงก็อ่าน อ่าน อ่านไม่เจอครับ ต้องรอมันเขียนเสร็จ อ่า แต่หมายถึงว่า อ่ะ ตัวเก่าอ่ะ ได้ตัวเก่าออกไปถูกมั้ย สมมุติว่ามัน ดึงข้อมูลที่เขียนไปแล้ว จังหวะที่มันจะเขียนของใหม่ลงไปอ่ะ ตัวเก่าก็ยังเห็นดึงออกไปได้ถูกป่ะ ได้ครับ ได้ครับ เพราะว่าคือ เบื้อง เบื้องหลัง ก็คือมัน มันเป็นเวอร์ชั่น มันมีเวอร์ชั่นคอนโทรลมันอยู่แล้ว แล้วก็ ClickHouse มัน implement optimistic concurrency control ให้ด้วย ครับ ฉะนั้น read กับ write พร้อมกันได้ ครับ ประมาณนี้

สรุปและแนะนำหนังสือ Designing Data-Intensive Applications17:51

น่าสนใจดี

จริงๆ คือไม่ได้อยากขาย database คืออยากให้ ให้ดูที่ว่า เออ แบบฟีเจอร์อะไรที่มันจำเป็น ในการเลือกใช้ database ถูกมั้ย แต่ว่า ClickHouse เนี่ยคือ adopt ใช้เยอะมากจริงๆ แล้วก็แบบมาแรงแซงทางโค้งเยอะมาก ทางจริงๆ อ่ะผมว่าแค่ เข้าไปลองอ่าน docs ของ ClickHouse อ่ะครับ อาจจะได้เห็นแพทเทิร์นหลายอย่างว่า เอ้ย ทำไม database นี้มันถึงปัง เพราะว่ามันมีฟีเจอร์ที่แบบค่อนข้างตอบโจทย์หลายอย่างอะไรอย่างเงี้ย แล้วบล็อกเขาก็เขียนค่อนข้างดีครับผม มีใครมีคำถามเพิ่มเติม ขอสอบถาม Tech Stack เมื่อกี้อะครับ มันจะมีตัว

เอ่อ Duck DuckDB อะครับ อยากให้แบบ ยกตัวอย่าง Use Case นิดนึง อ๋อ ครับ ได้ครับ คือ คือ นี่ผมแบบใส่ตัวเล็กตัวใหญ่ก็คือตามความหมายนั้นเลย คือ อันที่ใช้เยอะใช้น้อยแล้วกัน แต่ไม่ได้บอกว่าอันไหนดีกว่าอันไหนอะไรเงี้ยครับ เอ่อ อย่างเช่น DuckDB ใช่มั้ย ก็คือ คือ หนึ่งเลย พอ พอเรามีไฟล์ Parquet ใช่มั้ยครับ แล้วสมมุติว่า เรามี คือ ข้อมูลเนี้ย มันไม่ได้เป็นประโยชน์ต่อ User อย่างเดียว แต่มันเป็นประโยชน์ต่อ Analysis ด้วย เรามี Blockchain Analysis มีคนที่อยากวิเคราะห์ข้อมูลของ Chain อยู่ด้วยอะไรเงี้ยครับ ฉะนั้นเราสามารถเอาไฟล์ Parquet เนี่ย ประโยชน์ให้ DuckDB ได้เลย แล้วก็ใช้แทนตัวนี้ได้เลย ซึ่งเบื้องหลังอะ DuckDB มันก็ใช้

คือน่าจะใช้ File Format แบบ Apache Arrow อะไรอยู่แล้ว ฉะนั้นมันก็ค่อนข้าง compatible กับพวก Pandas พวกอะไรอย่างงี้ที่มันแบบสามารถ ใช้คู่กับงาน Data Science ได้อะไรเงี้ยครับ ก็ตอนนี้ Use Case หลักก็คือใช้แค่กับ เป็นเหมือน Embedding Storage อันนึงที่แบบ แทนที่เราจะต้องอ่านไฟล์ Parquet ทั้งหมด คือ ที่ ที่หลักของการใช้ DuckDB ผมมองว่ามันคือสิ่งที่เรียกว่า Push Down Predicate อะ คือสมมุติว่าเรา Filter แล้วเรา Aggregate ข้อมูลอะ เราไม่จำเป็นต้องโหลดข้อมูลทั้งหมดเข้า เข้า Memory ก่อน แล้วค่อย Aggregate เราสามารถทำที่ Layer ของ File Format ได้เลย แล้วก็ DuckDB มันจัดการให้ ฉะนั้นมันก็เลยทำให้ การใช้งาน Parquet File มันง่ายขึ้นเยอะ แบบไฟล์ Parquet สมมุติ 10 GB 30 GB เนี่ย เราก็ใช้ DuckDB ครอบจบเลยครับ ไม่ ไม่ ไม่ได้หนักเครื่องเลยอะไรเงี้ยครับ สงสัยการใช้งาน InfluxDB กับ ClickHouse อะค่ะว่า ตอน ตอนนี้ที่แบบใช้อยู่เงี้ย แบบว่ามีการทำ Change Data Capture ยังไง หรือว่าใช้ตัว Feature ของ ClickHouse ที่บอกเลยอะคะ เอ่อ InfluxDB ตอน InfluxDB ครับ เรา เราต้องเขียนเองครับ เพราะว่า InfluxDB ตอน ตอนที่เลือกใช้ InfluxDB อะ คือ สาเหตุหลักๆ เพราะว่า เขาขายเรื่องของ Injection มัน มัน High Throughput มาก เพราะมันอาจจะออกแบบมาสำหรับ ข้อมูล Time Series เนาะ พวก IoT พวกอะไรเงี้ยครับ เราก็เลยลองเอามา Adopt ใช้กับ Blockchain ดู อะไรเงี้ยครับ แล้ว เราไม่ พอมันเป็น Blockchain อะ เราไม่ได้มี Out of the Order Data เยอะ ฉะนั้น InfluxDB ก็เลยอาจจะตอบโจทย์ แต่ว่า เอ่อ การที่จะให้ได้ Throughput สูงขนาดนั้นน่ะครับ มันต้องใช้ Flux Protocol อะไรของมัน ซึ่งมันไม่ได้มี ผม ผมจำ ถ้าจำไม่ผิดคือมันไม่ได้มีโปรแกรมสำเร็จรูปให้ เราก็เลยต้องเขียนโค้ดเองด้วย GoLang ก็เลยลำบากหน่อย เพราะว่า ถ้าใช้ Flux Protocol อะ ในการ Write ข้อมูลอะ มัน มันเร็วกว่าอะไรเงี้ยครับ ส่วน QuestDB เนี่ย ก็ขายเรื่อง Injection เหมือนกัน คือ เร็วมั้ย เร็วจริง แต่ว่าบั๊กเยอะมาก บั๊กเยอะมากครับ คือ ไม่รู้ผมเจอคนเดียวรึเปล่า แต่ว่าตอนนั้นใช้เวอร์ชัน ตอนนั้นนี่หนึ่งเวอร์ชันอะ คือบั๊กเยอะมาก แล้วก็ Cleverse ถึงขั้นต้องแบบ เข้าไป Contribute เลยอะ แบบไปช่วยแก้บั๊ก ได้เสื้อมาเต็มอะไรเงี้ย คือ ซึ่ง ซึ่งสุดท้ายก็ เลิก เลิกใช้ดีกว่า เพราะว่า เออ บั๊ก บั๊กไม่ ไม่หมดสักทีอะไรเงี้ยครับ Quest QuestDB ก็ คือพอมันเป็น SQL อะ มันก็ใช้ Change Data Capture ปกติได้หมด เหมือน เหมือน ได้เหมือนกัน ครับ โอเค งั้นเดี๋ยวขอขอบคุณพี่ฟามากนะคะ ขอเสียงปรบมือให้พี่ฟาหน่อยค่า

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