การไล่สี
ERDDAP™ - สัมภาระหนัก, กริด, คลูสเตอร์, สหพันธ์, และ การประกอบเมฆ
ERDDAP .
ERDDAP™ เป็นโปรแกรมเว็บและบริการเว็บ ที่รวบรวมข้อมูลทางวิทยาศาสตร์ จากแหล่งต่าง ๆ ในท้องถิ่นและระยะไกล และเสนอวิธีง่ายๆ ที่ต่อเนื่องในการดาวน์โหลดสับเซตของข้อมูลในรูปแบบแฟ้มเดียวกัน และทํากราฟและแผนที่ เว็บไซต์ นี้ พิจารณา ประเด็น ที่ เกี่ยว ข้อง กับ ความ หนัก ERDDAP™ การ ใช้ ของ หนัก และ การ สํารวจ ความ เป็น ไป ได้ สําหรับ การ จัด การ กับ ของ หนัก ที่ หนัก หน่วง มาก ๆ ผ่าน ทาง ตาราง, กระจุก ดาว, เครื่อง ดูด ฝุ่น, และ การ คํานวณ เมฆ.
- ต้นฉบับเขียนขึ้นในเดือนมิถุนายน 2009. ไม่มีการเปลี่ยนแปลงที่สําคัญ นี่เป็นการปรับปรุงล่าสุด 2019-04-15
เดซิลิเมก้า
เนื้อหาในเว็บเพจนี้ คือ บ็อบ ไซมอนส์ ความคิดเห็นส่วนตัว และไม่จําเป็นต้องสะท้อนให้เห็นถึงตําแหน่งที่รัฐบาลหรือ National Oceanic and Atmospheric Administration . การ คํานวณ เป็น แบบ เรียบ ง่าย แต่ ผม คิด ว่า ข้อ สรุป นั้น ถูก ต้อง. ผมใช้ตรรกะที่ผิดหรือคํานวณผิดพลาด? ถ้าเป็นอย่างนั้น ความผิดก็คือฉันคนเดียว โปรดส่งอีเมลพร้อมกับการแก้ไขไปยัง erd dot data at noaa dot gov .
ภาระ หนัก / ข้อ ท้าทาย
ด้วยการใช้งานอย่างหนัก โดดเดี่ยว ERDDAP™ จะถูกบีบคั้น (จากมากที่สุดที่จะเป็นไปได้น้อยที่สุด) โดย:
แบนด์วิธทางไกล
- แบนด์วิธของแหล่งข้อมูลจากระยะไกล แม้จะมีการเชื่อมต่อที่มีประสิทธิภาพ (อี.จี. ผ่าน OPeNDAP ) ยกเว้นข้อมูลระยะไกล มีการเชื่อมต่ออินเทอร์เน็ตแบบแบนด์วิดสูง ERDDAP การตอบรับจะถูกจํากัดด้วยความเร็ว ERDDAP™ สามารถได้ข้อมูลจากแหล่งข้อมูล คําตอบคือคัดลอกชุดข้อมูลไปยัง ERDDAP ฮาร์ดไดรฟ์ อาจจะด้วย EDDGrid คัดลอก หรือ โปรแกรมคัดลอก DDTable .
ERDDAP เครื่องแม่ข่ายแบนด์วิธ
- เว้นแต่ว่า ERDDAP เซิร์ฟเวอร์มีการเชื่อมต่ออินเทอร์เน็ตแบบแบนด์วิธสูงมาก ERDDAP การตอบรับจะถูกจํากัดด้วยความเร็ว ERDDAP™ สามารถได้ข้อมูลจากแหล่งข้อมูล และเร็วแค่ไหน ERDDAP™ สามารถคืนข้อมูลให้ลูกค้าได้ ทางแก้เดียวคือ เชื่อมต่ออินเทอร์เน็ตได้เร็วขึ้น
หน่วยความจํา
- ถ้ามีคําขอมากมาย ERDDAP™ อาจหมดความทรงจํา และปฏิเสธคําขอใหม่ชั่วคราว ( ERDDAP™ มี กลวิธี สอง อย่าง ที่ จะ หลีก เลี่ยง และ ลด ผล ที่ ตาม มา หาก เกิด ขึ้น.) ดังนั้นยิ่งหน่วยความจําในเซิร์ฟเวอร์ยิ่งดี บนเซิร์ฟเวอร์ 32 บิต 4+ GB เป็นสิ่งที่ดีจริงๆ 2 GB จะโอเค ไม่ขอแนะนําให้ใช้น้อยกว่า บนเซิร์ฟเวอร์ 64 บิต คุณสามารถหลีกเลี่ยงปัญหาได้เกือบทั้งหมด โดยได้รับหน่วยความจําจํานวนมาก ดู ตั้งค่า /- Xmx และ - Xms สําหรับ ERDDAP ทอมแคท ขนาด ERDDAP™ การใช้คอมพิวเตอร์อย่างหนัก โดยมีบริการบริการ 64 บิตที่มีหน่วยความจํา 8GB และ - Xmx ที่กําหนดเป็น 4000M แทบจะไม่ถูกจํากัดด้วยหน่วยความจํา
ไดรฟ์แบนด์วิธ
- การเข้าถึงข้อมูลในฮาร์ดไดรฟ์ของเครื่องแม่ข่ายนั้น เร็วกว่าการเข้าถึงข้อมูลจากระยะไกลอย่างมาก ถึงอย่างนั้นก็เถอะ ERDDAP™ แม่ข่ายให้บริการมีการเชื่อมต่ออินเทอร์เน็ตแบบแบนด์วิดที่สูงมาก เป็นไปได้ว่าการเข้าถึงข้อมูลในฮาร์ดไดรฟ์ จะเป็นคอขวด คําตอบบางส่วนคือให้เร็วกว่า (e.g., 10,000 RPM) ฮาร์ดไดรฟ์แม่เหล็กหรือไดรฟ์ SSD (ถ้ามันสมเหตุสมผล ค่าใช้จ่ายอย่างชาญฉลาด) . ทาง แก้ อีก อย่าง หนึ่ง คือ เก็บ ชุด ข้อมูล ที่ ต่าง กัน ไว้ ใน ไดรฟ์ ต่าง ชนิด เพื่อ ว่า ฮาร์ดไดรฟ์ ที่ สะสม ไว้ จะ สูง กว่า มาก.
มีหลายแฟ้มที่ถูกแคชไว้
- มีแฟ้มมากเกินไปใน แคช ไดเรกทอรี — ERDDAP™ จัดเก็บภาพทั้งหมด แต่จะบันทึกเฉพาะข้อมูลที่ร้องขอมา มันเป็นไปได้ที่ไดเร็กทอรีแคชสําหรับชุดข้อมูลจะมีแฟ้มจํานวนมากชั่วคราว นี่จะเป็นการชะลอการร้องขอเพื่อดูว่าแฟ้มอยู่ในแคชหรือไม่ (จริงๆเลย!) .<แคช นาที@ label ตั้งค่า. xml ให้คุณตั้งค่าระยะเวลาของแฟ้มที่อยู่ในแคช ก่อนที่จะถูกลบ การหาเลขที่น้อยกว่า จะทําให้ปัญหานี้น้อยที่สุด
ตัวประมวลผลหลัก
- มี 2 อย่างที่ต้องใช้เวลา CPU มาก
- NetCDF 4 และ HDF 5 ตอนนี้สนับสนุนการบีบอัดข้อมูลภายใน การ ทํา ให้ เกิด การ อัด แน่น อย่าง มาก NetCDF 4 / HDF 5 ไฟล์สามารถใช้เวลา 10 หรือมากกว่าวินาที (นั่นไม่ใช่ความผิดพลาด มันเป็นธรรมชาติของการบีบอัด) ดังนั้น การร้องขอข้อมูลแบบพร้อมเพรียงกันหลายชุด กับข้อมูลที่ถูกเก็บไว้ในแฟ้มบีบอัด สามารถทําให้เกิดความเครียดอย่างรุนแรงบนเซิร์ฟเวอร์ใด ๆ ก็ได้ ถ้านี่เป็นปัญหา คําตอบก็คือ เก็บชุดข้อมูลยอดนิยมไว้ในไฟล์ที่ไม่บีบอัด หรือเอาเซิร์ฟเวอร์ที่มี CPU ที่มีแกนมากกว่า
- สร้างกราฟ (รวมแผนที่ด้วย) – 1 วินาทีต่อกราฟ ดังนั้นถ้ามีการขอกราฟแบบไม่ซ้ํากันหลายแบบ ( WMS ลูก ค้า มัก จะ ขอ อย่าง พร้อม เพรียง กัน ถึง 6 ครั้ง!) อาจมีการจํากัด CPU เมื่อผู้ใช้หลายคนกําลังทํางานอยู่ WMS ลูกค้า, นี่กลายเป็นปัญหา
จํานวนตัวอักษร ERDDAP มีกระสุนบาลาแนนซิ่งมั้ย
คําถามมักขึ้นมาว่า "เพื่อจัดการกับภาระหนัก ผมตั้งหลายเดียวกันได้ไหม ERDDAP ที่มีการโหลดสมดุล?" มันเป็นคําถามที่น่าสนใจเพราะมันได้รับได้อย่างรวดเร็วแก่แกนของ ERDDAP การออกแบบ คําตอบสั้นๆคือ "ไม่" ผมรู้ว่ามันเป็นคําตอบที่น่าผิดหวัง แต่มันมีเหตุผลโดยตรงอยู่สองสามข้อ และมีเหตุผลพื้นฐานบางประการ ERDDAP™ เพื่อใช้วิธีการอื่น (ผู้ทรงเกียรติ ERDDAP S, ที่บรรยายในเอกสารนี้) ซึ่งผมเชื่อว่าเป็นทางออกที่ดีกว่า
เหตุผลตรง ๆ ว่าทําไมคุณถึงไม่สามารถ/ไม่ควรตั้งให้เหมือนกันได้ ERDDAP S คือ:
- ให้ ERDDAP™ อ่านแฟ้มข้อมูลแต่ละตัวเมื่อเริ่มใช้ก่อน เพื่อหาช่วงของข้อมูลในแฟ้ม จากนั้นก็เก็บข้อมูลไว้ในแฟ้มดัชนี ต่อมา เมื่อผู้ใช้ร้องขอข้อมูลเข้ามา ERDDAP™ ใช้ดัชนีนั้นเพื่อหาว่าแฟ้มไหนที่จะค้นหาข้อมูลที่ร้องขอมา ถ้ามีหลายแบบเหมือนกัน ERDDAP S, พวกเขาแต่ละคนทําดัชนีนี้ ซึ่งเป็นการเสียความพยายาม ด้วยระบบหล่อเลี้ยงที่บรรยายด้านล่างนี้ การทําดัชนีเพียงครั้งเดียว โดยหนึ่งใน ERDDAP เอส.
- สําหรับการร้องขอของผู้ใช้บางประเภท (อี.จี. สําหรับ .nc แฟ้ม .png, .pdf) ERDDAP™ ต้องสร้างแฟ้มทั้งหมดก่อนที่จะส่งการตอบกลับ ดังนั้น ERDDAP™ จัดเก็บแฟ้มเหล่านี้เป็นเวลาอันสั้น ถ้าคําขอเดียวกันเข้ามา (โดยเฉพาะกับภาพที่มีที่อยู่ URL ฝังอยู่ในหน้าเว็บ) . ERDDAP™ สามารถเรียกแฟ้มที่มีแคชใหม่ได้ ในระบบของหลายเดียวกัน ERDDAP s, แฟ้มที่จัดเก็บเหล่านั้นไม่สามารถใช้ร่วมกันได้, ดังนั้นแต่ละแฟ้ม ERDDAP™ โดยไม่จําเป็น และสร้าง .nc ไฟล์.png หรือ .pdf. ด้วยระบบ feedered ที่บรรยายด้านล่างนี้ ไฟล์ถูกสร้างขึ้นครั้งเดียว โดยหนึ่งใน ERDDAP เอส และใช้ซ้ํา
- ERDDAP ระบบแบ่งรายการไม่ได้ตั้งให้ใช้ร่วมกันหลายระบบ ERDDAP เอส. ตัวอย่างเช่น ถ้าตัวชั่งโหลดส่งผู้ใช้ไปที่หนึ่ง ERDDAP™ และผู้ใช้จะสมัครเข้าใช้ชุดข้อมูล และอื่น ๆ ERDDAP S จะไม่ทราบการสมัครสมาชิกที่ ในภายหลัง หากตัวจัดการการโหลดจะส่งผู้ใช้ไปยังตัวอื่น ERDDAP™ และขอรายชื่อสมาชิกของเขา ERDDAP™ จะบอกว่าไม่มี (นําเขา/เธอที่จะทําสมาชิกซ้ําในอีพีเออื่น ๆ DAP ) . ระบบ รับ ประทาน อาหาร ดัง ที่ พรรณนา ไว้ ข้าง ล่าง ระบบ บอก รับ เพียง แต่ จัด การ โดย ระบบ หลัก, ระบบ สาธารณะ, ประกอบ ERDDAP .
ใช่ สําหรับปัญหาแต่ละข้อ (ด้วยความพยายามอย่างมาก) วิศวกร วิธี แก้ (เพื่อแบ่งปันข้อมูลระหว่าง ERDDAP วินาที) แต่ฉันคิดว่า การบํารุงรักษา ERDDAP กําลังเข้าใกล้ (คํา อธิบาย ส่วน ใหญ่ ของ เอกสาร นี้) เป็นคําตอบโดยรวมที่ดีกว่า, ส่วนหนึ่งเพราะมันเกี่ยวกับ ปัญหาอื่น ๆ ที่มีหลายตัวแปร ERDDAP การใช้ S-ร่วมกับการโหลด-directer ไม่ได้เริ่มใช้ที่อยู่ โดยเฉพาะอย่างยิ่งธรรมชาติที่ผ่านการรับรองแล้วของแหล่งข้อมูลในโลก
มันดีที่สุดที่จะยอมรับความจริงที่ฉันไม่ได้ออกแบบ ERDDAP™ ให้ใช้เป็นจํานวนเท่าเหมือนกัน ERDDAP กับตัวถ่วงดุล ฉันออกแบบอย่างมีสติ ERDDAP™ เพื่อทํางานอย่างดีภายในการบํารุงรักษา ERDDAP s ซึ่งผมเชื่อว่ามีประโยชน์หลายอย่าง โดยเฉพาะอย่างยิ่ง การดูดพลัง ERDDAP s สอดคล้องกับระบบข้อมูลที่เรียบเรียงแล้ว, การกระจายของศูนย์ข้อมูลที่เรามีในโลกแห่งความเป็นจริง (คิดถึงพื้นที่ไอโอเอสที่แตกต่างกัน หรือพื้นที่สังเกตการณ์โคสต์ต่างๆ หรือส่วนต่าง ๆ ของซีเอ็นไอ หรือศูนย์ข้อมูลอื่นๆ อีก 100 แห่ง NOAA หรือ NASA DAACs หรือศูนย์ข้อมูล 1000 ของทั่วโลก) . แทนที่จะบอกศูนย์ข้อมูลของโลกว่า พวกเขาจําเป็นต้องละทิ้งความพยายามของพวกเขา และใส่ข้อมูลทั้งหมดไว้ในศูนย์กลาง "ทะเลสาบดาตา" (ถึงแม้ว่ามันจะเป็นไปได้ ก็เป็นความคิดที่น่ากลัวสําหรับเหตุผลมากมาย -- ดูผลวิเคราะห์ต่างๆ แสดงถึงประโยชน์มากมายของ ระบบที่ถูกปรับให้พอดี ) . ERDDAP การออกแบบทํางานกับโลกอย่างที่มันเป็น ศูนย์ ข้อมูล แต่ ละ แห่ง ซึ่ง ผลิต ข้อมูล สามารถ คงทน, รักษา, และ ให้ ข้อมูล แก่ พวก เขา ต่อ ไป (พวกเขาควรจะ) และยังมี ERDDAP™ ข้อมูลสามารถใช้ได้ในทันที จากศูนย์กลาง ERDDAP โดยไม่ต้องส่งข้อมูลไปยังศูนย์กลาง ERDDAP™ หรือเก็บสําเนาของข้อมูล จริง ๆ แล้ว ชุดข้อมูลที่ให้ สามารถใช้ได้พร้อมกัน จาก ERDDAP™ ในองค์กรที่สร้างและเก็บข้อมูล (อี.) . จาก ERDDAP™ ที่ องค์การ พ่อ แม่ (E.g., IOOS Central) . จากทุกคน NOAA ERDDAP™ . จากรัฐบาลทั้งหมด ERDDAP™ . จากทั่วโลก ERDDAP™ (โกส) . และจาก (มะลาอิกะฮฺ) ผู้ควบคุมอย่างรัดกุม ERDDAP วินาที (เช่น ERDDAP™ ที่สถาบันที่อุทิศให้กับการวิจัย HAB) . โดยหลัก ๆ แล้ว ในทันใด และมีประสิทธิภาพ เพราะเพียง แต่ข้อมูลกํากับจะถูกโอนระหว่าง ERDDAP เอส ไม่ใช่ข้อมูล ดีที่สุด หลังจากเริ่มต้น ERDDAP™ ที่การจัดตั้งองค์กรทั้งหมด ERDDAP เตรียมการได้เร็วมาก (ไม่กี่ชั่วโมง) ด้วยทรัพยากรที่น้อยที่สุด (เซิร์ฟเวอร์หนึ่งที่ไม่จําเป็นต้องใช้ RAID สําหรับจัดเก็บข้อมูล เนื่องจากไม่จัดเก็บข้อมูลภายในเครื่อง) ด้วยต้นทุนที่น้อยที่สุด เมื่อเทียบกับค่าใช้จ่ายในการตั้งและรักษาศูนย์ข้อมูลส่วนกลาง กับทะเลสาบข้อมูล และความต้องการขนาดใหญ่อย่างแท้จริง สําหรับผมแล้ว ERDDAP แนวทางที่เรียบร้อย ชุ่มชื้น เหนือกว่ามาก
ในสถานการณ์ที่ศูนย์ข้อมูลกําหนดต้องการหลาย ERDDAP เพื่อตอบสนองความต้องการ ERDDAP การออกแบบสามารถเข้ากันได้อย่างสมบูรณ์แบบ หรือมากเกินความสามารถของหลายมิติ ERDDAP ใช้วิธีปรับสมดุล คุณมักจะมีทางเลือกในการตั้ง เลเยอร์ ERDDAP วินาที (ดัง ที่ พิจารณา กัน ข้าง ล่าง) แต่ละอันได้ข้อมูลทั้งหมดมาจากคนอื่น ERDDAP S, ไม่สมดุลย์ ในกรณีนี้, ผมแนะนําให้คุณพูดถึง การให้องค์ประกอบแต่ละตัว ERDDAP ชื่อ / ชื่อ สมมุติ (E.g., ภูมิภาค AWS ที่แตกต่างกัน) อี.จี. ERD _สวรรคต ERD [US / เวสต์, ERD I_i ERD _FR ERD IT เพื่อให้ผู้ใช้มีสติ, ทําซ้ํา, ทํางานโดยเฉพาะอย่างยิ่ง ERDDAP ผลประโยชน์ที่เพิ่มขึ้นมาก็คือ คุณได้กําจัดความเสี่ยงนี้ออกจากจุดนึงของความล้มเหลว
กริด, คลัสเตอร์, และ สหพันธ์
ภายใต้การใช้งานที่หนักมากเดียว ERDDAP™ จะวิ่งชนหนึ่งหรือมากกว่า เงื่อนไข แม้ แต่ วิธี แก้ ที่ มี ข้อ เสนอ แนะ ไว้ ข้าง บน และ แม้ แต่ ก็ ไม่ เพียง พอ. สําหรับสถานการณ์ดังกล่าว ERDDAP™ มีคุณลักษณะที่ทําให้ง่ายต่อการสร้างตารางที่เขียนได้ (หรือเรียกว่า ช่อ หรือ ปอกเปลือก) ของ ERDDAP s ซึ่งช่วยให้ระบบจัดการการใช้งานอย่างหนัก (เช่น ศูนย์ข้อมูลขนาดใหญ่) .
ฉันกําลังใช้ ตาราง เป็นคําทั่วไปที่จะระบุ กระจุก ดาว ที่ ซึ่ง ส่วน ต่าง ๆ ทั้ง หมด อาจ ตั้ง หรือ ไม่ อาจ ตั้ง อยู่ ใน สถาน ที่ ใด แห่ง หนึ่ง และ อาจ มี การ จัด การ หรือ ไม่ อาจ จัด การ โดย ตรง ได้. ผลประโยชน์จากการแยกกันอยู่ เป็นศูนย์กลางและดําเนินการระบบ (มวล) คือมันได้รับประโยชน์จากระบบเศรษฐกิจ (โดยเฉพาะงานของมนุษย์) และ ทํา ให้ ส่วน ต่าง ๆ ของ ระบบ เป็น อย่าง ดี ด้วย กัน. เป็นข้อได้เปรียบของตารางที่ไม่ต้องวางจําหน่าย ไม่ใช้มาตรฐานและดําเนินการ (แหล่งป้อน) พวก เขา แจก จ่าย ภาระ งาน ของ มนุษย์ และ ค่า ใช้ จ่าย และ อาจ ให้ การ ยอม รับ ผิด เพิ่ม ขึ้น อีก. ทาง แก้ ที่ ผม เสนอ ให้ ข้าง ล่าง ใช้ ได้ ผล ดี สําหรับ ทุก ตาราง เวลา, กระจุก ดาว, และ เครื่อง ขยาย เสียง.
แนว คิด พื้น ฐาน เกี่ยว กับ การ ออก แบบ ระบบ ที่ ยืดหยุ่น ได้ ก็ คือ การ ระบุ ว่า คอ ขวด ที่ อาจ เป็น ไป ได้ และ จาก นั้น ก็ ออก แบบ ระบบ นี้ เพื่อ จะ สามารถ เลียน แบบ ส่วน ต่าง ๆ ของ ระบบ ได้ ตาม ความ จําเป็น เพื่อ บรรเทา คอ ขวด. ในอุดมคติแล้ว แต่ละส่วนจําลอง เพิ่มความจุของส่วนนั้นของระบบ (ประสิทธิภาพของการปรับขนาด) . ระบบนี้ไม่สามารถตรวจสอบได้ นอกจากจะแก้ปัญหาได้ทุกขวด ความแหลม: แตกต่างจากประสิทธิภาพ (งาน จะ ทํา ได้ เร็ว แค่ ไหน — ประสิทธิภาพ ของ ส่วน ต่าง ๆ) . ความทนทานทําให้ระบบเติบโต เพื่อรับมือกับความต้องการใด ๆ ความเปรียบต่าง (การปรับขนาดและการแยกส่วน) กําหนดจํานวนเซิร์ฟเวอร์ ฯลฯ ว่าต้องการทําสิ่งใด เพื่อตอบสนองความต้องการ ความเหมาะสมเป็นสิ่งสําคัญมาก แต่มีข้อจํากัดเสมอ ความทนทานเป็นวิธีแก้ปัญหาเดียวที่ใช้ได้ในการสร้างระบบที่สามารถจัดการ มาก ใช้ยากนะ ตาม ความ เป็น จริง แล้ว ระบบ นี้ จะ สามารถ แยกแยะ ได้ และ มี ประสิทธิภาพ.
เป้า
เป้าหมายของการออกแบบนี้คือ
- เพื่อสร้างสถาปัตยกรรมที่เขียนได้ (ที่สามารถขยายได้อย่างง่ายดาย โดยการจําลองส่วนใด ๆ ที่กลายเป็นภาระมากเกินไป) . เพื่อทําให้ระบบมีประสิทธิภาพ ที่ขยายความสามารถและผ่านข้อมูล ที่ให้ทรัพยากรการคํานวณที่มี (ค่า ใช้ จ่าย มัก จะ เป็น ประเด็น.)
- เพื่อสมดุลกับความสามารถของส่วนต่างๆของระบบ เพื่อที่ว่าส่วนหนึ่งของระบบ จะไม่ครอบงําส่วนอื่น
- เพื่อสร้างสถาปัตยกรรมง่ายๆ ดังนั้นระบบจึงง่ายต่อการตั้งและจัดการ
- เพื่อสร้างสถาปัตยกรรมที่ใช้งานได้ดี กับทุกๆตารางกราฟ
- เพื่อทําให้ระบบที่ล้มเหลวอย่างสุภาพ และอย่างจํากัด ถ้าส่วนใด ๆ กลายเป็นภาระ (เวลาที่จําเป็นในการคัดลอกชุดข้อมูลขนาดใหญ่ จะจํากัดความสามารถในการจัดการระบบ การเพิ่มขึ้นอย่างฉับพลัน ในความต้องการสําหรับชุดข้อมูลเฉพาะ)
- (ถ้าเป็นไปได้) เพื่อสร้างสถาปัตยกรรมที่ไม่เกี่ยวข้องกับอะไรเป็นพิเศษ การคํานวณของเมฆ บริการหรือบริการภายนอกอื่น ๆ (เพราะมันไม่ต้องการพวกเขา) .
แนะนํา
เราแนะนํา
- โดยพื้นฐานแล้ว ผมแนะนําให้ติดตั้งคอมโพไซต์ ERDDAP™ ( D ในแผนภาพ) ซึ่งเป็นปกติ ERDDAP™ ยกเว้นว่ามันแค่ให้ข้อมูลจากคนอื่น ERDDAP เอส. สถาปัตยกรรมของตารางถูกออกแบบให้เปลี่ยนงานให้มากที่สุดเท่าที่จะทําได้ (การใช้ CPU, การใช้หน่วยความจํา, การใช้แถบเวียน) จากผู้ประพันธ์ ERDDAP™ ต่อคนอื่น ๆ ERDDAP เอส.
- ERDDAP™ มีชุดข้อมูลพิเศษสองประเภท EDDGrid จาก เอลด์ดาป ถึง DDTable from Edardp ซึ่งหมายถึง ชุดข้อมูลบนตัวอื่น ๆ ERDDAP เอส.
- เมื่อองค์ประกอบ ERDDAP™ รับการร้องขอข้อมูลหรือภาพจากชุดข้อมูลเหล่านี้, ชุดภาพ ERDDAP™ เปลี่ยนทิศทาง ร้องขอข้อมูลกับคนอื่น ERDDAP™ เซิฟเวอร์ ผล คือ:
- มันมีประสิทธิภาพมาก (CPU, หน่วยความจํา, และแบนด์วิธ) เพราะไม่งั้น
- ภาพ ประกอบ ERDDAP™ ต้องส่งคําขอข้อมูลไปยังคนอื่น ๆ ERDDAP .
- อื่น ๆ ERDDAP™ ต้องเอาข้อมูล, ปฏิรูปมัน, แล้วส่งต่อข้อมูลไปยังองค์ประกอบ ERDDAP .
- ภาพ ประกอบ ERDDAP™ ต้องรับข้อมูล (ใช้แบนด์วิธพิเศษ) การปฏิรูปมัน (ใช้เวลาและหน่วยความจําของ CPU เพิ่มเติม) และส่งข้อมูลไปยังผู้ใช้ (ใช้แบนด์วิธพิเศษ) . โดยเปลี่ยนทิศทางคําขอข้อมูลและอนุญาตให้อื่น ๆ ERDDAP™ เพื่อส่งข้อความไปยังผู้ใช้โดยตรง ERDDAP™ การใช้เวลา CPU, ความจํา, หรือแบนด์วิดท์ ที่ไม่ต้องการข้อมูล
- การเปลี่ยนเส้นทางเป็นแบบโปร่งใสกับผู้ใช้ ไม่คํานึงถึงซอฟต์แวร์ของไคลเอนต์ (เบราว์เซอร์หรือเครื่องมือโปรแกรมหรือบรรทัดคําสั่งอื่น ๆ) .
- มันมีประสิทธิภาพมาก (CPU, หน่วยความจํา, และแบนด์วิธ) เพราะไม่งั้น
ส่วนประกอบกริด
A . สําหรับข้อมูลทั้งหมดที่มีแผ่นพับสูง OPeNDAP เซิร์ฟเวอร์ คุณสามารถเชื่อมต่อโดยตรงไปยังเซิร์ฟเวอร์ทางไกลได้ หากเซิร์ฟเวอร์ทางไกลเป็น ERDDAP™ ใช้ EDDGrid จาก Eddep หรือ EDTable จาก ERDDAP เพื่อให้บริการข้อมูลในคอมโพไซต์ ERDDAP . ถ้าเซิร์ฟเวอร์ทางไกลเป็นชนิดอื่น DAP เซิฟเวอร์, e.g., THEDS, Hyrax หรือ GraADS ใช้ EDDGrid จากแดป
บี สําหรับทุกๆ คน ERDDAP แหล่งที่มาของข้อมูล (แหล่งข้อมูลจาก ERDDAP สามารถอ่านข้อมูลได้) ที่มีเซิร์ฟเวอร์แบบ bandwid ที่ติดตั้งใหม่ ERDDAP™ ในตารางที่มีหน้าที่ให้บริการ ข้อมูลจากแหล่งข้อมูลนี้
- ถ้าหลายเช่น ERDDAP s ไม่ได้ขอข้อมูลมากนัก, คุณสามารถรวมมันเข้ากับ 1 ได้ ERDDAP .
- ถ้า ERDDAP™ ทุ่มเทเพื่อหาข้อมูลจากแหล่งห่างไกลแหล่งหนึ่ง มีการร้องขอมากเกินไป มีสิ่งล่อใจที่จะเพิ่ม ERDDAP s เพื่อเข้าถึงแหล่งข้อมูลทางไกล ใน กรณี พิเศษ นี้ อาจ ฟัง ดู มี เหตุ ผล แต่ ดู เหมือน ว่า เรื่อง นี้ จะ ครอบ คลุม ข้อมูล ที่ อยู่ ห่าง ไกล (ซึ่งคือการป้องกันตัวเอง) และป้องกันผู้ใช้อื่น ๆ จากการเข้าถึงข้อมูลระยะไกล (ซึ่งไม่ดี) . ใน กรณี เช่น นั้น ขอ ให้ พิจารณา การ ตั้ง อีก คน หนึ่ง ERDDAP™ เพื่อให้บริการชุดข้อมูลหนึ่ง และคัดลอกชุดข้อมูลบนที่ ERDDAP ฮาร์ดไดรฟ์ (ดู C ) บางทีกับ EDDGrid คัดลอก &/ หรือ โปรแกรมคัดลอก DDTable .
- บี แม่ข่ายจะต้องเข้าถึงสาธารณะ
C สําหรับทุกๆ คน ERDDAP แหล่งข้อมูล - language ที่มีเซิร์ฟเวอร์แบบบล็อคต่ํา (หรือเป็นบริการที่ช้าด้วยเหตุผลอื่น) (ดูกร) ERDDAP™ และเก็บสําเนาของชุดข้อมูลนั้น ERDDAP ฮาร์ดไดรฟ์ อาจจะด้วย EDDGrid คัดลอก &/ หรือ โปรแกรมคัดลอก DDTable . ถ้าหลายเช่น ERDDAP s ไม่ได้ขอข้อมูลมากนัก, คุณสามารถรวมมันเข้ากับ 1 ได้ ERDDAP . C แม่ข่ายจะต้องเข้าถึงสาธารณะ
คอมโพไซต์ ERDDAP
D . ภาพ ประกอบ ERDDAP™ เป็นปกติ ERDDAP™ ยกเว้นว่ามันแค่ให้ข้อมูลจากคนอื่น ERDDAP เอส.
- เพราะองค์ประกอบ ERDDAP™ มีข้อมูลอยู่ในหน่วยความจําเกี่ยวกับชุดข้อมูลทั้งหมด มันสามารถตอบสนองต่อการร้องขอสําหรับรายการชุดข้อมูล (ค้นหาข้อความเต็มรูปแบบ, หมวดหมู่การค้นหา, รายการของชุดข้อมูลทั้งหมด) และร้องขอข้อมูลส่วนตัว เข้าสู่ระบบข้อมูล, สร้างรูปแบบกราฟ, หรือ WMS หน้าข้อมูล นี่เป็นหน้าเล็กๆ ที่สร้างมาแบบไม่ตายตัว โดยอิงจากข้อมูลที่ถูกเก็บในหน่วยความจํา ดังนั้นการตอบสนองก็เร็วมาก
- เพราะการขอข้อมูลจริงๆ จะหันไปทางอื่นอย่างรวดเร็ว ERDDAP s, องค์ประกอบ ERDDAP™ สามารถตอบสนองต่อการขอข้อมูลจริงได้อย่างรวดเร็ว โดยไม่ต้องใช้เวลา CPU ใด ๆ, ความจํา, หรือแบนด์วิธ
- โดยการเลื่อนงานให้มากที่สุดเท่าที่จะทําได้ (CPU, หน่วยความจํา, แบนด์วิธ) จากผู้ประพันธ์ ERDDAP™ ต่อคนอื่น ๆ ERDDAP s, องค์ประกอบ ERDDAP™ สามารถดูข้อมูลจากชุดข้อมูลทั้งหมด และยังติดตามดูข้อมูลจํานวนมาก ที่ร้องขอจากผู้ใช้จํานวนมาก
- การ ทดสอบ ขั้น ต้น บ่ง ชี้ ว่า ประกอบ ERDDAP™ สามารถตอบสนองต่อการร้องขอส่วนใหญ่ใน ~1 มิลลิวินาทีของเวลา CPU หรือ 1000 ครั้ง/วินาที ดังนั้น ตัวประมวลผลหลัก 8 ตัว ควรจะตอบสนองความต้องการ 8000 ครั้ง/วินาที แม้ ว่า เป็น ไป ได้ ที่ จะ นึก ภาพ การ ระเบิด ของ กิจกรรม ที่ สูง กว่า ซึ่ง จะ ทํา ให้ ช้า ลง แต่ ก็ มี การ เจาะ ลึก มาก. เป็นไปได้ว่าศูนย์ข้อมูลแบนด์วิธ จะเป็นคอขวดนานก่อนที่จะประกอบ ERDDAP™ กลายเป็นคอขวด
ขยายใหญ่สุด (เวลา) ?
เดอะ EDDGrid / Tube from Dardp in the genet ERDDAP™ เปลี่ยนเฉพาะข้อมูลที่เก็บเกี่ยวกับชุดข้อมูลแหล่งแต่ละชุดเมื่อชุดข้อมูลต้นฉบับ "โหลดใหม่" และส่วนบางส่วนของการเปลี่ยนแปลง (เช่น ตัวแปรเวลา actual\_range ) จึงทําให้เกิดการแจ้งข้อมูล ถ้าชุดข้อมูลต้นฉบับมีข้อมูลที่เปลี่ยนแปลงบ่อยครั้ง (ตัวอย่างเช่น ข้อมูลใหม่ทุกๆวินาที) และใช้ "อัพเดต" ระบบที่จะสังเกตเห็นการเปลี่ยนแปลงบ่อยครั้งกับข้อมูลพื้นฐาน, EDDGrid / Table from Eddradap จะไม่ได้รับแจ้งเกี่ยวกับการเปลี่ยนแปลงที่เกิดขึ้นบ่อย ๆ นี้ จนกว่าชุดข้อมูลถัดไป "โหลด", ดังนั้น EDDGrid - Table จาก Eddadap จะไม่ได้สมบูรณ์ขึ้นสู่วันที่ คุณสามารถทําให้ปัญหานี้น้อยที่สุด โดยการเปลี่ยนข้อมูลแหล่ง<โหลดรายการทุก ๆNMitutes> ไปยังค่าที่น้อยกว่า (60 หรือ 15) เพื่อให้มีการแจ้งข้อมูลเพิ่มเติมที่จะบอกว่า EDDGrid สืบค้นข้อมูลแหล่งข้อมูล
หรือ ถ้าระบบจัดการข้อมูลของคุณรู้ เมื่อข้อมูลแหล่งมีข้อมูลใหม่ (เช่น โดยใช้สคริปต์ที่คัดลอกแฟ้มข้อมูลเข้าที่) และถ้ามันไม่บ่อยมากๆ (เช่นทุกๆ 5 นาที หรือบ่อยขึ้น) มีทางออกที่ดีกว่า
- อย่าใช้<อัปเดต AllNMilles> เพื่อให้ข้อมูลแหล่งที่มาตั้งค่าขึ้นถึงวันที่
- ตั้งค่าชุดข้อมูลต้นฉบับ<โหลดรายการทุก ๆ NMituts> ไปยังหมายเลขที่มากกว่า (1440?) .
- ให้ติดต่อสคริปต์ชุดข้อมูลต้นฉบับ ที่อยู่ URL ธง หลังจากที่มันคัดลอกไฟล์ข้อมูลใหม่เข้ามา นั่นจะนําไปสู่ข้อมูลแหล่ง ที่สมบูรณ์แบบขึ้นถึงวัน และทําให้มันสร้างการแจ้งรับข้อมูล ซึ่งจะส่งไปยัง EDDGrid ข้อมูลจาก Eddadap นั่นจะนํา EDDGrid ข้อมูลต่าง ๆ ของปฏิทิน (ภายใน 5 วินาที ข้อมูลใหม่จะถูกเพิ่ม) . และทุกสิ่งที่จะทําอย่างมีประสิทธิภาพ (โดยไม่ต้องใส่ข้อมูลซ้ํา) .
คอมโพไซต์หลายอัน ERDDAP วินาที
- ในกรณีที่รุนแรงมากหรือสําหรับ การยอมรับผิดคุณอาจต้องการที่จะตั้งค่ามากกว่าหนึ่งองค์ประกอบ ERDDAP . เป็นไปได้ว่าส่วนอื่นของระบบ (โดยเฉพาะที่ศูนย์ข้อมูล) จะกลายเป็นปัญหาได้นานก่อนที่จะประกอบ ERDDAP™ กลายเป็นคอขวด ดังนั้นคําตอบน่าจะเป็น การตั้งศูนย์ข้อมูล ที่หลากหลายทางภูมิศาสตร์ (กระจก) แต่ละอันมีองค์ประกอบหนึ่ง ERDDAP™ และเซิร์ฟเวอร์ด้วย ERDDAP s และ (อย่างน้อย) สําเนาของชุดข้อมูล ที่มีความต้องการสูง การตั้งค่าดังกล่าวยังให้ความอดทนผิดและสํารองข้อมูลข้อมูล (ผ่านการคัดลอก) . ในกรณีนี้, มันจะดีที่สุดหากคอมโพสิท ERDDAP s มีที่อยู่ URL ต่างกัน
ถ้าคุณอยากได้คอมโพสิททั้งหมด ERDDAP s เพื่อให้มีที่อยู่ URL เดียวกัน โดยใช้ระบบปลายหน้า ที่กําหนดผู้ใช้ให้เพียงแค่หนึ่งในองค์ประกอบภาพ ERDDAP วินาที (ตามที่อยู่ IP) เพื่อให้การร้องขอของผู้ใช้ทั้งหมดไปเพียงแค่หนึ่งในองค์ประกอบ ERDDAP เอส. มีเหตุผลสองอย่าง
- เมื่อชุดข้อมูลพื้นฐานถูกโหลดใหม่อีกครั้งและการเปลี่ยนแปลงข้อมูลกํากับภาพ (เช่น ไฟล์ข้อมูลใหม่ในชุดข้อมูลแบบฝังตัว ทําให้เกิดตัวแปรเวลา actual\_range เพื่อเปลี่ยน) องค์ประกอบ ERDDAP แต่ด้วย ความสอดคล้องในที่สุด . โดยปกติ มันจะกลับมาเดินใหม่ภายใน 5 วินาที แต่บางครั้งมันจะยาวขึ้น หากผู้ใช้สร้างระบบอัตโนมัติที่ขึ้นอยู่กับ ERDDAP™ สมาชิก การกระทําของตัวกระตุ้นนั้น ปัญหาการประสานสั้น ๆ จะมีความสําคัญ
- ชุด 2+ ERDDAP แต่ ละ คน รักษา การ บอก รับ ของ ตน เอง (เพราะปัญหาความต่อเนื่องที่บรรยายไว้) .
ดังนั้น ผู้ใช้ควรถูกกํากับให้ทําการประกอบ ERDDAP เพื่อหลีกเลี่ยงปัญหาเหล่านี้ ถ้าหนึ่งในองค์ประกอบ ERDDAP s ลง, ระบบปลายด้านหน้าสามารถเปลี่ยนเส้นทางที่ ERDDAP ผู้ใช้ไปยังผู้ใช้อื่น ERDDAP™ นั่นขึ้น อย่างไรก็ตาม ถ้ามันเป็นปัญหาความจุ ที่ทําให้เกิดองค์ประกอบแรก ERDDAP™ ล้มเหลว (ผู้ใช้ที่ตื่นตระหนกเกินไป? คือ การปฏิเสธการให้บริการ ?) นี้ทําให้เป็นไปได้มากที่การเปลี่ยนผู้ใช้ของตนไปยังองค์ประกอบอื่น ๆ ERDDAP s จะทําให้เกิด การเข้ารหัสล้มเหลว . ด้วย เหตุ นี้ การ จัด เตรียม ที่ มั่นคง ที่ สุด ก็ คือ การ ประกอบ ด้วย ERDDAP ที่อยู่ URL ที่แตกต่างกัน
หรือ, บางที, ควรตั้งหลายองค์ประกอบ ERDDAP ไม่ใส่น้ําหนัก ในกรณีนี้, คุณควรตั้งประเด็นว่า ERDDAP ชื่อ / ชื่อ สมมุติ (E.g., ภูมิภาค AWS ที่แตกต่างกัน) อี.จี. ERD _สวรรคต ERD [US / เวสต์, ERD I_i ERD _FR ERD IS_IT เพื่อให้ผู้ใช้มีสติ ทํางานซ้ําด้วยการระบุ ERDDAP .
- \[ สําหรับการออกแบบที่น่าตื่นตาตื่นใจของระบบประสิทธิภาพสูงที่ทํางานบนเซิร์ฟเวอร์หนึ่งเห็นนี้ รายละเอียดของผู้ส่ง . \]
ชุด ข้อมูล ใน ความ ต้องการ สูง
ในกรณีผิดปกติจริงๆ ที่หนึ่งใน A . บี หรือ C ERDDAP s ไม่สามารถทําตามคําขอได้เพราะข้อจํากัดแบนด์วิดหรือฮาร์ดไดรฟ์, มันสมเหตุสมผลที่จะคัดลอกข้อมูล (อีกครั้ง) บนเซิร์ฟเวอร์อื่น+ฮาร์ด ไดรฟ์+ ERDDAP บางทีกับ EDDGrid คัดลอก &/ หรือ โปรแกรมคัดลอก DDTable . ถึง แม้ อาจ ดู เหมือน เหมาะ ที่ สุด ที่ จะ มี ชุด ข้อมูล ดั้งเดิม และ ชุด ข้อมูล ที่ คัด ลอก มา นั้น ดู เหมือน ไม่ มี อะไร เหมือน เป็น ข้อมูล ชุด เดียว ใน ชุด ข้อมูล เหล่า นั้น ERDDAP™ นี่เป็นเรื่องยาก เพราะชุดข้อมูลทั้งสอง จะอยู่คนละรัฐกัน (โดดเด่น, หลังจากที่ต้นฉบับได้รับข้อมูลใหม่ แต่ก่อนที่ชุดข้อมูลคัดลอกจะได้รับสําเนา) . ดังนั้น ผมขอแนะนําว่า ชุดข้อมูลเหล่านี้ ได้รับชื่อที่แตกต่างกันเล็กน้อย (อี.จี. (คัดลอก #1) และ... (คัดลอก # 2) "หรือบางที" (กระจก # n ) หรือ (เซิร์ฟเวอร์ # n ) ") และปรากฏเป็นชุดข้อมูลแยกในองค์ประกอบ ERDDAP . ผู้ใช้มักใช้ดูรายการ ทํากระจกเงาไซต์ ที่ไซต์ดาวน์โหลดเอกสารที่ได้รับความนิยม ดังนั้น นี่จึงไม่ทําให้แปลกใจหรือทําให้พวกเขาผิดหวัง เนื่อง จาก มี ขีด จํากัด ของ แถบ แบน วิช ใน สถาน ที่ แห่ง หนึ่ง จึง นับ ว่า มี เหตุ ผล ที่ จะ มี กระจก ที่ อีก แห่ง หนึ่ง. ถ้าการคัดลอกกระจกอยู่ที่ศูนย์ข้อมูลอื่น การเข้าถึงเพียงโดยองค์ประกอบของศูนย์ข้อมูลที่ ERDDAP™ ตําแหน่งที่แตกต่างกัน (E.g., "Meror #1.) ไม่จําเป็น
เชื้อ รา กับ ฮาร์ด ไดรฟ์ ปกติ
หากชุดข้อมูลขนาดใหญ่หรือกลุ่มข้อมูลไม่ได้ถูกใช้อย่างหนัก มันอาจจะมีเหตุผลในการเก็บข้อมูลบน RAID เนื่องจากมันนําเสนอการยอมรับข้อผิดพลาด และเนื่องจากคุณไม่ต้องการพลังงานในการประมวลผล หรือแบนวิทของเซิร์ฟเวอร์อื่น แต่หากใช้ชุดข้อมูลอย่างหนัก อาจจะมีเหตุผลมากขึ้นในการคัดลอกข้อมูล บนเซิร์ฟเวอร์อื่น + ERDDAP™ เพิ่มฮาร์ดไดรฟ์ (คล้าย สิ่งที่กูเกิ้ลทํา ) แทนที่จะใช้เครื่องแม่ข่ายหนึ่งเครื่อง และ RAID เพื่อใช้จัดเก็บข้อมูลต่าง ๆ เนื่องจากคุณสามารถใช้งานทั้งเซิร์ฟเวอร์+ฮาร์ด Dreview+ ERDDAP ในตารางจนกว่าหนึ่งในนั้นจะล้มเหลว
ล้มเหลว
จะเกิดอะไรขึ้นถ้า...
- มีการขอข้อมูลหนึ่งชุด (เช่น นักเรียนทุกคนในห้องเรียน ขอข้อมูลที่คล้ายกันพร้อมกัน) ? เฉพาะ ERDDAP™ การรับข้อมูลชุดนั้นจะถูกเพิ่มข้อมูลจนล้น และจะชะลอหรือปฏิเสธการร้องขอ ภาพ ประกอบ ERDDAP™ และอื่น ๆ ERDDAP ไม่ได้รับผลกระทบ เนื่องจากตัวประกอบการจํากัดสําหรับชุดข้อมูลที่กําหนดภายในระบบคือฮาร์ดไดรฟ์ที่มีข้อมูล (ไม่ ERDDAP ) คําตอบเดียว (ไม่ใช่ทันที) คือทําสําเนาชุดข้อมูลต่าง ๆ บนเซิร์ฟเวอร์อื่น ๆ+ฮาร์ด Dreviive+ ERDDAP .
- ขนาด A . บี หรือ C ERDDAP™ ล้มเหลว (เช่น ฮาร์ดไดรฟ์ล้มเหลว) ? เฉพาะชุดข้อมูล (วินาที) เสิร์ฟโดย ERDDAP™ ได้รับผลกระทบ ถ้าชุดข้อมูล (วินาที) มีกระจกเงาบนเซิร์ฟเวอร์อื่น+ฮาร์ดฟลายซ์+ ERDDAP ผลกระทบน้อยที่สุด ถ้าปัญหาคือฮาร์ดไดรฟ์ล้มเหลวในระดับ 5 หรือ 6 RAID คุณแค่เปลี่ยนไดรฟ์ และให้ RAID สร้างข้อมูลขึ้นมาใหม่ในไดรฟ์
- ภาพ ประกอบ ERDDAP™ ล้มเหลว? ถ้าคุณต้องการสร้างระบบที่มี มีความสามารถสูง คุณสามารถตั้งค่า เลเยอร์ ERDDAP วินาที (ดัง พิจารณา ข้าง ต้น) ใช้บางอย่างเช่น INX หรือ สี่เหลี่ยม เพื่อจัดการสมดุลย์ สังเกตว่าชุดที่ให้มา ERDDAP™ สามารถจัดการกับการร้องขอจํานวนมากจากผู้ใช้จํานวนมากเพราะ การขอข้อมูลกํากับนั้นเล็กมาก และถูกจัดการโดยข้อมูลที่อยู่ในหน่วยความจํา ร้องขอข้อมูล (ที่อาจจะมีขนาดใหญ่) หันไปหาเด็ก ERDDAP เอส.
พิมพ์แบบง่าย ๆ
ระบบนี้ตั้งและจัดการง่าย และสามารถทํางานได้อย่างง่ายดาย เมื่อส่วนใดส่วนหนึ่งของมัน กลายเป็นภาระเกินเหตุ ข้อจํากัดที่แท้จริงสําหรับศูนย์ข้อมูลที่ให้มา คือข้อมูลแบนด์วิธ และค่าใช้จ่ายของระบบ
แบนด์วิธ
โปรด สังเกต ดู ส่วน ประกอบ ต่าง ๆ ของ ระบบ ที่ ใช้ กัน ทั่ว ไป โดย ประมาณ:
| ส่วนประกอบ | แบนด์วิดีท (ไบต์/ วินาที) |
|---|---|
| หน่วยความจําของ DDR | 2.5 |
| ไดรฟ์ SSD | 1 |
| ฮาร์ดไดรฟ์ SATA | 0.3 |
| กิกาบิต Etronet | 0.1 |
| OC-12 | 0.06 |
| OC-3 | 0.015 |
| T1 | 0.0002 |
ฮาร์ดไดรฟ์ของ SATA (0.3GB/s) บนเซิร์ฟเวอร์หนึ่งเครื่อง ERDDAP™ อาจจะ saturate a Gigabit Eathernet lan (0.1GB/s) . และ Gigabit Eternet LAN (0.1GB/s) อาจจะทําให้อินเทอร์เน็ตเชื่อมต่อ OC-12 ได้ (0. 06GB/s) . และอย่างน้อย 1 แหล่งที่มา รายชื่อ โอซี-12 บรรทัด ราคาประมาณ 100,000 บาทต่อเดือน (ใช่ แล้ว การ คํานวณ เหล่า นี้ อาศัย การ ผลัก ดัน ระบบ ไป สู่ ขีด จํากัด ซึ่ง ไม่ ดี เพราะ ทํา ให้ เกิด การ ตอบ สนอง ที่ เฉื่อย ชา. แต่การคํานวณเหล่านี้มีประโยชน์ในการวางแผน และสําหรับการสมดุลส่วนของระบบ) เห็น ได้ ชัด ว่า การ เชื่อม ต่อ อินเทอร์เน็ต อย่าง รวด เร็ว ใน ศูนย์ ข้อมูล ของ คุณ เป็น ส่วน ที่ แพง ที่ สุด ของ ระบบ. คุณสามารถง่ายและค่อนข้างสร้างตารางที่มีโหลเซิร์ฟเวอร์ทํางานโหล ERDDAP S ซึ่งสามารถปล่อยข้อมูลออกมาอย่างรวดเร็ว แต่การเชื่อมต่ออินเทอร์เน็ตแบบเร็วนั้น คําตอบบางส่วนก็คือ
- สนับสนุนลูกค้าให้ร้องขอสับเซตของข้อมูล หากนั่นคือทั้งหมดที่จําเป็น ถ้าลูกค้าต้องการแค่ข้อมูล สําหรับพื้นที่เล็ก ๆ หรือในความละเอียดที่ต่ํากว่า นั่นคือสิ่งที่พวกเขาควรจะร้องขอ การ จัด การ เป็น จุด รวม ของ โปรโตคอล ERDDAP™ รองรับการร้องขอข้อมูล
- สนับสนุนการส่งข้อมูลบีบอัด ERDDAP™ บีบข้อมูล การส่งข้อมูล หากมันพบ "การตอบรับ" ใน HTTP GET ขอส่วนหัว โปรแกรมเว็บเบราว์เซอร์ทั้งหมดจะใช้ "การรับ- เชื่อมต่อ" และลดการตอบสนองโดยอัตโนมัติ ลูกข่ายอื่น ๆ (เช่น โปรแกรมคอมพิวเตอร์) ต้องใช้มันโดยตรง
- จับคู่เซิร์ฟเวอร์ของคุณที่ ISP หรือเว็บไซต์อื่น ๆ ที่ให้ต้นทุนที่ค่อนข้างแพง
- แยกเซิร์ฟเวอร์ด้วย ERDDAP สถาบันต่างๆจึงมีค่าใช้จ่ายที่กระจัดกระจาย คุณสามารถเชื่อมโยงองค์ประกอบของคุณ ERDDAP™ ถึงพวกเขา ERDDAP เอส.
สังเกตว่า การซ้อนทับเมฆ และบริการการเป็นเจ้าภาพเว็บ ก็เสนอโครงการอินเทอร์เน็ตแบนด์วิธที่คุณต้องการ แต่อย่าแก้ปัญหาราคา
สําหรับข้อมูลทั่วไปเกี่ยวกับการออกแบบ Scalable ความจุสูง ระบบจับเท็จ ดูหนังสือของไมเคิล ที ไนการ์ด ปล่อย .
เหมือนเลโก้
นักออกแบบซอฟต์แวร์มักจะพยายามใช้ รูปแบบการออกแบบซอฟต์แวร์ เพื่อแก้ไขปัญหา รูปแบบที่ดีนั้นดี เพราะมันบอกค่าที่ดี, ง่ายต่อการสร้าง และทํางานกับ, วิธีแก้ปัญหาทั่วไป ชื่อรูปแบบไม่ได้มาตรฐาน, ผมจะเรียกว่ารูปแบบ ERDDAP™ ใช้รูปแบบเลโก้ เลโก้ แต่ ละ ตัว (แต่ละ ERDDAP ) ♪ is simple, ขนาดเล็ก, มาตรฐาน, stand-one,อิฐ (เซิร์ฟเวอร์ข้อมูล) กับส่วนเชื่อมต่อที่นิยามไว้ ที่ช่วยให้มันเชื่อมต่อกับ Legos อื่น ๆ ( ERDDAP วินาที) . ส่วนของ ERDDAP™ ที่สร้างระบบนี้ขึ้นมาคือ ระบบสมัครสมาชิกและระบบธง (ซึ่งช่วยให้สื่อสารระหว่าง ERDDAP วินาที) อีดี... ระบบเปลี่ยนเส้นทางจาก Eddep และระบบ RESTful ร้องขอข้อมูลที่สามารถสร้างได้โดยผู้ใช้หรืออื่น ๆ ERDDAP เอส. ด้วย เหตุ นี้ จึง มี การ ให้ ลูก เขย สอง คน หรือ กว่า นั้น ( ERDDAP วินาที) คุณสามารถสร้างรูปร่างที่แตกต่างได้มากมาย (เครือข่าย ERDDAP วินาที) . แน่นอน การออกแบบและคุณสมบัติของ ERDDAP™ อาจจะทําแตกต่างกันไป ไม่ใช่เลโก้ที่เหมือน บางที แค่ให้สามารถและปรับแต่ง แต่เรารู้สึกว่า ERDDAP ออกแบบเหมือนเลโก้ มีวิธีแก้ปัญหาทั่วไปที่ดี ที่ช่วยให้ใด ๆ ERDDAP™ ผู้ดูแล (หรือกลุ่มผู้บริหารระบบ) เพื่อสร้างเครื่องดูดฝุ่นทุกชนิด ตัว อย่าง เช่น อาจ มี องค์การ หนึ่ง ตั้ง ขึ้น ได้ สาม องค์การ (หรือมากกว่านั้น) ERDDAP s ที่แสดงใน ERDDAP™ แผนภูมิตาราง/ Cluster ด้านบน . หรือกลุ่มที่กระจายตัว (ไอโอเอส? โคสต์วอทช์? เซดี้? NWS? NOAA ? USGS? ข้อมูลส่วนตัว? นีออน? LTER? OOI? บ๊อบ? ONC? จอร์ก? WMO?) สามารถสร้าง ERDDAP™ แต่ละด่านเล็ก ๆ (ดังนั้นข้อมูลสามารถอยู่ใกล้กับแหล่ง) แล้วก็ตั้งชุด ERDDAP™ ในสํานักงานส่วนกลางพร้อมกับชุดข้อมูลเสมือน (ซึ่งมักจะสมบูรณ์แบบขึ้นสู่วัน) แต่ละอาคารเล็กๆ ERDDAP เอส. แท้จริงแล้ว ทั้งหมด ERDDAP S, ติดตั้งที่สถาบันต่างๆทั่วโลก, ซึ่งได้รับข้อมูลจากที่อื่น ERDDAP s และ/ หรือให้ข้อมูลอื่น ๆ ERDDAP S, เป็นเครือข่ายขนาดใหญ่ของ ERDDAP เอส. เจ๋งไหมล่ะ? ดังนั้น เช่นเดียวกับเลโก้ ความเป็นไปได้ที่ไม่มีที่สิ้นสุด นั่นคือสาเหตุที่มันเป็นรูปแบบที่ดี นั่นคือสาเหตุที่มันเป็นการออกแบบที่ดี ERDDAP .
คํา ขอ ต่าง ๆ
หนึ่งในปัญหาแทรกซ้อนในชีวิตจริง ของการสนทนาเรื่องเซิร์ฟเวอร์ข้อมูลนี้ คือมีคําขอที่แตกต่างกัน นี่เป็นประเด็นที่แยกต่างหาก (เร็วแค่ไหน ERDDAP™ ด้วยข้อมูลที่ตอบสนองคําขอข้อมูลหรือไม่) จากการสนทนาทางวิทยาศาสตร (จัดการกับความสัมพันธ์ระหว่างเซิร์ฟเวอร์ข้อมูล และเซิร์ฟเวอร์ที่มีข้อมูลจริง) . ERDDAP™ แน่นอน พยายาม จะ รับมือ กับ คํา ขอ ทุก อย่าง อย่าง อย่าง มี ประสิทธิภาพ แต่ ก็ จัด การ ได้ ดี กว่า คน อื่น.
- คํา ขอ หลาย อย่าง ง่าย ๆ. ตัว อย่าง เช่น: ข้อมูลกํากับภาพของชุดข้อมูลนี้คืออะไร? หรือ: ค่าของมิติเวลา สําหรับชุดข้อมูลที่ฝังอยู่เป็นเท่าไหร่? ERDDAP™ มี การ ออก แบบ เพื่อ จัด การ เรื่อง เหล่า นี้ ให้ เร็ว ที่ สุด เท่า ที่ เป็น ไป ได้ (โดย ทั่ว ไป ใน<โดยเก็บข้อมูลนี้ไว้ในความทรงจํา
- การ ขอ บาง อย่าง ยาก พอ สม ควร. ตัว อย่าง เช่น: ให้สับเซตของชุดข้อมูลมา (ซึ่งอยู่ในแฟ้มเดียว) . การขอเหล่านี้สามารถจัดการกับได้ค่อนข้างอย่างรวดเร็ว เพราะพวกเขาไม่ได้เป็นเรื่องยากที่
- คํา ขอ บาง อย่าง ยาก และ จึง ต้อง ใช้ เวลา. ตัว อย่าง เช่น: ให้สับเซตของชุดข้อมูลมา (ซึ่งอาจจะอยู่ในใด ๆ 10,000 + ไฟล์ข้อมูล หรืออาจจะมาจากบีบอัดไฟล์ข้อมูล ที่แต่ละใช้เวลา 10 วินาทีในการย่อยสลาย) . ERDDAP™ v2. 0 ได้แนะนําวิธีใหม่, วิธีที่เร็วกว่าในการจัดการกับการร้องขอเหล่านี้, โดยเฉพาะ โดยอนุญาตให้การร้องขอใช้เธรดจัดการเพื่อวางเส้นด้ายงานหลายๆ เส้นซึ่งจัดการสับเซตต่างๆ ของการร้องขอได้ แต่มันมีอีกวิธีนึงในปัญหานี้ ERDDAP™ ยังไม่รองรับ: สับเซตของแฟ้มข้อมูลสําหรับชุดข้อมูลที่ให้ จะสามารถเก็บและวิเคราะห์บนคอมพิวเตอร์แยกกันได้ และผลลัพธ์ที่ได้จะรวมกันบนเซิร์ฟเวอร์เดิม วิธีนี้เรียกว่า เมือก และเพื่อเป็นการเปรียบเทียบ ♪ had loop อันแรก (?) โปรแกรม open-source MapReducue ซึ่งตั้งอยู่บนพื้นฐานความคิดจากกระดาษกูเกิล (ถ้าคุณต้องการเมเปิลรูซ ERDDAP โปรดส่งการร้องขอไปยัง erd.data at noaa.gov .) กูเกิ้ล สืบค้นใหญ่ มันน่าสนใจเพราะมันดูเหมือนว่าเป็นการจัดระบบของ MapReducs ที่นําไปใช้กับชุดข้อมูลมุมจัดรูปแบบ ซึ่งเป็นหนึ่งใน ERDDAP เป้าหมายหลัก เป็นไปได้ว่าคุณสามารถสร้าง ERDDAP™ ข้อมูลต่าง ๆ จากชุดข้อมูลขนาดใหญ่ที่ใช้ค้นหาผ่านทาง เพิ่มข้อมูล เพราะบิ๊กเซิร์ฟสามารถเข้าถึงได้ผ่านทาง อินเตอร์เฟส JDBC
นี่คือความคิดเห็นของผม
ใช่ การคํานวณมันสั้นเกินไป (และตอนนี้ก็เดท) แต่ฉันคิดว่าข้อสรุปที่ถูกต้อง ผมใช้ตรรกะที่ผิดหรือคํานวณผิดพลาด? ถ้าเป็นอย่างนั้น ความผิดก็คือฉันคนเดียว โปรดส่งอีเมลพร้อมกับการแก้ไขไปยัง erd dot data at noaa dot gov .
การซ้อนทับเมฆ
หลาย บริษัท เสนอ บริการ การ คํานวณ เมฆ (อี.จี. บริการเว็บของ Amazon ถึง กราฟแสดงความถี่ ) . บริษัทโฮสต์เว็บ ได้เสนอบริการที่ง่ายกว่านี้ตั้งแต่กลางปี ค.ศ. ตั้งแต่ ERDDAP™ กริดประกอบด้วย ERDDAP s และตั้งแต่ ERDDAP s คือ Java โปรแกรมเว็บที่สามารถทํางานใน Tomcat (แม่ข่ายโปรแกรมที่ใช้บ่อยที่สุด) หรือเซิร์ฟเวอร์โปรแกรมอื่น ๆ ควรจะตั้งค่าได้ค่อนข้างง่าย ERDDAP™ เครือข่ายบริการเมฆ หรือเว็บไซต์โฮสต์ ข้อดีของบริการเหล่านี้คือ
- พวกเขาเสนอการเข้าถึง การเชื่อมต่ออินเทอร์เน็ตแบบแบนด์วิธ การ ทํา เช่น นี้ เพียง อย่าง เดียว อาจ ทํา ให้ มี เหตุ ผล ที่ จะ ใช้ การ บริการ เหล่า นี้.
- พวกเขาคิดเงินเฉพาะบริการที่คุณใช้ ตัวอย่างเช่น คุณเข้าถึง การเชื่อมต่ออินเทอร์เน็ตแบบแบนด์วิดที่สูงมาก แต่คุณจ่ายค่าข้อมูลเท่านั้น ที่ทําให้คุณสร้างระบบที่ไม่ค่อยถูกครอบงํา (แม้แต่ความต้องการสูงสุด) โดยไม่ต้องจ่ายค่าความจุที่ไม่ค่อยได้ใช้
- มันสามารถทดแทนได้อย่างง่ายดาย คุณสามารถเปลี่ยนประเภทของเซิร์ฟเวอร์ หรือเพิ่มเซิร์ฟเวอร์หรือจัดเก็บข้อมูลได้มากตามที่คุณต้องการ ภายใน 1 นาที การ ทํา เช่น นี้ เพียง อย่าง เดียว อาจ ทํา ให้ มี เหตุ ผล ที่ จะ ใช้ การ บริการ เหล่า นี้.
- พวกเขาปลดคุณออกจากหน้าที่การบริหารหลายอย่าง ในการทํางานเซิร์ฟเวอร์และเครือข่าย การ ทํา เช่น นี้ เพียง อย่าง เดียว อาจ ทํา ให้ มี เหตุ ผล ที่ จะ ใช้ การ บริการ เหล่า นี้.
ข้อเสียของบริการเหล่านี้คือ
- พวกเขาคิดค่าบริการ บางทีก็มาก (ในเทอมสัมบูรณ์, ไม่ใช่ว่ามันไม่ใช่ค่าที่ดี) . ราคารายการที่นี่สําหรับ Amazon EC2 . ราคาเหล่านี้ (20 มิถุนายน 2015) จะลงมา
ใน อดีต ราคา สูง กว่า แต่ ข้อมูล และ จํานวน ที่ ต้องการ ลด ลง.
ในอนาคต ราคาจะลดลง แต่ข้อมูลและจํานวนที่ร้องขอจะมากขึ้น
ดังนั้นรายละเอียดเปลี่ยนแปลง แต่สถานการณ์ค่อนข้างคงที่
และไม่ใช่ว่าบริการนั้นแพงเกินไป แต่เป็นการที่เราใช้และซื้อบริการจํานวนมาก
- การ ถ่ายโอน ข้อมูล — การ ถ่ายโอน ข้อมูล เข้า ไป ใน ระบบ ปัจจุบัน เป็น อิสระ (ใช่!) . การโอนข้อมูลออกจากระบบเป็น $0.09/GB ฮาร์ดไดรฟ์ SATA หนึ่งตัว (0.3GB/s) บนเซิร์ฟเวอร์หนึ่งเครื่อง ERDDAP™ อาจจะ saturate a Gigabit Eathernet lan (0.1GB/s) . 1 กิกาบิต อีเทอร์เน็ต แลง (0.1GB/s) อาจจะทําให้อินเทอร์เน็ตเชื่อมต่อ OC-12 ได้ (0. 06GB/s) . ถ้าการเชื่อมต่อ OC-12 หนึ่งเครื่อง สามารถส่ง ~150,000 GB/เดือน ค่าโอนข้อมูลอาจมากถึง 150,000 บาท @ $0.09/GB = $13,500/เดือน ซึ่งเป็นค่าใช้จ่ายที่สําคัญ เห็นได้ชัดว่าถ้าคุณมีงานหนักเป็นโหล ERDDAP S บนบริการเมฆ ค่าถ่ายโอนข้อมูลรายเดือนของคุณอาจจะมาก (ถึง 12,000 ดอลลาร์/เดือน) . (อีกครั้ง ที่บริการไม่ได้แพงเกินไป คือเรากําลังใช้และซื้อบริการจํานวนมาก)
- การ เก็บ ข้อมูล — แอ มะ ซอน กล่าว หา 50 เดือน ต่อ ทีบี. (เทียบกับการซื้อ enterprise enterprise 4TB โดยตรงสําหรับ ~50/TB, แม้ว่า RAID จะใส่มันเข้าไป และค่าใช้จ่ายด้านบริหารจะเพิ่มขึ้นเป็นค่าใช้จ่ายรวม) ดังนั้นหากคุณต้องเก็บข้อมูลจํานวนมากในเมฆ มันอาจจะแพงทีเดียว (เช่น, 100TB ราคา $500/เดือน) . แต่ถ้าคุณไม่มีข้อมูลจํานวนมาก นี่เป็นประเด็นที่มีขนาดเล็กกว่า ค่าใช้จ่ายการโอนของแบนด์วิธ/ดาตา (อีกครั้ง ที่บริการไม่ได้แพงเกินไป คือเรากําลังใช้และซื้อบริการจํานวนมาก)
ตั้งค่า
- ปัญหาการจัดวาง: ทางเดียวที่จะกระจายข้อมูลจากแฟ้มข้อมูลอย่างมีประสิทธิภาพได้ คือการมีโปรแกรมที่จะกระจายข้อมูล (อี.จี. ERDDAP ) ทํางานบนเซิร์ฟเวอร์ที่มีข้อมูลที่เก็บไว้ในฮาร์ดไดรฟ์ภายในเครื่อง (หรือในแบบเดียวกัน เข้าถึง SAN หรือ RAID ท้องถิ่น) . อนุญาตให้ใช้ระบบแฟ้มภายในระบบ ERDDAP™ (และเป็นรากฐานของห้องสมุด เช่น Netcdf-java) เพื่อร้องขอช่วงย่อยเฉพาะจากแฟ้ม และได้รับการตอบสนองอย่างรวดเร็ว มีการร้องขอข้อมูลหลายประเภทจาก ERDDAP™ ไปยังเอกสาร (ต้องการข้อมูลแบบฝังตัวอย่างโดดเด่น โดยมีความคืบหน้าที่; 1) ไม่สามารถทํางานได้อย่างมีประสิทธิภาพหากโปรแกรมมีการร้องขอแฟ้มทั้งหมด หรือส่วนใหญ่ของแฟ้มที่ไม่ใช่ท้องถิ่น (ดังนั้นช้าลง) ระบบเก็บข้อมูล แล้วก็ดึงสับเซตออกมา ถ้าเมฆตั้งไม่ได้ให้ ERDDAP™ การเข้าถึงแฟ้มทีละน้อย (เร็วเท่ากับแฟ้มภายในระบบ) . ERDDAP การเข้าถึงข้อมูลนั้น จะเป็นการดึงคอขวดที่ร้ายแรง และปลดผลประโยชน์อื่น ๆ จากการใช้บริการเมฆ
ข้อมูลเครื่องโฮสต์
อีกทางเลือกหนึ่งสําหรับค่าใช้จ่ายข้างต้น การวิเคราะห์ผลประโยชน์ (ซึ่งขึ้นอยู่กับเจ้าของข้อมูล (อี.จี. NOAA ) จ่ายสําหรับข้อมูลของพวกเขาที่จะถูกเก็บไว้ในเมฆ) 2555 เมื่ออะเมซอน พ.ศ. (และอีกอย่างคือ ผู้จัดหาเมฆบางดวง) เริ่มจัดวางข้อมูลในเมฆของพวกเขา (ขนาด AWS S3) ฟรี (บางทีด้วยความหวังว่าพวกเขาจะสามารถกู้ค่าใช้จ่ายของพวกเขา ถ้าผู้ใช้จะเช่า AWS EC2 กรณีคํานวณการทํางานด้วยข้อมูลที่) . เห็นได้ชัดว่า นี่ทําให้การคํานวณค่าใช้จ่ายที่มากขึ้นอย่างมาก เพราะเวลาและค่าใช้จ่ายในการอัพโหลดข้อมูล ด้วย ERDDAP™ v2.0, มีคุณลักษณะใหม่ในการวิ่ง ERDDAP ในกลุ่มเมฆ
- ตอนนี้ EDDGrid จากแฟ้มหรือ DDTable จากแฟ้มข้อมูล สามารถสร้างได้จากแฟ้มข้อมูล ที่อยู่ห่างไกลและเข้าถึงได้ทางอินเทอร์เน็ต (E.g., AWS S3 ถัง) โดยการใช้<แคชจากUrl> และ<แคชSize GB> ตัวเลือก ERDDAP™ จะรักษาแคชภายในของแฟ้มข้อมูลที่ใช้ล่าสุด
- ตอนนี้ถ้าใด ๆ EDTable จากแฟ้มซอร์สที่ถูกบีบอัด (อี.จี. .tgz ) . ERDDAP™ มันจะย่อยสลายพวกเขาโดยอัตโนมัติ เมื่อมันอ่าน
- ตอนนี้ ERDDAP™ เธรดที่ตอบสนองการร้องขอไป จะก่อให้เกิดเธรดงานที่จะทํางานในส่วนย่อยของการร้องขอถ้าคุณใช้<nheads> ตัวเลือก การ เทียบ เคียง เช่น นี้ น่า จะ ทํา ให้ มี การ ตอบ สนอง ที่ รวด เร็ว ต่อ คํา ขอ ที่ ยาก.
การเปลี่ยนแปลงเหล่านี้แก้ปัญหาของ AWS S3 ที่ไม่นําเสนอภายใน, จัดเก็บแฟ้มระดับบล็อกและ (เก่า) มีปัญหาเรื่องการเข้าถึงข้อมูล S3 ที่มีความล้าหลังที่สําคัญ (หลายปีก่อน (~2014) แต่ปัจจุบันสั้นลงมากและไม่ได้มีความสําคัญเท่า) ทั้งหมด มันหมายถึง การตั้ง ERDDAP™ ในกลุ่มเมฆนั้น ทํางานดีขึ้นมาก
ขอบคุณ — หลาย คน ขอบคุณ แมต ทิว อาร์ รอต และ กลุ่ม ของ เขา ใน ความ พยายาม แรก เดิม ของ พวก เขา ที่ จะ ทํา งาน ของ พวก เขา ใน งาน นี้ ERDDAP™ ในกลุ่มเมฆและเรื่องราวที่เกิดขึ้น
การจําลองชุดข้อมูลทางไกล
มี ปัญหา ทั่ว ไป ที่ เกี่ยว ข้อง กับ การ พิจารณา ข้าง ต้น เกี่ยว กับ ตาราง และ การ บํารุง รักษา ของ ERDDAP s: การจําลองข้อมูลระยะไกล ปัญหาพื้นฐานคือ:ผู้ให้บริการข้อมูลรักษาชุดข้อมูลที่เปลี่ยนแปลงเป็นบางครั้ง และผู้ใช้ต้องการคงการคัดลอกข้อมูลภายในเครื่องไว้ (สําหรับเหตุผลต่าง ๆ) . เห็น ได้ ชัด ว่า มี ความ หลาก หลาย มาก มาย ใน เรื่อง นี้. ความ แตก ต่าง บาง อย่าง จัด การ ได้ ยาก กว่า คน อื่น มาก.
- ปรับปรุงอย่างรวดเร็ว การเก็บข้อมูลในท้องถิ่นนั้น ยากกว่า ทันที (เช่น ภายใน 3 วินาที) หลังจากการเปลี่ยนเป็นแหล่งกําเนิดทุกๆ ครั้ง ตัวอย่างเช่น ภายในไม่กี่ชั่วโมง
- การเปลี่ยนแปลงบ่อย ๆ บ่อย ครั้ง การ เปลี่ยน แปลง ยาก กว่า การ รับมือ กับ การ เปลี่ยน แปลง บ่อย ๆ. ตัวอย่างเช่น การเปลี่ยนแปลงครั้งเดียวต่อวัน ง่ายกว่ามากที่จะจัดการกับการเปลี่ยนแปลง ทุกๆ 0.1 วินาที
- การเปลี่ยนแปลงขนาดเล็ก การเปลี่ยนแปลงเล็ก ๆ น้อย ๆ ในแฟ้มต้นทาง เป็นเรื่องยากกว่าแฟ้มใหม่ทั้งหมด เป็น ความ จริง โดย เฉพาะ อย่าง ยิ่ง ถ้า การ เปลี่ยน แปลง เล็ก ๆ น้อย ๆ อาจ อยู่ ที่ ไหน ก็ ได้ ใน แฟ้ม. การ เปลี่ยน แปลง เล็ก ๆ น้อย ๆ เป็น เรื่อง ยาก มาก และ ทํา ให้ ยาก ที่ จะ แยก ข้อมูล ที่ ต้อง ทํา ซ้ํา. แฟ้มใหม่สามารถตรวจสอบได้และมีประสิทธิภาพในการโอนได้
- ชุดข้อมูลรวม การเก็บข้อมูลทั้งหมด up-date เป็นเรื่องยากกว่าการรักษาข้อมูลล่าสุด ผู้ใช้บางคนต้องการข้อมูลล่าสุด (8 วันสุดท้าย) .
- หลายสําเนา การ เก็บ สําเนา ระยะไกล หลาย ฉบับ ไว้ ใน สถาน ที่ ต่าง ๆ นั้น ยาก กว่า การ เก็บ ไว้ เพียง ฉบับ เดียว. นี่คือปัญหาการปรับขนาด
เห็นได้ชัดว่ามีการเปลี่ยนแปลงมากมาย ที่เป็นไปได้กับแหล่งข้อมูล และความต้องการของผู้ใช้ มี หลาย อย่าง ที่ แก้ ได้ ยาก มาก. วิธีแก้ปัญหาที่ดีที่สุดสําหรับกรณีหนึ่ง มักไม่ใช่วิธีแก้ปัญหาที่ดีที่สุดสําหรับสถานการณ์อื่น -- มันยังไม่มีคําตอบที่ยิ่งใหญ่สากล
ลิฟต์ ERDDAP™ เครื่องมือ
ERDDAP™ นําเสนอเครื่องมือหลาย ๆ ตัว ซึ่งสามารถใช้เป็นส่วนประกอบของระบบได้ ซึ่งพยายามรักษาการคัดลอกข้อมูลจากระยะไกล:
- ERDDAP ' RSS (ริชซิทสรุป?) บริการ
นําเสนอวิธีที่รวดเร็วเพื่อตรวจสอบว่าชุดข้อมูลบนระยะไกล ERDDAP™ เปลี่ยนไปแล้ว - ERDDAP ' บริการสมัครสมาชิก
มีประสิทธิภาพมากกว่า (มากกว่า RSS ) วิธีการ: มันจะส่งอีเมลหรือติดต่อที่อยู่ URL ไปยังตัวบอกรับข้อมูลแต่ละตัวทันที เมื่อใดก็ตามที่มีการอัปเดตข้อมูล และการปรับปรุงมีผลให้มีการเปลี่ยนแปลง มี ประสิทธิภาพ ใน การ ที่ เหตุ การณ์ นั้น เกิด ขึ้น อย่าง รวด เร็ว และ ไม่ ต้อง เสีย แรง เปล่า (เหมือนการลงคะแนน RSS บริการ) . ผู้ใช้สามารถใช้เครื่องมืออื่นได้ (เช่น IFTTT ) เพื่อตอบสนองต่อการแจ้งเตือนทางอีเมลจากระบบบอกรับ ตัวอย่างเช่น ผู้ใช้สามารถสมัครรับข้อมูลบนระยะไกลได้ ERDDAP™ และใช้ IFTT เพื่อตอบสนองต่อการแจ้งเตือนทางอีเมล และเรียกปรับปรุงข้อมูลภายใน - ERDDAP ' ระบบธง
หาทางให้ ERDDAP™ ผู้ดูแลระบบที่จะบอกชุดข้อมูลบน/her ERDDAP ใส่กระสุนเร็วที่สุด รูปแบบที่อยู่ URL ของธงสามารถใช้ได้ง่ายในสคริปต์ รูปแบบที่อยู่ URL ของธงสามารถใช้เป็นการกระทําสําหรับการบอกรับข้อมูลได้ - ERDDAP ' "files" ระบบ
สามารถเสนอสิทธิ์ในการอ่านแฟ้มต้นฉบับสําหรับชุดข้อมูลที่ให้ รวมถึงรายการไดเร็คทอรีรูปแบบ Apache ของแฟ้ม ("โฟลเดอร์สิ่งอํานวยความสะดวก") ซึ่งมีที่อยู่ URL ที่ดาวน์โหลดมาได้แต่ละแฟ้ม, เวลาที่มีการแก้ไขล่าสุด, และขนาด ข้อเสียของการใช้ "files" ระบบคือแฟ้มต้นทางอาจมีชื่อตัวแปรที่แตกต่างกัน และข้อมูลกํากับภาพที่แตกต่างจากชุดข้อมูลตามที่ปรากฏใน ERDDAP . ถ้าระยะไกล ERDDAP™ ชุดข้อมูลเสนอการเข้าถึงแฟ้มต้นฉบับของมัน ซึ่งจะเปิดความเป็นไปได้ของ Rsync รุ่นยากจน: มันกลายเป็นการง่ายสําหรับระบบท้องถิ่นที่จะดูว่าแฟ้มระยะไกลใดมีการเปลี่ยนแปลง และจําเป็นต้องดาวน์โหลด (ดู ตัวเลือกแคชจาก Url ข้างล่างสามารถใช้นี่ได้)
วิธี แก้
แม้ว่ามันจะมีความแตกต่างมากมายในโจทย์นี้ และคําตอบที่เป็นไปได้นับไม่ถ้วน แต่มันมีวิธีแก้ปัญหาพื้นฐานอยู่หยิบมือ
ศุลกากร, การ แก้ ปัญหา ของ บรูต ฟอร์ซ
วิธีแก้ปัญหาที่ชัดเจน คือ การออกแบบวิธีแก้ปัญหาที่กําหนดเอง ซึ่งเหมาะกับสถานการณ์ที่กําหนด คือ สร้างระบบที่ตรวจสอบหรือตรวจสอบว่าข้อมูลใดมีการเปลี่ยนแปลง และส่งข้อมูลนั้นไปยังผู้ใช้ เพื่อให้ผู้ใช้สามารถร้องขอข้อมูลที่มีการแก้ไขได้ คุณทําได้ แต่มีข้อเสีย
- วิธีแก้ปัญหาตามธรรมเนียม เป็นงานที่หนักมาก
- วิธีแก้ปัญหาที่กําหนดเอง มักจะถูกปรับเป็นชุดข้อมูลที่ให้ และให้ผู้ใช้มา ซึ่งทําให้ไม่สามารถเรียกข้อมูลใหม่ได้
- คุณ ต้อง สร้าง และ รักษา ไว้. (นั่นไม่ใช่ความคิดที่ดีเลย มันเป็นความคิดที่ดีเสมอที่จะหลีกเลี่ยงการทํางาน และให้คนอื่นทํางานแทน)
ผมเลิกใช้วิธีการแบบนี้ เพราะมันมักจะดีกว่าเสมอ ที่จะมองหาคําตอบทั่วไป สร้างและรักษาไว้โดยคนอื่น
rsync
rsync เป็นวิธีแก้ปัญหาทั่วไป ที่ดีอย่างน่าทึ่ง เพื่อเก็บสะสมแฟ้มต่าง ๆ ไว้ในคอมพิวเตอร์ของแหล่ง ในการปรับเทียบข้อมูลบนคอมพิวเตอร์ของผู้ใช้ วิธีการทํางานก็คือ
- บางเหตุการณ์ (เช่น ERDDAP™ เหตุการณ์การบอกรับของระบบ) จุดชนวน rsync (หรือ, งาน Cron ทํางาน rsync ที่เวลาเฉพาะทุกวันบนคอมพิวเตอร์ของผู้ใช้)
- ซึ่งติดต่อ rsync บนคอมพิวเตอร์ต้นฉบับ
- ซึ่งคํานวณชุดของ haches สําหรับชิ้นของแต่ละแฟ้ม และส่ง highs เหล่านั้นไปยัง rsync ของผู้ใช้
- ซึ่งเปรียบเทียบข้อมูลดังกล่าวกับข้อมูลที่คล้ายกัน สําหรับคัดลอกแฟ้มของผู้ใช้
- ซึ่งจะร้องขอส่วนย่อยของแฟ้มที่มีการเปลี่ยนแปลง
พิจารณาทุกสิ่งที่มันทํา rsync ทํางานอย่างรวดเร็ว (e.g., 10 วินาที บวกเวลาส่งข้อมูล) และมีประสิทธิภาพมาก มี ความแตกต่างของ rsync ที่เหมาะกับสถานการณ์ต่างๆ (e.g. โดยการคํานวณและ camping haes of parts ของแต่ละแฟ้มต้นทาง) .
จุดอ่อนหลักของ rsync คือ: ต้องใช้ความพยายามในการตั้ง (ปัญหาความปลอดภัย) มีบางประเด็นเกี่ยวกับการปรับขนาด และมันไม่ดีต่อการรักษาข้อมูล NRT (เช่น มันอึดอัดที่จะใช้ rsync มากกว่าทุกๆ 5 นาที) . ถ้าคุณจัดการกับจุดอ่อนได้ หรือถ้ามันไม่ส่งผลกระทบต่อสถานการณ์ของคุณ rsync เป็นวิธีแก้ปัญหาพื้นฐานที่ยอดเยี่ยม
มีของอยู่ใน ERDDAP™ เพื่อทํารายการเพื่อพยายามเพิ่มการสนับสนุนบริการ rsync ไปยัง ERDDAP (อาจจะเป็นงานที่ยากสวย) เพื่อให้ลูกค้าคนใดสามารถใช้ rsync (หรือสิ่งกีดขวาง) เพื่อรักษาสําเนาข้อมูล ถ้าใครอยากทํางานนี้ กรุณาส่งอีเมล์ erd.data at noaa.gov .
มีโปรแกรมอื่น ๆ ที่ทํามากขึ้นหรือน้อยกว่าสิ่งที่ rsync ทํา บางครั้งเน้นไปยังข้อมูลชุดจําลอง (แม้ว่ามักจะอยู่ในระดับแฟ้ม) อี.จี. Unidata ' หมายเลขประจําตัว .
แคชจากอูเรล
แคชจากUrl การตั้งค่าใช้ได้ (เริ่มด้วย ERDDAP™ v2. 0) สําหรับทั้งหมด ERDDAP ประเภทชุดข้อมูลที่จะใช้สร้างชุดข้อมูลต่าง ๆ จากแฟ้ม (โดยพื้นฐานแล้ว ชนชั้นย่อยของ EDDGrid จากแฟ้ม ถึง เลือกแฟ้ม ) . แคช จาก Url ทําให้การดาวน์โหลดและรักษาแฟ้มข้อมูลภายในโดยอัตโนมัติ โดยคัดลอกมันจากแหล่งปลายทางผ่านทางแคช จากที่ตั้ง Url แฟ้มระยะไกลสามารถอยู่ในโฟลเดอร์สิ่งอํานวยความสะดวกบนเว็บ หรือรายการแฟ้มแบบไดเร็กทอรีที่นําเสนอโดย THEDS Hyrax ตะกร้า S3 หรือ ERDDAP ' "files" ระบบ
หากแหล่งของแฟ้มทางไกลเป็นระยะไกล ERDDAP™ ชุดข้อมูลที่จะใช้แสดงแฟ้มต้นฉบับผ่านทาง ERDDAP™ "files" ระบบ จากนั้นคุณสามารถ การสมัครสมาชิก ไปยังชุดข้อมูลระยะไกล และใช้ ที่อยู่ URL ธง สําหรับข้อมูลท้องถิ่นของคุณ เป็นการกระทําที่ใช้ในการบอกรับข้อมูล เมื่อใดก็ตามที่ชุดข้อมูลระยะไกลมีการเปลี่ยนแปลง มันจะติดต่อกับที่อยู่ URL แฟล็กสําหรับข้อมูลต่าง ๆ ของคุณ ซึ่งจะบอกมันว่าให้โหลดข้อมูลอัตโนมัติ ซึ่งจะตรวจสอบและดาวน์โหลดแฟ้มข้อมูลระยะไกลที่มีการเปลี่ยนแปลงไป ทั้งหมดนี้เกิดขึ้นเร็วมาก (โดยทั่วไปแล้ว ~5 วินาที บวกเวลาที่จําเป็นในการดาวน์โหลดแฟ้มเปลี่ยนแปลง) . วิธีการนี้ใช้ได้ดี หากแฟ้มข้อมูลต้นฉบับมีการเปลี่ยนแปลง เป็นแฟ้มใหม่ที่ถูกเพิ่มเป็นระยะ ๆ และเมื่อแฟ้มที่มีอยู่ไม่เคยเปลี่ยน วิธีนี้ใช้ไม่ได้ ถ้าข้อมูลถูกต่อเข้ากับทั้งหมด (หรือมากที่สุด) จากแฟ้มข้อมูลแหล่งที่มีอยู่แล้ว เพราะว่าชุดข้อมูลท้องถิ่นของคุณ มักจะถูกดาวโหลดข้อมูลจากระยะไกลทั้งหมด (นี่คือที่ที่ต้องการวิธีการแบบ Rsync)
แฟ้มจัดเก็บADatata
ERDDAP™ ' แฟ้มจัดเก็บADatata เป็นคําตอบที่ดีเมื่อข้อมูลถูกเพิ่มเข้ากับชุดข้อมูลบ่อยครั้ง แต่ข้อมูลเก่าไม่เคยถูกเปลี่ยนแปลง โดยทั่วไปแล้ว ERDDAP™ ผู้ดูแลระบบสามารถประมวลผลแฟ้มจัดเก็บ ADADatatet ได้ (บางทีในสคริปต์อาจจะดําเนินการโดย cron) และระบุสับเซตของชุดข้อมูลที่ต้องการแยก (บางทีในหลายแฟ้ม) และแพ็คเกจใน .zip หรือ .tgz แฟ้มเพื่อให้คุณสามารถส่งแฟ้มไปยังผู้สนใจหรือกลุ่ม (E.g., SAMCI สําหรับโบราณคดี) หรือทําให้สามารถดาวน์โหลดได้ ตัวอย่างเช่น คุณสามารถดําเนินการเขียนแฟ้มจัดเก็บ ADatatet ทุกวันที่ 12: 10 และทําให้มัน .zip จากข้อมูลทั้งหมดตั้งแต่ 12:00 น. เป็นวันที่แล้ว จนกระทั่ง 12:00 น. (หรือ ทํา เช่น นี้ ทุก สัปดาห์, ทุก เดือน, หรือ ทุก ปี ตาม ความ จําเป็น.) เนื่องจากแฟ้มแพกเกจถูกสร้างให้ออฟไลน์ ไม่มีอันตรายของเวลานอกหรือข้อมูลมากเกินไป เป็นสําหรับมาตรฐาน ERDDAP™ ขอ
ERDDAP™ ระบบร้องขอมาตรฐาน
ERDDAP™ ระบบร้องขอมาตรฐาน เป็นวิธีแก้ปัญหาที่ดีที่สุด เมื่อข้อมูลถูกเพิ่มเข้ากับชุดข้อมูลบ่อยครั้ง แต่ข้อมูลเก่าไม่เคยถูกเปลี่ยนแปลง โดยพื้นฐานแล้ว ทุกคนสามารถใช้คําขอมาตรฐานเพื่อหาข้อมูล สําหรับช่วงเวลาที่แน่นอน ตัวอย่างเช่น เวลา 12: 10 น. ทุก ๆ วัน คุณสามารถขอข้อมูลทั้งหมด จากข้อมูลระยะไกล จากเวลา 12:00 น. จํากัด (เปรียบเทียบกับวิธีเขียนแฟ้มจัดเก็บADatatet) คือความเสี่ยงของการหมดเวลาหรือมีข้อมูลมากเกินไปสําหรับเพียงแฟ้มเดียว คุณ สามารถ หลีก เลี่ยง ข้อ จํากัด ได้ โดย การ ขอ เป็น ครั้ง คราว สําหรับ ช่วง เวลา ที่ สั้น กว่า.
เพิ่มข้อมูล
\[ ตัวเลือกนี้ยังไม่มีอยู่ แต่ดูเหมือนจะสร้างได้ในอนาคตอันใกล้ \]
ของใหม่ เพิ่มข้อมูล ประเภทชุดข้อมูล ERDDAP™ v20 ทําให้สามารถนึกภาพคําตอบอีกตัวได้ ไฟล์หลักที่รักษาไว้โดยชุดข้อมูลประเภทนี้ ก็คือปูมบันทึกแฟ้ม ที่บันทึกการเปลี่ยนแปลงของชุดข้อมูล ควร จะ เป็น ไป ได้ ที่ จะ สร้าง ระบบ ที่ รักษา ข้อมูล ใน ท้อง ถิ่น ไว้ เป็น ระยะ ๆ (หรือจากตัวกระตุ้น) ร้องขอการเปลี่ยนแปลงทั้งหมดที่ได้ทําไปยังชุดข้อมูลระยะไกล ตั้งแต่คําขอล่าสุด นั่นน่าจะมีประสิทธิภาพพอ (หรือมากกว่านั้น) กว่า rsync และจะจัดการสถานการณ์ยาก ๆ หลาย ๆ อย่าง แต่จะทํางานถ้าชุดข้อมูลระยะไกลและท้องถิ่น เป็น EDTable fromhtpget ข้อมูลชุด
ถ้าใครอยากทํางานนี้ กรุณาติดต่อ erd.data at noaa.gov .
ข้อมูลที่แยกแล้ว
ไม่ มี ทาง แก้ ข้าง บน ที่ ดี มาก ใน การ แก้ ปัญหา ที่ ยุ่ง ยาก เพราะ การ จําลอง เวลา จริง (ขนาด NRT) ชุดข้อมูลเป็นเรื่องยากมาก ส่วนหนึ่งเป็นเพราะสถานการณ์ทั้งหมดที่เป็นไปได้
มีคําตอบที่ดี: อย่าพยายามเลียนแบบข้อมูล แทน ที่ จะ เป็น เช่น นั้น จง ใช้ แหล่ง ที่ เชื่อ ถือ ได้ แหล่ง เดียว (ชุดข้อมูลหนึ่งตัวบนหนึ่ง ERDDAP ) เก็บรักษาโดยผู้ให้บริการข้อมูล (อี.จี. สํานักงานภูมิภาค) . ผู้ใช้ทุกคนที่อยากได้ข้อมูลจากชุดข้อมูลนั้น มักจะได้ข้อมูลจากแหล่งกําเนิดเสมอ ตัวอย่างเช่น apps ที่อยู่บนเว็บเบราว์เซอร์ จะรับข้อมูลจากการร้องขอจากที่อยู่ URL ดังนั้น ไม่สําคัญว่าสิ่งที่ร้องขอไป จะมาจากต้นฉบับบนเซิร์ฟเวอร์ทางไกลหรือไม่ (ไม่ใช่เซิร์ฟเวอร์เดียวกับที่เป็นเจ้าภาพ ESM) . มีหลายคนที่สนับสนุนวิธีการนี้ ที่ไม่ต่อเนื่องมานาน (E.g., รอย เมนเดลส์สัน ตลอด 20 + ปีที่ผ่านมา) . ERDDAP โมเดลตาราง/ ความเปลี่ยนแปลง (80% ของเอกสารนี้) มันตั้งอยู่บนวิธีการนี้ วิธี แก้ แบบ นี้ เป็น เหมือน ดาบ สําหรับ กอร์ เดีย น ค นอต — ปัญหา ทั้ง หมด จะ หาย ไป.
- วิธีแก้นี้ง่ายมาก
- คําตอบนี้มีประสิทธิภาพอย่างน่าทึ่ง เนื่องจากไม่มีงานที่จะทําเพื่อให้ชุดข้อมูลซ้ํา (วินาที) up-date.
- ผู้ใช้สามารถรับข้อมูลล่าสุดเมื่อไหร่ก็ได้ (e.g. ด้วยอัตราเร็วเพียง ~0.5 วินาที) .
- มันชั่งได้ค่อนข้างดี และมีวิธีปรับปรุงการปรับขนาด (โปรด ดู การ พิจารณา ใน ตอน ต้น 80% ของ เอกสาร นี้.)
ไม่ นี่ไม่ใช่ทางออกสําหรับทุกสถานการณ์ที่เป็นไปได้ แต่มันเป็นทางออกที่ดีสําหรับคนส่วนใหญ่ หาก มี ปัญหา หรือ ความ อ่อนแอ เกี่ยว กับ วิธี แก้ นี้ ใน บาง กรณี บ่อย ครั้ง คุ้ม ค่า ที่ จะ พยายาม แก้ ปัญหา เหล่า นั้น หรือ อยู่ กับ ความ อ่อนแอ เหล่า นั้น เนื่อง จาก ข้อ ได้ เปรียบ อัน น่า ทึ่ง ของ วิธี แก้ นี้. ถ้า/ เมื่อคําตอบนี้ไม่สามารถยอมรับได้จริงๆ สําหรับสถานการณ์ที่กําหนด เช่น เมื่อคุณต้องมีสําเนาภายในของข้อมูล
ไม่ซ้ํากัน
ในขณะที่ไม่มีหนึ่งคําตอบง่าย ๆ ที่สมบูรณ์แบบแก้ปัญหาทุกกรณี (เป็น rsync และ distrituted ข้อมูลเกือบเป็น) หวังว่าจะมีเครื่องมือและทางเลือกเพียงพอ เพื่อให้คุณสามารถหาทางออกที่ยอมรับได้ สําหรับสถานการณ์ของคุณโดยเฉพาะ