ชนิดข้อมูลที่เหมาะสมที่สุดสำหรับเขตข้อมูล MD5 คืออะไร

เรากำลังออกแบบระบบที่รู้กันว่าอ่านยาก (ตามคำสั่งของการอ่านหมื่นครั้งต่อนาที)

• มีตารางnamesที่ทำหน้าที่จัดเรียงรีจิสทรีกลาง แต่ละแถวมีtextเขตข้อมูลrepresentationและไม่ซ้ำกันkeyซึ่งเป็นแฮช MD5 ของสิ่งrepresentationนั้น ¹ตารางนี้มีระเบียนหลายสิบล้านระเบียนและคาดว่าจะเติบโตเป็นพันล้านตลอดอายุการใช้งานแอปพลิเคชัน
• มีตารางอื่น ๆ อีกหลายสิบตาราง (ของสคีมาที่แตกต่างกันอย่างมากและจำนวนเรคคอร์ด) ที่อ้างอิงถึงnamesตาราง ระเบียนใดก็ตามที่ระบุในตารางใดตารางหนึ่งเหล่านี้รับประกันว่าจะมี a name_keyซึ่งเป็น foreign key ไปยังnamesตาราง

_{1: อนึ่งตามที่คุณคาดไว้ระเบียนในตารางนี้จะไม่เปลี่ยนรูปเมื่อมีการเขียน}

สำหรับตารางใดก็ตามที่ไม่ใช่namesตารางแบบสอบถามที่พบบ่อยที่สุดจะเป็นไปตามรูปแบบนี้:

SELECT list, of, fields 
FROM table 
WHERE name_key IN (md5a, md5b, md5c...);

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

คำถาม:
อะไรคือ / ชนิดข้อมูลที่ดีที่สุดสำหรับkeyและname_keyคอลัมน์คืออะไร?
มีเหตุผลที่จะใช้hex(32)มากกว่าbit(128)? BTREEหรือGIN?

ชนิดข้อมูลuuidเป็นที่ที่ดีที่สุดที่เหมาะสำหรับงาน มีขนาด 16 ไบต์เท่านั้นเมื่อเทียบกับ RAM ขนาด 37 ไบต์สำหรับการเป็นตัวแทนvarcharหรือ text(หรือ 33 ไบต์บนดิสก์ แต่จำนวนคี่จะต้องใช้การขยายในหลาย ๆ กรณีเพื่อให้ได้40ไบต์อย่างมีประสิทธิภาพ) และuuidชนิดมีข้อดีมากกว่า

ตัวอย่าง:

SELECT md5('Store hash for long string, maybe for index?')::uuid AS md5_hash

รายละเอียดและคำอธิบายเพิ่มเติม:

• แปลงเลขฐานสิบหกในการแสดงข้อความเป็นตัวเลขทศนิยม
• การค้นหาดัชนีจะเร็วขึ้นอย่างเห็นได้ชัดด้วย char vs varchar หรือไม่เมื่อค่าทั้งหมดเป็น 36 ตัวอักษร

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

คำเตือน : สำหรับกรณีของคุณ ( immutable once writtenบริการ) การทำงานขึ้นอยู่กับ (หลอกธรรมชาติ) PKดี แต่สิ่งเดียวกันจะเป็นความเจ็บปวดที่textเป็นไปได้ในการอัปเดต คิดว่าการแก้ไขการพิมพ์ผิด: PK และดัชนีขึ้นอยู่ทั้งหมดคอลัมน์ FK ในdozens of other tablesและการอ้างอิงอื่น ๆ จะต้องเปลี่ยนเช่นกัน ตารางและดัชนีขยายตัวปัญหาการล็อคการอัปเดตช้าการอ้างอิงที่สูญหาย ...

หากtextสามารถเปลี่ยนแปลงการทำงานปกติตัวแทน PKก็จะเป็นทางเลือกที่ดีกว่า ผมขอแนะนำให้bigserialคอลัมน์ (ช่วง-9223372036854775808 to +9223372036854775807- ที่เก้า Quintillion 223 quadrillion 372000000000000 สามสิบหกบางสิ่งบางอย่างพันล้าน ) billions of rowsค่าแตกต่างกันสำหรับ อาจเป็นความคิดที่ดีในกรณีใด ๆ : 8แทน16ไบต์สำหรับคอลัมน์ FK และดัชนีหลายสิบรายการ!) หรือUUID แบบสุ่มสำหรับความสำคัญมากกว่าหรือระบบกระจาย คุณสามารถจัดเก็บ md5 ที่กล่าวไว้ (เช่นuuid) เพิ่มเติมเพื่อค้นหาแถวในตารางหลักจากข้อความต้นฉบับได้อย่างรวดเร็ว ที่เกี่ยวข้อง:

• ค่าเริ่มต้นสำหรับคอลัมน์ UUID ใน Postgres

สำหรับคำถามของคุณ:

• ปรับแต่งแบบสอบถาม Postgres ด้วย IN ขนาดใหญ่

หากต้องการระบุความคิดเห็นของ @ Daniel : หากคุณต้องการตัวแทนที่ไม่มีเครื่องหมายขีดคั่นให้ลบเครื่องหมายขีดคั่นเพื่อแสดง:

SELECT replace('90b7525e-84f6-4850-c2ef-b407fae3f271', '-', '')

แต่ฉันจะไม่รบกวน การเป็นตัวแทนเริ่มต้นนั้นใช้ได้ และปัญหาไม่ใช่การแสดงที่นี่จริง ๆ

หากฝ่ายอื่นควรมีแนวทางที่แตกต่างกันและโยนสายอักขระโดยไม่มีเครื่องหมายขีดคั่นในการผสมนั่นก็ไม่ใช่ปัญหาเช่นกัน Postgres ยอมรับหลายการแสดงข้อความที่เหมาะสมเป็น input uuidสำหรับ เอกสารประกอบ :

PostgreSQL ยังยอมรับรูปแบบทางเลือกต่อไปนี้สำหรับการป้อนข้อมูล: ใช้ตัวเลขตัวพิมพ์ใหญ่, รูปแบบมาตรฐานที่ล้อมรอบด้วยเครื่องหมายวงเล็บ, ไม่ใส่เครื่องหมายยัติภังค์บางส่วนหรือทั้งหมด, เพิ่มเครื่องหมายขีดคั่นหลังจากกลุ่มสี่หลักใด ๆ ตัวอย่างคือ:

A0EEBC99-9C0B-4EF8-BB6D-6BB9BD380A11
{a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11}
a0eebc999c0b4ef8bb6d6bb9bd380a11
a0ee-bc99-9c0b-4ef8-bb6d-6bb9-bd38-0a11
{a0eebc99-9c0b4ef8-bb6d6bb9-bd380a11}

ยิ่งไปกว่านั้นmd5()ฟังก์ชั่นกลับtextมาคุณจะใช้decode()ในการแปลงbyteaและการแสดงเริ่มต้นของที่ :

SELECT decode(md5('Store hash for long string, maybe for index?'), 'hex')

\220\267R^\204\366HP\302\357\264\007\372\343\362q

คุณจะต้องencode()รับข้อความที่เป็นต้นฉบับอีกครั้ง:

SELECT encode(my_md5_as_bytea, 'hex');

ยิ่งไปกว่านั้นค่าที่เก็บไว้byteaจะมีขนาด 20 ไบต์ใน RAM (และ 17 ไบต์บนดิสก์, 24 กับการเติมเต็ม ) เนื่องจากโอเวอร์เฮดภายในvarlenaซึ่งไม่เอื้ออำนวยต่อขนาดและประสิทธิภาพของดัชนีอย่างง่าย

ทุกอย่างทำงานได้ดีuuidที่นี่

ฉันจะเก็บ MD5 ไว้ในคอลัมน์textหรือ varcharไม่มีความแตกต่างของประสิทธิภาพระหว่างชนิดข้อมูลอักขระต่างๆ คุณอาจต้องการจำกัดความยาวของค่า md5 โดยใช้varchar(xxx)เพื่อให้แน่ใจว่าค่า md5 ไม่เกินความยาวที่แน่นอน

รายการขนาดใหญ่ในปกติไม่เร็วจริง ๆ ควรทำดังนี้:

with md5vals (md5) as (
  values ('one'), ('two'), ('three')
)
select t.*
from the_table t
  join md5vals m on t.name_key  = m.md5;

ตัวเลือกอื่นที่บางครั้งกล่าวว่าเร็วขึ้นคือการใช้อาร์เรย์:

select t.*
from the_table t
where name_key = ANY (array['one', 'two', 'three']);

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

ตัวเลือกอื่นคือใช้คอลัมน์ 4 INTEGER หรือ 2 BIGINT