ดาวน์โหลดอย่างมีความรับผิดชอบ

 (blog.geofabrik.de)
1 คะแนน โดย GN⁺ 2025-09-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เดือนนี้มีการอัปเกรดโครงสร้างพื้นฐานของเซิร์ฟเวอร์ดาวน์โหลด ทำให้มอบประสบการณ์การดาวน์โหลดที่รวดเร็วยิ่งขึ้น
  • วิธีการร้องขอไฟล์ “…latest” ถูกเปลี่ยนเป็นการรีไดเร็กต์ผ่าน HTTP
  • มุ่งให้ผู้ใช้ทุกคนเข้าถึงข้อมูล OSM ล่าสุดได้อย่างสะดวก
  • กรณีการใช้งานที่ผิดปกติซึ่งมีการดาวน์โหลดไฟล์ขนาดใหญ่ซ้ำๆ มากเกินไป ส่งผลให้ประสิทธิภาพของบริการโดยรวมลดลง
  • มีการเสนอคำแนะนำที่เป็นรูปธรรม 3 ข้อเพื่อการดาวน์โหลดอย่างมีประสิทธิภาพและมีความรับผิดชอบ

อัปเดตเซิร์ฟเวอร์ดาวน์โหลดและคำแนะนำในการใช้งานอย่างมีความรับผิดชอบ

ในเดือนนี้ ได้ดำเนินการเสริมความแข็งแกร่งให้โครงสร้างพื้นฐานของเซิร์ฟเวอร์ดาวน์โหลด
ส่งผลให้สามารถสร้างสภาพแวดล้อมที่การดาวน์โหลดทำได้เร็วขึ้น และพร้อมให้ใช้งานได้ไวขึ้น
ในส่วนของการเปลี่ยนแปลงทางเทคนิค เมื่อร้องขอไฟล์ “…latest” ระบบจะพาไปยังไฟล์เวอร์ชันล่าสุดด้วยวิธีHTTP redirect แทนการส่งไฟล์โดยตรงแบบเดิม

เหตุผลที่ต้องดาวน์โหลดอย่างมีความรับผิดชอบ

เซิร์ฟเวอร์นี้ถูกให้บริการเพื่อให้ผู้ใช้ทุกคนเข้าถึงข้อมูล OSM (OpenStreetMap) ล่าสุดได้อย่างสะดวก
อย่างไรก็ตาม มีบางกรณีที่ผู้ใช้ดาวน์โหลดไฟล์ขนาดใหญ่ไฟล์เดิมซ้ำๆ (เช่น 20GB) วันละหลายร้อยถึงหลายพันครั้ง

  • ตัวอย่างเช่น มีผู้ใช้รายหนึ่งดาวน์โหลดไฟล์ italy-latest.osm.pbf เกือบ 10,000 ครั้ง ภายใน 24 ชั่วโมง
  • อีกบางรายทำซ้ำด้วยการดาวน์โหลดทุกไฟล์ทั้งหมดบนเซิร์ฟเวอร์ทุกวัน

พฤติกรรมลักษณะนี้ทำให้ผู้ใช้ทั้งหมดใช้งานได้ช้าลง เนื่องจากข้อจำกัดด้านแบนด์วิดท์ของเซิร์ฟเวอร์
หากจำเป็นต้องบล็อกช่วง IP ก็อาจทำให้ผู้ใช้ที่ไม่เกี่ยวข้องได้รับผลกระทบไปด้วย

คำแนะนำที่เป็นรูปธรรม 3 ข้อสำหรับผู้ใช้เซิร์ฟเวอร์

  1. หากต้องการข้อมูลทั้งโลก แนะนำให้ดาวน์โหลดไฟล์ planet แบบครั้งเดียวจาก planet.openstreetmap.org แทนการโหลดแยกจากเซิร์ฟเวอร์เป็นส่วนๆ
  2. หากต้องการอัปเดตข้อมูลระดับทวีปหรือพื้นที่ขนาดใหญ่ (เช่น Europe, North America) ทุกวัน ให้ใช้โปรแกรม pyosmium-up-to-date เพื่อดาวน์โหลดเฉพาะส่วนที่เปลี่ยนแปลง ซึ่งช่วยลดทราฟฟิกทั้งหมดได้ 98% และยังเร็วกว่าด้วย
  3. หากใช้สคริปต์อัตโนมัติ ควรมอนิเตอร์ว่ากำลังดาวน์โหลดอะไรอยู่ หรือเพิ่มการจัดการข้อผิดพลาดที่เหมาะสม เพื่อป้องกันความผิดพลาดอย่างการดาวน์โหลดไฟล์เดิมซ้ำไม่สิ้นสุด

บทสรุป

ขอความร่วมมือให้ทุกคนช่วยกันสร้างสภาพแวดล้อมที่ทุกคนสามารถใช้งานข้อมูลล่าสุดได้อย่างราบรื่น ด้วยพฤติกรรมการดาวน์โหลดที่มีความรับผิดชอบมากขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-09-23
ความคิดเห็นจาก Hacker News
  • ทุกครั้งที่เห็นปัญหาแบบนี้ก็สงสัยว่าทำไม BitTorrent ถึงไม่ได้ถูกใช้มากกว่านี้ อยากให้มันกลายเป็นโปรโตคอลพื้นฐานในที่ต่าง ๆ ให้หลากหลายกว่านี้ เช่น container registry หรือ package repository
    • BitTorrent มีภาพลักษณ์ด้านลบในวงกว้าง คนส่วนใหญ่มักเชื่อมโยงมันกับการดาวน์โหลดผิดกฎหมายเท่านั้น<br>การตั้งค่าไฟร์วอลล์ก็ยุ่งยากกว่า HTTP ถ้าไปขอให้ผู้ดูแลเครือข่ายเปิดทางให้แบบนี้อาจถูกมองแปลก ๆ โดยเฉพาะเพราะหลายคนต่อต้าน BitTorrent อยู่แล้ว<br>ไคลเอนต์ BitTorrent ซับซ้อนกว่าไคลเอนต์ HTTP มาก และโดยมากก็ไม่ได้ติดตั้งอยู่ในคอมพิวเตอร์บริษัทหรือ CI pipeline ส่วนใหญ่หลายคนแค่อยากจบด้วยคำสั่ง curl ครั้งเดียว<br>ยังมีความเข้าใจผิดกันมากว่าต้อง seed ด้วย เลยยิ่งทำให้คนกลัว<br>สุดท้ายแล้วเพราะภาพลักษณ์และเพราะทุกอย่างทำได้ด้วย curl อย่างเดียว จึงน่าเสียดายที่ BitTorrent ถูกประเมินคุณค่าต่ำไป<br>แม้จะมีกรณีอย่างไคลเอนต์วิดีโอเกมที่ใช้ BT สำหรับอัปเดต หรือ PeerTube ที่ใช้ webtorrent แต่ก็ยังน่าเสียดายที่มันไม่ได้ถูกใช้แพร่หลายกว่านี้
    • บริษัทหลายสิบแห่ง เช่น Amazon, Esri, Grab, Hyundai, Meta, Microsoft, Precisely, Tripadvisor และ TomTom เปิดให้ใช้ข้อมูล OpenStreetMap ในรูปแบบ Parquet บน S3 ฟรี ซึ่งช่วยให้สามารถ query และวิเคราะห์เฉพาะข้อมูลที่ต้องการได้โดยใช้แบนด์วิดท์เพียงระดับ MB แม้ชุดข้อมูลจะมีขนาดหลาย TB<br>ดู รายละเอียดเพิ่มเติม<br>ผู้ใช้ ArcGIS Pro ยังใช้ ปลั๊กอินนี้ ได้ด้วย
    • จำได้ว่าเมื่อหลายปีก่อนเคยเห็นแนวคิดเรื่อง "torrent ที่มีคอนเทนต์แบบไดนามิก" แต่สุดท้ายก็ไม่ได้ถูกใช้งานจริงจัง อยากให้มันเกิดขึ้นจริง เลยสงสัยว่ามีปัญหาร้ายแรงอย่างเรื่องความปลอดภัยหรือเปล่าที่ทำให้ไปไม่รอด ลิงก์อ้างอิง
    • เมื่อเทียบกับ HTTP ผมคิดว่า BitTorrent ขาด "ไคลเอนต์อเนกประสงค์" ที่ใช้งานได้ทุกที่ในตัวเอง มันไม่ได้คุ้นมือแบบ SSH หรือ SCP และต้องลง ติดตั้ง ตั้งค่า รวมถึงจัดการ tracker อีกพอสมควร โดยทั่วไปต้องมีความต้องการดาวน์โหลดไฟล์ขนาดใหญ่ซ้ำ ๆ บ่อยพอ โครงสร้างแบบนี้ถึงจะคุ้ม และถ้ารวมเรื่องความน่าเชื่อถือกับปริมาณการ seed เข้าไปด้วย สุดท้ายก็ต้องกลับมาคิดว่าประโยชน์คุ้มกับต้นทุนในการพัฒนาและดูแลเครื่องมือแค่ไหน ไม่แน่ใจว่าอะไรอย่าง Git LFS จะช่วยได้ไหม แต่ความรู้ผมมีแค่นี้
    • บริษัทเก่าที่ผมเคยทำงานต้องแจกจ่ายไฟล์ขนาดใหญ่ให้กับนักพัฒนาทุกคนทุกสัปดาห์ ช่วงแรกใช้ rsync แล้วทุกคนดึงพร้อมกันแบบถาโถม แต่พอเปลี่ยนมาใช้ BitTorrent ความเร็วดีขึ้นอย่างมหาศาล
  • รู้สึกขอบคุณเสมอที่มีบริษัทอย่าง Geofabrik อยู่ ทำให้บางครั้งเรายังได้ประสบการณ์ที่ดีมาก พอได้ดูแล API เองจะเจอกับความมักง่ายหรือความไม่รู้ของนักพัฒนาจนน่าตกใจจริง ๆ มีคำขอประหลาด ๆ เข้ามาบ่อยมาก ถ้าไม่ได้เจอเองมาก่อน แล้วมีใครมาเล่าให้ฟัง ผมคงคิดว่าเขาพูดเกินจริง แต่ในอีกด้าน นักพัฒนา API เองก็มักไม่ได้คิดเผื่อหลายกรณีเช่นกัน ส่วนใหญ่มีให้แค่การจัดการเอนทิตีเดี่ยว ทั้งที่ use case จริงต้องทำงานหลายรายการ เลยบังคับให้ต้องยิง request 700 ครั้ง
    • คนที่มีทักษะพัฒนาไม่มากก็อาจแสดงความไม่รับผิดชอบหรือความไม่รู้ได้ ไม่ว่าจะอยู่ในอาชีพไหนก็ตาม ผมมั่นใจว่าไม่ใช่นักพัฒนาทุกคนที่จะทุบ API แบบไม่คิดหน้าคิดหลัง การเขียนโปรแกรมเปิดกว้างสำหรับทุกคนแล้ว และช่วงหลังยังมีแนวโน้มแบบ "vibe-coding" อีก มองภาพใหญ่แล้วก็คงเลี่ยงไม่ได้ ถ้าตอบกลับด้วย 429 (Too Many Requests) หรือใช้ leaky-bucket algorithm ไว้ นักพัฒนาจูเนียร์หรือผู้เริ่มต้นก็น่าจะรู้ตัวได้เองอย่างรวดเร็วว่ามีปัญหา
    • ผมไม่เข้าใจว่าทำไมฟีเจอร์ "downloader pays" ของ S3 ถึงไม่ถูกนำมาใช้แพร่หลายกว่านี้ ถ้ามีโมเดลแบบนี้นอก AWS ด้วยก็น่าจะทำให้ผู้ใช้ที่ใช้งานอย่างไม่มีประสิทธิภาพต้องจ่ายตามต้นทุนของตัวเองได้ ข้อเสียคือคนที่ไม่มีระบบจ่ายเงินอาจเข้าถึงได้ยากขึ้น แต่บางทีก็อาจคงตัวเลือกฟรีแต่จำกัดความเร็วไว้ได้ไหม
    • มีคนดาวน์โหลดไฟล์ 20GB วันละหลายพันครั้ง ฟังแล้วก็สงสัยว่าทำไมไม่ควบคุมด้วย rate limit แบบตรงไปตรงมา
    • ผมคิดว่าทั้งสองฝ่ายควรมีความเห็นอกเห็นใจกันมากกว่านี้: ฝั่งไคลเอนต์ควรเคารพโครงสร้างพื้นฐาน และฝั่งนักพัฒนา API ก็ควรคิดจากมุมผู้ใช้ให้กว้างขึ้น
  • กรณีที่ว่า "มีผู้ใช้คนหนึ่งดาวน์โหลดไฟล์ italy-latest.osm.pbf เกือบหมื่นครั้งภายใน 24 ชั่วโมง" มีโอกาสสูงมากว่าเป็นปัญหาจากโค้ด แค่ตั้งข้อจำกัดต่อ IP ก็น่าจะพอ แม้จะเป็นผู้ใช้ VPN ก็ตาม
  • ดูเหมือนว่าผู้คนจำนวนหนึ่งกำลังดาวน์โหลดไฟล์ข้อมูลแผนที่ใน CI pipeline และบ่อยครั้งก็เป็นการดาวน์โหลดโดยไม่ตั้งใจด้วยซ้ำโดยที่เจ้าตัวไม่รู้ตัว<br>นั่นจึงเป็นเหตุผลว่าทำไมหลายบริการถึงเริ่มห้ามการดาวน์โหลดอัตโนมัติสำหรับผู้ใช้ที่ไม่ได้สมัครสมาชิก<br>ถ้าจะให้ดาวน์โหลดไฟล์ด้วย cURL ผมคิดว่าควรให้สมัครสมาชิกก่อน และถ้าใครดาวน์โหลดมากเกินไปก็ควรถูกบล็อกหรือคิดค่าบริการ
    • ผมคิดว่า CI เป็นหนึ่งในสิ่งประดิษฐ์ที่แย่ที่สุดในแง่การสิ้นเปลืองทรัพยากรคอมพิวต์ แต่สำหรับข้อมูลแผนที่ ผมก็ยังไม่ค่อยเข้าใจว่าทำไมถึงมีการดาวน์โหลดแบบมหาศาลในลักษณะเดียวกับการใช้ library โค้ดเกินจำเป็น
    • สงสัยว่าอาจเป็นการที่เว็บแอป "query" ไฟล์ GPKG อยู่หรือเปล่า รูปแบบ Parquet สามารถ query เฉพาะส่วนที่ต้องการได้อย่างมีประสิทธิภาพ แต่ไม่แน่ใจว่า GPKG จะทำแบบเดียวกันได้หรือไม่
    • สงสัยว่าสามารถแยกแยะ request จาก CI server ได้อย่างน่าเชื่อถือหรือไม่
    • แค่มีการยืนยันตัวตนอย่างง่าย ๆ (เช่น API key หรืออีเมล) ก็ดูน่าจะเป็นจุดประนีประนอมที่ดีแล้ว
  • กรณีที่ว่า "มีผู้ใช้ดาวน์โหลดไฟล์ 20GB เดิมซ้ำวันละหลายร้อยครั้งติดต่อกันหลายวัน (และมีคนหนึ่งดาวน์โหลดถึงหมื่นครั้งใน 24 ชั่วโมง) รวมถึงมีคนที่ดาวน์โหลดทุกไฟล์บนเซิร์ฟเวอร์ทุกวัน" ดูเหมือนจะหยุดได้ง่ายมากด้วย rate-limiting<br>ในเมื่อมีการนับจำนวนการดาวน์โหลดไฟล์ในช่วง 24 ชั่วโมงอยู่แล้ว ก็สงสัยว่าทำไมไม่ตั้งเพดานไว้ ผมไม่คิดว่าคนกลุ่มนี้จะ (a) อ่านโพสต์เตือนของผู้ดูแลเซิร์ฟเวอร์ และ (b) เปลี่ยนพฤติกรรมตามนั้น
  • หลายปีก่อนผมเคยคิดว่า "คงไม่มีใครบ้าเอาของขนาดเกิน 100MB มาดาวน์โหลดทุกครั้งใน build script หรอก" แต่พอได้เจอ Docker แล้วก็รู้ว่ากรณีแบบนั้นมีเยอะมาก
    • ผมเห็นบ่อยว่าพออยู่ใน container คนจะเผลอคิดไปเองว่ามันฟรีเหมือนมีเวทมนตร์
    • Docker รองรับ layer cache อยู่แล้ว งั้นก็ไม่น่าจำเป็นต้องดาวน์โหลดทุกอย่างใหม่ทุกครั้งไม่ใช่หรือ
    • เพราะแบบนั้นผมเลยสร้าง image สำหรับโปรเจ็กต์ไว้ล่วงหน้าใช้เฉพาะใน CI เพราะถ้าต้องมาตั้งค่าด้วย apt-get ทุกครั้งมันเสียเวลามาก
  • สงสัยว่าเขามีการส่งอีเมลหาผู้ใช้ที่ดาวน์โหลดมากเกินไปเป็นพิเศษหรือไม่ ตอนที่ผมใช้ Nominatim API ฟรีในปี 2012 ต้องใส่อีเมลไว้ และผมก็เคยได้รับอีเมลแนะนำจริง ๆ ให้ลดจำนวน request ด้วยการทำ cache เป็นต้น
    • ถ้าไม่มีระบบล็อกอิน ก็จะไม่ได้รับอีเมลของผู้ใช้ จึงส่งเมลไม่ได้
  • ผมไม่ใช่ผู้ใช้ที่ดาวน์โหลดไฟล์ italy-latest ทุก 8 วินาทีคนนั้น แต่สตาร์ตอัปอิตาลีที่ผมอยู่ใช้ GeoFabrik เยอะมาก และอาจมีใครในทีมทดลอง container แล้วเผลอดาวน์โหลดมากเกินไป เมื่อก่อนเราเคยถูก geofabrik แบน แต่จนถึงตอนนี้ก็ยังไม่รู้สาเหตุ เลยหวังว่าจะไม่เกิดซ้ำอีกในอนาคต ผมเคยลองทั้งโทรและอีเมลไปที่ช่องทางติดต่อของ geofabrik.de แล้วแต่ไม่ได้รับคำตอบ ถ้าใครพอรู้วิธีแก้ปัญหานี้หรือช่องทางติดต่ออื่น รบกวนช่วยบอกที
  • ผมคิดว่าคนที่ดาวน์โหลดไฟล์มากเกินไปแบบนี้ก็คงไม่ได้มาอ่านโพสต์บล็อกแนวนี้หรอก
  • ฟังดูเป็น use case ที่เหมาะกับ bittorrent มาก
    • ถ้าข้อมูลมีการเปลี่ยนแปลง ผมสงสัยว่า torrent client จะรับเฉพาะส่วนที่เปลี่ยนแบบอัตโนมัติได้อย่างไร