คำถามติดแท็ก nosql

ฐานข้อมูลที่เสนอโซลูชันทางเลือกให้กับฐานข้อมูล SQL (เชิงสัมพันธ์) ซึ่งสามารถเน้นเอกสารคีย์ / ค่ากราฟวัตถุ ...

1
แบบจำลองข้อมูลมีผลกระทบต่อความสามารถในการขยายและประสิทธิภาพในฐานข้อมูลที่เรียกว่า“ NoSQL” มากน้อยเพียงใด?
คุณไม่เคยมีการพูดคุยเกี่ยวกับฐานข้อมูลที่เรียกว่า "NoSQL" โดยไม่ต้องนำทฤษฎีบท CAP (ความสอดคล้องความพร้อมใช้งานพาร์ติชัน: เลือกสอง) ถ้าคุณต้องเลือกว่าระหว่าง MongoDB (Partition, Consistency) และ CouchDB (Availability, Partition) สิ่งแรกที่คุณต้องคิดคือ "ฉันต้องการข้อมูลที่ถูกต้องหรือต้องเข้าถึงตลอดเวลาหรือไม่" ฐานข้อมูลใหม่เหล่านั้นถูกจัดทำขึ้นเพื่อแบ่งพาร์ติชัน แต่ถ้าฉันทำไม่ได้ล่ะ ถ้าฉันคิดว่ามันยอดเยี่ยมมากที่มีคีย์ / ค่าคอลัมน์เอกสารฐานข้อมูลใด ๆ แทนที่จะเป็นเชิงสัมพันธ์และเพิ่งสร้างเซิร์ฟเวอร์อินสแตนซ์เดียวและไม่เคยทิ้งมัน ในกรณีนั้นฉันจะไม่มีทั้งความพร้อมใช้งานและความสอดคล้องใช่ไหม MongoDB ไม่จำเป็นต้องทำซ้ำสิ่งใดดังนั้นจึงสามารถใช้งานได้ และ CouchDB จะมีแหล่งข้อมูลเพียงแหล่งเดียวดังนั้นมันจึงค่อนข้างสอดคล้องกัน นั่นหมายความว่าในกรณีนี้ MongoDB และ CouchDB จะมีความแตกต่างเล็กน้อยในแง่ของการใช้งาน? ดียกเว้นประสิทธิภาพของหลักสูตร API และ al แต่นั่นจะเป็นการเลือกระหว่าง PostgreSQL และ MySQL มากกว่าการมีข้อกำหนดที่แตกต่างกันสองชุด ฉันอยู่ตรงนี้หรือไม่ ฉันสามารถเปลี่ยนฐานข้อมูล AP หรือ CP เป็น AC …

4
สกีมาฐานข้อมูลมีการโยกย้ายปัญหาในสภาพแวดล้อมการผลิตหรือไม่
ในการอภิปรายเกี่ยวกับฐานข้อมูล NoSQL vs SQL บางครั้งฉันได้ยินว่า บริษัท ต้องการใช้ฐานข้อมูลแบบไม่มี schema ของ schemaless เนื่องจากเป็นปัญหาในการโยกย้ายสคีมาเป็นเวอร์ชันใหม่ แต่นั่นเป็นปัญหาใหญ่จริง ๆ เมื่อทำการอัพเกรด ฐานข้อมูลเชิงสัมพันธ์นั้นแย่สำหรับการดำเนินการดังกล่าวหรือไม่? ฉันอ่านโพสต์บล็อกนี้ในบล็อก MongoDB: ทำไมต้อง Schemaless

1
ฉันจะแสดงแผนภาพสคีมาของฐานข้อมูล MongoDB ของฉันได้อย่างไร
ฉันมีฐานข้อมูล MongoDB ที่ฉันต้องการเอกสารการออกแบบสคีมาอย่างถูกต้อง ฉันรู้ว่า MongoDB เป็นฐานข้อมูล NoSQL และเป็น schemaless ตามธรรมชาติ แต่ฉันบังคับใช้ schema ผ่านแอปพลิเคชันของฉันและฉันต้องการที่จะเป็นตัวแทนในวิธีที่ดีกว่าการพิมพ์findOne()ผลลัพธ์ ฉันเห็นคนจำนวนมากที่ใช้ ER หรือ UML แต่ฉันไม่รู้สึกว่าเป็นแนวคิดที่ถูกต้องในการแสดงฐานข้อมูล NoSQL ของฉันเป็นฐานข้อมูลเชิงสัมพันธ์หรืออย่างน้อยก็ดูแปลก ตัวอย่างการใช้ UML: MongoDB: จะแสดงไดอะแกรมสคีมาในวิทยานิพนธ์ได้อย่างไร ฉันคิดว่าผู้คนจะใช้โมเดลที่แตกต่างกัน ฉันค้นหาแล้วและไกลที่สุดเท่าที่ฉันเคยเห็นคือMongoVUEที่เสนอมุมมองแบบต้นไม้ที่ดีเพื่อทำความเข้าใจกับสคีมา แต่มันไม่เป็นมิตรกับเครื่องพิมพ์ มีอย่างอื่นที่ฉันขาดหายไปสำหรับโลก NoSQL หรือไม่? หรือฉันควรพักผ่อนและติดกับ UML แบบดั้งเดิม?

5
ทีมของฉันกลัวฐานข้อมูลเชิงสัมพันธ์ที่มีความสัมพันธ์กับต่างประเทศและฉันไม่เข้าใจว่าทำไม
ฉันค่อนข้างใหม่นอกมหาวิทยาลัยดังนั้นความคุ้นเคยกับฐานข้อมูลเชิงสัมพันธ์ส่วนใหญ่มาจากหลักสูตรฐานข้อมูลของฉันซึ่งไม่มีอะไรใน BCNF หรือ 3NF เป็นการเลียนแบบ แน่นอนว่าปลายด้านหนึ่งของสุดขั้ว แต่ทีมของฉันในที่ทำงานดูเหมือนจะนำไปสู่จุดจบที่ตรงกันข้ามอย่างสมบูรณ์ ใน microservice db schemas ของเราเอนทิตีมักจะมีมากกว่าหนึ่งตาราง สิ่งใดก็ตามที่คุณต้องการทำให้เป็นปกติในตารางอื่นจะถูกเก็บไว้ในคอลัมน์ json หากภายหลังพบว่าคุณสมบัติอย่างใดอย่างหนึ่งใน json นี้ต้องถูกสอบถามคอลัมน์ใหม่จะถูกเพิ่มและข้อมูลจะถูกเก็บไว้ในทั้งสองแห่ง (ใช่ในคอลัมน์ที่ต่างกันสองแห่งในตารางเดียวกัน) ในหลายกรณีคอลัมน์ json เหล่านี้มีข้อได้เปรียบอย่างแน่นอน หากคุณไม่จำเป็นต้องสืบค้นข้อมูลนั้นและหากคุณไม่จำเป็นต้องทำการเปลี่ยนแปลงข้อมูลข้างเดียว (ซึ่งเป็นสิ่งที่คุณไม่สามารถคาดการณ์ได้อย่างชัดเจน) นั่นไม่ใช่ความคิดที่ไม่ดี บวกกับบริการหลายอย่างของเราที่ไม่เห็นเซิร์ฟเวอร์หรือโฮสต์อยู่บนเครื่องที่มีเนื้อที่ดิสก์ลามกอนาจารสำหรับสิ่งที่พวกเขาต้องการดังนั้นการทำสำเนาข้อมูลจึงไม่ใช่ปัญหาใหญ่ (ถึงแม้ว่าสิ่งที่ฉันมักจะต้องการหลีกเลี่ยงปรัชญา) ขณะนี้เรากำลังสร้างบริการที่ตรงกับกฎตามชุดเงื่อนไขที่พวกเขาเป็นเจ้าของแล้วดำเนินการชุดของการกระทำที่เกี่ยวข้องกับกฎเหล่านั้นเมื่อกฎเป็นจริง (เช่นเงื่อนไขทั้งหมดเป็นจริง) ทีมงานย่อยของฉันที่สร้างบริการนี้ในทันทีส่วนใหญ่เชื่อว่ามีประโยชน์อย่างมากในการทำให้การดำเนินการและเงื่อนไขเป็นปกติอยู่ห่างจากกฎในสคีมา เห็นได้ชัดว่าตารางเหล่านี้รักษาความสัมพันธ์กับต่างประเทศที่สำคัญกับรหัสกฎ จากมุมมองของเราเราสามารถหลีกเลี่ยงการทำซ้ำข้อมูลในเงื่อนไขที่ทำให้เรามั่นใจได้ว่าพวกเขาจะได้รับการประเมินเพียงครั้งเดียวและเป็นเรื่องง่ายที่จะหาเงื่อนไขและกฎที่เราต้องการเมื่อต้องการโดยไม่ต้องดึงกฎออกทุกครั้ง การพูดกับหนึ่งในวิศวกรหลักของเราในวันนี้เขาพยายามผลักฉันให้ห่างจากสคีมานี้ การพยายามโต้แย้งในทุก ๆ ด้านที่เราไม่ต้องการจริง ๆ มันจะทำให้เกิดปัญหาด้านประสิทธิภาพในอนาคตโดยอ้างอิงจากหินก้อนเดียวที่เราเป็นเจ้าของนั่นคือการเลียนแบบการออกแบบ เขาอ้างถึงสิ่งที่เราทำในฐานะ "วิธีเก่า" และโต๊ะแบนที่มี json เป็น "วิธีใหม่" เขาแย้งว่าในสถานที่ที่ฉันต้องการอะตอมมิกเราไม่ต้องการมันและแทนที่จะเป็นแบบสอบถามเราควรทำหลายอย่างในความทรงจำ นี่คือหลักการออกแบบที่บริการหลายอย่างของเราปฏิบัติตามในขณะนี้ เราไม่คาดหวังว่าปริมาณข้อมูลของเราจะเติบโตอย่างมีนัยสำคัญซึ่งจะทำให้การสืบค้นของเรารวดเร็ว สิ่งที่เราคาดหวังคือเวลาที่ใช้ในการประเมินกฎและการดำเนินการ ฉันเข้าใจว่าฐานข้อมูลเชิงสัมพันธ์ที่ไม่ได้เป็นที่นิยมมากขึ้นในช่วงไม่กี่ปีที่ผ่านมา แต่แม้ในขณะที่ค้นหาข้อมูลเกี่ยวกับผลการปฏิบัติงานของความสัมพันธ์กับต่างประเทศที่สำคัญฉันไม่เห็นข้อมูลจำนวนมากที่ทำให้คดีของเขา ฉันคิดว่าพวกเขามีแนวโน้มที่จะแนะนำการทำธุรกรรมขนาดใหญ่ซึ่งอาจทำให้เกิดปัญหา …

4
การจัดเก็บข้อมูลแบบกรัม
ฉันหวังว่าจะระดมสมองเล็กน้อยเกี่ยวกับเรื่องการจัดเก็บข้อมูลn -gram ในโครงการของฉันฉันพยายามในการแก้ปัญหาทางภาษาที่ฉันรู้ทั้งหมด ( nรายการ -1) ข้อมูลและต้องการที่จะคาดเดาสถิติของฉันnใช้สอดแทรกเชิงเส้นมากกว่าที่บังคับใช้ทั้งหมดn -grams (ใช่มีตัวแท็กเกอร์ที่กำหนดแท็กให้กับคำที่รู้จักตามพจนานุกรมและต้นไม้ต่อท้ายที่พยายามเดาชนิดคำสำหรับคำที่ไม่รู้จัก; องค์ประกอบn -gram ที่กล่าวถึงที่นี่จะได้รับมอบหมายด้วยการแก้ไขความคลุมเครือ) วิธีการเริ่มต้นของฉันคือการเก็บข้อมูลn -grams (สำหรับn = 1..3 ที่สังเกตได้ทั้งหมดคือ monogram, bigram, trigram) ในฐานข้อมูล SQL ที่เกี่ยวข้องและเรียกมันต่อวัน แต่ข้อกำหนดของโครงการของฉันอาจเปลี่ยนเป็นความยาวเวกเตอร์อื่น ๆ ( n ) และฉันต้องการให้แอปพลิเคชันของฉันปรับให้เหมาะกับ 4 กรัมโดยไม่ต้องทำงานมาก (อัปเดตสคีมาอัปเดตรหัสแอปพลิเคชัน ฯลฯ ); นึกคิดฉันจะบอกให้แอปพลิเคชันของฉันทำงานด้วย 4 กรัมในขณะนี้โดยไม่ต้องเปลี่ยนรหัสมาก (หรือเลย) และฝึกอบรมข้อมูลจากแหล่งข้อมูลที่กำหนด เพื่อสรุปข้อกำหนดทั้งหมด: ความสามารถในการเก็บข้อมูลn -gram (เริ่มแรกสำหรับn = {1, 2, 3} ความสามารถในการเปลี่ยนชนิดของn -grams …

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

3
แหล่งข้อมูลใดดีที่สุดสำหรับสถานการณ์ของฉัน
ฉันกำลังทำงานกับแอปพลิเคชันที่เกี่ยวข้องกับการเรียกใช้คิวรีแบบเลือกใช้ / อัปเดตในฐานข้อมูล ฉันมีตารางฐาน (A) ซึ่งจะมีระเบียนประมาณ 500 รายการสำหรับหนึ่งวัน และสำหรับผู้ใช้ทุกคนในระบบรูปแบบของเอนทิตีนี้จะถูกสร้างขึ้นตามการตั้งค่าบางอย่างของผู้ใช้และพวกเขาจะถูกเก็บไว้ในตารางอื่น (B) ทำได้โดยงาน cron ที่ทำงานตอนเที่ยงคืนทุกวัน ดังนั้นหากมี 10,000 ผู้ใช้และ 500 บันทึกในตาราง A จะมีระเบียน 5M ในตาราง B สำหรับวันนั้น ฉันมักจะเก็บข้อมูลเป็นเวลาหนึ่งวันในตารางเหล่านี้และในเวลาเที่ยงคืนฉันจะเก็บข้อมูลประวัติเพื่อ HBase การตั้งค่านี้ทำงานได้ดีและฉันไม่มีปัญหาด้านประสิทธิภาพมาก่อน มีการเปลี่ยนแปลงข้อกำหนดทางธุรกิจเมื่อไม่นานมานี้และตอนนี้คุณลักษณะบางอย่างในตารางฐาน A (สำหรับ 15 - 20 บันทึก) จะเปลี่ยนทุก ๆ 20 วินาทีและขึ้นอยู่กับว่าฉันต้องคำนวณค่าบางอย่างสำหรับบันทึกชุดรูปแบบทั้งหมดในตาราง B สำหรับ ผู้ใช้ทั้งหมด. แม้ว่าจะมีการเปลี่ยนแปลงเรคคอร์ดหลักเพียง 20 รายการ แต่ฉันต้องทำการคำนวณใหม่และอัปเดตระเบียนผู้ใช้ 200,000 รายการซึ่งใช้เวลามากกว่า 20 วินาทีจากนั้นการอัปเดตครั้งต่อไปก็เกิดขึ้นในที่สุดจึงทำให้คิวรี Select …

7
เอนทิตีที่ซ้อนกันและการคำนวณเกี่ยวกับคุณสมบัติของเอนทิตีใบไม้ - วิธี SQL หรือ NoSQL
ฉันกำลังทำงานในโครงการงานอดิเรกที่เรียกว่าการจัดการเมนู / สูตร นี่คือลักษณะที่หน่วยงานของฉันและความสัมพันธ์ของพวกเขามีลักษณะ NutrientมีคุณสมบัติCodeและValue IngredientมีคอลเลกชันของNutrients A Recipeมีคอลเล็กชันIngredientsและบางครั้งสามารถมีคอลเล็กชันอื่นได้recipes A Mealได้รวบรวมRecipesและIngredients A Menuมีคอลเล็กชันของMeals ความสัมพันธ์สามารถอธิบายได้ว่า ในหน้าใดหน้าหนึ่งสำหรับเมนูที่เลือกฉันจำเป็นต้องแสดงข้อมูลสารอาหารที่มีประสิทธิภาพซึ่งคำนวณจากส่วนประกอบ (อาหารสูตรอาหารส่วนผสมและสารอาหารที่เกี่ยวข้อง) ณ ตอนนี้ฉันกำลังใช้ SQL Server เพื่อจัดเก็บข้อมูลและฉันกำลังนำทางลูกโซ่จากรหัส C # ของฉันเริ่มจากอาหารแต่ละมื้อของเมนูแล้วรวบรวมค่าสารอาหาร ฉันคิดว่านี่ไม่ใช่วิธีที่มีประสิทธิภาพเนื่องจากการคำนวณนี้กำลังทำทุกครั้งที่มีการร้องขอหน้าเว็บและมีการเปลี่ยนแปลงองค์ประกอบในบางครั้ง ฉันคิดเกี่ยวกับการให้บริการพื้นหลังที่รักษาตารางที่เรียกว่า MenuNutrients ( {MenuId, NutrientId, Value}) และจะเติม / อัปเดตตารางนี้ด้วยสารอาหารที่มีประสิทธิภาพเมื่อมีองค์ประกอบใด ๆ (Meal, Recipe, Ingredient) เปลี่ยนแปลง ฉันรู้สึกว่า GraphDB เหมาะสำหรับความต้องการนี้ แต่การได้รับ NoSQL ของฉันมี จำกัด ฉันต้องการที่จะรู้ว่าสิ่งที่เป็นทางเลือกวิธีการแก้ปัญหา / แนวทางในการแสดงสารอาหารของเมนูที่กำหนด หวังว่าคำอธิบายของฉันเกี่ยวกับสถานการณ์จะชัดเจน

2
วิธีการออกแบบสกีมาฐานข้อมูล NoSql อย่างถูกต้อง? [ปิด]
ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังว่าคำตอบจะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน8 ปีที่ผ่านมา ฉันต้องการเรียนรู้เพิ่มเติมเกี่ยวกับฐานข้อมูล NoSQL ดังนั้นฉันจึงเลือกสร้างโครงการใหม่ตั้งแต่เริ่มต้นเพื่อจัดการผลฟุตบอล ในฐานข้อมูลเชิงสัมพันธ์แบบดั้งเดิมของฉันฉันมีการแข่งขันทีมผลการแข่งขันและตารางการแข่งขัน เห็นได้ชัดว่าเกี่ยวข้องกันทั้งหมด สิ่งที่อาจเป็นวิธีที่ดีสำหรับการออกแบบโครงการเช่นนี้โดยใช้วิธี NoSQL แทน

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

6
MongoDB เป็นตัวเลือกที่ถูกต้องในกรณีของฉันหรือไม่? [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน6 ปีที่ผ่านมา ฉันจะสร้างโปรเจ็กต์แรกของฉันใน Rails ซึ่งประกอบด้วยในเว็บแอปที่ประกอบด้วย 3 ส่วนหลัก: ส่วนคงที่ที่ไม่มีการใช้ฐานข้อมูล ส่วนการลงทะเบียนผู้ใช้ซึ่งจะต้องใช้ฐานข้อมูลและฉันสามารถใช้ MySQL ได้เนื่องจากแถวของผู้ใช้แต่ละคนจะมีเขตข้อมูลเดียวกัน "แอป" ที่ผู้ใช้จะสามารถสร้างจัดการแก้ไข ... รายการในคอลเล็กชันและแบ่งปันกับผู้ใช้รายอื่น จะมีหลายประเภทรายการและแต่ละประเภทจะมีตัวเลือกต่างกันเช่นฉันอาจมีรายการ "วิดีโอ" พร้อมตัวเลือกต่อไปนี้: รหัส user_id collection_id หัวข้อ แพลตฟอร์ม (ถ้าฝัง) URL (ถ้าฝัง) ชื่อไฟล์ (หากโฮสต์บนแอปของฉัน) ขนาดไฟล์ (id โฮสต์บนแอปของฉัน) และรายการ "แผนที่": รหัส user_id collection_id หัวข้อ แพลตฟอร์ม (แผนที่ google, แผนที่ …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.