หลักการสร้างแบบจำลองเอกสาร CouchDB

ฉันมีคำถามที่พยายามหาคำตอบมาระยะหนึ่งแล้ว แต่คิดไม่ออก:

คุณออกแบบหรือแบ่งเอกสาร CouchDB อย่างไร?

ยกตัวอย่าง Blog Post

วิธีกึ่ง "เชิงสัมพันธ์" คือการสร้างวัตถุสองสามชิ้น:

• เสา
• ผู้ใช้งาน
• คิดเห็น
• แท็ก
• เศษเล็กเศษน้อย

สิ่งนี้สมเหตุสมผลมาก แต่ฉันพยายามใช้ couchdb (ด้วยเหตุผลทั้งหมดที่ว่ามันยอดเยี่ยม) เพื่อสร้างโมเดลสิ่งเดียวกันและมันก็ยากมาก

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

• โพสต์ (พร้อมแท็กและตัวอย่างโมเดล "หลอก" ในเอกสาร)
• คิดเห็น
• ผู้ใช้งาน

บางคนอาจบอกว่าคุณสามารถแสดงความคิดเห็นและผู้ใช้ในนั้นได้ดังนั้นคุณจะมีสิ่งนี้:

post {
    id: 123412804910820
    title: "My Post"
    body: "Lots of Content"
    html: "<p>Lots of Content</p>"
    author: {
        name: "Lance"
        age: "23"
    }
    tags: ["sample", "post"]
    comments {
        comment {
            id: 93930414809
            body: "Interesting Post"
        } 
        comment {
            id: 19018301989
            body: "I agree"
        }
    }
}

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

แต่แล้วฉันก็คิดว่า "ทำไมไม่รวมทั้งไซต์ของฉันไว้ในเอกสารเดียว":

site {
    domain: "www.blog.com"
    owner: "me"
    pages {
        page {
            title: "Blog"
            posts {
                post {
                    id: 123412804910820
                    title: "My Post"
                    body: "Lots of Content"
                    html: "<p>Lots of Content</p>"
                    author: {
                        name: "Lance"
                        age: "23"
                    }
                    tags: ["sample", "post"]
                    comments {
                        comment {
                            id: 93930414809
                            body: "Interesting Post"
                        } 
                        comment {
                            id: 19018301989
                            body: "I agree"
                        }
                    }
                }
                post {
                    id: 18091890192984
                    title: "Second Post"
                    ...
                }
            }
        }
    }
}

คุณสามารถดูเพื่อค้นหาสิ่งที่คุณต้องการได้อย่างง่ายดาย

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

ฉันคิดว่ามันน่าจะเป็น "Object Oriented" มากกว่าและง่ายกว่าในการแมปกับ Value Objects หากแบ่งออกเป็นดังนี้:

posts {
    post {
        id: 123412804910820
        title: "My Post"
        body: "Lots of Content"
        html: "<p>Lots of Content</p>"
        author_id: "Lance1231"
        tags: ["sample", "post"]
    }
}
authors {
    author {
        id: "Lance1231"
        name: "Lance"
        age: "23"
    }
}
comments {
    comment {
        id: "comment1"
        body: "Interesting Post"
        post_id: 123412804910820
    } 
    comment {
        id: "comment2"
        body: "I agree"
        post_id: 123412804910820
    }
}

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

ฉันได้อ่านหลายสิ่งหลายอย่างเกี่ยวกับวิธี / เวลาที่จะใช้ฐานข้อมูลเชิงสัมพันธ์กับฐานข้อมูลเอกสารดังนั้นนั่นไม่ใช่ปัญหาหลักที่นี่ ฉันแค่สงสัยว่ากฎ / หลักการที่ดีที่จะใช้เมื่อสร้างแบบจำลองข้อมูลใน CouchDB คืออะไร

อีกตัวอย่างหนึ่งคือไฟล์ / ข้อมูล XML ข้อมูล XML บางรายการซ้อนกันลึก 10+ ระดับและฉันต้องการเห็นภาพว่าการใช้ไคลเอนต์เดียวกัน (เช่น Ajax บน Rails หรือ Flex) ที่ฉันต้องการแสดงผล JSON จาก ActiveRecord, CouchRest หรือ Object Relational Mapper อื่น ๆ บางครั้งฉันได้รับไฟล์ XML ขนาดใหญ่ที่เป็นโครงสร้างไซต์ทั้งหมดเช่นเดียวกับด้านล่างและฉันจำเป็นต้องแมปกับ Value Objects เพื่อใช้ในแอป Rails ของฉันดังนั้นฉันจึงไม่ต้องเขียนวิธีอื่นในการทำให้เป็นอนุกรม / deserializing ข้อมูล :

<pages>
    <page>
        <subPages>
            <subPage>
                <images>
                    <image>
                        <url/>
                    </image>
                </images>
            </subPage>
        </subPages>
    </page>
</pages>

ดังนั้นคำถามทั่วไปของ CouchDB คือ:

1. คุณใช้กฎ / หลักการอะไรในการแบ่งเอกสารของคุณ (ความสัมพันธ์ ฯลฯ )?
2. สามารถรวมทั้งไซต์ไว้ในเอกสารเดียวได้หรือไม่?
3. ถ้าเป็นเช่นนั้นคุณจะจัดการกับเอกสาร serializing / deserializing ด้วยระดับความลึกที่กำหนดเองได้อย่างไร (เช่นตัวอย่าง json ขนาดใหญ่ด้านบนหรือตัวอย่าง xml)
4. หรือคุณไม่เปลี่ยนให้เป็น VO คุณแค่ตัดสินใจว่า "สิ่งเหล่านี้ซ้อนอยู่กับ Object-Relational Map มากเกินไปดังนั้นฉันจะเข้าถึงโดยใช้วิธี XML / JSON แบบดิบ"

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

ฉันได้ศึกษาไซต์ / โครงการต่อไปนี้

1. ข้อมูลลำดับชั้นใน CouchDB
2. CouchDB Wiki
3. โซฟา - แอป CouchDB
4. CouchDB The Definitive Guide
5. PeepCode CouchDB Screencast
6. CouchRest
7. CouchDB README

... แต่พวกเขายังไม่ได้ตอบคำถามนี้

มีคำตอบที่ยอดเยี่ยมสำหรับเรื่องนี้แล้ว แต่ฉันต้องการเพิ่มคุณสมบัติ CouchDB ล่าสุดให้กับตัวเลือกต่างๆสำหรับการทำงานกับสถานการณ์ดั้งเดิมที่อธิบายโดย viatropos

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

รายการใหญ่อันดับแรกคือการจัดเรียงมุมมอง เมื่อคุณปล่อยคู่คีย์ / ค่าลงในผลลัพธ์ของแบบสอบถามแผนที่ / ลดคีย์จะถูกจัดเรียงตามการเรียง UTF-8 ("a" มาก่อน "b") คุณสามารถคีย์ซับซ้อนยังเอาท์พุทจากแผนที่ของคุณ / ลดอาร์เรย์ ["a", "b", "c"]JSON: การทำเช่นนั้นจะช่วยให้คุณสามารถรวม "ต้นไม้" ประเภทต่างๆที่สร้างขึ้นจากคีย์อาร์เรย์ จากตัวอย่างของคุณด้านบนเราสามารถส่งออก post_id จากนั้นเป็นประเภทของสิ่งที่เราอ้างอิงจากนั้นก็คือ ID (หากจำเป็น) หากเราส่งออก id ของเอกสารที่อ้างอิงไปยังวัตถุในค่าที่ส่งคืนเราสามารถใช้พารามิเตอร์การสืบค้น "include_docs" เพื่อรวมเอกสารเหล่านั้นในแผนที่ / ลดผลลัพธ์:

{"rows":[
  {"key":["123412804910820", "post"], "value":null},
  {"key":["123412804910820", "author", "Lance1231"], "value":{"_id":"Lance1231"}},
  {"key":["123412804910820", "comment", "comment1"], "value":{"_id":"comment1"}},
  {"key":["123412804910820", "comment", "comment2"], "value":{"_id":"comment2"}}
]}

การขอมุมมองเดียวกันกับ '? include_docs = true' จะเพิ่มคีย์ 'doc' ที่จะใช้ '_id' ที่อ้างอิงในออบเจ็กต์ 'value' หรือหากไม่มีอยู่ในออบเจ็กต์ 'value' ก็จะใช้ '_id' ของเอกสารที่แสดงแถว (ในกรณีนี้คือเอกสาร "post") โปรดทราบว่าผลลัพธ์เหล่านี้จะรวมฟิลด์ 'id' ที่อ้างอิงถึงเอกสารต้นทางที่มีการปล่อยสัญญาณออกมา ฉันทิ้งมันไว้เพื่อให้มีพื้นที่ว่างและสามารถอ่านได้

จากนั้นเราสามารถใช้พารามิเตอร์ 'start_key' และ 'end_key' เพื่อกรองผลลัพธ์ให้เหลือเพียงข้อมูลของโพสต์เดียว:

? start_key = ["123412804910820"] & end_key = ["123412804910820", {}, {}]

? start_key = ["123412804910820", "comment"] & end_key = ["123412804910820", "comment", {}]

ส่วนเพิ่มเติมที่เป็นประโยชน์อย่างที่สองจาก CouchDB ในสถานการณ์เหล่านี้คือฟังก์ชัน _list สิ่งนี้จะช่วยให้คุณสามารถเรียกใช้ผลลัพธ์ข้างต้นผ่านระบบเทมเพลตบางประเภท (หากคุณต้องการ HTML, XML, CSV หรืออะไรก็ตามที่อยู่ด้านหลัง) หรือส่งออกโครงสร้าง JSON แบบรวมหากคุณต้องการขอเนื้อหาของโพสต์ทั้งหมด (รวมถึง ข้อมูลผู้เขียนและความคิดเห็น) ด้วยคำขอเดียวและส่งคืนเป็นเอกสาร JSON เดียวที่ตรงกับสิ่งที่รหัสฝั่งไคลเอ็นต์ / UI ของคุณต้องการ การทำเช่นนั้นจะช่วยให้คุณสามารถขอเอกสารผลลัพธ์รวมของโพสต์ด้วยวิธีนี้:

/ db / _design / app / _list / posts / unified ?? start_key = ["123412804910820"] & end_key = ["123412804910820", {}, {}] & include_docs = true

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

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

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

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

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

หนังสือบอกว่าถ้าผมจำได้อย่างถูกต้องเพื่อ denormalize จนกระทั่ง "มันเจ็บ" ในขณะที่การรักษาในใจความถี่ที่เอกสารของคุณอาจจะได้รับการปรับปรุง

1. คุณใช้กฎ / หลักการอะไรในการแบ่งเอกสารของคุณ (ความสัมพันธ์ ฯลฯ )?

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

2. สามารถรวมทั้งไซต์ไว้ในเอกสารเดียวได้หรือไม่?

ไม่นั่นอาจเป็นเรื่องโง่เพราะ:

• คุณจะต้องอ่านและเขียนทั้งไซต์ (เอกสาร) ในการอัปเดตแต่ละครั้งซึ่งไม่มีประสิทธิภาพมาก
• คุณจะไม่ได้รับประโยชน์จากการแคชมุมมองใด ๆ

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

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

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

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

จากนั้นในการเขียนมุมมองที่ให้ข้อคิดเห็นสำหรับโพสต์คุณจะส่งผ่านรหัสโพสต์จากนั้นจึงแสดงความคิดเห็นทั้งหมดที่อ้างอิง ID โพสต์หลักนั้นโดยเรียงลำดับตามตรรกะ บางทีคุณอาจจะส่งบางอย่างเช่น [postID, byUsername] เป็นกุญแจสำคัญในมุมมอง "ความคิดเห็น" เพื่อระบุโพสต์หลักและวิธีการจัดเรียงผลลัพธ์หรือบางอย่างตามบรรทัดเหล่านั้น

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

เนื่องจากการล็อกการเขียนและลักษณะการทำงานแบบ single-master ของ Mongo ปัญหาการแก้ไขที่ขัดแย้งกันของคนสองคนที่เพิ่มความคิดเห็นจะไม่เกิดขึ้นที่นั่นและความสามารถในการสืบค้นของเนื้อหาตามที่กล่าวไว้นั้นไม่ได้รับผลกระทบที่แย่เกินไปเนื่องจากข้อย่อย ดัชนี

ที่ถูกกล่าวว่าถ้าองค์ประกอบย่อยในทั้งฐานข้อมูลจะมีขนาดใหญ่ (10s พูดของพันความเห็น) ผมเชื่อว่ามันเป็นข้อเสนอแนะของทั้งสองค่ายที่จะทำให้การแยกองค์ประกอบเหล่านั้น ฉันได้เห็นแล้วว่าจะเป็นเช่นนั้นกับ Mongo เนื่องจากมีข้อ จำกัด บางประการเกี่ยวกับความใหญ่ของเอกสารและองค์ประกอบย่อย