JSONB พร้อมการจัดทำดัชนี vs. hstore

ฉันกำลังพยายามตัดสินใจเกี่ยวกับการออกแบบฐานข้อมูลโดยมีข้อสมมติฐานน้อยที่สุด (เกี่ยวกับวิธีที่แอพพลิเคชั่นบนเว็บพัฒนาขึ้น) ในขั้นตอนนี้

เป็นขั้นตอนแรกการทำความเข้าใจว่าการเข้าร่วมนั้นมีราคาแพงฉันกำลังพิจารณาตารางเสาหินจำนวนน้อยเมื่อเทียบกับตารางขนาดเล็กจำนวนมากปกติ เป็นจุดที่สองฉันสับสนระหว่างการใช้ hstore กับตารางปกติเทียบกับ JSONB (ด้วยการทำดัชนี GiST)

AFAIK (โปรดแก้ไขให้ถูกต้อง):

โดยทั่วไปใน Postgres hstore จะทำงานได้ดีกว่าประเภทข้อมูลอื่น งานนำเสนอจาก FOSDEM PGDAY มีสถิติที่น่าสนใจ (ในช่วงครึ่งหลังของสไลด์) https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf
ข้อได้เปรียบของ hstore คือการสร้างดัชนีอย่างรวดเร็ว (GiN หรือ GiST) อย่างไรก็ตามด้วยการทำดัชนี JSONB, GiN และ GiST สามารถนำไปใช้กับข้อมูล JSON ได้
บล็อกนี้จากมืออาชีพที่ 2 Quadrant กล่าวว่า "ณ จุดนี้อาจคุ้มค่าที่จะแทนที่การใช้ hstore ด้วย jsonb ในแอปพลิเคชันใหม่ทั้งหมด" (เลื่อนไปยังจุดสิ้นสุด): http://blog.2ndquadrant.com/postgresql-anti-patterns-unn Essential -jsonhstore ไดนามิกคอลัมน์ /

ดังนั้นฉันต้องการตัดสินใจดังต่อไปนี้:

สำหรับส่วนหลัก (โครงสร้าง) ของข้อมูล: มันควรจะอยู่ในตารางเชิงสัมพันธ์สองสามอัน (ค่อนข้างใหญ่ที่มีหลายคอลัมน์) หรือควรเป็นร้านค้าคีย์ - ค่าจำนวนหนึ่งที่ใช้ hstore หรือไม่
สำหรับข้อมูล ad hoc (ผู้ใช้มีส่วนร่วม / ไม่มีโครงสร้าง) ควรอยู่ใน JSON หรือที่เก็บค่าคีย์ ad hoc ใน hstore (โดยมีคีย์ที่เก็บไว้ในตารางสัมพันธ์หลักอย่างใดอย่างหนึ่ง)

postgresql database-design

— Yogesch
แหล่งที่มา

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

— dezso

@Yogesch ลิงก์เหล่านั้นมีบางสิ่งที่น่าสนใจและขัดแย้งกันมาก :) ตามหลักจริยธรรมแล้วดูเหมือนว่า MySQL จะไม่ค่อยดีในการเข้าร่วมและคน NoSQL มักจะพูดแนวความคิดนี้โดยไม่มีพื้นฐานความจริงใด ๆ ในทางกลับกันแอรอนและแม็กซ์มีความอ่อนไหวต่อคำว่า p - การใช้งานที่กว้างขวางแสดงให้เห็นว่าผู้ที่ไม่ใช่เจ้าของภาษา (รวมตัวเอง) ใช้คำผิดอย่างมีความสุข

— dezso

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

— Erik

@Yogesch: การหลีกเลี่ยงการรวมเป็นสิ่งสำคัญสำหรับการดำเนินการแบบอ่านอย่างหนักซึ่งคุณรู้รูปแบบการเข้าถึงข้อมูลล่วงหน้าและคุณสามารถใส่ข้อมูลทั้งหมดที่คุณต้องการลงในแถวเดียวได้อย่างปลอดภัย อย่างไรก็ตามสิ่งนี้ทำให้การเข้าร่วมอื่น ๆอาจมีราคาสูงกว่า ใครบอกว่าคุณไม่จำเป็นต้องเข้าร่วมข้อมูลด้วยวิธีการต่าง ๆ เพื่อตอบคำถามต่าง ๆ ตอนนี้เรากำลังจะลงไปเพียงแค่ทฤษฎีของแบบจำลองข้อมูลเชิงสัมพันธ์ ...

— คริส

@Yogesch ในการปฏิบัติของฉันกับฐานข้อมูลคอขวดไม่ค่อย RAM หรือ CPU แต่ I / O - วิธีนี้หลีกเลี่ยงการเก็บข้อมูลซ้ำซ้อนยังคงเป็นสิ่งสำคัญ อย่างที่ Chris บอกไว้ถ้าคุณเห็นข้อมูลของคุณเพียงครั้งเดียวเสมอนี่อาจจะคุ้มค่ากับราคา ถ้าไม่คุณอยู่ที่นั่นพร้อมกับก้อนข้อมูลขนาดใหญ่และไม่ยืดหยุ่นสูง

— dezso

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

นอกจากว่าคุณมีเหตุผลที่ดีที่จะไม่ใช้การออกแบบปกติให้ใช้การออกแบบปกติ

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

หากคุณสามารถสร้างโมเดลได้ตามความสัมพันธ์ให้สร้างโมเดลตามความสัมพันธ์ หากคุณทำไม่ได้ให้พิจารณา json ฯลฯหากคุณเลือกระหว่าง json / jsonb / hstore โดยทั่วไปแล้วเลือก jsonb เว้นแต่คุณจะไม่มีเหตุผล

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

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

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

สิ่งหนึ่งที่เกี่ยวข้องกับการเข้าใจและสรุปสาระสำคัญ GIN ดัชนีเช่นเดียวกับที่ใช้ใน jsonb มักจะมีมากมีประสิทธิภาพน้อยกว่าดัชนี B ต้นไม้ธรรมดา มันมีความยืดหยุ่นมากกว่า แต่ดัชนี b-tree ในคอลัมน์ปกติจะเร็วกว่ามาก

— Craig Ringer
แหล่งที่มา

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

— Yogesch

@Yogesch ดูเหมือนว่าตารางการเข้าร่วม mog: มาตรฐานที่มีรูปแบบที่สอดคล้องและมีเสถียรภาพ คำถามควรเป็น "มีเหตุผลที่ดีหรือไม่ที่ฉันไม่ควรทำแบบนี้เป็นวิธีเชิงสัมพันธ์ตามปกติสำหรับกรณีนี้?"

— Craig Ringer

hstoreเลิกใช้แล้ว jsonbใช้

— danger89

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

— Craig Ringer