เหตุผลที่ดีที่ไม่ใช้ฐานข้อมูลเชิงสัมพันธ์?

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

ไฟล์ข้อความธรรมดาในระบบไฟล์

• ง่ายมากในการสร้างและแก้ไข
• ง่ายสำหรับผู้ใช้ที่จะจัดการด้วยเครื่องมือง่ายๆ (เช่นโปรแกรมแก้ไขข้อความ grep และอื่น ๆ )
• การจัดเก็บที่มีประสิทธิภาพของเอกสารไบนารี

ไฟล์ XML หรือ JSON บนดิสก์

• ข้างต้น แต่มีความสามารถอีกเล็กน้อยในการตรวจสอบโครงสร้าง

ไฟล์สเปรดชีต / CSV

• รูปแบบที่ง่ายมากสำหรับผู้ใช้ทางธุรกิจที่จะเข้าใจ

การโค่นล้ม (หรือระบบการควบคุมเวอร์ชันของดิสก์ที่คล้ายกัน)

• การสนับสนุนที่ดีมากสำหรับการกำหนดเวอร์ชันของข้อมูล

Berkeley DB (โดยทั่วไปเป็น hashtable ที่ใช้ดิสก์)

• แนวคิดง่ายมาก (เพียงคีย์ / ค่าที่ไม่ได้พิมพ์)
• ค่อนข้างเร็ว
• ไม่มีค่าใช้จ่ายในการบริหาร
• รองรับธุรกรรมที่ฉันเชื่อ

ฐานข้อมูลที่ง่ายของ Amazon

• ฉันเชื่อเหมือน Berkeley DB แต่เป็นเจ้าภาพ

App Engine Datastore ของ Google

• โฮสต์และปรับขนาดได้อย่างมาก
• การจัดเก็บคีย์ - ค่าเอกสาร (เช่นตัวแบบข้อมูลยืดหยุ่น)

CouchDB

• โฟกัสเอกสาร
• จัดเก็บง่ายของข้อมูลตามกึ่งโครงสร้าง / เอกสาร

คอลเลกชันภาษาดั้งเดิม (เก็บไว้ในหน่วยความจำหรือต่อเนื่องบนดิสก์)

• การรวมภาษาที่แน่นมาก

เอ็นจินการจัดเก็บแบบกำหนดเอง (เขียนด้วยมือ)

• อาจมีประสิทธิภาพสูงมากในการใช้เคสที่จำเป็น

ฉันไม่สามารถรับรู้อะไรเกี่ยวกับพวกเขาได้มากมาย แต่คุณอาจต้องการตรวจสอบระบบฐานข้อมูลเชิงวัตถุด้วย

คำตอบของ Matt Sheppard นั้นยอดเยี่ยม (mod up) แต่ฉันจะคำนึงถึงปัจจัยเหล่านี้เมื่อคิดถึงแกนหมุน:

1. โครงสร้าง: เห็นได้ชัดว่ามันแตกเป็นชิ้น ๆ หรือคุณกำลังทำการแลกเปลี่ยนหรือไม่?
2. การใช้งาน: จะวิเคราะห์ / ดึงข้อมูล / grokked ได้อย่างไร?
3. อายุการใช้งาน: ข้อมูลมีประโยชน์นานเท่าใด
4. ขนาด: มีข้อมูลเท่าใด

ข้อดีอย่างหนึ่งของไฟล์ CSV ใน RDBMS คือสามารถย่อและย้ายไปที่เครื่องอื่นได้ เราถ่ายโอนข้อมูลจำนวนมากและทุกอย่างก็ง่ายพอที่เราจะใช้ไฟล์ CSV ขนาดใหญ่หนึ่งไฟล์และสคริปต์ง่าย ๆ โดยใช้เครื่องมือเช่น rsync เพื่อลดความซ้ำซ้อนในไฟล์ CSV ใหญ่คุณสามารถใช้สิ่งที่ต้องการYAML ฉันไม่แน่ใจว่าฉันจะเก็บอะไรเช่น JSON หรือ XML ยกเว้นว่าคุณมีข้อกำหนดด้านความสัมพันธ์ที่สำคัญ

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

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

หมายเหตุฉันคุ้นเคยกับการคิดขนาดใหญ่ขึ้น

ระบบไฟล์ของ prety นั้นมีประโยชน์สำหรับการจัดเก็บข้อมูลไบนารีซึ่งไม่สามารถทำงานได้ดีในฐานข้อมูลเชิงสัมพันธ์

ลอง Prevayler: http://www.prevayler.org/wiki/ Prevayler เป็นทางเลือกแทน RDBMS ในเว็บไซต์มีข้อมูลเพิ่มเติม

หากคุณไม่ต้องการกรดคุณอาจไม่จำเป็นต้องมีค่าใช้จ่ายของ RDBMS ดังนั้นตรวจสอบว่าคุณต้องการที่แรก คำตอบที่ไม่ใช่ RDBMS ส่วนใหญ่ที่ให้ไว้ที่นี่ไม่ได้จัดเตรียมกรด

เอ็นจินการจัดเก็บแบบกำหนดเอง (เขียนด้วยมือ) / อาจมีประสิทธิภาพสูงมากในกรณีที่จำเป็นต้องใช้

http://www.hdfgroup.org/

หากคุณมีชุดข้อมูลขนาดใหญ่แทนที่จะใช้ชุดของคุณเองคุณอาจใช้ HDF รูปแบบข้อมูลลำดับชั้น

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

HDF รองรับหลายรุ่นข้อมูลที่แตกต่างกันรวมถึงอาร์เรย์หลายมิติภาพแรสเตอร์และตาราง

นอกจากนี้ยังมีลำดับชั้นเช่นระบบไฟล์ แต่ข้อมูลจะถูกเก็บไว้ในไฟล์ไบนารีมายากล

HDF5 เป็นชุดที่ทำให้สามารถจัดการชุดข้อมูลขนาดใหญ่และซับซ้อนได้

คิดถึง petabytes ของ NASA / JPL data sensing remote

G'day,

กรณีหนึ่งที่ฉันนึกได้คือเมื่อข้อมูลที่คุณกำลังสร้างแบบจำลองไม่สามารถแสดงได้อย่างง่ายดายในฐานข้อมูลเชิงสัมพันธ์

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

ฉันเกือบทั้งหมดของกรณีเหล่านี้มีการใช้OO DBไม่ว่าจะเป็นผลิตภัณฑ์เชิงพาณิชย์หรือระบบที่ม้วนตัวเองซึ่งช่วยให้สามารถสืบทอดวัตถุได้

ฉันทำงานกับแอปพลิเคชั่นตรวจสอบ 3G สำหรับ บริษัท ขนาดใหญ่ที่จะยังคงไม่ระบุชื่อ แต่มีโลโก้เป็นคราบไวน์แดง (-: และพวกเขาใช้ OO DB เช่นนี้เพื่อติดตามคุณลักษณะต่าง ๆ ทั้งหมดสำหรับเซลล์แต่ละเซลล์ภายใน เครือข่าย

การซักถามของฐานข้อมูลดังกล่าวกระทำโดยใช้เทคนิคที่เป็นกรรมสิทธิ์ซึ่งปกติแล้วจะปราศจาก SQL

HTH

เสียงเชียร์

ปล้น

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

ในบางกรณี (ตัวอย่างเช่นข้อมูลตลาดการเงินและการควบคุมกระบวนการ) คุณอาจจำเป็นต้องใช้ฐานข้อมูลแบบเรียลไทม์มากกว่า RDBMS ดูลิงค์วิกิ

มีเครื่องมือ RAD ชื่อJADEเขียนเมื่อสองสามปีก่อนที่มี OODBMS ในตัว แปลงก่อนหน้าของเครื่องยนต์ DB ยังรองรับ Digitalk Smalltalk หากคุณต้องการตัวอย่างการสร้างแอปพลิเคชันโดยใช้กระบวนทัศน์ที่ไม่ใช่ RDBMS นี่อาจเป็นการเริ่มต้น

ผลิตภัณฑ์ OODBMS อื่น ๆ ได้แก่Objectivity , GemStone (คุณจะต้องใช้VisualWorks Smalltalk ในการรันเวอร์ชัน Smalltalk แต่ยังมีรุ่น java ด้วย) นอกจากนี้ยังมีโครงการวิจัยโอเพนซอร์ซในพื้นที่นี้ - EXODUS และ SHORE สืบเชื้อสายมาจากใจ

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

OODBMS เหมาะที่สุดสำหรับการใช้งานที่มีโครงสร้างข้อมูลหลักที่แสดงได้ดีที่สุดเป็นกราฟของโหนดที่เชื่อมต่อถึงกัน ฉันเคยบอกว่าแอพพลิเคชั่น OODBMS ที่เป็นแก่นสารคือ Multi-User Dungeon (MUD) ที่ห้องจะมีอวตารของผู้เล่นและวัตถุอื่น ๆ

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

สิ่งอื่น ๆ ที่ไม่เหมาะกับ RDBMS ก็คือโครงสร้างข้อมูลแบบลำดับชั้นและฉันเดาว่าข้อมูลเชิงพื้นที่และแบบจำลอง 3 มิติไม่ใช่เรื่องง่ายที่จะทำงานด้วย

บริการเช่นAmazon S3มีรูปแบบการจัดเก็บข้อมูลที่ง่ายขึ้น (คีย์ -> ค่า) ที่ไม่รองรับ SQL ความยืดหยุ่นเป็นกุญแจสำคัญ

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

มีหลายวิธีในการจัดเก็บข้อมูล - แม้ "relational databse" ครอบคลุมช่วงของทางเลือกจากไลบรารีของรหัสอย่างง่ายที่จัดการไฟล์ภายในเครื่อง (หรือไฟล์) ราวกับว่ามันเป็นฐานข้อมูลเชิงสัมพันธ์บนพื้นฐานผู้ใช้คนเดียวผ่าน ระบบที่ใช้ไฟล์มากกว่าที่สามารถจัดการผู้ใช้หลายคนเพื่อเลือกระบบที่ใช้ "เซิร์ฟเวอร์" ที่ร้ายแรง

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

สำหรับเรานั่นคือเรากำลังจะใช้สิ่งที่จะทำ SQL (MS เสนอชุดเครื่องมือที่เรียกใช้จาก. DLL เพื่อทำสิ่งที่ผู้ใช้คนเดียวตลอดจนถึงเซิร์ฟเวอร์องค์กรและพวกเขาพูด SQL เดียวกัน (ด้วยข้อ จำกัด ที่ส่วนล่างสุด)) หรือเราจะใช้ XML เป็นรูปแบบเพราะ (สำหรับเรา) การใช้คำฟุ่มเฟือยนั้นไม่ค่อยมีปัญหา

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

Murph

หนึ่งอาจต้องการพิจารณาการใช้เซิร์ฟเวอร์ LDAP แทนฐานข้อมูล SQL แบบดั้งเดิมหากข้อมูลแอปพลิเคชันมีการเน้นคีย์ / ค่าอย่างมากและเป็นลำดับชั้นในลักษณะ

ไฟล์ BTree มักเร็วกว่าฐานข้อมูลเชิงสัมพันธ์ SQLite มีอยู่ในนั้นเป็นห้องสมุด BTree ซึ่งอยู่ในโดเมนสาธารณะ (เช่นเดียวกับใน 'โดเมนสาธารณะ' อย่างแท้จริงไม่ได้ใช้คำว่าหลวม)

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

ฐานข้อมูลข้อความแบบเต็มซึ่งสามารถสอบถามกับตัวดำเนินการใกล้เคียงเช่น "ภายใน 10 คำ" เป็นต้น

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

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

นอกจากนี้: * สถานการณ์ในตัว - โดยปกติจะต้องใช้บางสิ่งบางอย่างที่เล็กกว่านี้และใช้ RDBMS แบบเต็ม Db4oเป็น ODB ที่สามารถใช้งานได้ง่ายในกรณีดังกล่าว * การพัฒนาอย่างรวดเร็วหรือพิสูจน์แนวคิด - ที่คุณต้องการมุ่งเน้นไปที่ธุรกิจและไม่ต้องกังวลกับชั้นความเพียร

ทฤษฎีบท CAPอธิบายอย่างกระชับ SQL ส่วนใหญ่ให้ "Strong Consistency: ไคลเอนต์ทั้งหมดเห็นมุมมองเดียวกันแม้จะมีการปรับปรุง"

KISS: ทำให้มันเล็กและเรียบง่าย

ฉันจะเสนอ RDBMS :) หากคุณไม่เคยมีปัญหากับการตั้งค่า / การจัดการไปสำหรับ SQLite สร้างขึ้นใน RDBMS พร้อมรองรับ SQL อย่างเต็มรูปแบบ มันยังช่วยให้คุณสามารถเก็บข้อมูลประเภทใดก็ได้ในคอลัมน์ใดก็ได้

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

เกี่ยวกับการค้นหาข้อความแบบเต็ม: SQLite มีโมดูลสำหรับการค้นหาข้อความแบบเต็มเช่นกัน

เพียงแค่สนุกกับอินเทอร์เฟซมาตรฐานกับข้อมูลของคุณ :)

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

Hadoop นอกจากนี้ยังมีการดำเนินการของไฟล์ระบบของ Googleที่เรียกว่าHadoop Distributed ระบบไฟล์

ฉันขอแนะนำ Lua เป็นทางเลือกแทนการจัดเก็บข้อมูลแบบ SQLite

เพราะ:

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

นี่คือตัวเลือก "ชุดภาษาดั้งเดิม" ของคำตอบที่ยอมรับ หากคุณใช้ C / C ++ เป็นระดับแอปพลิเคชั่นมันมีความเหมาะสมอย่างยิ่งที่จะโยน Lua engine (ไบนารีขนาด 100kB) เพื่อการอ่าน configs / data หรือเขียนมันออกมา