เมื่อไม่ใช้ Cassandra

มีการพูดคุยกันมากมายเกี่ยวกับคาสซานดราเมื่อเร็ว ๆ นี้

Twitter, Digg, Facebook และอื่น ๆ ทั้งหมดใช้มัน

เมื่อใดที่ทำให้รู้สึกถึง:

• ใช้คาสซานดรา
• ไม่ใช้ Cassandra และ
• ใช้ RDMS แทนคาสซานดรา

ไม่มีอะไรเหมือนกระสุนเงินทุกอย่างถูกสร้างขึ้นเพื่อแก้ไขปัญหาเฉพาะและมีข้อดีและข้อเสียของตัวเอง มันขึ้นอยู่กับคุณว่าคุณมีคำแถลงปัญหาอะไรและคำตอบที่เหมาะสมที่สุดสำหรับปัญหานั้นคืออะไร

ฉันจะพยายามตอบคำถามของคุณทีละคนตามลำดับที่คุณถาม เนื่องจากคาสซานดราอิงตามฐานข้อมูลตระกูล NoSQL จึงเป็นสิ่งสำคัญที่คุณต้องเข้าใจว่าเหตุใดจึงต้องใช้ฐานข้อมูล NoSQL ก่อนที่ฉันจะตอบคำถามของคุณ

ทำไมต้องใช้ NoSQL

ในกรณีของ RDBMS การเลือกค่อนข้างง่ายเพราะฐานข้อมูลทั้งหมดเช่น MySQL, Oracle, MS SQL, PostgreSQL ในหมวดหมู่นี้นำเสนอโซลูชั่นแบบเดียวกับที่เน้นไปที่คุณสมบัติของกรด เมื่อพูดถึง NoSQL การตัดสินใจจะกลายเป็นเรื่องยากเพราะฐานข้อมูล NoSQL ทุกข้อเสนอวิธีแก้ไขปัญหาที่แตกต่างกันและคุณต้องเข้าใจว่าอันไหนเหมาะที่สุดสำหรับความต้องการแอพ / ระบบของคุณ ตัวอย่างเช่น MongoDB เหมาะสำหรับกรณีการใช้งานที่ระบบของคุณต้องการที่เก็บเอกสารที่ไม่ใช้สคีมา HBase อาจเหมาะสำหรับเครื่องมือค้นหาการวิเคราะห์ข้อมูลบันทึกหรือสถานที่ที่ต้องการสแกนตารางการเข้าร่วมแบบสองมิติขนาดใหญ่เป็นสิ่งจำเป็น Redis ถูกสร้างขึ้นเพื่อให้การค้นหาในหน่วยความจำสำหรับโครงสร้างข้อมูลที่หลากหลายเช่น tree, queues, รายการที่เชื่อมโยง ฯลฯ และสามารถเหมาะสมสำหรับการสร้างลีดเดอร์บอร์ดแบบเรียลไทม์ระบบ pub-sub ในทำนองเดียวกันมีฐานข้อมูลอื่น ๆ ในหมวดหมู่นี้ (รวมถึง Cassandra) ซึ่งเหมาะสำหรับคำแถลงปัญหาที่แตกต่างกัน ตอนนี้ให้ย้ายไปยังคำถามต้นฉบับและตอบคำถามทีละข้อ

เมื่อใดจึงควรใช้ Cassandra

เป็นส่วนหนึ่งของตระกูล NoSQL คาสซานดราเสนอทางออกสำหรับปัญหาที่หนึ่งในความต้องการของคุณคือมีระบบการเขียนที่หนักมากและคุณต้องการให้มีระบบการรายงานที่ตอบสนองได้ค่อนข้างดี พิจารณากรณีการใช้งานของการวิเคราะห์เว็บที่จัดเก็บข้อมูลบันทึกสำหรับคำขอแต่ละรายการและคุณต้องการสร้างแพลตฟอร์มการวิเคราะห์เพื่อนับจำนวนการเข้าชมต่อชั่วโมงเบราว์เซอร์โดย IP ฯลฯ ตามเวลาจริง คุณสามารถอ้างอิงโพสต์บล็อกนี้เพื่อทำความเข้าใจเพิ่มเติมเกี่ยวกับกรณีการใช้งานที่เหมาะสมกับ Cassandra

เมื่อใดควรใช้ RDMS แทนคาสซานดรา

Cassandra ขึ้นอยู่กับฐานข้อมูล NoSQL และไม่ได้จัดเตรียม ACID และคุณสมบัติข้อมูลเชิงสัมพันธ์ หากคุณมีข้อกำหนดที่เข้มงวดสำหรับคุณสมบัติ ACID (เช่นข้อมูลทางการเงิน) Cassandra จะไม่เหมาะสมในกรณีนี้ เห็นได้ชัดว่าคุณสามารถแก้ไขปัญหาได้อย่างไรก็ตามคุณจะต้องเขียนรหัสแอปพลิเคชันจำนวนมากเพื่อจำลองคุณสมบัติกรดและจะเสียเวลาในการทำตลาดอย่างไม่ดี การจัดการระบบประเภทนั้นด้วย Cassandra นั้นจะซับซ้อนและน่าเบื่อสำหรับคุณ

เมื่อไม่ใช้ Cassandra

ฉันไม่คิดว่าจะต้องตอบหากคำอธิบายข้างต้นสมเหตุสมผล

เมื่อประเมินระบบข้อมูลแบบกระจายคุณต้องพิจารณาทฤษฎีบท CAP - คุณสามารถเลือกสองข้อต่อไปนี้: ความสอดคล้องความพร้อมใช้งานและความทนทานต่อพาร์ติชัน

คาสซานดราเป็นระบบที่พร้อมใช้งานสำหรับพาร์ติชันที่รองรับความสอดคล้องในที่สุด สำหรับข้อมูลเพิ่มเติมโปรดดูที่บล็อกโพสต์นี้ผมเขียน: ภาพคู่มือระบบ NoSQL

คาสซานดราเป็นคำตอบสำหรับปัญหาเฉพาะ: คุณจะทำอย่างไรเมื่อคุณมีข้อมูลมากจนไม่เหมาะกับเซิร์ฟเวอร์เครื่องเดียว คุณจะเก็บข้อมูลทั้งหมดของคุณบนเซิร์ฟเวอร์จำนวนมากได้อย่างไรและไม่ทำลายบัญชีธนาคารของคุณและไม่ทำให้นักพัฒนาของคุณเสียสติ Facebook ได้รับข้อมูลที่บีบอัดใหม่ 4 เทราไบต์ทุกวัน และจำนวนนี้มีแนวโน้มที่จะเติบโตมากกว่าสองเท่าภายในหนึ่งปี

หากคุณไม่มีข้อมูลจำนวนมากหรือหากคุณมีหลายล้านที่จะต้องจ่ายสำหรับการติดตั้งคลัสเตอร์ Enterprise Oracle / DB2 และผู้เชี่ยวชาญที่จำเป็นในการตั้งค่าและบำรุงรักษาคุณก็สามารถใช้ฐานข้อมูล SQL ได้

อย่างไรก็ตาม Facebook ไม่ได้ใช้คาสซานดราอีกต่อไปและตอนนี้ใช้ MySQL เกือบจะย้ายการแบ่งพาร์ติชันในแอปพลิเคชันสแต็คเพื่อประสิทธิภาพที่เร็วขึ้นและการควบคุมที่ดีขึ้น

แนวคิดทั่วไปของ NoSQL ก็คือคุณควรใช้แหล่งข้อมูลใดเหมาะสมที่สุดสำหรับแอปพลิเคชันของคุณ หากคุณมีตารางข้อมูลทางการเงินให้ใช้ SQL ถ้าคุณมีวัตถุที่ต้องใช้แบบสอบถามที่ซับซ้อน / ช้าในการแมปไปยังสคีมาเชิงสัมพันธ์ใช้วัตถุหรือที่เก็บคีย์ / ค่า

แน่นอนว่าปัญหาเกี่ยวกับโลกแห่งความจริงที่คุณพบเจอนั้นอยู่ที่ไหนสักแห่งระหว่างทั้งสองสุดขั้วและวิธีการแก้ปัญหาไม่สมบูรณ์แบบ คุณต้องพิจารณาความสามารถของแต่ละร้านค้าและผลที่ตามมาของการใช้หนึ่งส่วนด้วยกันซึ่งจะมีความเฉพาะเจาะจงมากกับปัญหาที่คุณพยายามแก้ไข

นอกจากคำตอบที่ให้ไว้ข้างต้นเกี่ยวกับเวลาที่จะใช้และเมื่อไม่ใช้ Cassandra ถ้าคุณตัดสินใจใช้ Cassandra คุณอาจต้องการพิจารณาไม่ใช้ Cassandra เอง แต่เป็นลูกพี่ลูกน้องหนึ่งในนั้น

คำตอบบางข้อข้างต้นชี้ไปที่ระบบ "NoSQL" ที่ใช้คุณสมบัติหลายอย่างร่วมกับ Cassandra ซึ่งมีความแตกต่างเล็กหรือใหญ่และอาจดีกว่า Cassandra สำหรับความต้องการเฉพาะของคุณ

นอกจากนี้เมื่อไม่นานมานี้ (หลายปีหลังจากคำถามนี้ถูกถาม) โคลน Cassandra ชื่อ Scylla (ดูhttps://en.wikipedia.org/wiki/Scylla_(database) ) ได้รับการปล่อยตัว Scylla เป็นการนำโอเพนซอร์สมาใช้ใหม่ของ Cassandra ใน C ++ ซึ่งอ้างว่ามีปริมาณงานสูงและเวลาแฝงต่ำกว่า Java Cassandra ดั้งเดิมอย่างมีนัยสำคัญในขณะที่ส่วนใหญ่เข้ากันได้กับมัน ดังนั้นหากคุณกำลังพิจารณา Cassandra อยู่แล้วคุณอาจต้องการพิจารณา Scylla ด้วย

การพูดคุยกับใครสักคนท่ามกลางการใช้งานคาสซานดรามันไม่ได้จัดการกับหลายต่อหลายคน พวกเขากำลังทำงานแฮ็คเพื่อทำการทดสอบเบื้องต้น ฉันพูดกับที่ปรึกษาของคาสซานดราเกี่ยวกับเรื่องนี้และเขาบอกว่าเขาจะไม่แนะนำถ้าคุณมีปัญหาชุดนี้

คุณควรถามตัวเองด้วยคำถามต่อไปนี้:

1. (ปริมาตร, ความเร็ว)คุณจะเขียนและอ่าน TONS ของข้อมูลหรือไม่ข้อมูลมากมายที่ไม่มีคอมพิวเตอร์เครื่องใดสามารถจัดการเขียนได้
2. (ทั่วโลก)คุณต้องการความสามารถในการเขียนและการอ่านทั่วโลกเพื่อให้การเขียนในส่วนหนึ่งของโลกสามารถเข้าถึงได้ในอีกส่วนหนึ่งของโลก?
3. (ความน่าเชื่อถือ)คุณต้องการให้ฐานข้อมูลนี้ทำงานตลอดเวลาและไม่เคยลงไปไม่ว่าจะเป็นคลาวด์ที่ประเทศใดไม่ว่าจะเป็น VM, Container หรือ Bare metal?
4. (ชั่งความสามารถ)คุณต้องการฐานข้อมูลนี้เพื่อให้สามารถเติบโตได้อย่างง่ายดาย
5. (สอดคล้อง)คุณต้องการความสอดคล้องแบบ TUNABLE ที่การเขียนบางอย่างสามารถเกิดขึ้นแบบอะซิงโครนัสในขณะที่คนอื่น ๆ ต้องได้รับการรับรองหรือไม่?
6. (Skill)คุณยินดีที่จะทำสิ่งที่จะเรียนรู้เทคโนโลยีนี้และการสร้างแบบจำลองข้อมูลที่ไปพร้อมกับการสร้างฐานข้อมูลกระจายทั่วโลกที่รวดเร็วสำหรับทุกคนทุกที่หรือไม่?

หากคำถามเหล่านี้คุณคิดว่า "อาจจะ" หรือ "ไม่" คุณควรใช้อย่างอื่น หากคุณมี "นรกใช่" เป็นคำตอบสำหรับพวกเขาทั้งหมดคุณควรใช้คาสซานดรา

ใช้ RDBMS เมื่อคุณสามารถทำทุกอย่างในกล่องเดียว มันอาจจะง่ายกว่าคนส่วนใหญ่และทุกคนสามารถทำงานกับมันได้

ข้อความค้นหาเดี่ยวขนาดใหญ่และข้อความค้นหาเบา ๆโหลดเป็นอีกจุดที่ควรพิจารณานอกเหนือจากคำตอบอื่น ๆ ที่นี่ เป็นการยากยิ่งขึ้นที่จะเพิ่มประสิทธิภาพการสืบค้นเดียวโดยอัตโนมัติในฐานข้อมูล NoSql ฉันใช้ MongoDB และพบปัญหาเรื่องประสิทธิภาพเมื่อพยายามคำนวณข้อความค้นหาที่ซับซ้อน ฉันไม่ได้ใช้ Cassandra แต่ฉันคาดหวังว่ามันจะมีปัญหาเดียวกัน

ในทางกลับกันหากการโหลดของคุณคาดว่าจะเป็นแบบสอบถามขนาดเล็กจำนวนมากและคุณต้องการที่จะขยายออกไปได้อย่างง่ายดายคุณสามารถใช้ประโยชน์จากความสอดคล้องในที่สุดที่มีให้โดย NoSql DBs ส่วนใหญ่ โปรดทราบว่าความสอดคล้องในท้ายที่สุดไม่ได้เป็นคุณลักษณะของตัวแบบข้อมูลที่ไม่เกี่ยวข้อง แต่มันง่ายกว่ามากในการนำไปใช้และตั้งค่าในระบบที่ใช้ NoSql

สำหรับเคียวรีที่หนักหน่วงมาก ๆ เอ็นจิ้น RDBMS ที่ทันสมัยสามารถทำงานได้อย่างมีประสิทธิภาพในการเรียงลำดับส่วนของเคียวรีและใช้ประโยชน์จาก CPU และหน่วยความจำที่คุณขว้างมามาก (บนเครื่องเดียว) ฐานข้อมูล NoSql ไม่มีข้อมูลเพียงพอเกี่ยวกับโครงสร้างของข้อมูลเพื่อให้สามารถสันนิษฐานได้ว่าจะช่วยให้สามารถทำการสืบค้นแบบคู่ขนานอย่างชาญฉลาดอย่างแท้จริง พวกเขาช่วยให้คุณสามารถขยายเซิร์ฟเวอร์ได้ง่ายขึ้น (หรือแกนประมวลผล) แต่เมื่อแบบสอบถามพบระดับความซับซ้อนคุณจะถูกบังคับให้แยกมันออกเป็นส่วน ๆ ด้วยตนเองเป็นส่วน ๆ ที่เอ็นจิ้น NoSql รู้วิธีจัดการอย่างชาญฉลาด

จากประสบการณ์ของฉันกับ MongoDB ในที่สุดเพราะความซับซ้อนของการสืบค้น Mongo ไม่สามารถทำได้มากนักในการปรับให้เหมาะสมและเรียกใช้บางส่วนของมันกับข้อมูลจำนวนมาก Mongo parallelizes คำสั่งหลาย ๆแต่ไม่ดีดังนั้นในการเพิ่มประสิทธิภาพหนึ่งเดียว

ลองอ่านบางกรณีในโลกแห่งความจริง:

http://planetcassandra.org/apache-cassandra-use-cases/

ในบทความนี้: http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

พวกเขาอธิบายเหตุผลว่าทำไมพวกเขาไม่เลือก MySql เพราะการซิงโครไนซ์ฐานข้อมูลช้าเกินไป

(เนื่องจากการกระทำ 2 วลี, FK, PK)

Cassandra ขึ้นอยู่กับกระดาษ Amazon Dynamo

คุณสมบัติ:

ความมั่นคง

พร้อมใช้งานสูง

การสำรองข้อมูลทำได้ดี

อ่านและเขียนดีกว่า HBase (BigTable clone ใน java)

wiki http://en.wikipedia.org/wiki/Apache_Cassandra

บทสรุปของพวกเขาคือ:

We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.

ตั้งแต่ 2018

ฉันอยากจะแนะนำให้ใช้ ScyllaDB เพื่อแทนที่ Cassandra แบบคลาสสิกหากคุณต้องการการสนับสนุนกลับ

ปลั๊กอิน kv ของ Postgres นั้นรวดเร็วกว่าคาสซานดรา จะไม่มีความยืดหยุ่นในการใช้งานหลายครั้งได้อย่างไร

ฉันจะให้ความสำคัญกับประเด็นสำคัญที่จะช่วยให้คุณตัดสินใจว่าคุณต้องการคาสซานดราหรือไม่ รายการไม่ครบถ้วนสมบูรณ์เพียงบางจุดที่ฉันมีอยู่ในใจ -

• อย่าถือว่าคาสซานดราเป็นตัวเลือกแรกเมื่อคุณมีข้อกำหนดที่เข้มงวดเกี่ยวกับความสัมพันธ์ (ในชุดข้อมูลของคุณ)

• คาสซานดราโดยค่าเริ่มต้นคือระบบ AP (ของ CAP) แต่รองรับความสอดคล้องที่ปรับได้ซึ่งหมายความว่าสามารถกำหนดค่าให้รองรับเป็น CP ได้เช่นกัน ดังนั้นอย่าเพิกเฉยเพียงเพราะคุณอ่านที่ไหนสักแห่งว่าเป็น AP และคุณกำลังมองหาระบบ CP คาสซานดราเป็นคำที่ถูกต้องมากกว่า“ มีความสอดคล้องกันอย่างลงตัว” ซึ่งหมายความว่าช่วยให้คุณสามารถตัดสินใจระดับความสอดคล้องที่คุณต้องการได้อย่างง่ายดายในสมดุลกับระดับความพร้อมใช้งาน

• อย่าใช้คาสซานดราถ้าขนาดของคุณไม่มากหรือถ้าคุณสามารถจัดการกับฐานข้อมูลที่ไม่ได้รับการแจกจ่าย

• คิดให้หนักขึ้นถ้าทีมของคุณคิดว่าปัญหาทั้งหมดของคุณจะได้รับการแก้ไขถ้าคุณใช้ฐานข้อมูลแบบกระจายเช่นคาสซานดรา การเริ่มต้นด้วยฐานข้อมูลเหล่านี้นั้นง่ายมากเพราะมันมาพร้อมกับค่าเริ่มต้นจำนวนมาก แต่การปรับให้เหมาะสมและเชี่ยวชาญในการแก้ปัญหาเฉพาะจะต้องใช้ความพยายามด้านวิศวกรรมที่ดี (ถ้าไม่มาก)

• คาสซานดราเป็นแบบคอลัมน์ แต่ในเวลาเดียวกันแต่ละแถวก็มีคีย์ที่ไม่ซ้ำกัน ดังนั้นอาจเป็นประโยชน์หากคิดว่าเป็นร้านที่จัดทำดัชนีแบบแถวเรียงคุณสามารถใช้เป็นที่เก็บเอกสาร

• คาสซานดราไม่ได้บังคับให้คุณกำหนดเขตข้อมูลล่วงหน้า ดังนั้นหากคุณอยู่ในโหมดเริ่มต้นหรือคุณสมบัติของคุณมีการพัฒนา (เช่นในความคล่องตัว) - คาสซานดราโอบกอดมัน ดีกว่ามาก,ก่อนอื่นให้คิดถึงคำถามแล้วจึงคิดถึงข้อมูลเพื่อตอบคำถาม

• คาสซานดราได้รับการปรับปรุงเพื่อให้ได้ปริมาณงานที่สูงมาก หากกรณีการใช้งานของคุณเป็นแบบอ่านอย่างหนัก (เช่นแคช) Cassandra อาจไม่ใช่ตัวเลือกในอุดมคติ

อีกสถานการณ์ที่ทำให้การเลือกง่ายขึ้นคือเมื่อคุณต้องการใช้ฟังก์ชันการรวมเช่นผลรวม, นาที, สูงสุด, ฯลฯ และซับซ้อน (เช่นในระบบการเงินที่กล่าวถึงข้างต้น) แล้วฐานข้อมูลเชิงสัมพันธ์อาจจะสะดวกกว่าฐานข้อมูล nosql เนื่องจากทั้งสอง เป็นไปไม่ได้ในฐานข้อมูล nosql เว้นแต่ว่าคุณจะใช้ดัชนี Inverted จำนวนมากจริงๆ เมื่อคุณใช้ nosql คุณจะต้องทำฟังก์ชั่นรวมในรหัสหรือเก็บไว้ในคอลัมน์ของตัวเอง แต่มันทำให้มันค่อนข้างซับซ้อนและลดประสิทธิภาพที่คุณได้รับจากการใช้ nosql

หากคุณต้องการฐานข้อมูลที่สอดคล้องอย่างสมบูรณ์กับซีแมนทิกส์ SQL แคสซานดราไม่ใช่โซลูชันสำหรับคุณ Cassandra รองรับการค้นหาคีย์ - ค่า ไม่รองรับการสืบค้น SQL ข้อมูลใน Cassandra นั้น "ในที่สุดสอดคล้องกัน" การค้นหาข้อมูลพร้อมกันอาจไม่สอดคล้องกัน แต่ในที่สุดการค้นหาก็สอดคล้องกัน

หากคุณต้องการซีแมนทิกส์ที่เข้มงวดและต้องการการสนับสนุนสำหรับเคียวรี SQL ให้เลือกโซลูชันอื่นเช่น MySQL, PostGres หรือรวมการใช้ Cassandra กับ Solr

คาสซานดราเป็นตัวเลือกที่ดีถ้า:

1. คุณไม่ต้องการคุณสมบัติ ACID จากฐานข้อมูลของคุณ

2. จะมีการเขียนจำนวนมากและมากในฐานข้อมูล

3. มีข้อกำหนดในการรวมเข้ากับ Big Data, Hadoop, Hive และ Spark

4. มีความต้องการการวิเคราะห์ข้อมูลแบบเรียลไทม์และการสร้างรายงาน

5. มีความต้องการกลไกการป้องกันความผิดปกติที่น่าประทับใจ

6. มีความต้องการของระบบที่เป็นเนื้อเดียวกัน

7. มีความต้องการปรับแต่งมากมายสำหรับการปรับแต่ง

Mongodb มีฟังก์ชั่นรวมที่มีประสิทธิภาพมากและกรอบการรวมที่แสดงออก มันมีคุณสมบัติที่นักพัฒนาจำนวนมากคุ้นเคยกับการใช้จากฐานข้อมูลเชิงสัมพันธ์ มันเป็นโครงสร้างข้อมูล / การจัดเก็บเอกสารที่ช่วยให้มีรูปแบบข้อมูลที่ซับซ้อนกว่าคาสซานดราเป็นต้น

ทั้งหมดนี้มาพร้อมกับการแลกเปลี่ยนที่แน่นอน ดังนั้นเมื่อคุณเลือกฐานข้อมูลของคุณ (NoSQL, NewSQL หรือ RDBMS) ให้ดูว่าปัญหาใดที่คุณกำลังพยายามแก้ไขและความต้องการในการปรับขนาดของคุณ ไม่มีฐานข้อมูลเดียวทำทั้งหมด

ตาม DataStax คาสซานดราไม่ใช่กรณีการใช้งานที่ดีที่สุดเมื่อมีความต้องการ

1- อุปกรณ์ฮาร์ดแวร์ระดับสูง 2- สอดคล้องกับกรดโดยไม่มีการย้อนกลับ (การทำธุรกรรมธนาคาร)

• ไม่รองรับการจัดการธุรกรรมที่สมบูรณ์ทั่วทั้งตาราง
• ไม่รองรับดัชนีรอง
• ต้องพึ่งพาการค้นหาแบบยืดหยุ่น / Solr สำหรับดัชนีรองและองค์ประกอบการซิงค์แบบกำหนดเองจะต้องมีการเขียน
• ไม่ใช่ระบบที่สอดคล้องกับกรด
• การสนับสนุนการค้นหามี จำกัด

Apache Cassandra เป็นฐานข้อมูลแบบกระจายสำหรับการจัดการข้อมูลที่มีโครงสร้างจำนวนมากในเซิร์ฟเวอร์สินค้าโภคภัณฑ์จำนวนมากในขณะที่ให้บริการที่พร้อมใช้งานสูงและไม่มีความล้มเหลวในจุดเดียว

สถาปัตยกรรมที่มีพื้นฐานมาจากทฤษฎีบทหมวกล้วนๆคือความพร้อมใช้งานและความทนทานต่อการแบ่งพาร์ติชันและในที่สุดก็น่าสนใจอย่างสม่ำเสมอ

อย่าใช้มันหากคุณไม่ได้จัดเก็บข้อมูลจำนวนมากบนชั้นวางของคลัสเตอร์อย่าใช้ถ้าคุณไม่ได้จัดเก็บข้อมูลอนุกรมเวลาอย่าใช้ถ้าคุณไม่ได้ patitioning เซิร์ฟเวอร์ของคุณอย่าใช้ถ้าคุณต้องการความมั่นคงที่แข็งแกร่ง