การใช้ฐานข้อมูลเชิงสัมพันธ์เทียบกับอ็อบเจ็กต์ JSON สำหรับข้อมูลเหตุการณ์ / กิจกรรม

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

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

เหตุการณ์ดนตรีสด (อธิบายแบบเต็มโดยใช้สคีมา JSON ที่ด้านล่างของคำถามนี้) เป็นวัตถุที่เก็บข้อมูลเช่นสถานที่ที่จะจัดกิจกรรมเวลา / วันที่ของเหตุการณ์และค่าใช้จ่ายของเหตุการณ์ วัตถุเหตุการณ์ดนตรีสดมีทั้งแบบหนึ่งต่อหนึ่ง (เหตุการณ์ -> ชื่อเหตุการณ์ -> คำอธิบาย) และแบบตัวต่อตัว (เหตุการณ์ -> สถานที่จัดงาน, กิจกรรม -> วันที่, กิจกรรม -> ประเภทตั๋ว ) ความสัมพันธ์ นอกจากนี้วัตถุเหตุการณ์สามารถมีหนึ่งรหัสนักแสดงหรือมากกว่าซึ่งลิงก์ไปยังวัตถุนักแสดง วัตถุนักแสดงจัดเก็บข้อมูลเกี่ยวกับนักดนตรีที่กำลังแสดงในการแสดงดนตรีสด

ข้อมูลจะถูกสอบถามโดยผู้ใช้ที่ใช้ง่าย ("Find me events with 'x' name") และ complex ("Find me events ด้วยแนวเพลง 'x' และ 'y' ภายในรัศมี 'z' จากปัจจุบันของฉัน การค้นหา ") ข้อมูลจะถูกส่งโดยผู้ใช้โดยใช้แบบฟอร์มบนเว็บ

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

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

{
    "event": {
        "eventID":{
            "type":"string"
        },  
        "eventType":{
            "type":"array",
            "eventTypeItem":{
                "type":"string"
            }
        },
        "eventName":{
            "type":"string"
        },      
        "eventDescription":{
            "type":"string"
        },
        "eventVenueList":{
            "type":"array",
            "eventVenueListID":{
                "type":"integer"
            }
        },
        "eventURL":{
            "type":"string"
        },
        "eventTwitter":{
            "type":"string"
        },
        "eventFB":{
            "type":"string"
        },
        "eventInstagram":{
            "type":"string"
        },
        "eventEmail":{
            "type":"string",
            "format":"email"
        },
        "eventContactPerson":{
            "type":"string"
        },
        "eventDoorTime": {
            "type":"string",
            "format":"date-time"
        },  
        "eventPerformerIDList":{
            "type":"array",
            "liveMusicPerformerID":{
                "type":"integer"
            }
        },  
        "eventSetList":{
            "type":"array",
            "eventPerformerID":{
                "type":"integer"
            },
            "eventPerformerStartTime":{
                "type":"string",
                "format":"date-time"
            },
            "eventPerformerEndTime":{
                "type":"string",
                "format":"date-time"
            }                                   
        },
        "eventDateList": {
            "type":"array",
            "eventDateItem": {
                "type":"string",
                "format":"date-time"
            }   
        },
        "eventDateStartTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventDateEndTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventTicket":{ 
            "type":"array",
            "eventTicketType":{
                "type":"string" 
            },
            "eventTicketLowPrice":{
                "type":"number"
            },
            "eventTicketHighPrice":{
                "type":"number" 
            },
            "eventDatesAdvancePrice": {
                "type":"number"
            }   
        }
    },  
    "performer": {
        "performerID": {
            "type":"integer"
        },
        "performerType": {
            "type":"string"
        },
        "performerName": {
            "type":"string"
        },
        "performerAlternateName": {
            "type":"array",
            "performerAlterateNameItem":{
                "type":"string"
            }
        },
        "performerGenreList": {
            "type":"array",
            "performerGenreItem":{
                "type":"string"
            }
        },
        "performerURL": {
            "type":"string"
        }                                       
    }
}   

ฉันคิดว่าคำถามของคุณจะลดลงอย่างมาก: เมื่อใดที่ฉันควรใช้วิธี NoSQL เทียบกับ RDBMS คุณตัดสิน JSON ก่อนกำหนด (การตัดสินใจ NoSQL-ish) อาจเป็นเพราะคุณมีผู้บริโภค Ajax

คำตอบที่แน่นอนถึงเวลาที่จะใช้แนวทาง NoSQL กับ RDBMS นั้นเกี่ยวกับประเภทของข้อมูลที่คุณทำงานด้วยและสิ่งที่ผู้บริโภคคาดหวัง หากข้อมูลของคุณมีความสัมพันธ์ (ลำดับชั้นค่อนข้างแบนไม่มีประเภทข้อมูลแปลก ๆ เช่นภาพหรือเสียงความสัมพันธ์ที่คาดเดาได้ระหว่างสกีมาที่สามารถอธิบายได้ง่ายในคีย์) และผู้บริโภคของคุณคาดว่าจะรวมคนที่ต้องการสอบถามข่าวกรองธุรกิจ (การสอบถามเฉพาะกิจ) จากนั้น RDBMS เป็นวิธีที่จะไป มันค่อนข้างง่ายที่จะเปลี่ยนการสืบค้นให้เป็นตัวแทนของ JSON ดังนั้นมันจึงไม่เป็นภาระต่อผู้บริโภค Ajax ของคุณ - เพียงแค่เพิ่มการแปลงรหัสเล็กน้อยลงในปลายทางของคุณ (REST / SOAP / อะไรก็ตาม) โดยตรงกันข้ามหากข้อมูลของคุณมีลำดับขั้นสูง (schema ลึก) มีประเภทข้อมูลแปลก ๆ เช่นรูปภาพเสียงวิดีโอ ฯลฯ มีความสัมพันธ์ระหว่างเอนทิตี้น้อยและคุณรู้ว่าผู้ใช้ปลายทางของคุณจะไม่ทำ BI ดังนั้น NoSQL / การจัดเก็บ JSON อาจเหมาะสม

แน่นอนว่าแม้แนวทางทั่วไปเหล่านี้จะไม่มั่นคง เหตุผลที่Google พัฒนาระบบไฟล์ของ Google, MapReduce (งานที่ดั๊กตัดใช้เพื่อสร้าง Hadoop ที่ Yahoo)และ BigQuery รุ่นต่อมา (วิธี NoSQL ที่มุ่งเน้น [schemaless] ในการจัดการข้อมูลขนาดใหญ่) เป็นสิ่งที่แม่นยำเพราะพวกเขามีจำนวนมาก คำร้องขอ BI และพวกเขาไม่สามารถหาวิธีที่สัมพันธ์กันเพื่อปรับมาตราส่วน tera / peta / exa / zetta / yotta ที่พวกเขาพยายามจัดการ วิธีการปฏิบัติเพียงวิธีเดียวคือการขยายขนาดการเสียสละความเป็นมิตรของผู้ใช้แบบ ad-hoc-query ที่ RDBMS ให้และแทนที่อัลกอริทึมแบบง่าย (MapReduce) ที่สามารถเข้ารหัสได้อย่างง่ายดายสำหรับการสืบค้นใด ๆ

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

'อย่าไปหาพวกเอลฟ์เพื่อขอคำแนะนำเพราะพวกเขาจะพูดทั้งไม่และใช่' - โฟรโด

ฉันเชื่อว่ามีข้อควรพิจารณาเพิ่มเติมที่นี่ที่คุณอาจไม่ได้มองหา มีข้อกังวลกว้าง ๆ สองข้อที่นี่:

• การเก็บรักษา
• ค้นหาและสืบค้น

การเก็บรักษา

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

ค้นหา

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

แม้ว่านี่จะดูเหมือนงานพิเศษมากมาย แต่คุณจะต้องขอบคุณตัวเองที่คาดการณ์ว่าจะใช้เครื่องมือค้นหาข้อความแบบเต็มในภายหลัง ฐานข้อมูล NoSql หรือ RDBMS ไม่มีประสิทธิภาพและความคล่องตัวของ SOLR / Lucene

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

ที่เริ่มกล่าวว่าฉันสามารถ จำกัด คำถามของคุณไปที่: ข้อดีและข้อเสียของNoSQLและRDBMSคืออะไร? และมันก็ได้รับคำตอบมาแล้วหลายพันครั้งบนเน็ต

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

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

ในแอปพลิเคชันส่วนใหญ่มีข้อกำหนดให้

1. ป้อนข้อมูลดำเนินการประมวลผลบันทึกข้อมูลเรียกข้อมูลและสืบค้นข้อมูล อาจมีข้อกำหนดในการสร้างรายงานเกี่ยวกับข้อมูล
2. แลกเปลี่ยนข้อมูลระหว่างส่วนต่าง ๆ ของระบบหรือกับระบบภายนอก

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

เพื่อให้บรรลุข้อกำหนดสำหรับรายการที่ 2 มีวิธีการที่แตกต่างหลากหลายในการอนุญาตให้มีการแลกเปลี่ยนข้อมูลระหว่างระบบรวมถึง XML, JSON เป็นต้น

วิธีการเหล่านี้ช่วยให้โครงสร้างข้อมูลถูกกำหนดโดยผู้ใช้และเป็นภาษาที่อิสระช่วยให้ระบบที่แตกต่างกันในการแลกเปลี่ยนข้อมูล

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

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

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

หากคุณใช้ฐานข้อมูลแล้วการเพิ่มเขตข้อมูลเพิ่มเติมนั้นค่อนข้างง่ายและมีเพียงรหัสของคุณที่จะสร้าง JSON เท่านั้นที่จะต้องมีการแก้ไขในที่เดียวซึ่งจะทำให้ JSON ใหม่ทั้งหมดของคุณมีฟิลด์ใหม่

ในการใช้งานสั้น ๆ เทคโนโลยีแต่ละชิ้นสำหรับสิ่งที่มันถูกออกแบบมาสำหรับ JSON สำหรับการแลกเปลี่ยนข้อมูลและฐานข้อมูลสำหรับการเก็บข้อมูล

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

เพียงเพราะข้อมูลบางอย่างมีความสัมพันธ์อย่างหมดจดไม่ได้หมายความว่าอีกต่อไปมันจะต้องคงอยู่ใน RDBMS (SQL) บางอย่าง ข้อมูลเชิงสัมพันธ์ของ IMO จะแปลให้ดีขึ้นในฐานข้อมูลกราฟ

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

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

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

ฉันคิดว่าคุณควรใช้ทั้งคู่และฉันไม่คิดว่ามันเป็นการตัดสินใจที่ 'เทียบกับ'

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

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

ดังนั้นฉันจะแนะนำ SQL สำหรับการจัดเก็บข้อมูลและ JSON สำหรับรูปแบบการขนส่งข้อมูล

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