คุณประสบปัญหาเกี่ยวกับความยืดหยุ่นในการปรับใช้โดยใช้แหล่งข้อมูล NoSQL [ปิด]

NoSQL อ้างถึงที่เก็บข้อมูลที่ไม่เกี่ยวข้องซึ่งทำลายประวัติของฐานข้อมูลเชิงสัมพันธ์และการรับประกัน ACID แหล่งข้อมูลโอเพ่นซอร์สยอดนิยม NoSQL รวมถึง:

• Cassandra (ตารางเขียนใน Java ใช้โดย Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit และ Twitter)
• CouchDB (เอกสารเขียนใน Erlang ใช้โดย BBC และ Engine Yard)
• Dynomite (คีย์ - ค่าเขียนใน Erlang ใช้โดย Powerset)
• HBase (คีย์ - ค่าเขียนด้วยภาษาจาวาที่ใช้โดย Bing)
• ไฮเปอร์เทเบิล ( แท็บเล็ตเขียนด้วย C ++ ใช้โดย Baidu)
• Kai (คีย์ - ค่าเขียนใน Erlang)
• MemcacheDB (คีย์ - ค่าเขียนใน C ใช้โดย Reddit)
• MongoDB (เอกสารเขียนด้วย C ++, ใช้โดย Electronic Arts, Github, NY Times และ Sourceforge)
• Neo4j (กราฟ, เขียนเป็นภาษา Java, ใช้โดยมหาวิทยาลัยในสวีเดนบางแห่ง)
• Project Voldemort (คีย์ - ค่า, เขียนเป็นภาษาจาวา, ใช้โดย LinkedIn)
• Redis (คีย์ - ค่าเขียนเป็น C ใช้โดย Craigslist, Engine Yard และ Github)
• Riak (คีย์ - ค่าเขียนใน Erlang ใช้โดย Comcast และ Mochi Media)
• Ringo (คีย์ - ค่าเขียนเป็น Erlang ใช้โดย Nokia)
• Scalaris (คีย์ - ค่าเขียนใน Erlang ใช้โดย OnScale)
• Terrastore (เอกสารเขียนด้วยภาษา Java)
• ThruDB (เอกสารเขียนด้วย C ++ ใช้โดย JunkDepot.com)
• คณะรัฐมนตรีโตเกียว / โตเกียวทรราช (คีย์ - ค่าเขียนเป็น C ใช้โดย Mixi.jp (ไซต์เครือข่ายสังคมญี่ปุ่น))

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

คำถาม:

• คุณมีปัญหาเรื่องความสามารถในการปรับขนาดได้บ้างที่ใช้ศูนย์ข้อมูล NoSQL เพื่อแก้ปัญหา?
• คุณใช้ที่เก็บข้อมูล NoSQL ใด
• ฐานข้อมูลใดที่คุณใช้ก่อนที่จะเปลี่ยนเป็นที่เก็บข้อมูล NoSQL

ฉันกำลังมองหาประสบการณ์โดยตรงดังนั้นโปรดอย่าตอบถ้าคุณไม่มี

ฉันได้เปลี่ยน subproject ขนาดเล็กจาก MySQL เป็น CouchDB เพื่อให้สามารถจัดการกับโหลดได้ ผลลัพธ์ที่ได้นั้นยอดเยี่ยมมาก

ประมาณ 2 ปีที่แล้วเราได้เปิดตัวซอฟต์แวร์ที่เขียนด้วยตนเองบนhttp://www.ubuntuusers.de/ (ซึ่งอาจเป็นเว็บไซต์ชุมชน Linux Linux ที่ใหญ่ที่สุดของเยอรมัน) ไซต์นี้เขียนด้วย Python และเราได้เพิ่มมิดเดิลแวร์ WSGI ซึ่งสามารถดักจับข้อยกเว้นทั้งหมดและส่งไปยังเว็บไซต์ MySQL ขับเคลื่อนขนาดเล็กอื่นได้ เว็บไซต์ขนาดเล็กนี้ใช้แฮชเพื่อระบุข้อบกพร่องต่าง ๆ และเก็บจำนวนการเกิดและการเกิดครั้งสุดท้ายเช่นกัน

น่าเสียดายที่หลังจากเปิดตัวไม่นานเว็บไซต์ตรวจสอบย้อนกลับไม่ตอบสนองอีกต่อไป เรามีปัญหาการล็อคกับฐานข้อมูลการผลิตของเว็บไซต์หลักของเราซึ่งมีข้อยกเว้นเกือบทุกคำขอรวมถึงข้อบกพร่องอื่น ๆ อีกหลายอย่างที่เรายังไม่ได้สำรวจในระหว่างขั้นตอนการทดสอบ เซิร์ฟเวอร์คลัสเตอร์ของไซต์หลักของเราเรียกว่า traceback-logger submit page หลายครั้ง k ต่อวินาที และนั่นเป็นวิธีที่มากเกินไปสำหรับเซิร์ฟเวอร์ขนาดเล็กที่โฮสต์ตัวบันทึกการติดตามย้อนกลับ (ซึ่งเป็นเซิร์ฟเวอร์เก่าซึ่งใช้เพื่อการพัฒนาเท่านั้น)

ในเวลานี้ CouchDB ค่อนข้างเป็นที่นิยมและดังนั้นฉันจึงตัดสินใจลองและเขียน logger-logger ขนาดเล็กด้วย ตัวบันทึกใหม่ประกอบด้วยไฟล์หลามไฟล์เดียวซึ่งมีรายการข้อบกพร่องพร้อมตัวเลือกการเรียงลำดับและตัวกรองและหน้าส่ง และในพื้นหลังฉันเริ่มกระบวนการ CouchDB ซอฟต์แวร์ใหม่ตอบสนองต่อคำขอทั้งหมดอย่างรวดเร็วและเราสามารถดูรายงานข้อผิดพลาดอัตโนมัติจำนวนมากได้

สิ่งหนึ่งที่น่าสนใจคือวิธีแก้ปัญหาก่อนหน้านี้กำลังทำงานอยู่บนเซิร์ฟเวอร์เฉพาะเก่าที่ซึ่งไซต์ใหม่ของ CouchDB บนมืออื่น ๆ กำลังทำงานบนอินสแตนซ์ xen ที่ใช้ร่วมกันที่มีทรัพยากร จำกัด มากเท่านั้น และฉันไม่ได้ใช้ความแข็งแกร่งของร้านค้าคีย์ - สเกลในแนวนอน ความสามารถของ CouchDB / Erlang OTP เพื่อจัดการคำขอที่เกิดขึ้นพร้อมกันโดยไม่ต้องล็อกอะไรก็เพียงพอแล้วที่จะตอบสนองความต้องการ

ตอนนี้ตัวบันทึก CouchDB-traceback ที่เขียนอย่างรวดเร็วยังคงทำงานอยู่และเป็นวิธีที่มีประโยชน์ในการสำรวจข้อบกพร่องในเว็บไซต์หลัก อย่างไรก็ตามประมาณเดือนละครั้งฐานข้อมูลจะใหญ่เกินไปและกระบวนการ CouchDB ถูกฆ่า แต่แล้วคำสั่ง compact-db ของ CouchDB จะลดขนาดจากหลาย GB เป็น KBs อีกครั้งและฐานข้อมูลก็เริ่มทำงานอีกครั้ง (บางทีฉันควรพิจารณาเพิ่ม cronjob ที่นั่น ... 0o)

โดยสรุป CouchDB เป็นตัวเลือกที่ดีที่สุด (หรืออย่างน้อยก็เป็นทางเลือกที่ดีกว่า MySQL) สำหรับโครงการย่อยนี้และทำงานได้ดี

โครงการปัจจุบันของฉันจริง

การจัดเก็บวัตถุ 18,000 ชิ้นในโครงสร้างปกติ: 90,000 แถวใน 8 ตารางที่แตกต่างกัน ใช้เวลา 1 นาทีในการดึงและแมปไปยังโมเดลวัตถุ Java ของเรานั่นคือทุกอย่างที่มีการจัดทำดัชนีอย่างถูกต้อง ฯลฯ

จัดเก็บเป็นคู่คีย์ / ค่าโดยใช้การแสดงข้อความแบบเบา: 1 ตาราง, 18,000 แถว, 3 วินาทีเพื่อดึงข้อมูลทั้งหมดและสร้างวัตถุ Java ใหม่

ในแง่ธุรกิจ: ตัวเลือกแรกไม่เป็นไปได้ ตัวเลือกที่สองหมายถึงแอปของเราทำงาน

รายละเอียดเทคโนโลยี: ทำงานบน MySQL สำหรับทั้ง SQL และ NoSQL! การผสานกับ MySQL สำหรับการทำธุรกรรมที่ดีประสิทธิภาพและประวัติที่พิสูจน์แล้วสำหรับการไม่ทำลายข้อมูลปรับขนาดได้ดีรองรับการทำคลัสเตอร์ ฯลฯ

แบบจำลองข้อมูลของเราใน MySQL ตอนนี้เป็นเพียงฟิลด์สำคัญ (จำนวนเต็ม) และฟิลด์ "ค่า" ขนาดใหญ่: เป็นเพียงฟิลด์ TEXT ขนาดใหญ่โดยทั่วไป

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

ประโยชน์พิเศษของ (AB) ใช้ MySQL - บิตของรูปแบบของเราที่ทำงาน relationally สามารถเชื่อมโยงได้อย่างง่ายดายในการเก็บข้อมูลคีย์ / ค่าของเรา

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

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]

highscalability.comของ Todd Hoff มีความครอบคลุมอย่างมากของ NoSQL รวมถึงกรณีศึกษาบางส่วน

DBMS เชิงคอลัมน์Verticaเชิงพาณิชย์อาจเหมาะกับวัตถุประสงค์ของคุณ (แม้ว่าจะสนับสนุน SQL): มันเร็วมากเมื่อเทียบกับ DBMS เชิงสัมพันธ์แบบดั้งเดิมสำหรับเคียวรีการวิเคราะห์ ดู Stonebraker และรายงานล่าสุดของCACM ที่ตัดกัน Vertica พร้อมแผนที่ลด

อัปเดต: และCassandra ที่ได้รับการเลือกของ Twitterเหนือคนอื่น ๆ รวมถึง HBase, Voldemort, MongoDB, MemcacheDB, Redis และ HyperTable

การปรับปรุงที่ 2: Rick Cattell มีการเผยแพร่เพียงการเปรียบเทียบระบบ NoSQL หลายในHigh Performance ข้อมูลร้านค้า และ highscalability.com ใช้เวลาบนกระดาษริกเป็นที่นี่

เราย้ายข้อมูลบางส่วนจาก mysql ไปยัง mongodb ไม่มากสำหรับความสามารถในการปรับขนาด แต่เพิ่มเติมเพราะมันเหมาะสำหรับไฟล์และข้อมูลที่ไม่ใช่ตาราง

ในการผลิตเรากำลังจัดเก็บ:

• 25,000 ไฟล์ (60GB)
• "เอกสาร" อื่น ๆ อีก 130 ล้านรายการ (350GB)

ด้วยมูลค่าการซื้อขายรายวันประมาณ 10GB

ฐานข้อมูลถูกปรับใช้ในการกำหนดค่า "จับคู่" บนสองโหนด (6x450GB sas raid10) ด้วย apache / wsgi / python ไคลเอ็นต์โดยใช้ mongodb python api (pymongo) การตั้งค่าดิสก์อาจเป็น overkill แต่นั่นคือสิ่งที่เราใช้สำหรับ mysql

นอกจากปัญหาบางอย่างกับ pymongo threadpools และลักษณะการบล็อกของเซิร์ฟเวอร์ mongodb มันเป็นประสบการณ์ที่ดี

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

CouchDB: กรณีศึกษา

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

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

ฉันมีโอเพนซอร์ซลูกค้า c # redisที่ให้คุณจัดเก็บและดึงวัตถุ POCO ใด ๆ ที่มี 1 บรรทัด:

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

ที่เก็บค่าคีย์นั้นง่ายต่อการ 'ลดขนาด' เนื่องจากคุณสามารถเพิ่มเซิร์ฟเวอร์ใหม่แล้วแบ่งพาร์ติชันโหลดของคุณอย่างสม่ำเสมอเพื่อรวมเซิร์ฟเวอร์ใหม่ ที่สำคัญไม่มีเซิร์ฟเวอร์กลางที่จะจำกัดความสามารถในการขยายของคุณ (แม้ว่าคุณจะยังต้องการกลยุทธ์สำหรับการแฮชที่สอดคล้องกันเพื่อกระจายคำขอของคุณ)

ฉันคิดว่า Redis เป็น 'text text ที่ได้รับการจัดการ' บนเตียรอยด์ที่ให้การเข้าถึงที่รวดเร็วพร้อมกันและปรมาณูสำหรับลูกค้าหลาย ๆ คนดังนั้นอะไรก็ตามที่ฉันเคยใช้ไฟล์ข้อความหรือฐานข้อมูลแบบฝังสำหรับฉันตอนนี้ใช้ Redis เช่นเพื่อรับบันทึกข้อผิดพลาดการกลิ้งแบบเรียลไทม์สำหรับบริการทั้งหมดของเรา (ซึ่งเป็นงานที่ยากสำหรับเรา) ตอนนี้สามารถทำได้โดยมีเพียงไม่กี่บรรทัดโดยเพียงแค่รอข้อผิดพลาดล่วงหน้าไปยังรายการด้านเซิร์ฟเวอร์ Redis และ จากนั้นตัดรายการเพื่อเก็บเฉพาะ 1,000 รายการสุดท้ายเท่านั้นเช่น:

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);

ฉันไม่มีประสบการณ์โดยตรง แต่ฉันพบว่าบล็อกนี้น่าสนใจทีเดียว

ฉันค้นหาความพยายามในการแมปวัตถุโดเมนซอฟต์แวร์ (เช่น aSalesOrder, aCustomer ... ) กับฐานข้อมูลเชิงสัมพันธ์แบบสองมิติ (แถวและคอลัมน์) ใช้รหัสจำนวนมากเพื่อบันทึก / อัปเดตจากนั้นอีกครั้งเพื่ออินสแตนซ์วัตถุวัตถุโดเมนจากหลายตาราง . ไม่ต้องพูดถึงประสิทธิภาพการทำงานของการรวมทั้งหมดดิสก์เหล่านั้นอ่าน ... เพียงเพื่อดู / จัดการวัตถุโดเมนเช่นใบสั่งขายหรือบันทึกลูกค้า

เราได้เปลี่ยนไปใช้ Object Management Management Systems (ODBMS) มันเกินความสามารถของระบบ noSQL ที่ระบุไว้ GemStone / S (สำหรับ Smalltalk) เป็นตัวอย่างดังกล่าว มีวิธีแก้ไขปัญหา ODBMS อื่น ๆ ที่มีไดรเวอร์สำหรับหลายภาษา สิทธิประโยชน์สำหรับผู้พัฒนาที่สำคัญลำดับชั้นของคลาสของคุณจะเป็นสคีมาฐานข้อมูลของคุณคลาสย่อยและทั้งหมดโดยอัตโนมัติ เพียงใช้ภาษาเชิงวัตถุของคุณเพื่อทำให้วัตถุคงอยู่กับฐานข้อมูล ระบบ ODBMS ให้ความสมบูรณ์ของการทำธุรกรรมระดับกรดดังนั้นมันจะทำงานในระบบการเงิน

ฉันเปลี่ยนจาก MySQL (InnoDB) เป็นคาสซานดราสำหรับระบบ M2M ซึ่งโดยทั่วไปจะเก็บชุดอนุกรมของเซ็นเซอร์สำหรับอุปกรณ์แต่ละเครื่อง ข้อมูลแต่ละรายการจะถูกจัดทำดัชนีโดย (device_id, วันที่) และ (device_id, type_of_sensor, วันที่) รุ่น MySQL มีจำนวน 20 ล้านแถว

MySQL:

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

คาสซานดรา:

• ติดตั้งง่ายกว่า MySQL
• ต้องการ RAM จำนวนมาก อินสแตนซ์ 2GB ไม่สามารถทำให้มันรันในเวอร์ชันแรกได้ตอนนี้มันสามารถทำงานบนอินสแตนซ์ 1GB ได้ แต่ไม่ใช่ความคิด การให้ 8GB นั้นเพียงพอในกรณีของเรา
• เมื่อคุณเข้าใจวิธีการจัดระเบียบข้อมูลของคุณการจัดเก็บเป็นเรื่องง่าย การร้องขอมีความซับซ้อนมากขึ้นเล็กน้อย แต่เมื่อคุณได้รับมันเร็วมาก (คุณไม่สามารถทำผิดพลาดได้นอกจากคุณต้องการ)
• หากขั้นตอนก่อนหน้านี้ถูกต้องแสดงว่ามันเร็วและเร็วมาก
• ดูเหมือนว่าข้อมูลจะถูกจัดระเบียบเพื่อสำรองข้อมูล ข้อมูลใหม่ทุกรายการจะถูกเพิ่มเป็นไฟล์ใหม่ ฉันเป็นการส่วนตัว แต่มันก็ไม่ใช่เรื่องที่ดีล้างข้อมูลทุกคืนและก่อนทุกครั้งที่ปิดเครื่อง (โดยปกติจะอัพเกรด) เพื่อให้การกู้คืนใช้เวลาน้อยลงเนื่องจากเรามีบันทึกการอ่านน้อยลง มันไม่ได้สร้างไฟล์จำนวนมากที่ถูกบีบอัด
• การนำเข้าข้อมูลรวดเร็วเหมือนนรก และยิ่งโฮสต์มากเท่าไหร่คุณก็ยิ่งเร็วเท่านั้น การส่งออกและนำเข้ากิกะไบต์ของข้อมูลไม่ใช่ปัญหาอีกต่อไป
• การไม่มีสคีมาเป็นสิ่งที่น่าสนใจมากเพราะคุณสามารถทำให้ข้อมูลของคุณมีวิวัฒนาการตามความต้องการของคุณ ซึ่งอาจหมายถึงการมีข้อมูลเวอร์ชันต่าง ๆ ในเวลาเดียวกันในกลุ่มคอลัมน์เดียวกัน
• การเพิ่มโฮสต์นั้นเป็นเรื่องง่าย (ไม่เร็วนัก) แต่ฉันยังไม่ได้ทำการติดตั้งในหลายศูนย์ข้อมูล

หมายเหตุ: ฉันยังใช้elasticsearch (เน้นเอกสารตาม lucene) และฉันคิดว่าควรถือว่าเป็นฐานข้อมูล NoSQL มีการแจกจ่ายเชื่อถือได้และรวดเร็วบ่อยครั้ง (แบบสอบถามที่ซับซ้อนบางรายการสามารถทำงานได้ค่อนข้างแย่)

ฉันไม่. ฉันต้องการใช้ที่เก็บคีย์ - ค่าที่เรียบง่ายและฟรีที่ฉันสามารถโทรหาได้ แต่สิ่งนั้นไม่มีอยู่บนแพลตฟอร์ม Windows ตอนนี้ฉันใช้ Sqlite แต่ฉันต้องการใช้บางอย่างเช่น Tokyo Cabinet BerkeleyDB มี "ปัญหา" ของใบอนุญาต

อย่างไรก็ตามหากคุณต้องการใช้ระบบปฏิบัติการ Windows คุณสามารถเลือกฐานข้อมูล NoSQL ได้อย่าง จำกัด และไม่มีผู้ให้บริการ C # เสมอไป

ฉันลองใช้ MongoDB และเร็วกว่า Sqlite ถึง 40 เท่าดังนั้นบางทีฉันควรใช้มัน แต่ฉันยังคงหวังว่าจะมีวิธีแก้ปัญหาในกระบวนการอย่างง่าย

ฉันใช้ redis เพื่อจัดเก็บข้อความบันทึกในเครื่อง มันง่ายมากที่จะใช้งานและมีประโยชน์มาก Redis เป็นหินจริงๆ

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

ฉันเคยใช้ Couchbase ในอดีตและเราพบปัญหาการปรับสมดุลและโฮสต์ของปัญหาอื่น ๆ ปัจจุบันฉันใช้ Redis ในโครงการผลิตหลายแห่ง ฉันใช้redislabs.comซึ่งเป็นบริการที่ได้รับการจัดการสำหรับ Redis ซึ่งดูแลการปรับขนาด Redis clusters ของคุณ ฉันเผยแพร่วิดีโอเกี่ยวกับการคงอยู่ของวัตถุในบล็อกของฉันที่http://thomasjaeger.wordpress.comซึ่งแสดงวิธีการใช้ Redis ในรูปแบบผู้ให้บริการและวิธีการจัดเก็บวัตถุ C # ของคุณลงใน Redis ลองดูสิ.

ฉันอยากแนะนำให้ทุกคนที่อ่านข้อความนี้เพื่อลอง Couchbase อีกครั้งตอนนี้ที่ 3.0 อยู่นอกประตู มีคุณสมบัติใหม่กว่า 200 รายการสำหรับผู้เริ่มต้น ประสิทธิภาพความพร้อมใช้งานความสามารถในการปรับขยายได้และคุณสมบัติการจัดการที่ง่ายของ Couchbase Server ทำให้ฐานข้อมูลมีความยืดหยุ่นและพร้อมใช้งานสูง UI การจัดการนั้นมีอยู่แล้วภายในและ API จะค้นพบโหนดคลัสเตอร์โดยอัตโนมัติดังนั้นไม่จำเป็นต้องมี load balancer จากแอ็พพลิเคชันไปยัง DB ในขณะที่เราไม่มีบริการที่มีการจัดการในขณะนี้คุณสามารถเรียกใช้ couchbase ในสิ่งต่างๆเช่น AWS, RedHat Gears, Cloudera, Rackspace, Docker Containers เช่น CloudSoft และอีกมากมาย เกี่ยวกับการปรับสมดุลนั้นขึ้นอยู่กับสิ่งที่คุณอ้างถึงโดยเฉพาะ แต่ Couchbase ไม่ได้ปรับสมดุลโดยอัตโนมัติหลังจากความล้มเหลวของโหนดตามที่ออกแบบมา แต่ผู้ดูแลระบบสามารถตั้งค่าการ failover อัตโนมัติสำหรับความล้มเหลวของโหนดแรกและการใช้ API ของเราคุณยังสามารถเข้าถึง vbuckets จำลองสำหรับการอ่านก่อนที่จะทำให้พวกเขาใช้งานหรือใช้ RestAPI คุณสามารถบังคับใช้ failover โดยเครื่องมือการตรวจสอบ นี่เป็นกรณีพิเศษ แต่สามารถทำได้

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

1. เซิร์ฟเวอร์ Couchbase 3.0
2. คู่มือการบริหาร
3. REST API
4. คู่มือการพัฒนา

ท้ายสุดฉันขอแนะนำให้คุณดู N1QL สำหรับการสืบค้นแบบกระจาย:

1. บทแนะนำ N1QL
2. คู่มือ N1QL

ขอบคุณสำหรับการอ่านและแจ้งให้ฉันหรือผู้อื่นทราบหากคุณต้องการความช่วยเหลือเพิ่มเติม!

ออสติน

ฉันเคยใช้ Vertica มาแล้วในอดีตมันต้องอาศัยการบีบอัดแบบเสาและเร่งความเร็วในการอ่านดิสก์และพื้นที่เก็บข้อมูลที่ต่ำกว่าต้องใช้ประโยชน์จากฮาร์ดแวร์ของคุณให้มากที่สุด โหลดข้อมูลที่เร็วขึ้นและการทำงานพร้อมกันที่สูงขึ้นช่วยให้คุณสามารถให้บริการข้อมูลการวิเคราะห์แก่ผู้ใช้มากขึ้นด้วยเวลาแฝงขั้นต่ำ

ก่อนหน้านี้เรากำลังสืบค้นฐานข้อมูล Oracle ที่มีเร็กคอร์ดนับพันล้านรายการและประสิทธิภาพการทำงานนั้นเหมาะสมที่สุด ข้อความค้นหาใช้เวลา 8 ถึง 12 วินาทีในการเรียกใช้แม้จะปรับแต่งด้วย SSD แล้วก็ตาม ดังนั้นเราจึงรู้สึกว่าจำเป็นต้องใช้ฐานข้อมูลเชิงวิเคราะห์ที่เน้นการอ่านที่ได้รับการปรับปรุงให้เร็วที่สุด ด้วย Vertica Clusters ที่อยู่หลังเลเยอร์เซอร์วิสแบบลีนเราสามารถเรียกใช้ API พร้อมประสิทธิภาพรองได้

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

1. บีบอัดและเข้ารหัสข้อมูลเพื่อลดพื้นที่จัดเก็บ
2. ลดความซับซ้อนของการกระจายข้ามคลัสเตอร์ฐานข้อมูล
3. ให้ความพร้อมใช้งานสูงและการกู้คืน

Vertica ปรับฐานข้อมูลให้เหมาะสมด้วยการกระจายข้อมูลข้ามคลัสเตอร์โดยใช้ Segmentation

1. การแบ่งส่วนวางส่วนของข้อมูลบนโหนด
2. มันกระจายข้อมูลอย่างเท่าเทียมกันในทุกโหนด ดังนั้นแต่ละโหนดดำเนินการชิ้นส่วนของกระบวนการสอบถาม
3. แบบสอบถามทำงานบนคลัสเตอร์และทุกโหนดได้รับแผนแบบสอบถาม
4. ผลลัพธ์ของแบบสอบถามจะถูกรวบรวมและใช้เพื่อสร้างผลลัพธ์

สำหรับข้อมูลเพิ่มเติมโปรดดูเอกสาร Vertica ที่https://www.vertica.com/knowledgebase/