Sep 13, 2010

Share ประสบการณ์การใช้งาน TokyoTyrant

ก่อนอื่นต้องออกตัวว่าไม่ได้เป็น programmer เขียนโปรแกรมเพื่อใช้งาน TokyoTyrant นะครับ แต่ว่าเป็นคนดูแล service TokyoTyrant และให้คำแนะนำในฐานะ infrastructure service owner เท่านั้น  ซึ่งเท่าที่พบเห็นการใช้งานมาก็พอจะบอกได้ว่า อะไรควร อะไรไม่ควร


  • เนื่องจาก TokyoTyrant ไม่ support การกำหนด expire date ให้กับ key ดังนั้น ข้อมูลที่บันทึกเข้ามาจะถูกเก็บสะสมไปเรื่อยถ้า key ไม่ซ้ำกัน 
  • การทำ replication ต้องเปิด ulog ที่เครื่อง master ไม่งั้นจะทำ rep ไม่ได้ ดังนั้นถ้า application ใดที่มีการเปลี่ยนแปลงค่าบ่อยมากๆๆ ก็อาจจะทำให้ ulog โตขึ้นเรื่อยๆ ได้ ใน app ที่เคยเห็นพบว่า พอใช้งานไปได้แค่ 2 อาทิตย์ ulog โตขึ้นมากถึง 17GB ซึ่งถ้าปล่อยไปเรื่อย disk ก็คงเต็มภายในไม่กี่เดือน ก็ต้องยกเลิกการใช้งานในท้ายที่สุด

คำถามคือ แล้วข้อมูลแบบใหนที่ควรเก็บไว้ใน TokyoTyrant ผมมองว่า ควรเป็นข้อมูลที่เป็นเสมือน lookup table เช่น เก็บ status ของ online user, เก็บ property ง่ายๆ ของ user แทนการเก็บไว้ใน RDBMS และไม่ต้องการเก็บไว้ใน Memcached เพราะข้อมูลค่อนข้างมีความสำคัญ ไม่อยากเสี่ยงที่จะให้สูญหายหรือ get ข้อมูลไม่ได้ ดังนั้น TokyoTyrant (หรือ TokyoCabinet) ก็น่าจะเป็นทางเลือกที่ดีอีกตัว

อีกคำถามคือ ถ้าใช้ memcached อยู่แล้ว พบปัญหา timeout หรือข้อมูลหายบ่อย ควรจะแก้ไขอย่างไร ถ้าเรากำหนด expire ของข้อมูลได้ แนะนำให้ใช้ Redis เพราะทดสอบแล้ว เร็ว set expire ได้ ดังนั้นข้อมูลใน memory หรือ disk จะไม่บวมมาก แถมเป็น persistent คือ reboot server แล้วข้อมูลไม่หาย มีการบันทึกไว้บน disk ด้วย

ถ้าข้อมูลมีปริมาณที่แน่นอน ต้องการความน่าเชื่อถือมากขึ้น ต้องการทำ search ที่เร็ว ก็แนะนำ TokyoTyrant เลย ความสามารถก็น้องๆ RDBMS โดยเฉพาะส่วน search ใช้ software ชื่อ TokyoDystopia รับรองได้เรื่องความเร็ว ดีกว่า RDBMS แน่ๆ

งงแน่ๆ ถ้างง แนะนำง่ายๆ ลองดูด้วยตนเองทั้งหมดครับ ถ้ามีเวลาเพียงพอ เพราะการ set up ค่อนข้างง่าย แต่การ maintain ให้ทำงานได้ตลอดโดยไม่มีปัญหานั้นก็เป็นเรื่องท้าทายเช่นกัน

No comments: