วิธีจัดการผู้ใช้หลายล้านคน

ฉันกำลังจะเปิดตัวสิ่งที่ยิ่งใหญ่จริงๆ ฉันต้องเตรียมเซิร์ฟเวอร์และฐานข้อมูลของฉัน

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

ตัวอย่างเช่นฉันจะรู้ได้อย่างไรว่าผู้ใช้jay@mail.comนั้นเกี่ยวข้องกับตารางผู้ใช้ # 36

มันจะเหมือนกันไหมที่มีผู้ใช้ 10 ล้านคนในตารางผู้ใช้หนึ่งคนหรือ 100 จาก 100,000 คน?

Facebook เป็นอย่างไร ฉันไม่อยากเชื่อเลยว่าพวกเขาจะมีโต๊ะผู้ใช้ทั่วโลกที่มี 950 ล้านรายการ

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

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

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

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

เกี่ยวกับ 10M tuples ในหนึ่งตารางถ้าคุณมีการจัดทำดัชนีที่ดีมันจะดี เราจำเป็นต้องเก็บ tuples 100M หลาย ๆ ตัวในตารางเดียวที่นี่ (รายการที่ขาย) ซึ่งทำงานได้ดีบน oracle 11g ขนาดใหญ่

นี่คือการโพสต์จาก 2010 พร้อมแผนที่ของการออกแบบ db ของ facebook: ฐานข้อมูลของ Facebookการออกแบบฐานข้อมูล Facebook

คุณอาจต้องการอ่านเอกสาร mysql เกี่ยวกับประเภทพาร์ติชันเช่นนี้: เอกสารประกอบ MySQL: การแบ่งส่วน

MySQL รองรับประเภทเหล่านี้:

พิสัยแบ่งพาร์ติชันการแบ่งพาร์ติชันประเภทนี้จะกำหนดแถวให้กับพาร์ติชันตามค่าคอลัมน์ที่อยู่ภายในช่วงที่กำหนด ดูหัวข้อ 18.2.1“ การแบ่งพาร์ติชันช่วง”

รายการแบ่งพาร์ติชัน คล้ายกับการแบ่งพาร์ติชันโดย RANGE ยกเว้นว่ามีการเลือกพาร์ติชันตามคอลัมน์ที่ตรงกับหนึ่งในชุดของค่าที่ไม่ต่อเนื่อง ดูหัวข้อ 18.2.2“ การแบ่งพาร์ทิชันรายการ”

การแบ่งแฮช ด้วยการแบ่งพาร์ติชันประเภทนี้พาร์ติชั่นจะถูกเลือกตามค่าที่ส่งคืนโดยนิพจน์ที่ผู้ใช้กำหนดซึ่งทำงานกับค่าคอลัมน์ในแถวที่จะแทรกเข้าไปในตาราง ฟังก์ชั่นอาจประกอบด้วยการแสดงออกใด ๆ ที่ถูกต้องใน MySQL ที่ให้ค่าจำนวนเต็มลบ ส่วนขยายของประเภทนี้คือ LINEAR HASH ดูหัวข้อ 18.2.3“ การแบ่งพาร์ติชันแบบแฮช”

การแบ่งพาร์ติชันKEY การแบ่งพาร์ติชันประเภทนี้คล้ายกับการแบ่งพาร์ติชันโดย HASH ยกเว้นว่าจะมีการระบุคอลัมน์อย่างน้อยหนึ่งคอลัมน์เท่านั้นที่จะถูกประเมินและเซิร์ฟเวอร์ MySQL มีฟังก์ชันการแฮชของตนเอง คอลัมน์เหล่านี้สามารถมีค่าอื่นที่ไม่ใช่จำนวนเต็มเนื่องจากฟังก์ชันการแฮชที่จัดทำโดย MySQL รับประกันผลลัพธ์จำนวนเต็มโดยไม่คำนึงถึงชนิดข้อมูลคอลัมน์ ส่วนขยายสำหรับประเภทนี้คือ LINEAR KEY ดูหัวข้อ 18.2.4“ การแบ่งพาร์ติชันที่สำคัญ”

ก่อนอื่นอย่าแยกผู้ใช้ออกเป็นตารางแยกต่างหาก มันจะทำให้สิ่งต่าง ๆ ซับซ้อนและไม่มีจุดหมาย ฐานข้อมูลเช่น MySQL และอื่น ๆ สามารถทำงานกับฐานข้อมูลหลายล้านระเบียนในตารางเดียวกันโดยไม่มีปัญหาใด ๆ (มีคีย์หลักที่ถูกต้องตั้งค่า) ใช้ฐานข้อมูล AUTO_INCREMENT และเขตข้อมูลคีย์หลักที่ไม่ซ้ำกันสำหรับผู้ใช้แต่ละคน (ในตารางผู้ใช้หลัก) ดังนั้นทุกระเบียนจะไม่ซ้ำกัน (UID) จากนั้นในตารางอื่น ๆ ที่คุณอ้างอิงโดยใช้รหัสที่ไม่ซ้ำกันนั้น จากนั้นตรวจสอบให้แน่ใจว่าในทุกตารางที่คุณตั้งค่าเป็นคีย์หลักมันจะเร่งการประมวลผลข้อมูลในเซิร์ฟเวอร์ฐานข้อมูล คุณสามารถเรียนรู้จาก Drupal CMS ได้ว่ามันเก็บข้อมูลผู้ใช้อย่างไร ผ่านการทดสอบมานานกว่า 10 ปีโดยผู้ใช้หลายล้านคนและ บริษัท ขนาดใหญ่มาก (ใช้งานโดย บริษัท สื่อขนาดใหญ่รัฐบาลหรือแม้แต่ธนาคารที่ใหญ่ที่สุดในโลก) บน www.drupal คุณจะพบเพจ (โหนด) มากกว่า 1,6 ล้านเพจที่เก็บไว้ในตารางเดียวกันและมีผู้เข้าชมมากกว่าล้านรายต่อเดือนและเว็บไซต์ใช้งานได้โดยไม่ผิดพลาด ทุกอย่างเกี่ยวกับการปรับแต่งและการปรับแต่งที่เหมาะสม

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

ดูตัวอย่างของuserschema ของตารางในไฟล์user.install

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

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

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

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