อะไรคือความสมดุลที่ดีระหว่างการใช้ฟิลด์ซ้ำกับการสร้างฟิลด์ใหม่ในบริบทของการปรับขนาดฟิลด์

ฉันอ่านวลีต่อไปนี้บนเว็บไซต์:

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

และมีข้อสงสัยเกิดขึ้น

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

จะมีจำนวนแถวเท่าไรที่เหมาะสมที่สุดสำหรับการออกแบบเมื่อมีเป้าหมาย? ด้วยวิธีนี้เราสามารถตัดสินใจได้ว่าจะใช้ฟิลด์ใหม่เมื่อใดและจะสร้างใหม่เมื่อใด (แม้ว่าจะมีโอกาสนำมาใช้ซ้ำ)

จำนวนข้อมูลในเขตข้อมูลมักจะไม่มีปัญหา หากคุณกังวลเกี่ยวกับสิ่งนั้นให้ดูที่ปลั๊กอินหน่วยเก็บข้อมูลสำรองหรือเขียนของคุณเอง ตัวอย่างเช่นMongoDBซึ่งสามารถจัดการกับอะไรก็ได้ที่คุณใส่เข้าไป มันเป็นตัวอย่างที่ใช้ในhttp://examiner.com

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

ฉันเคยเห็นไซต์ที่มีฟิลด์มากกว่า 250 ฟิลด์ซึ่งการโหลดและยกเลิกการกำหนดค่าฟิลด์จะใช้หน่วยความจำ 13MB +

แก้ไข: แคชข้อมูลภาคสนามได้รับการปรับปรุง (ดูhttp://drupal.org/node/1040790เพื่อดูรายละเอียด) ด้วย Drupal 7.22 เฉพาะฟิลด์ของบันเดิลที่แสดงในหน้าบางหน้าเท่านั้นที่จะถูกโหลดจากแคช แยกรายการแคช ใช้งานได้หากไม่มีการเรียก API ที่ผิดที่ร้องขออินสแตนซ์ข้ามหลายบันเดิล

ฉันเห็นด้วยกับเบอร์ดี้อย่างเต็มที่ นี่คือประสบการณ์ของฉันกับโปรเจ็กต์ที่มีแถวนับล้านและ 30-40 ฟิลด์บนโหนดบางชนิด

1. จำนวนแถวในตารางเขตข้อมูลไม่ได้เป็นปัญหาใหญ่สำหรับประสิทธิภาพการอ่านเนื่องจากฟิลด์หลักทั้งหมดถูกดึงข้อมูลโดยคีย์หลัก
2. จำนวนฟิลด์ต่อชนิดโหนดสามารถเติบโตเป็นปัญหาด้านประสิทธิภาพได้อย่างรวดเร็วเมื่อเขียนโหนดใหม่ การมี 30+ ฟิลด์สำหรับผลลัพธ์หนึ่งโหนดพิมพ์ลงในคำสั่ง INSERT 60+เมื่อคุณสร้างโหนดใหม่ การดำเนินการนี้ใช้เวลาไม่กี่วินาที หากคุณเป็นผู้ใช้ที่สร้างข้อมูลจำนวนมากสิ่งนี้จะส่งผลต่อประสิทธิภาพของคุณ การแทรกจำนวน 1000 โหนดจะใช้เวลาเกือบหนึ่งชั่วโมง หากคุณต้องอัปเดตโหนด 100'000 นี่เป็นปัญหาใหญ่
3. หากคุณคิดว่าจำนวนฟิลด์ของปัญหากำลังจะมาถึงคุณคุณควรคิดอย่างจริงจังเกี่ยวกับการเขียนที่เก็บข้อมูลของคุณเองหรือเพียงแค่ไม่ใช้ฟิลด์ (คุณยังสามารถทำให้โหนดของคุณทำงานกับมุมมองได้โดยใช้ความพยายามพิเศษ)
4. คำเกี่ยวกับ MongoDB มันเป็นโครงการที่น่าสนใจมากและฉันหวังว่ามันจะทำให้มันกลายเป็นโอลิมปิกของฐานข้อมูลขนาดใหญ่ น่าเสียดายที่เมื่อเทียบกับอายุของ MySql หรือ PgSql มันเป็นเรื่องของเด็ก ได้เตรียมที่จะจัดการกับผลิตภัณฑ์ที่เล็กมาก

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

รับบัญชีที่ Rackspace Cloud, Amazon, Linode หรือที่ใดก็ได้ที่คุณสามารถหมุน VPS ได้อย่างง่ายดาย ทำสองอินสแตนซ์ที่เหมือนกัน ติดตั้ง Drupal ในแต่ละ สร้างประเภทเนื้อหาจำลองบางส่วนและตั้งค่าเขตข้อมูลทางเดียวในระบบเดียวและอีกทางหนึ่งในอีกทางหนึ่ง ใช้โมดูล devel เพื่อสร้างเนื้อหาของเรือ ปรับการตั้งค่าประสิทธิภาพเพื่อให้แน่ใจว่า Drupal กำลังแคชได้ตามต้องการ เรียกใช้ mysqltuner และปรับ MySQL ในแต่ละคำแนะนำ ตรวจสอบการตั้งค่า PHP และ APC อีกครั้งเพื่อให้คุณไม่ต้องกดปุ่มสลับและคุณไม่ได้ปั่นแคช APC

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

การจำลองไม่สมบูรณ์แบบ แต่พวกเขาสามารถพาคุณไปในทิศทางที่ถูกต้อง

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

เคล็ดลับอื่น: การมีฟิลด์จำนวนมากจะทำให้เกิดปัญหากับโมดูลที่แตกต่างกันเช่นกัน อินเทอร์เฟซ Token GUI จะทำให้เบราว์เซอร์ของคุณล่าช้าเป็นนาทีหากคุณพยายามแก้ไขชื่อแทน URL พฤติกรรมนี้สามารถเห็นได้ในทุกหน้าซึ่งจะมีการโหลดโทเค็นและแสดงผล (รวมถึง devel - dpm () เป็นต้น)

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

นอกจากนี้ยังอาจทำให้การสร้างเทมเพลตง่ายขึ้นเนื่องจากแอตทริบิวต์โหนดที่คล้ายกัน

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

อย่างไรก็ตามมันใช้งานได้ หากคุณใช้แคชและวานิชผู้ใช้รอเวลาก็ไม่เลว

ปัญหาหลักที่เราพบกับฟิลด์จำนวนมากคือกับ Display Suite เนื่องจากอาจช้ามาก (บางครั้งไม่ตอบสนอง) หากเราพยายามจัดเรียงใหม่หรือย้ายฟิลด์ไปรอบ ๆ

โชคดีที่เราตัดสินใจปรับสัดส่วนผลิตภัณฑ์ของเราอีกเล็กน้อยเพื่อให้เราหวังว่าจะได้จำนวนฟิลด์สูงสุดในช่วง 200-250 สำหรับผลิตภัณฑ์ที่ซับซ้อนที่สุดของเรา (เราอยู่ในเครื่องมือทางวิทยาศาสตร์การวัดและรายละเอียดที่ซับซ้อนจึงจำเป็นต้องใช้) .

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

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

ฉันได้ใช้ฟิลด์ซ้ำแล้วซ้ำอีก แต่ตอนนี้ฉันกำลังพิจารณาที่จะใช้ฟิลด์ที่ไม่ซ้ำกันตามประเภทโหนดสำหรับโครงการใหม่ ฉันต้องการเก็บทุกอย่างแยกอย่างชัดเจน (ฟิลด์มุมมองกฎบริบท ฯลฯ ) สำหรับแต่ละเอนทิตีบันเดิล ดังนั้นมันทำให้เกิดคำถามเกี่ยวกับความสามารถในการปรับขยายได้ซึ่งทำให้ฉันมาที่นี่ ฉันสบายใจ Berdir ของการแก้ไข (แคชข้อมูลภาคสนามได้รับการปรับปรุงให้ดีขึ้น (ดูhttp://drupal.org/node/1040790สำหรับรายละเอียด) ด้วย Drupal 7.22 เท่านั้นด้านของการรวมกลุ่มที่ปรากฏบนหน้าบางโหลดจาก แคชและพวกเขาแยกรายการแคชที่ทำงานเฉพาะเมื่อไม่มีการเรียก API ที่ไม่ถูกต้องที่ร้องขออินสแตนซ์ในหลาย ๆ บันเดิล)

ผมแค่อยากจะชี้ให้เห็นว่ามีโมดูลที่น่าสนใจมากที่ผมเคยใช้เวลาหลายเดือนในหลายเว็บไซต์ที่ซับซ้อน .: https://www.drupal.org/project/render_cache มันเป็นหนึ่งในอัญมณีที่ซ่อนอยู่ในความคิดของฉัน

ดังที่กล่าวไว้ในหน้าโครงการส่วนความเห็นนั้นถูกใช้จริงใน DO เอง

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

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