เรื่องเล่าที่ผมได้อ่านซ้ำแล้วซ้ำเล่าจากคนที่เลิกใช้ Nextcloud มักเป็นเรื่องเดียวกัน ไคลเอนต์ซิงก์บอกว่า “ซิงก์ครบแล้ว” แต่ไฟล์กลับหายไป การอัปเกรดชนเข้ากับปัญหาฐานข้อมูล การอัปโหลดรูปทำงานในแบบที่ผู้ใช้ไม่ได้คาดไว้
คำบ่นที่ซ่อนอยู่ใต้ทั้งสามเรื่องเหมือนกันหมด พวกเขาอยากได้รูปแบบการทำงานที่เชื่อถือได้เพียงอย่างเดียว จากชุดซอฟต์แวร์ที่ถูกสร้างมาเพื่อครอบคลุมหลายรูปแบบ
ผมมีอินสแตนซ์ Nextcloud อยู่บน VPS ที่แฟรงก์เฟิร์ต ติดตั้งไว้ในสุดสัปดาห์หนึ่งเมื่อสองปีก่อน และตั้งแต่นั้นมาก็ใช้ไปราวสี่ครั้ง การติดตั้งสำเร็จดี อินสแตนซ์ยังทำงานอยู่ ผมแค่เลิกเปิดมัน เพราะกลายเป็นว่าเก้าในสิบอย่างที่ Nextcloud ทำได้นั้นผมไม่เคยต้องใช้เลย
ดิสทริบิวชัน All-in-One อย่างเป็นทางการต้องการแรมอย่างน้อย 2 GB ทันทีที่เปิดคอนเทนเนอร์เสริมตัวใดก็ตาม และคำแนะนำด้านประสิทธิภาพยังแนะนำให้เพิ่มแรมราว 1 GB ต่อผู้ใช้ที่ใช้งานจริงหนึ่งคน นอกเหนือจากความต้องการพื้นฐาน การติดตั้งสำหรับทีมจึงต้องการพื้นที่เผื่อมากขึ้นเมื่อการใช้งานพร้อมกันเพิ่มขึ้น ชุมชนเองก็มีกระทู้ที่ยังเปิดอยู่บน help.nextcloud.com ขอให้โครงการพิจารณาเวอร์ชันที่เบากว่านี้
ต่อไปนี้คือทางออกสามทาง จับคู่กับรูปแบบการทำงานสามแบบ ตรงไหนที่มีข้อกำหนดทรัพยากรอย่างเป็นทางการ ผมก็ใช้ตามนั้น ตรงไหนที่ไม่มี ผมจะไม่ใส่ตัวเลขตายตัว แผนที่การย้ายจะครอบคลุมว่าคุณเก็บอะไรไว้ได้ เสียอะไรไป และการย้ายแต่ละแบบจะยุ่งยากตรงไหน
เวอร์ชันสั้น
- ถ้าคุณใช้ Nextcloud เพียงเพื่อซิงก์ไฟล์ระหว่างอุปกรณ์ของตัวเอง Syncthing เป็นตัวเลือกที่ดี ทำงานแบบเพียร์ทูเพียร์ ไม่ต้องมีเซิร์ฟเวอร์กลาง แต่มีข้อควรระวังสำคัญอยู่บ้างในฝั่งมือถือ
- ถ้าคุณใช้ Nextcloud เป็นพื้นที่แชร์ไฟล์ของทีมที่มีผู้ใช้หลายคน Seafile CE เป็นตัวเลือกที่ดี ความต้องการขั้นต่ำที่มีบันทึกไว้คือแรม 2 GB และซีพียู 2 คอร์ และขอบเขตที่แคบกว่าทำให้คำนวณขนาดได้ง่ายขึ้นเมื่อการแชร์ไฟล์คืองานหลัก
- ถ้าคุณใช้ Nextcloud เป็นตัวเรียกดูไฟล์ผ่านเว็บเป็นหลัก Cloudreve หรือ AList จะให้สถาปัตยกรรมที่แคบกว่ามาก โดยไม่ต้องแบกชุดเครื่องมือทำงานร่วมกันทั้งหมดของ Nextcloud ไปด้วย
- จุดฝืดสองจุดในการย้ายทุกครั้งคือช่องว่างของ CalDAV/CardDAV (ปฏิทินและรายชื่อผู้ติดต่อ) และการสำรองรูปภาพบน iOS ทั้งสองเรื่องมีอยู่ในแผนที่การย้ายด้านล่าง
ทำไม Nextcloud จึงรู้สึกหนัก (และทำไมนั่นไม่ใช่ข้อบกพร่อง)
บน Nextcloud All-in-One ที่เพิ่งติดตั้งใหม่ htop จะแสดงสถาปัตยกรรมหลายคอนเทนเนอร์ของจริง ทั้งคอนเทนเนอร์หลักของ AIO, Apache, แอปพลิเคชันเซิร์ฟเวอร์ของ Nextcloud, PostgreSQL, Redis และ Notify Push ส่วน Office, Talk, Talk Recording, ClamAV, การค้นหาข้อความเต็ม, Imaginary, Whiteboard และการสำรองข้อมูลที่อิง Borg นั้นเป็นตัวเลือกเสริม แกนหลักหนักกว่าเดมอนซิงก์ที่ทำหน้าที่เดียว แต่บริการเสริมเหล่านั้นจะกินแรมก็ต่อเมื่อคุณเปิดใช้เท่านั้น
กระทู้ All-in-One อย่างเป็นทางการบน GitHub ระบุค่าขั้นต่ำที่บันทึกไว้ที่แรม 2 GB แต่ตัวเลขไต่ขึ้นเร็ว เป็น 3 GB ทันทีที่เปิด ClamAV, Talk Recording หรือการค้นหาข้อความเต็ม เป็น 5 GB เมื่อเปิดทุกอย่าง บวกอีกราว 1 GB ต่อผู้ใช้ที่ใช้งานจริงหนึ่งคนเหนือค่าพื้นฐาน
ตัวเลขเหล่านี้เป็นคำแนะนำสำหรับการคำนวณขนาด ไม่ใช่การวัดการใช้แรมในสภาวะคงที่ AIO ต้องการหน่วยความจำมากขึ้นเมื่อเปิดบริการเสริม และแนะนำให้เผื่อเพิ่มสำหรับผู้ใช้ที่ใช้งานจริงแต่ละคน นี่คือต้นทุนเชิงสถาปัตยกรรมของการมัดฟีเจอร์กว่าสามสิบอย่างไว้ในชุดซอฟต์แวร์โฮสต์เองชุดเดียว ที่มา: github.com/nextcloud/all-in-one/discussions/1335.
ชุมชน Nextcloud เองก็สังเกตเห็น กระทู้บน help.nextcloud.com ชื่อ “Nextcloud Lite, discuss” ถูกเปิดขึ้นในเดือนธันวาคม 2024 เพื่อถามว่าโครงการควรออกดิสทริบิวชันแบบตัดทอนสำหรับผู้ใช้ที่ต้องการแค่ไฟล์กับการแชร์หรือไม่ ผู้ใช้บางส่วน รวมถึงคนที่ชอบ Nextcloud ในด้านอื่น ได้ขอให้มีบิลด์ที่เบากว่า แต่คำตอบส่วนใหญ่ไม่เห็นด้วย โดยให้เหตุผลว่าฟีเจอร์ที่ไม่ต้องการก็แค่ปิดเสีย และการตัดแอปด้านความปลอดภัยออกเป็นการแลกที่ไม่คุ้ม กระทู้ยังเปิดอยู่ และผู้ดูแลก็ยังไม่ได้ผูกมัดตัวเองไปทางใด อ้างอิง: help.nextcloud.com/t/nextcloud-lite-discuss/213611.
ข้อโต้แย้งฝั่งตรงข้ามก็มีน้ำหนัก AIO มาพร้อม PostgreSQL, Redis และ APCu อยู่แล้ว คำแนะนำด้านประสิทธิภาพของมันเองก็บอกให้ปิดคอนเทนเนอร์เสริมและแอป Nextcloud ที่คุณไม่ต้องใช้ ถ้าอินสแตนซ์ของคุณรู้สึกหนักเพราะคุณเปิด Office, Talk, ClamAV, การค้นหาข้อความเต็ม หรือบริการอื่นที่เลิกใช้ไปแล้ว ให้ตัดตรงนั้นก่อน แต่ถ้าคุณใช้บริการเหล่านั้นร่วมกันจริง ๆ พื้นที่ที่กินไปมากกว่าก็กำลังทำงานที่มีประโยชน์อยู่
แต่ถ้าคุณติดตั้ง Nextcloud แล้วเปิดมันเพียงเพื่อโยนไฟล์ลงโฟลเดอร์ที่ซิงก์ไว้ บทสนทนาเรื่องการปรับจูนก็ไม่เกี่ยวกับคุณ
หากอยากรู้ว่า Nextcloud ยืนอยู่ตรงไหนเมื่อเทียบกับฟอร์กที่ใกล้ที่สุดของมัน ดูได้ที่ การเปรียบเทียบ Nextcloud กับ ownCloud.
ใจความสำคัญของหัวข้อนี้: Nextcloud มีสเปกเกินความจำเป็นสำหรับรูปแบบการทำงานเพียงแบบเดียวที่คนโฮสต์เองส่วนใหญ่ใช้มันจริง ๆ
การวินิจฉัยสามต้นแบบ: ทางออกไหนคือของคุณ
ก่อนเลือกเครื่องมือ ให้เลือกรูปแบบการทำงานก่อน ผู้ใช้ Nextcloud แทบทุกคนที่ผมได้คุยด้วยเข้ากับหนึ่งในสามรูปแบบนี้อย่างชัดเจน
ต้นแบบ A ซิงก์ระหว่างอุปกรณ์อย่างเดียว “ผมติดตั้ง Nextcloud เพื่อให้แล็ปท็อป เดสก์ท็อป และมือถือซิงก์กัน ผมไม่เคยใช้หน้าเว็บทำอะไรจริงจัง และผมก็ไม่ได้แชร์ไฟล์กับคนอื่น”
ต้นแบบ B แชร์ไฟล์ในทีม “ผมติดตั้ง Nextcloud เพราะต้องมีหลายคนอัปโหลดขึ้นและดาวน์โหลดจากพื้นที่ไฟล์ร่วมกัน บางทีก็จากเบราว์เซอร์ บางทีก็จากไคลเอนต์บนเดสก์ท็อป ผมให้ความสำคัญกับประสิทธิภาพเวลาจัดการไฟล์ใหญ่”
ต้นแบบ C ใช้แค่เว็บพอร์ทัล “ผมติดตั้ง Nextcloud เป็นตัวเรียกดูไฟล์ผ่านเว็บ เป็นช่องทางล็อกอินแล้วหยิบไฟล์ของตัวเองจากที่ไหนก็ได้ ผมอาจจะเคยติดตั้งไคลเอนต์บนเดสก์ท็อป แต่แทบไม่ได้ใช้ การซิงก์แบบเรียลไทม์ไม่ใช่ประเด็น”
ถ้ามีสองแบบที่ตรงกับคุณ ให้เลือกแบบที่ทำให้คุณพูดได้ว่า “ถ้าพรุ่งนี้มันหยุดทำงาน ผมจะรู้ภายในหนึ่งชั่วโมง” นั่นคือรูปแบบการทำงานที่คุณพึ่งพาจริง ส่วนที่เหลือเป็นของแถมที่ดี ซึ่งเปลี่ยนทีหลังได้หรือไม่มีก็อยู่ได้
ทรัพยากรขั้นต่ำของแต่ละเส้นทาง:
| เครื่องมือ | คำแนะนำเรื่องแรม | สถาปัตยกรรมเบื้องหลัง | รูปแบบการซิงก์ |
|---|---|---|---|
| Nextcloud AIO | เริ่มที่ 2 GB เมื่อเปิดคอนเทนเนอร์เสริม บวกอีกราว 1 GB ต่อผู้ใช้ที่ใช้งานจริงหนึ่งคน | PHP + PostgreSQL + หลายคอนเทนเนอร์ | ไคลเอนต์-เซิร์ฟเวอร์ ซิงก์ทั้งไฟล์ |
| Seafile CE | ค่าขั้นต่ำที่บันทึกไว้คือ 2 GB | C/Python + MariaDB | ไคลเอนต์-เซิร์ฟเวอร์ ตัดข้อมูลซ้ำระดับบล็อก |
| Syncthing | ไม่มีค่าขั้นต่ำตายตัวอย่างเป็นทางการ ขึ้นกับขนาดคลังไฟล์และการสแกน | ไบนารี Go ไฟล์เดียว | เพียร์ทูเพียร์ |
| Cloudreve | ยังไม่มีการประกาศค่าขั้นต่ำแบบตายตัวอย่างเป็นทางการ | Go + ฐานข้อมูล | ไคลเอนต์-เซิร์ฟเวอร์ จัดเก็บได้หลายแบ็กเอนด์ |
| AList | ยังไม่มีการประกาศค่าขั้นต่ำแบบตายตัวอย่างเป็นทางการ | Go + ใช้ SQLite เป็นค่าเริ่มต้น | เว็บพอร์ทัลวางทับที่เก็บข้อมูลที่เมานต์ไว้ |
ตัวเลขของ Nextcloud AIO และ Seafile CE ข้างต้นเป็นข้อกำหนดหรือคำแนะนำที่มีบันทึกไว้ ส่วน Syncthing, Cloudreve และ AList ไม่ได้ประกาศค่าแรมขั้นต่ำแบบตายตัวที่เทียบเคียงกันได้อย่างสะอาด ดังนั้นให้คำนวณขนาดเครื่องมือเหล่านั้นจากคลังไฟล์จริงของคุณ แบ็กเอนด์ที่เก็บข้อมูล และภาระงานของคุณ แทนที่จะยึดตัวเลขหน่วยความจำตอนว่างจากชุมชนเป็นข้อกำหนด
ใจความสำคัญของหัวข้อนี้: เลือกเครื่องมือที่ตรงกับรูปแบบการทำงานที่คุณใช้ Nextcloud ทำอยู่ ไม่ใช่ตัวที่มีรายการฟีเจอร์ยาวที่สุด
ต้นแบบ A ใช้ Syncthing สำหรับซิงก์ระหว่างอุปกรณ์
แล็ปท็อปหนึ่งเครื่อง เดสก์ท็อปหนึ่งเครื่อง และมือถือหนึ่งเครื่อง คุณวางไฟล์ลงในโฟลเดอร์บนแล็ปท็อป ยี่สิบวินาทีต่อมามันก็ไปโผล่ที่อีกสองเครื่อง ไม่มีเว็บพอร์ทัล ไม่มีคลังไฟล์ร่วม ไม่มีทีม Syncthing ถูกสร้างมาเพื่อสิ่งนี้ และมันก็ทำแค่สิ่งนี้อย่างเดียว
Syncthing เป็นแบบเพียร์ทูเพียร์ ไม่มีเซิร์ฟเวอร์ในเชิงสถาปัตยกรรม อุปกรณ์ทุกเครื่องรันไบนารีตัวเดียวกัน และค้นหากันเองผ่านเครือข่ายรีเลย์ทั่วโลกหรือผ่าน LAN คุณจะเพิ่ม VPS เข้าไปในเครือข่ายก็ได้ แต่มันจะเป็นเพียงหนึ่งในเพียร์ ไม่ใช่ศูนย์กลาง ไม่มีตัวเรียกดูไฟล์ผ่านเว็บ ไม่มี CalDAV ไม่มีสิทธิ์แบบทีม ถ้าการใช้งาน Nextcloud ของคุณมีแค่ “ทำให้โฟลเดอร์ของผมซิงก์กัน” สิ่งที่เสียไปเหล่านี้ก็ไม่มีอันไหนสำคัญ
ส่วนที่ได้รับความสนใจมากที่สุดคือต้นทุนด้านทรัพยากร สำหรับคลังไฟล์ขนาดเล็ก สมมติว่าไม่กี่พันไฟล์ภายใน 50 GB Syncthing ตอนว่างมักใช้แรมอยู่ระหว่าง 50 ถึง 100 MB เมื่อคลังไฟล์ไต่ขึ้นไปถึงหลายแสนไฟล์ การใช้แรมอาจทะลุ 700 MB คนที่โฮสต์เองส่วนใหญ่ไม่เคยไปถึงจุดนั้น แต่ถ้าคุณมีไฟล์สองแสนห้าหมื่นไฟล์ในโฟลเดอร์เดียว คุณจะไปถึง
มีแหล่งข้อมูลชั้นต้นสองแห่งที่บันทึกพฤติกรรมเมื่อขยายขนาดนี้ไว้:
- กระทู้อายุยาวในฟอรัม Syncthing ว่าด้วยการใช้แรม: forum.syncthing.net/t/ram-utilization/9769
- อิชชูบน GitHub ของโครงการเองว่าด้วยหน้าผาของการขยายขนาด: github.com/syncthing/syncthing/issues/468
VPS ยังมีความหมายแม้ในโมเดลเพียร์ทูเพียร์ แล็ปท็อปกับมือถือของคุณไม่ได้ออนไลน์พร้อมกัน ถ้าคุณอยากให้การเปลี่ยนแปลงกระจายต่อได้แม้เครื่องหนึ่งหลับอยู่ คุณต้องมีเครื่องที่สามที่เปิดตลอดเวลา VPS ที่รัน Syncthing ทำหน้าที่นั้นได้ และส่งสำเนาล่าสุดให้อุปกรณ์เครื่องถัดไปที่ตื่นขึ้นมา คลังไฟล์ขนาดเล็กทำงานได้สบายภายในแรม 512 MB ให้ 1 GB ถ้าคลังไฟล์ของคุณโตเกินไม่กี่แสนไฟล์
พัฒนาบน Linux VPS พร้อมสิทธิ์รูท, NVMe และพลัง AMD EPYC
ดูแพ็กเกจ Linuxข้อควรระวังเรื่อง iOS คือสิ่งที่บทแนะนำ Syncthing มักข้ามไป ไม่มีไคลเอนต์ Syncthing อย่างเป็นทางการสำหรับ iOS ที่อัปโหลดรูปเบื้องหลังได้อย่างน่าเชื่อถือ มีไคลเอนต์จากบุคคลที่สามอยู่หลายตัว แต่ไม่มีตัวไหนเทียบได้กับสิ่งที่แอป iOS ของ Nextcloud ทำกับการสำรองรูปในม้วนฟิล์ม ถ้าการซิงก์รูปจาก iPhone คือเหตุผลที่คุณรัน Nextcloud อยู่ Syncthing เพียงลำพังจะแทนที่ไม่ได้ ทางเลี่ยงคือใช้แอปเสียเงินอย่าง PhotoSync ที่ส่งรูปเข้าโฟลเดอร์ Syncthing หรือปล่อยให้ Nextcloud ทำงานต่อไปเพื่องานนี้อย่างเดียว ระหว่างที่คุณย้ายทุกอย่างที่เหลือ
แรงเสียดทานในการย้ายทิศทางนี้ต่ำ Syncthing ทำงานบนระบบไฟล์ปกติ คุณชี้มันไปที่โฟลเดอร์ที่ไฟล์ของคุณอยู่แล้ว ใส่รหัสอุปกรณ์ของเครื่องอื่น แล้วการซิงก์ก็เริ่มทำงาน ไม่มีอะไรต้องแปลง ไม่มีอะไรต้องนำเข้า ข้อมูลก็คือสิ่งที่อยู่บนดิสก์อยู่แล้ว
ใจความสำคัญของหัวข้อนี้: Syncthing ชนะเรื่องทรัพยากรขั้นต่ำและความน่าเชื่อถือของการซิงก์ระหว่างอุปกรณ์ แต่แพ้เรื่องการสำรองรูปบน iOS และยอมทิ้งเว็บพอร์ทัลไปทั้งหมด
ต้นแบบ B ใช้ Seafile สำหรับซิงก์ไฟล์ในทีม
ทีมสี่คน คลังไฟล์ร่วมชื่อ “Operations” ที่มีสัญญา ไฟล์งานออกแบบ และไฟล์ส่งออกรวม 60 GB สามในสี่คนใช้ไคลเอนต์ซิงก์บนเดสก์ท็อป อีกคนชอบเบราว์เซอร์มากกว่า เป็นครั้งคราวก็มีคนอัปโหลดวิดีโอขนาด 4 GB
การติดตั้ง Nextcloud ที่ใช้แชร์ไฟล์อย่างเดียวก็ยังอาจต้องการพื้นที่เผื่อมากขึ้นเมื่อผู้ใช้ที่ใช้งานจริงและบริการเสริมเพิ่มขึ้น ส่วน Seafile แคบกว่าโดยการออกแบบ จึงคำนวณขนาดได้ง่ายกว่าเมื่อการซิงก์และแชร์ไฟล์เป็นงานเดียวที่คุณต้องการ
Seafile เขียนด้วย C และ Python โดยใช้ MariaDB เป็นแบ็กเอนด์ ไม่มีชั้น PHP รูปแบบการซิงก์คือการตัดข้อมูลซ้ำระดับบล็อก เมื่อคุณแก้ไฟล์ จะมีเฉพาะบล็อกที่เปลี่ยนเท่านั้นที่ถูกส่ง และบล็อกที่เหมือนกันระหว่างผู้ใช้จะถูกเก็บเพียงชุดเดียว ส่วนการซิงก์ค่าเริ่มต้นของ Nextcloud ส่งทั้งไฟล์ในสถานการณ์ส่วนใหญ่
รายงานจากชุมชนที่ว่า Seafile เร็วกว่าบนคลังไฟล์ขนาดใหญ่นั้นแพร่หลายมาก และสถาปัตยกรรมคือเหตุผล ผมจะไม่อ้างตัวเลขสัดส่วนที่ถูกพูดซ้ำในบทความเปรียบเทียบ เพราะร่องรอยไม่นำไปสู่แหล่งข้อมูลชั้นต้น สิ่งที่ผมพูดได้คือ การตัดข้อมูลซ้ำระดับบล็อกซึ่งมีบันทึกไว้ในคู่มือของ Seafile คือเหตุผลเชิงโครงสร้างที่ทำให้ความต่างด้านความเร็วมีอยู่จริง
เอกสารปัจจุบันของ Seafile Community Edition ระบุค่าขั้นต่ำไว้ที่แรม 2 GB และซีพียู 2 คอร์ ซึ่งตรงกับค่าขั้นต่ำ 2 GB ของ Nextcloud AIO เมื่อเปิดคอนเทนเนอร์เสริมตัวใดก็ตาม ขอบเขตที่แคบกว่าของ Seafile ยังช่วยให้คำนวณขนาดสำหรับการแชร์ไฟล์ได้ง่ายกว่า แต่ส่วนต่างหน่วยความจำที่แท้จริงขึ้นอยู่กับภาระงาน จำนวนผู้ใช้ที่ใช้งานจริง ขนาดคลังไฟล์ และบริการใดของ Nextcloud ที่เปิดอยู่
สำหรับทีมที่ต้องการแค่ซิงก์และแชร์ไฟล์ Seafile ช่วยให้คุณเลี่ยงบริการส่วนเกินของ Nextcloud ที่ไม่ได้ใช้ นั่นอาจลดพื้นที่ที่กินบนเซิร์ฟเวอร์ลงได้ แต่ส่วนต่างที่แท้จริงขึ้นอยู่กับภาระงาน ไม่ใช่กฎตายตัวแบบ 2 GB เทียบกับ 5 GB
การย้ายต้องวางแผนบ้าง เพราะไม่มีตัวนำเข้าในตัวจาก Nextcloud ไปยัง Seafile ให้ตั้งเซิร์ฟเวอร์ Seafile ขึ้นมา ติดตั้งไคลเอนต์ Seafile บนเดสก์ท็อปในเครื่องที่เข้าถึงไฟล์เดิมของคุณได้ สร้างคลังไฟล์ปลายทาง แล้วปล่อยให้ไคลเอนต์อัปโหลดไฟล์ขึ้นไป ระยะเวลาที่ใช้ขึ้นอยู่กับขนาดคลังไฟล์และแบนด์วิดท์ขาขึ้นที่มี
Seafile เก็บข้อมูลของคลังไฟล์เป็นบล็อกและวัตถุภายใน ไม่ใช่ไฟล์ปกติที่เปิดดูได้ การแสดงรายการไดเรกทอรีข้อมูลด้วย ls จะเห็นโครงสร้างวัตถุภายในของ Seafile แทนที่จะเป็นโครงสร้างโฟลเดอร์เดิมของคุณ การเข้ารหัสเป็นฟีเจอร์แยกต่างหาก ไม่ใช่เหตุผลที่วัตถุเหล่านั้นอ่านไม่ออก นั่นหมายความว่าคุณจะกู้คลังไฟล์ Seafile คืนมาด้วยการคัดลอกไฟล์ที่ดูปกติออกจากที่เก็บข้อมูลแบ็กเอนด์เฉย ๆ ไม่ได้
Seafile CE ยังต้องเก็บกวาดขยะด้วยมือ คุณต้องรันสคริปต์เพื่อเคลียร์บล็อกที่ไม่มีการอ้างอิงหลังจากลบคลังไฟล์หรือไฟล์ รุ่น Pro ทำส่วนนี้อัตโนมัติมากกว่า ส่วนรุ่น Community ไม่ทำ Seafile จะทำให้คุณอึดอัด ถ้าความสบายใจในการดูแลระบบของคุณมาจากการที่คัดลอกข้อมูลออกมาได้ทุกเมื่อด้วยคำสั่ง cp -r.
อีกสิ่งที่ต้องเผื่อใจไว้ว่าจะเสียไปคือปฏิทินและรายชื่อผู้ติดต่อ Seafile ไม่ได้รองรับทั้ง CalDAV และ CardDAV ถ้า Nextcloud ของคุณคือสมุดที่อยู่ที่อยู่เบื้องหลังมือถือ คุณจะต้องหาบริการเบา ๆ อีกตัวมาอุดช่องว่างนั้น Radicale และ Baikal คือคำตอบมาตรฐาน
ใจความสำคัญของหัวข้อนี้: Seafile เข้ากันดีถ้าคุณใช้ Nextcloud เป็นพื้นที่แชร์ไฟล์หลายผู้ใช้เป็นหลัก สถาปัตยกรรมที่เน้นไฟล์ช่วยให้คุณไม่ต้องแบกชุดเครื่องมือทำงานร่วมกันที่กว้างกว่าของ Nextcloud สิ่งที่แลกไปคือรูปแบบการเก็บข้อมูลแบบบล็อกและวัตถุ กับการเสีย CalDAV/CardDAV
ต้นแบบ C ใช้ Cloudreve หรือ AList สำหรับเว็บพอร์ทัล
ทางออกที่ถูกมองข้ามมากที่สุด ผู้ใช้กลุ่มนี้อยากได้หน้าเว็บที่ล็อกอินจากอุปกรณ์ไหนก็ได้แล้วหยิบไฟล์ของตัวเองไป เขาแทบไม่เคยใช้ไคลเอนต์บนเดสก์ท็อป และไม่ได้สนใจการซิงก์แบบเรียลไทม์ สำหรับงานนี้ ชุดฟีเจอร์ทั้งหมดของ Nextcloud มากเกินความจำเป็นไปไกล
สำหรับผู้ใช้กลุ่มนั้น ทั้ง Nextcloud, Seafile และ Syncthing ล้วนไม่ใช่คำตอบที่ถูก คำตอบที่ถูกคือเว็บพอร์ทัล มีสองโครงการที่ลงตัวตรงนี้ และทั้งคู่ต่างกันที่แกนเดียว คือเครื่องมือนั้นจัดการที่เก็บข้อมูลให้คุณ หรือแค่อ่านจากมัน
Cloudreve คือเว็บพอร์ทัลบวกกับชั้นที่เก็บข้อมูลแบบมีการจัดการ ไฟล์อยู่ในที่เก็บข้อมูลที่ Cloudreve ควบคุม (ดิสก์ในเครื่อง ที่เก็บวัตถุที่เข้ากันได้กับ S3 หรือแบ็กเอนด์อื่น) มีบัญชีผู้ใช้และโควตา และตอนนี้ Cloudreve Pro มีไคลเอนต์เดสก์ท็อปสำหรับ Windows อย่างเป็นทางการ พร้อมการซิงก์สองทางแบบเรียลไทม์ สถาปัตยกรรมคือไบนารี Go บวกฐานข้อมูล และที่เก็บซอร์สของโครงการยังคึกคักอยู่ที่ github.com/cloudreve/cloudreve.
AList วางอินเทอร์เฟซเว็บทับที่เก็บข้อมูลที่มีอยู่แล้ว มันเรียกดูและจัดการแบ็กเอนด์ที่เมานต์ไว้ได้ เช่น ดิสก์ในเครื่อง S3, Google Drive, OneDrive, SMB และ WebDAV รวมถึงการจัดการไฟล์ในกรณีที่แบ็กเอนด์รองรับ มันทำงานเป็นไบนารี Go และใช้ SQLite เป็นค่าเริ่มต้น การติดตั้งพื้นฐานจึงไม่ต้องมีเซิร์ฟเวอร์ฐานข้อมูลแยก ถ้าไฟล์ของคุณอยู่ในรูปไฟล์ปกติบนที่เก็บข้อมูลที่รองรับอยู่แล้ว AList ก็แสดงไฟล์เหล่านั้นได้โดยไม่ต้องนำเข้าไปเป็นรูปแบบไฟล์ใหม่
จะเลือกตัวไหนเมื่อไร:
- AList ถ้าไฟล์ของคุณจัดระเบียบไว้บนดิสก์หรือบนที่เก็บข้อมูลบนคลาวด์อยู่แล้ว และคุณต้องการแค่อินเทอร์เฟซเว็บที่รวมศูนย์วางทับ การย้ายแทบเป็นศูนย์ แค่ชี้ AList ไปยังที่ที่ไฟล์อยู่
- Cloudreve ถ้าคุณต้องการชั้นที่มีการจัดการ พร้อมบัญชีผู้ใช้ โควตา และแบ็กเอนด์ที่เก็บข้อมูลเดียวที่พอร์ทัลดูแลตั้งแต่ต้นจนจบ การย้ายเบา ตั้งค่าแบ็กเอนด์ คัดลอกไฟล์ แล้วก็จบ
มีเรื่องหนึ่งที่ต้องเข้าใจให้ชัดก่อนเลือกตัวใดตัวหนึ่ง AList ไม่ใช่ตัวแทนของการซิงก์ และความสามารถด้านการซิงก์ของ Cloudreve ก็แคบกว่า Nextcloud Cloudreve Pro มีไคลเอนต์ซิงก์บนเดสก์ท็อปสำหรับ Windows อย่างเป็นทางการ แต่ทั้งสองเครื่องมือไม่ได้ให้ระบบนิเวศ CalDAV/CardDAV แบบ Nextcloud หรือกระบวนการสำรองรูปที่ครอบคลุมทุกแพลตฟอร์มอย่างเทียบเท่า ถ้าสิ่งเหล่านั้นจำเป็น คุณก็ใกล้กับต้นแบบ A หรือ B มากกว่า C AList และ Cloudreve ไม่ใช่ Nextcloud รุ่นเบา แต่เป็นเครื่องมือที่แคบกว่าสำหรับงานที่แคบกว่า
ใจความสำคัญของหัวข้อนี้: Cloudreve และ AList เป็นตัวเลือกที่ดีถ้าคุณใช้ตัวเรียกดูไฟล์ผ่านเว็บของ Nextcloud เป็นหลัก AList ทำให้การติดตั้งเรียบง่ายกว่าเมื่อคุณต้องการแค่ชั้นเว็บวางทับที่เก็บข้อมูลเดิม ส่วน Cloudreve สมเหตุสมผลกว่าเมื่อคุณต้องการที่เก็บข้อมูลแบบมีการจัดการ บัญชีผู้ใช้ และการซิงก์บนเดสก์ท็อป Windows
แผนที่แรงเสียดทานในการย้าย: อะไรที่คุณเก็บไว้ได้ อะไรที่เสียไป
นี่คือตารางที่ควรอ่านก่อนจะถอดปลั๊ก และเป็นจุดที่การย้ายส่วนใหญ่พลาดพลั้ง
| จาก Nextcloud ไปยัง | ไฟล์ย้ายตามไปได้หรือไม่ | ปฏิทิน / รายชื่อผู้ติดต่อ | การสำรองรูปบน iOS | โน้ต / งาน / Talk | ความพยายามในการย้าย |
|---|---|---|---|---|---|
| Syncthing | ได้ คัดลอกตรง ๆ | ต้องมีบริการ CalDAV/CardDAV แยกต่างหาก | ไม่มีไคลเอนต์ iOS อย่างเป็นทางการ | ไม่รวมอยู่ | ขึ้นอยู่กับปริมาณข้อมูลและจำนวนอุปกรณ์ |
| Seafile | ได้ อัปโหลดผ่านไคลเอนต์บนเดสก์ท็อป | ต้องมีบริการ CalDAV/CardDAV แยกต่างหาก | รองรับผ่านแอปมือถือของ Seafile | ไม่รวมอยู่ | ขึ้นอยู่กับปริมาณข้อมูลและความเร็วอัปโหลด |
| Cloudreve | ได้ คัดลอกไปยังที่เก็บข้อมูลที่ตั้งค่าไว้ | ไม่รวมอยู่ | ไม่มีกระบวนการเทียบเท่าการสำรองรูปจากกล้องของ Nextcloud | ไม่รวมอยู่ | ขึ้นอยู่กับแบ็กเอนด์และปริมาณข้อมูล |
| AList | ที่เก็บข้อมูลปกติที่มีอยู่เดิมเมานต์ใช้ได้ทันที | ไม่รวมอยู่ | ไม่มีการซิงก์บนมือถือในตัว | ไม่รวมอยู่ | ต่ำ ถ้าไฟล์อยู่บนแบ็กเอนด์ที่รองรับอยู่แล้ว |
ช่องว่างของ CalDAV/CardDAV คือต้นทุนการย้ายที่ถูกมองข้ามมากที่สุด ถ้าสมุดที่อยู่ในมือถือของคุณซิงก์กับ Nextcloud อยู่ สายนั้นจะขาดทันทีที่คุณหยุดรัน Nextcloud ไม่ว่าคุณจะเอาเครื่องมือจัดการไฟล์ตัวไหนมาแทนก็ตาม Radicale และ Baikal คือตัวแทนแบบเบาที่ใช้กันทั่วไป และทั้งคู่เป็นบริการที่เล็กกว่าการติดตั้ง Nextcloud เต็มรูปแบบมาก นี่คือตัวอุดช่องว่างที่ควรมีอยู่ในสายตาก่อนจะถอดปลั๊กอินสแตนซ์ Nextcloud
ถ้าคุณอยากมีสภาพแวดล้อมแยกไว้ทดสอบการย้ายก่อนจะเอาข้อมูลจริงเข้าไปเสี่ยง Linux VPS ของ Cloudzy ให้พื้นที่สะอาด ๆ สำหรับทำสิ่งนั้น เซิร์ฟเวอร์ทดสอบแยกต่างหากช่วยให้คุณซ้อมการย้ายได้โดยไม่แตะอินสแตนซ์ที่ใช้งานจริง และคุณติดตั้งตัวใดก็ได้ต่อไปนี้ด้วยคลิกเดียว:
เมื่อไรที่คุณควรอยู่กับ Nextcloud ต่อไป
การวินิจฉัยนี้ใช้ได้สองทาง ต่อไปนี้คือสามเหตุผลที่ควรอยู่ต่อ เรียงตามน้ำหนัก
คุณใช้ระบบปฏิทิน รายชื่อผู้ติดต่อ งาน และโน้ตอย่างจริงจัง Nextcloud รวมทั้งสี่อย่างไว้หลังการล็อกอินเดียว พร้อมการรองรับ CalDAV/CardDAV ที่ใช้งานได้จริง หน้าเว็บที่ใช้งานได้จริง และแอปมือถือที่ใช้งานได้จริง การแทนที่สิ่งนั้นด้วยบริการแยกกันหมายถึงต้องรัน Radicale หรือ Baikal สำหรับปฏิทินและรายชื่อผู้ติดต่อ แอปโน้ตอีกตัว และตัวจัดการงานอีกตัว จากบริการเดียวกลายเป็นสองหรือสาม จากจุดที่พังได้จุดเดียวกลายเป็นสองหรือสาม ถ้านี่คือการทำงานประจำวันของคุณ Nextcloud ก็คุ้มค่าแรมที่มันกินไป
คุณพึ่งพาชุดเครื่องมือทำงานร่วมกันที่รวมมาในตัวของ Nextcloud Nextcloud เก็บไฟล์ การแก้ไขเอกสาร ปฏิทิน รายชื่อผู้ติดต่อ งาน โน้ต และฟีเจอร์การทำงานร่วมกันอื่น ๆ ไว้หลังบัญชีเดียวและอินเทอร์เฟซเดียว Seafile เองก็เชื่อมต่อ Collabora หรือ OnlyOffice เพื่อแก้เอกสารพร้อมกันได้ ดังนั้นงานเอกสารร่วมกันเพียงอย่างเดียวจึงไม่ใช่เหตุผลที่จะตัดมันทิ้ง ความต่างอยู่ตรงที่การแทนที่ระบบนิเวศที่กว้างกว่าของ Nextcloud ยังคงหมายถึงการเอาบริการแยก ๆ มาต่อกันสำหรับฟีเจอร์ที่ Seafile ไม่ได้ครอบคลุม
Nextcloud ของคุณหนักเพราะบริการที่คุณไม่ได้ใช้ AIO มาพร้อม PostgreSQL, Redis และ APCu อยู่แล้ว การเปลี่ยนฐานข้อมูลหรือเปิด APCu จึงไม่ใช่ขั้นตอนการปรับจูนตรงนี้ ให้เริ่มจากการปิดคอนเทนเนอร์เสริมและแอป Nextcloud ที่คุณไม่ต้องใช้ ถ้า Office, Talk, ClamAV, การค้นหาข้อความเต็ม หรือบริการพรีวิวทำงานอยู่โดยไม่มีจุดประสงค์จริง ให้ปลดภาระนั้นออกก่อนตัดสินใจย้าย
ตรรกะที่บอกว่า “ไปเถอะ ถ้าคุณใช้ฟีเจอร์แค่ 10%” ก็บอกด้วยว่า “อยู่ต่อเถอะ ถ้าคุณใช้ฟีเจอร์เหล่านั้นจริง” ซื่อสัตย์กับตัวเองว่าคุณเป็นแบบไหน
ใจความสำคัญของหัวข้อนี้: ถ้ารูปแบบการทำงานของคุณมีปฏิทิน รายชื่อผู้ติดต่อ และงานเอกสารร่วมกัน Nextcloud ก็ยังเป็นเครื่องมือที่ถูกต้อง จัดการการตั้งค่าให้เรียบร้อยก่อนจะหนี
คำถามที่พบบ่อย
ทางเลือกแทน Nextcloud ที่เบาที่สุดคืออะไร
ขึ้นอยู่กับรูปแบบการทำงาน AList เป็นหนึ่งในตัวเลือกที่ง่ายที่สุดสำหรับการเข้าถึงไฟล์ผ่านเว็บอย่างเดียว เพราะมันวางทับที่เก็บข้อมูลเดิมได้และใช้ SQLite เป็นค่าเริ่มต้น Syncthing เป็นตัวเลือกที่แคบกว่าสำหรับการซิงก์ระหว่างอุปกรณ์ ส่วน Seafile Community Edition เป็นตัวแทนที่ครบถ้วนกว่าเมื่อคุณต้องการแชร์ไฟล์แบบหลายผู้ใช้ โดยค่าขั้นต่ำที่บันทึกไว้คือแรม 2 GB และซีพียู 2 คอร์
Seafile ใช้หน่วยความจำน้อยกว่า Nextcloud หรือไม่
Seafile อาจต้องการทรัพยากรน้อยกว่าสำหรับภาระงานที่มีแค่การแชร์ไฟล์ แต่ไม่มีส่วนต่างแรมตายตัวที่ใช้ได้กับทุกการติดตั้ง ทั้ง Seafile CE และ Nextcloud AIO ต่างเริ่มต้นได้ราว 2 GB ขึ้นอยู่กับการตั้งค่า จากนั้นความจุที่ Nextcloud แนะนำจะโตขึ้นตามผู้ใช้ที่ใช้งานจริงและบริการที่เปิดไว้ ขณะที่ Seafile ถูกสร้างขึ้นรอบภาระงานที่แคบกว่า คือการซิงก์และแชร์ไฟล์
ย้ายจาก Nextcloud ไป Seafile อย่างไร
ไม่มีตัวนำเข้าอัตโนมัติ เส้นทางที่ได้ผลคือ ติดตั้ง Seafile ติดตั้งไคลเอนต์ Seafile บนเดสก์ท็อปในเครื่องที่อ่านไดเรกทอรีข้อมูลของ Nextcloud ได้ สร้างคลังไฟล์บนเซิร์ฟเวอร์ Seafile แล้วปล่อยให้ไคลเอนต์ดันไฟล์เข้าไปในรูปของบล็อก ปฏิทินและรายชื่อผู้ติดต่อจะไม่ย้ายตามไฟล์ไปด้วย คุณจะต้องตั้งเซิร์ฟเวอร์ CalDAV แยกต่างหากอย่าง Radicale หรือ Baikal แล้วซิงก์ใหม่จากมือถือ ระยะเวลาที่ใช้ขึ้นอยู่กับปริมาณข้อมูลและแบนด์วิดท์ขาขึ้นที่คุณมี
Syncthing ดีกว่า Nextcloud สำหรับการสำรองรูปหรือไม่
บนมือถือยังตอบไม่ได้เต็มปาก แอป Android อย่างเป็นทางการของ Syncthing ยุติไปหลังรุ่นเดือนธันวาคม 2024 แม้จะยังมีตัวเลือกบน Android ที่ชุมชนดูแลอยู่ ส่วน iOS ก็ยังไม่มีไคลเอนต์ Syncthing อย่างเป็นทางการที่สำรองรูปเบื้องหลังได้แบบ Nextcloud ถ้าการสำรองรูปจากกล้องอัตโนมัติคือหัวใจของระบบคุณ ให้ถือว่าการรองรับบนมือถือเป็นการตัดสินใจแยกต่างหาก แทนที่จะเหมาว่า Syncthing แทนแอป Nextcloud ได้
รันทางเลือกแทน Nextcloud บน VPS ราคาถูกได้ไหม
ได้ แต่ให้คำนวณขนาด VPS ตามเครื่องมือและภาระงานที่เจาะจง แทนที่จะเหมาว่าเป้าหมายหน่วยความจำเดียวใช้ได้กับทั้งสี่ตัว Seafile CE แนะนำอย่างเป็นทางการว่าอย่างน้อยแรม 2 GB และซีพียู 2 คอร์ ส่วน Syncthing, AList และ Cloudreve ไม่ได้ให้ค่าแรมขั้นต่ำแบบตายตัวที่เทียบกันได้ตรง ๆ สำหรับภาระงานที่พูดถึงตรงนี้ ให้เริ่มจากข้อกำหนดการติดตั้งของแต่ละตัว แล้วเผื่อพื้นที่ไว้สำหรับขนาดคลังไฟล์ ฐานข้อมูล และแบ็กเอนด์ที่เก็บข้อมูลของคุณ
การสนทนา
ความคิดเห็น
เข้าสู่ระบบเพื่อร่วมสนทนา