Tìm kiếm
40 kết quả cho “SSD”. Tìm không phân biệt dấu.
- Increasing Magic Pocket write throughput by removing our SSD cache disks Bài tóm tắt · Dropbox · 2022
…re/increasing-magic-pocket-write-throughput-by-removing-our-ssd-cache-disks) Bối cảnh - 2017: Magic Pocket dùng ổ SMR (mật độ cao, nhưng nổi tiếng chậm khi ghi ngẫu nhiên). Mọi lượ…
- Evolution of Application Data Caching: From RAM to SSD Bài tóm tắt · Netflix · 2018
…-techblog/evolution-of-application-data-caching-from-ram-to-ssd-a33d6fa7a690) Bối cảnh - EVCache (từ 2013): cache phân tán dựa trên memcached, tích hợp với AWS, được gọi là "micros…
- How Discord Supercharges Network Disks for Extreme Low Latency Bài tóm tắt · Discord · 2022
…trong DB có giới hạn, quá ngưỡng thì phải chờ đĩa. - Local SSD (NVMe) nhanh nhưng, theo Discord, kém tin cậy trong thử nghiệm của họ: hỏng đĩa hoặc host gặp sự cố là mất dữ liệu,…
- What it takes to run Stack Overflow Bài tóm tắt · Stack Overflow · 2013
…lancer, 1 mạng. - Scale up: SQL Server 384 GB RAM và 1,8 TB SSD; Redis 96 GB; Elasticsearch 196 GB; tag engine dùng CPU nhanh nhất mua được; web server bình thường (32 GB, 2 CPU 4…
- A Higgs-bugson in the Linux Kernel Bài tóm tắt · Jane Street · 2025
…ông bao giờ fail. Thay đổi chính (quá trình gỡ) - Kiểm rpc gssd (daemon root lấy credential Kerberos hộ kernel qua rpc pipefs ): kernel không xin credential mới, credential còn hạn…
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồn:
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.
- Tách compute khỏi storage Chủ đề Thành viên
Hệ có trạng thái kiểu cổ điển (database, broker Kafka, fileserver Git) đặt dữ liệu bền trên đĩa của chính máy xử lý. Máy đó vừa là compute vừa là storage, nên:
- Chọn database theo workload Chủ đề Thành viên
Không có database tốt nhất, chỉ có database hợp với mẫu đọc/ghi ở một quy mô cụ thể. Mẫu đó thay đổi khi sản phẩm lớn lên. Ngoài ra, chuyên môn vận hành của đội cũng là một phần của "workload".
- Load shedding, rate limit và backpressure Chủ đề Thành viên
Mọi hệ đều có lúc nhận nhiều việc hơn sức làm: spike của người dùng, client nội bộ có bug, dependency chậm đi, retry dồn lại. Theo Discord, khi chạm giới hạn năng lực thì đó là bài toán kinh tế: hoặc tăng cung (thêm…
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- Dropbox Công ty Thành viên
Dropbox luôn là hybrid: metadata ở data center riêng, nội dung file trên S3. Ở ~500 PB họ tự xây Magic Pocket, theo Dropbox vì hiệu năng và unit economics . Cái giá kèm theo là phải tự dựng cả backbone và edge network .…
- Stack Overflow: The Hardware - 2016 Edition Bài tóm tắt · Stack Overflow · 2016
…a bao nhiêu; - đĩa: có chạm đĩa không, tải ghi ra sao (loại SSD nào), dữ liệu có tạm thời không (SSD không tụ rẻ hơn); - RAM: phải mua bao nhiêu và có thể dùng bao nhiêu; - CPU: ít…
- Netflix Công ty Thành viên
Sự cố hỏng DB năm 2008 dẫn tới 7 năm lên AWS theo hướng cloud-native . Bài kiểm tra lớn đầu tiên là sự cố AWS US-East năm 2011: kiến trúc stateless, nhiều zone, fallback chịu được, nhưng rút khỏi zone phải làm tay. Từ…
- A Decade of Evolution of Alibaba's Databases - Part 1 Bài tóm tắt · Alibaba · 2019
…dleware phân tán TDDL , AliSQL (nhánh MySQL), server x86 và SSD thay cho IOE. Nhờ đó họ scale out được, tự thêm tính năng vào kernel (vá hot row cho tồn kho , throttle SQL, thread…
- The Deceptively Simple Act of Writing to Disk Bài tóm tắt · ScyllaDB · 2026
…ật, throughput ghi lại giảm khoảng 10% trên các instance có SSD mới, nhanh. Họ đã chờ cải thiện, nên đây là tín hiệu đáng lo. - Phát hiện kèm theo: vụ request 512 byte ở phần 1 thậ…
- Common Performance Pitfalls of Modern Storage I/O Bài tóm tắt · ScyllaDB · 2026
…và logic: ghi không căn theo sector vật lý buộc controller SSD đọc cả trang, sửa, ghi lại. Firmware NVMe mới trên i7i báo sai sector vật lý là 512 byte (thật là 4 KB), nên IOTune…
- Discord Công ty Thành viên
Hiếm có công ty nào kể cùng một bài toán qua 6 năm như Discord. Năm 2015 họ cố ý dùng một replica set MongoDB để ra sản phẩm trong 2 tháng, kèm đường thoát. Họ phân tích workload rồi chuyển sang Cassandra 12 node với…
- 25% or 6 to 4: The 11/6/23 Authentication Outage Bài tóm tắt · Discord · 2023
…chuẩn của Discord: "super-disk" RAID gương giữa NVMe local SSD (mất khi reboot) và persistent disk; replication qua 3 zone, đọc quorum, nên chịu được mất một zone. Khởi động node…
- A look inside our sixth generation of server hardware Bài tóm tắt · Dropbox · 2022
…a của Magic Pocket: mật độ rack gấp đôi, CPU nhiều hơn 60%, SSD NVMe 16 TB (gấp đôi flash thế hệ trước). - Compute (Cartman): máy 1U cấp thấp, 46 máy/rack: 48 core, 256 GB RAM, NIC…
- Fastest Table Sort in the West – Redesigning DuckDB's Sort Bài tóm tắt · DuckDB Labs · 2021
…uckDB) - Hiệu năng giảm mượt khi dữ liệu vượt RAM, tận dụng SSD; theo họ các hệ khác hoặc hết bộ nhớ mà chết, hoặc chuyển sang chiến lược sort ngoài chậm hơn nhiều. Bài học cho SWE…
- Scaling Kubernetes to 2,500 nodes Bài tóm tắt · OpenAI · 2018
…: etcd chậm. kubectl hay timeout; thêm master chỉ đỡ tạm. Ổ SSD mạng P30 (5.000 IOPS) nhưng etcd ghi tuần tự, nên bị giới hạn bởi latency (2 ms mỗi lần ghi), chỉ dùng được khoảng 1…
- Alibaba Công ty Thành viên
Database của Alibaba đi qua ba giai đoạn, đều do đỉnh tải Double 11 dẫn dắt: thương mại (IBM/Oracle/EMC, 2005–2009) → "De-IOE" sang mã nguồn mở với middleware TDDL và AliSQL (2010–2015) → tự phát triển X-DB (từ 2016).…
- Evaluating MySQL Parallel Replication Part 4: More Benchmarks in Production Bài tóm tắt · Booking.com · 2016
…là thắng lớn. - Mọi test dùng đĩa từ; chưa rõ hành vi trên SSD. Bài học cho SWE - Cách lạc quan (chạy hết, xung đột thì làm lại) thường thắng cách bảo thủ (chỉ chạy cái được chứng…
- Real-Time Indexing for Billions of Vectors: How we built fast, fresh vector indexing at scale in CockroachDB Bài tóm tắt · Cockroach Labs · 2025
…ải pháp giả định cả tập dữ liệu nằm trong RAM một máy (hoặc SSD cục bộ), không đa region, đòi ghi theo lô, trả kết quả cũ hoặc phải dựng lại định kỳ. DB phân tán giao dịch thì cần…
- Ideal isn't real: Stress testing CockroachDB's resilience Bài tóm tắt · Cockroach Labs · 2025
…CPU/IO trước khi tài nguyên quá tải. - Disk stall: trên EBS/SSD/PD có thể 20–30 lần mỗi giờ trong một cụm (theo bài); ghi WAL bị chặn gây timeout và "grey failure". Mỗi node có nhi…
- How Discord Stores Trillions of Messages Bài tóm tắt · Discord · 2023
…gration: - Cụm Scylla mới dùng topology "super-disk": Local SSD + RAID mirror sang persistent disk. - Kế hoạch đầu: ghi kép, cắt theo mốc thời gian, chép dữ liệu lịch sử bằng Spark…
- How we optimized Magic Pocket for cold storage Bài tóm tắt · Dropbox · 2019
Magic Pocket () lưu block bất biến tối đa 4 MB trên đĩa quay (SMR từ 2018, ); trong một region thì mới upload là replication n-way, sau đó erasure coding nền.
- After four years of SMR storage, here's what we love and what comes next Bài tóm tắt · Dropbox · 2023
Theo Dropbox, năm 2018 họ là công ty công nghệ lớn đầu tiên dùng ổ SMR mật độ cao.
- Prefetch Caching of Items at eBay Bài tóm tắt · eBay · 2020
Phần lớn traffic vào trang item đến từ trang kết quả tìm kiếm. Những năm trước eBay đã prefetch ảnh item sau khi trang tìm kiếm tải xong. Lần này họ muốn phục vụ cả trang item từ cache khi user bấm vào từ kết quả tìm…
- Deployment of etcd on AWS EC2 Bài tóm tắt · etcd · 2017
…mất ổn định ; Provisioned IOPS ổn định hơn general purpose SSD. - Bước tiếp: etcd-operator trên Kubernetes (backup định kỳ lên S3, thay node hỏng, khôi phục từ backup khi mất quor…
- How to shuffle a big dataset Bài tóm tắt · Jane Street · 2018
…nh hai lượt khoảng một ngày, nhanh khoảng 1.000 lần . Kể cả SSD cục bộ không nén, tuần tự vẫn nhanh 48 lần. Vì sao - Chi phí bị chi phối bởi kiểu truy cập (tuần tự hay ngẫu nhiên)…
- Fixing Linux filesystem performance regressions Bài tóm tắt · LinkedIn · 2020
…à 5.4 và chỉ trên máy có đĩa gốc HDD (RAID1 phần mềm) , máy SSD không bị. - Thử patch upstream cho blk-mq thì đỡ một phần; đổi I/O scheduler không ảnh hưởng. Nghi ext4 (đã biết hồi…
- Faster Python 3.14: faster compression and fixing 28-year-old bugs Bài tóm tắt · Man Group · 2026
…chỉ vài MB/s tới dưới 100 MB/s ngay ở level 1, chậm hơn cả SSD và mạng DC. Thay đổi chính - Python 3.14 chuyển sang zlib-ng (một fork thay thế trực tiếp zlib; Fedora 40 đã chuyển…
- How Facebook deals with PCIe faults to keep our data centers running reliably Bài tóm tắt · Meta · 2021
…linh kiện PCIe (ASIC tăng tốc video và inference, GPU, NIC, SSD), nhiều nhà cung cấp, nhiều bản firmware, chạy các ứng dụng có mức chịu lỗi khác nhau. Lỗi có thể từ phần cứng, firm…
- Active-Active for Multi-Regional Resiliency Bài tóm tắt · Netflix · 2013
Theo Netflix, tỉ lệ hỏng phụ thuộc hai thứ: quy mô deploy và tốc độ thay đổi; chạy lớn mà vẫn đổi nhanh thì "lúc nào cũng có thứ hỏng". Mục tiêu nội bộ là 99,99%. Mất trọn một region rất hiếm, nhưng chính tốc độ thay…
- Lessons from Building Observability Tools at Netflix Bài tóm tắt · Netflix · 2018
Netflix có 125 triệu thành viên, xem trên hơn 1.000 loại thiết bị (2018). Đội làm công cụ observability (log, trace, metric) cho cả thiết bị lẫn server, để người dùng vào một công cụ thay vì nhiều công cụ theo loại dữ…
- Scaling Time Series Data Storage — Part I Bài tóm tắt · Netflix · 2018
Lịch sử xem (viewing history) dùng cho bookmark và gợi ý; hội viên xem hơn 140 triệu giờ/ngày, hơn 100 triệu hội viên (2018). Dữ liệu tăng theo ba chiều: thời gian, số hội viên, số giờ xem mỗi người.