การใช้ประโยชน์ไม่ได้ในการออกแบบฐานข้อมูล

หนึ่งในรายการในจาวาที่มีประสิทธิภาพของ Joshua Bloch คือความคิดที่ว่าคลาสควรยอมให้มีการเปลี่ยนแปลงอินสแตนซ์น้อยที่สุดเท่าที่จะเป็นไปได้

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

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

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

create table myObj (id integer, ...other_data... not null);
create table myObjSuppliment (id integer, myObjId integer, ...more_data... not null);

หวังว่าจะเห็นได้ชัดว่าชื่อเหล่านี้ไม่ใช่คำต่อคำ แต่เป็นเพียงการสาธิตความคิด

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

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

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

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

นี่เป็นสิ่งเดียวกับที่คุณคิดในการสร้างตารางใหม่ยกเว้นอัตโนมัติและยืดหยุ่นมากขึ้น

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

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

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

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

นั่นคือสิ่งที่อยู่ในใจของฉันเมื่อคุณพูดว่า "ความไม่สามารถเปลี่ยนแปลงได้ในการออกแบบฐานข้อมูล"

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

Datomicเป็นฐานข้อมูลที่คิดค้นโดย Rich Hickey ซึ่งเป็นพันธมิตรกับ Think เกี่ยวข้องมีวิดีโอมากมายที่พวกเขาอธิบายสถาปัตยกรรมเป้าหมายรูปแบบข้อมูล ค้นหา InfoQ หนึ่งโดยเฉพาะอย่างยิ่งเป็นเรื่องDatomic, ฐานข้อมูลเป็นค่า ในความลับคุณสามารถค้นหาคำปราศรัยที่ Rich Hickey มอบให้ในการประชุม euroclojure ในปี 2012

มีการพูดคุยใน vimeo.com/53162418 ซึ่งมุ่งเน้นการพัฒนามากขึ้น

นี่คืออีกหนึ่งจาก stuart halloway ที่.pscdn.net/008/00102/videoplatform/kv/121105techconf_close.html

• Datomic เป็นฐานข้อมูลของข้อเท็จจริงในเวลาที่เรียกว่า datums ใน 5-tuples [E, A, V, T, O]
  • รหัสเอนทิตีE
  • ชื่อแอตทริบิวต์ในกิจการ (สามารถมี namespaces)
  • Vมูลค่าของคุณสมบัติ
  • T ID การทำธุรกรรมด้วยสิ่งนี้คุณมีเวลา
  • Oการยืนยันหนึ่งครั้ง (ปัจจุบันหรือมูลค่าปัจจุบัน) การปฏิเสธ (มูลค่าในอดีต);
• ใช้รูปแบบข้อมูลของตัวเองที่เรียกว่า EDN (สัญลักษณ์ข้อมูล Extensible)
• ธุรกรรมเป็นกรด
• ใช้ดาต้าล็อกเป็นภาษาของแบบสอบถามซึ่งมีการประกาศเป็น SQL + เคียวรี่แบบเรียกซ้ำ แบบสอบถามจะถูกแสดงด้วยโครงสร้างข้อมูลและขยายด้วยภาษา jvm ของคุณคุณไม่จำเป็นต้องใช้ clojure
• ฐานข้อมูลถูกแยกออกใน 3 บริการแยกกัน (กระบวนการเครื่องจักร):
  • การซื้อขาย
  • การเก็บรักษา
  • Query Engine
• คุณสามารถแยกมาตราส่วนแต่ละบริการ
• มันไม่ได้เป็นโอเพ่นซอร์ส แต่มี Datomic รุ่นฟรี (ดังเช่นในเบียร์)
• คุณสามารถระบุสคีมาที่มีความยืดหยุ่นได้
  • ชุดของคุณลักษณะเปิด
  • เพิ่มคุณสมบัติใหม่ได้ตลอดเวลา
  • ไม่มีความแข็งแกร่งในคำนิยามหรือแบบสอบถาม

ตอนนี้เนื่องจากข้อมูลถูกเก็บไว้เป็นข้อเท็จจริงในเวลา:

• สิ่งที่คุณทำคือการเพิ่มข้อเท็จจริงลงในฐานข้อมูลคุณจะไม่ลบ (ยกเว้นเมื่อกฎหมายกำหนด)
• คุณสามารถแคชทุกอย่างตลอดไป Query Engine อาศัยอยู่ในแอ็พพลิเคชันเซิร์ฟเวอร์ในฐานะฐานข้อมูลหน่วยความจำ (สำหรับภาษา jvm ภาษาที่ไม่ใช่ jvm มีการเข้าถึงผ่าน REST API)
• คุณสามารถค้นหาเมื่อเวลาผ่านไป

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

มีโครงการโอเพ่นซอร์สจาก Rich Hickey ที่เรียกว่าcodeqคุณสามารถค้นหาได้ใน github Datomic / codeq ซึ่งขยายโมเดล git และเก็บการอ้างอิงไปยังวัตถุ git ในฐานข้อมูลที่ปราศจากข้อมูลและทำการสอบถามรหัสของคุณ สามารถดูตัวอย่างของวิธีการใช้ datomic

คุณสามารถนึกถึง datomic เป็น ACID NoSQL ด้วย datums คุณสามารถสร้างแบบจำลองตารางหรือเอกสารหรือ Kv-stores หรือกราฟ

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

สิ่งนี้มีความสัมพันธ์อย่างใกล้ชิดกับสิ่งที่เรียกว่า "มิติการเปลี่ยนแปลงอย่างช้า ๆ " ในโลกคลังข้อมูลและตาราง "Temporal" หรือ "Bi-Temporal" ในโดเมนอื่น

โครงสร้างพื้นฐานคือ:

1. ใช้คีย์ตัวแทนตัวแทนที่สร้างขึ้นเป็นคีย์หลักเสมอ
2. ตัวระบุที่ไม่ซ้ำใครของสิ่งที่คุณกำลังอธิบายจะกลายเป็น "คีย์ตรรกะ"
3. แต่ละแถวควรมีการประทับเวลาอย่างน้อย "ValidFrom" และเลือกการประทับเวลา "ValidTo" และอาจมีการตั้งค่าสถานะ "เวอร์ชันล่าสุด" อีกทางเลือกหนึ่ง
4. ใน "การสร้าง" ของเอนทิตีแบบลอจิคัลคุณใส่แถวใหม่ด้วย "ถูกต้องจาก" ของการประทับเวลาปัจจุบัน ตัวเลือก ValidTo ตั้งค่าเป็น "ถาวร" (9999-12-31 23:59:59) และรุ่นสุดท้ายเป็น "จริง"
5. ในการปรับปรุงภายหลังของนิติบุคคลที่ อย่างน้อยคุณก็แทรกแถวใหม่ข้างต้น คุณอาจต้องปรับเปลี่ยน ValidTo ในรุ่นก่อนหน้าเป็น "ตอนนี้ () - 1 วินาที" และรุ่นล่าสุดเป็น "เท็จ"
   6. ในการลบแบบลอจิคัล (ใช้งานได้เฉพาะกับการประทับเวลา ValidTo!) คุณตั้งค่าการตั้งค่าสถานะ ValidTo ในแถวปัจจุบันเป็น "ตอนนี้ () -1 วินาที"

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

ข้อเสียคือคุณเก็บข้อมูลได้มากขึ้นและคุณต้องปรับปรุงดัชนีเพิ่มเติม (อย่างน้อยที่สุดใน Logical Key + ValidFrom + ValidTo) ดัชนีของ Logical Key + เวอร์ชันล่าสุดช่วยเพิ่มความเร็วในการสืบค้นส่วนใหญ่ได้อย่างมาก นอกจากนี้ยังทำให้ SQL ของคุณซับซ้อนขึ้นด้วย!

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

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

คำเตือน: ฉันสวยใหม่โดย DB: p

ที่ถูกกล่าวว่าวิธีการของข้อมูลดาวเทียมนี้มีผลทันทีต่อประสิทธิภาพ:

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

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

ฉันไม่เห็นว่ารูปแบบของคุณสามารถเรียกว่า "ไม่เปลี่ยนรูป" ได้อย่างไร

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

สำหรับฐานข้อมูลที่ไม่เปลี่ยนแปลงอย่างแท้จริงจะต้องได้รับการดูแลโดย "INSERTS" เท่านั้น สำหรับสิ่งนี้คุณต้องมีวิธีการระบุแถว "ปัจจุบัน" นี่เกือบจะจบลงด้วยการที่ไม่มีประสิทธิภาพอย่างน่ากลัว คุณต้องคัดลอกค่าที่ไม่เปลี่ยนแปลงก่อนหน้าทั้งหมดทั้งหมดหรือรวมสถานะปัจจุบันจากหลาย ๆ ระเบียนเมื่อคุณสอบถาม การเลือกแถวปัจจุบันมักต้องการ SQL ที่ยุ่งเหยิงอย่างเช่น ( where updTime = (SELECT max(updTime) from myTab where id = ?)

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

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