SQL (MySQL) เทียบกับ NoSQL (CouchDB) [ปิด]

ฉันอยู่ระหว่างการออกแบบแอปพลิเคชันที่ปรับขนาดได้สูงซึ่งต้องจัดเก็บข้อมูลจำนวนมาก ตัวอย่างเช่นมันจะเก็บข้อมูลเกี่ยวกับผู้ใช้จำนวนมากจากนั้นสิ่งต่างๆเช่นข้อความความคิดเห็น ฯลฯ จำนวนมากฉันเคยใช้ MySQL มาก่อน แต่ตอนนี้ฉันตั้งใจที่จะลองสิ่งใหม่ ๆ เช่น couchdb หรือสิ่งที่คล้ายกันซึ่งไม่ใช่ SQL

ใครมีความคิดหรือคำแนะนำเกี่ยวกับเรื่องนี้หรือไม่?

นี่พูดจากที่ผ่านมาโพสต์บล็อกจาก Dare Obasanjo

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

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

ซึ่งฉันสามารถเพิ่มได้เฉพาะการเปลี่ยนจาก MySQL ที่คุณมีประสบการณ์อย่างน้อยมาเป็น CouchDB ซึ่งคุณไม่มีประสบการณ์หมายความว่าคุณจะต้องจัดการกับชุดปัญหาใหม่ทั้งหมดและเรียนรู้แนวคิดและแนวทางปฏิบัติที่ดีที่สุดที่แตกต่างกัน ในขณะที่มันยอดเยี่ยม (ฉันเล่นที่บ้านกับ MongoDB และชอบมันมาก) มันจะเป็นค่าใช้จ่ายที่คุณต้องคำนวณเมื่อประมาณงานสำหรับโครงการนั้นและนำมาซึ่งความเสี่ยงที่ไม่ทราบสาเหตุในขณะที่สัญญาว่าจะได้รับผลประโยชน์ที่ไม่รู้จัก มันจะยากมากที่จะตัดสินว่าคุณสามารถทำโครงการได้ตรงเวลาและมีคุณภาพที่คุณต้องการ / จำเป็นต้องประสบความสำเร็จหรือไม่หากมันขึ้นอยู่กับเทคโนโลยีที่คุณไม่รู้จัก

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

อัปเดต : เพียงแค่โยนน้ำมันเบนซินลงในกองไฟที่คุณเริ่มต้นต่อไปนี้เป็นบทความที่น่าสนใจสองบทความจากผู้คนในค่าย SQL :-)

ฉันไม่สามารถรอให้ NoSQL ตายได้ (บทความต้นฉบับหายไปแล้วนี่คือสำเนา )
การต่อสู้กับ NoSQL Mindset แม้ว่านี่จะไม่ใช่การ
อัปเดตชิ้นส่วนต่อต้าน NoSQL : นี่คือบทความที่น่าสนใจเกี่ยวกับ NoSQL
Making Sense of NoSQL

ดูเหมือนว่าจะมีเพียงวิธีแก้ปัญหาที่แท้จริงในปัจจุบันเท่านั้นที่หมุนไปตามการปรับขนาดหรือการแตก ฐานข้อมูลที่ทันสมัยทั้งหมด (NoSQLs และ NewSQLs) รองรับการปรับขนาดแนวนอนทันทีที่เลเยอร์ฐานข้อมูลโดยไม่จำเป็นต้องให้แอปพลิเคชันต้องมีการชาร์ดโค้ดหรืออะไรบางอย่าง

น่าเสียดายที่เพียงพอสำหรับ MySQL รุ่นเก่าที่เชื่อถือได้ไม่มีการแบ่งส่วนข้อมูล "นอกกรอบ" ScaleBase (ข้อจำกัดความรับผิดชอบ: ฉันทำงานอยู่ที่นั่น) เป็นผู้ผลิตโซลูชันการขยายขนาดที่สมบูรณ์ซึ่งเป็น "เครื่องชาร์ดอัตโนมัติ" หากคุณต้องการ ScaleBae วิเคราะห์ข้อมูลและสตรีม SQL ของคุณแยกข้อมูลข้ามโหนด DB และรวมในรันไทม์ดังนั้นคุณจะไม่ต้องทำ! และดาวน์โหลดได้ฟรี

อย่าเข้าใจฉันผิด NoSQL นั้นยอดเยี่ยมเป็นของใหม่ใหม่เป็นทางเลือกที่ดีกว่าและทางเลือกที่ดีเสมอ !! แต่การเลือก NoSQL มาพร้อมกับราคามั่นใจว่าจ่ายได้ ...

คุณสามารถดูข้อมูลเพิ่มเติมเกี่ยวกับ MySQL, NoSQL ... ได้ที่นี่: http://www.scalebase.com/extreme-scalability-with-mongodb-and-mysql-part-1-auto-sharding

หวังว่าจะช่วยได้

หนึ่งในตัวเลือกที่ดีที่สุดคือไปที่ MongoDB (NOSql dB) ที่รองรับความสามารถในการปรับขนาดเก็บข้อมูลจำนวนมากไม่มีอะไรนอกจาก bigdata ในรูปแบบของเอกสารซึ่งแตกต่างจากแถวและตารางใน sql นี่คือตัวยึดที่ตามมาจากการแตกของข้อมูล เพื่อให้แน่ใจว่าการรับประกันข้อมูลจะดูแลเซิร์ฟเวอร์หลายเครื่องที่มีเซิร์ฟเวอร์ฐานข้อมูลหลักเป็นฐาน ภาษาอิสระ มีความยืดหยุ่นในการใช้งาน