Thiết bị IO và độ trễ
(planetscale.com)- Thiết bị lưu trữ bất biến đã phát triển từ băng từ sang HDD, SSD và lưu trữ mạng trên đám mây, nhưng vị trí và cách bố trí dữ liệu vẫn chi phối độ trễ IO
- Lưu trữ băng từ mạnh ở đọc/ghi tuần tự, nhưng khi đọc dữ liệu ở xa có thể mất tới hàng chục giây, nên không phù hợp với cơ sở dữ liệu giao dịch có lưu lượng cao
- HDD đã giảm đáng kể độ trễ so với băng từ, nhưng do đĩa quay và chuyển động của đầu đọc/ghi, đọc ngẫu nhiên thường ở mức 1~3ms, và hiệu năng khác biệt lớn tùy theo thứ tự yêu cầu
- SSD hoạt động bằng NAND flash, không có bộ phận cơ khí, nên đọc ngẫu nhiên có thể nhanh tới 16μs; tuy vậy, cách bố trí dữ liệu vẫn luôn quan trọng vì việc tận dụng tính song song và garbage collection
- Việc tách storage và compute trên đám mây giúp mở rộng và ứng phó sự cố dễ hơn, nhưng thêm độ trễ khứ hồi mạng và giới hạn IOPS; PlanetScale Metal cố gắng giảm chi phí này bằng NVMe SSD kết nối trực tiếp và cơ chế sao chép
Các yếu tố cơ bản chi phối độ trễ lưu trữ
- Thiết bị lưu trữ bất biến giữ dữ liệu ngay cả khi tắt nguồn, là nền tảng để lưu dữ liệu như ảnh, email, số dư ngân hàng và hồ sơ y tế
- Thiết bị lưu trữ khả biến như thanh ghi CPU, cache CPU và RAM nhanh hơn nhưng cần nguồn điện liên tục
- Hiệu năng lưu trữ không chỉ là vấn đề dung lượng, mà còn phụ thuộc vào cách tiếp cận dữ liệu, đơn vị đọc/ghi, xếp hàng, tính song song và việc có phải đi vòng qua mạng hay không
- Khi ra mắt PlanetScale Metal, PlanetScale cho biết Metal chạy cơ sở dữ liệu đám mây trên ổ NVMe cục bộ thay vì lưu trữ kết nối qua mạng
Lưu trữ băng từ: mạnh với truy cập tuần tự, yếu với truy cập ngẫu nhiên
- Từ thập niên 1950, máy tính đã dùng ổ băng từ làm thiết bị lưu trữ số bất biến
- Hộp băng gồm nhiều track và nhiều cell; trạng thái phân cực từ của mỗi cell biểu diễn dữ liệu nhị phân
- Khi đưa hộp băng vào đầu đọc và cuộn bằng motor, IO head sẽ đọc dữ liệu đi ngang qua nó
- Nếu vị trí đọc/ghi gần đầu đọc thì nhanh, nhưng nếu ở xa thì độ trễ tăng
- Ngay cả trong các hệ thống băng từ hiện đại, để đọc dữ liệu ở xa có thể phải cuộn hàng trăm mét băng
- Trong những trường hợp như vậy, việc đọc có thể mất hàng chục giây
- Dù số lần đọc/ghi như nhau, nếu dữ liệu nằm rải rác thì sẽ mất lâu hơn nhiều so với bố trí tuần tự
- Ví dụ trong bài cho thấy trường hợp các thao tác đọc/ghi rải rác mất lâu hơn khoảng 7 lần với cùng khối lượng công việc
- Băng từ có độ trễ đọc/ghi ngẫu nhiên kém, nhưng vẫn phù hợp với các lượt đọc/ghi tuần tự dài
- Chi phí trên mỗi GB thấp hơn SSD và HDD, đồng thời tuổi thọ lưu trữ dài
- CERN quản lý hơn 400PB dữ liệu trong kho dữ liệu lưu trữ băng từ
- AWS cũng cung cấp dịch vụ lưu trữ băng từ
- Băng từ không phù hợp với cơ sở dữ liệu giao dịch có lưu lượng cao
HDD: sự đánh đổi giữa đĩa quay và xếp hàng lệnh
- HDD lưu dữ liệu trên platter, tức các đĩa kim loại hình tròn, thay vì băng từ
- Platter quay nhanh bên trong vỏ ổ; ví dụ đưa ra 7200 RPM là tốc độ phổ biến
- Track của HDD có dạng tròn, và một đĩa có thể có hơn 100.000 track
- Mỗi track chứa hàng trăm nghìn page, mỗi page chứa khoảng 4KB dữ liệu
- HDD căn chỉnh vị trí đọc/ghi bằng cách di chuyển đầu đọc/ghi và quay platter
- Khác với băng từ, các bit trên toàn bộ bề mặt luôn có thể truy cập được
- Không cần cuộn băng cho đến khi dữ liệu mong muốn lộ ra
- Một lượt đọc ngẫu nhiên điển hình có thể thực hiện trong 1~3ms
- Thứ tự yêu cầu ảnh hưởng lớn đến hiệu năng
- Các lượt đọc/ghi có tính tuần tự cao sẽ hoàn tất nhanh
- Ngay cả với cùng 6 lượt đọc/ghi, nếu thứ tự bị xáo trộn, thời gian chờ platter quay đến đúng vị trí sẽ tăng lên
- Đĩa từ đã hỗ trợ xếp hàng lệnh từ lâu
- SCSI cung cấp các tính năng liên quan từ thập niên 1980, SATA từ thập niên 2000
- OS có thể gửi nhiều lệnh để chúng được thực thi song song hoặc khác thứ tự
- Bộ điều khiển đĩa có thể dùng hàng đợi công việc để lập lịch đọc/ghi phù hợp với cấu trúc của đĩa
- HDD đã cải thiện so với băng từ, nhưng đôi khi vẫn chậm, đặc biệt với đọc/ghi ngẫu nhiên
SSD: các biến số hiệu năng vẫn còn dù bộ phận cơ khí biến mất
- SSD hay lưu trữ flash được phát minh vào thập niên 1980, nhưng chỉ trở thành thiết bị lưu trữ tiêu dùng chủ đạo vào thập niên 2000
- SSD không phụ thuộc vào bộ phận cơ khí để đọc dữ liệu
- Nó dùng các transistor bất biến gọi là NAND flash
- Các giá trị 1 và 0 được đọc, ghi và xóa bằng tín hiệu điện, không cần di chuyển bộ phận vật lý
- SSD gồm một hoặc nhiều target; mỗi target chứa nhiều block, và block chứa nhiều page
- SSD đọc và ghi theo đơn vị page
- Ngay cả khi chỉ cần một phần dữ liệu, đơn vị yêu cầu của ổ vẫn là page
- Trong cấu hình ví dụ, nếu page là 4096 bit, block là 16K page, target là 16K block và thiết bị có 8 target, tổng cộng là
4k * 16k * 16k * 8 = 8,796,093,022,208bit, tức 8TB - Đọc ngẫu nhiên trên SSD tùy theo model, nhưng có thể nhanh tới 16μs
- Dù không có bộ phận cơ khí, cách bố trí dữ liệu vẫn quan trọng
- Các yếu tố hiệu năng của SSD gồm tính song song và garbage collection
Tính song song của SSD: phân tán target làm thay đổi thông lượng
- Thông thường, mỗi target có một line riêng kết nối với bộ điều khiển
- Mỗi line xử lý đọc/ghi nhưng mỗi lần chỉ có thể truyền một page
- Việc truyền page rất nhanh, nhưng vẫn mất một khoảng thời gian nhỏ
- Nếu 8 lượt write được phân tán trên 4 target, có thể dùng 4 line song song và ghi trong hai lát thời gian
- Nếu cả 8 lượt write đều dồn vào cùng một target, chỉ một line được dùng và các line còn lại sẽ nhàn rỗi
- Thứ tự đọc/ghi và cách bố trí dữ liệu ảnh hưởng đến hiệu năng ngay cả trên SSD
- Khi thiết kế phần mềm như MySQL, cần chú ý dữ liệu được lưu trong cấu trúc nào và được bố trí trên đĩa ra sao
Garbage collection của SSD: chi phí xóa trước khi ghi
- Page SSD có thể được đọc nhiều lần, nhưng một page đã ghi không thể bị ghi đè bằng dữ liệu mới cho đến khi dữ liệu cũ được xóa rõ ràng
- Không thể xóa từng page riêng lẻ; phải xóa toàn bộ block
- SSD cần các thuật toán nội bộ để quản lý page empty, in-use và dirty
- dirty page là page đã được ghi nhưng dữ liệu không còn cần thiết và sẵn sàng để xóa
- Có những trường hợp phải tái bố trí dữ liệu để nhận write mới; thuật toán quản lý việc này là garbage collector
- Nếu có đủ page unused, dữ liệu mới có thể được ghi ngay
- Nếu thiếu page unused và có nhiều dirty page, phải chạy garbage collection trước
- Trong ví dụ, để ghi 5 page mới, 2 page non-dirty được chuyển sang vị trí khác
- Sau đó, toàn bộ page trong target đó được đưa về trạng thái dirty để có thể xóa
- Các bước bổ sung này làm hiệu năng write chậm đi đáng kể
- Trên SSD bận rộn với nhiều thao tác đọc, ghi và xóa, garbage collection có thể làm các công việc khác chậm lại
Thay đổi do đám mây mang lại: tách storage và compute
- Sự chuyển đổi từ băng từ sang HDD rồi SSD đã nâng cao đáng kể hiệu năng IO bền vững
- Việc chuyển sang đám mây tạo ra một thay đổi khác đối với hiệu năng IO
- AWS được nêu như một dịch vụ đã thúc đẩy mạnh mẽ quá trình chuyển dịch lên đám mây kể từ khi ra mắt năm 2006
- Trong môi trường đám mây, người dùng thuê server ảo hóa chạy trên phần cứng bất kỳ trong các trung tâm dữ liệu lớn
- Server có thể bị tắt bất cứ lúc nào vì nhiều lý do như lỗi phần cứng, thay thế phần cứng hoặc mất kết nối mạng
- Khi xây dựng hệ thống trên hạ tầng đám mây thuê, hệ thống phải chịu được lỗi xảy ra thường xuyên hơn
- Những điều kiện này cùng nhu cầu về volume lưu trữ có thể mở rộng linh hoạt đã dẫn tới việc tách storage và compute
Ưu điểm và chi phí của lưu trữ kết nối qua mạng
- Theo truyền thống, server, desktop, laptop và điện thoại kết nối trực tiếp với thiết bị lưu trữ bất biến
- Có thể dùng cáp SATA, giao diện PCIe hoặc dạng tích hợp trong cùng SoC
- Lưu trữ kết nối trực tiếp rất nhanh nhưng có hai hạn chế
- Nếu server ngừng hoạt động, dữ liệu cũng không thể sử dụng được
- Kích thước lưu trữ là cố định
- Server ứng dụng thường phù hợp với môi trường tạm thời (ephemeral), và nhiều công việc diễn ra trong bộ nhớ nên vấn đề này không quá lớn
- Cơ sở dữ liệu không được mất dữ liệu khi server ngừng hoạt động, và kích thước dữ liệu có thể tăng nhanh đến mức chạm giới hạn lưu trữ
- Nhiều nhà cung cấp đám mây cho phép gắn lưu trữ kết nối qua mạng có thể cấu hình riêng vào instance compute
- Cấu hình mặc định của EC2 thường là gắn volume lưu trữ mạng EBS
- Các dịch vụ cơ sở dữ liệu như Amazon RDS, Amazon Aurora, Google Cloud SQL và PlanetScale cũng dựa vào hệ thống trong đó compute và storage được tách qua mạng
- Cách này cho phép điều chỉnh động volume lưu trữ theo mức tăng giảm dữ liệu
- Ngay cả khi server ngừng hoạt động, dữ liệu vẫn an toàn và có thể gắn lại vào server khác
- Đổi lại, nó tạo ra chi phí hiệu năng là độ trễ khứ hồi mạng và giới hạn IOPS
Chênh lệch độ trễ giữa NVMe cục bộ và lưu trữ mạng
- NVMe SSD kết nối trực tiếp là SSD dùng đặc tả giao diện bộ điều khiển host cho bộ nhớ bất biến, cung cấp tốc độ IO và băng thông cao
- Một vòng khứ hồi từ CPU đến RAM được nêu là khoảng 100ns
- Một vòng khứ hồi từ CPU đến NVMe SSD kết nối cục bộ là khoảng 50.000ns, tức 50μs
- Volume lưu trữ kết nối qua mạng cần một vòng khứ hồi mạng ngắn trong trung tâm dữ liệu
- Lưu trữ kết nối qua mạng như EBS được nêu là có thời gian khứ hồi khoảng 250.000ns, tức 250μs hoặc 0,25ms
- Ngay cả khi dùng cùng SSD hiện đại, kết nối qua mạng khiến thời gian xử lý từng yêu cầu đọc/ghi riêng lẻ dài hơn ở mức một chữ số lần
- Với IO tuần tự khối lượng lớn, có thể giảm tác động tiêu cực nhưng không thể loại bỏ hoàn toàn
- Lưu trữ kết nối qua mạng tạo ra độ trễ bổ sung mỗi lần truy cập hệ thống lưu trữ
Giới hạn IOPS và khác biệt của lưu trữ kết nối trực tiếp
- Nhiều nhà cung cấp đám mây, bao gồm AWS và Google Cloud, giới hạn số thao tác IO có thể gửi qua wire trong mô hình lưu trữ kết nối qua mạng
- Instance GP3 EBS của Amazon mặc định cho phép 3000 IOPS mỗi giây
- Có thể đặt cao hơn nhưng sẽ tốn thêm chi phí
- Các volume GP2 EBS trước đây hoạt động bằng cách tích lũy IOPS pool để thỉnh thoảng cho phép burst
- Nếu kết nối lưu trữ trực tiếp với instance compute, sẽ không có giới hạn thao tác IO nhân tạo
- Với kết nối trực tiếp, có thể đọc và ghi nhiều đến mức phần cứng cho phép
Cách duy trì độ bền và khả năng mở rộng
- Vấn đề thứ nhất của SSD kết nối trực tiếp là độ bền dữ liệu, có thể giải quyết bằng sao chép
- Cách phổ biến là đặt một server làm primary để nhận mọi yêu cầu write, và có từ 2 server bổ sung trở lên nhận bản sao dữ liệu
- Khi dữ liệu nằm ở ba nơi, khả năng mất dữ liệu giảm đi
- Với số liệu ví dụ, giả sử xác suất lỗi server hằng tháng là 1%:
- Trên một server đơn, xác suất mất dữ liệu mỗi tháng là 1%
- Trên ba server, con số giảm xuống
1% × 1% × 1% = 0.0001%, tức 1 phần triệu
- PlanetScale tự động phát hiện và thay thế node lỗi, đồng thời sao lưu dữ liệu cơ sở dữ liệu thường xuyên và ổn định
- Vấn đề thứ hai là khả năng mở rộng ổ đĩa, cần nhiều can thiệp thủ công hơn
- Cần giám sát và cảnh báo khi ổ đĩa gần chạm giới hạn dung lượng
- Cần công cụ để dễ dàng tăng dung lượng khi cần
Cách tiếp cận của PlanetScale Metal
- Metal cung cấp cụm cơ sở dữ liệu dùng NVMe SSD kết nối trực tiếp
- Mỗi instance cơ sở dữ liệu chạy trên direct-attached NVMe SSD
- Cụm Metal mặc định gồm 1 primary và 2 replica
- Các cụm cơ sở dữ liệu được hỗ trợ là Vitess hoặc Postgres
- Khi chạm giới hạn lưu trữ, có thể đổi kích thước sang server có ổ lớn hơn chỉ với vài cú nhấp chuột
- Về nội bộ, hệ thống khởi chạy node mới và di chuyển dữ liệu từ instance hiện tại sang instance mới; quá trình này được xử lý với zero downtime
- Cơ sở dữ liệu Metal không có IOPS cap nhân tạo
- Người dùng có thể thực hiện thao tác IO với độ trễ thấp và sử dụng tối đa khả năng phần cứng cho phép, không phải trả chi phí cho các lớp IOPS đắt đỏ của nhà cung cấp đám mây hay bị throttle
1 bình luận
Ý kiến trên Hacker News
Tôi là tác giả blog. Quá trình viết bài này thật sự rất thú vị, và đây chắc chắn là bài phức tạp nhất trong số những bài tôi từng làm
Để tạo các hình ảnh trực quan tương tác, tôi đã viết đúng nghĩa là hàng nghìn dòng JavaScript, hy vọng mọi người thấy vui khi xem
Tuy nhiên, cách diễn đạt “1 phần triệu” về độ bền có vẻ quá bi quan nếu xét đến thời gian sự cố ngắn trước khi máy chủ mới được đưa vào và sao chép lại
Ví dụ nếu khôi phục mất 10 phút, ngay cả khi ba máy chủ chắc chắn hỏng mỗi tháng một lần, xác suất chúng hỏng chồng lên nhau cùng lúc có lẽ đã vào khoảng 1 phần 2 triệu; còn nếu xác suất hỏng trong một tháng là 1% thì khả năng ba sự cố chồng lên nhau là cực kỳ thấp
Nếu có 1 triệu khách hàng thì 1 phần triệu không phải con số tốt lắm, nên tôi bổ sung vậy
Tôi biết thời gian gõ bàn phím và thời gian suy nghĩ trong đầu có thể khá khác nhau
Chủ đề này thì tôi rất quen nên không có gì để bổ sung về nội dung, lướt qua cũng thấy ổn. Chỉ là tôi đang lên ý tưởng làm hoạt ảnh cho blog của mình, mà vài thư viện gần đây tôi thử đều không ưng ý
Tôi đã ủng hộ tổ hợp SQLite+NVMe một thời gian. Cá nhân tôi thấy đây là một mẫu mới cho phép đi xa hơn bình thường rất nhiều, và trong một số trường hợp có thể trụ đến cùng mà không cần mở rộng ngang
Trong hiệu năng, độ trễ là vua, đặc biệt khi phải xử lý các mục theo tuần tự. Chạy SQLite trên NVMe mang lại lợi thế độ trễ mà các nhà cung cấp khác không thể đem lại
Với hầu hết các ca sử dụng thực tế, tôi cũng không nghĩ chạy trong bộ nhớ tốt hơn đáng kể so với lưu trữ bền vững trên NVMe
Trên một host đơn lẻ có thể nhanh hơn một chút, nhưng ngay khi web server từ 1 máy thành 2 máy và cả hai đều cần ghi vào cơ sở dữ liệu, có vẻ như bạn đang tự làm khó mình
Nói rằng độ trễ quan trọng cũng dễ gây hiểu nhầm. Nếu không có tính nhất quán thì hiệu năng không còn ý nghĩa, và ngay khi có nhiều web server, bạn phải tự giải quyết tính nhất quán đó
Hơn nữa, độ trễ cơ sở dữ liệu thường nhỏ hơn nhiều so với độ trễ khứ hồi qua Internet, và ngay cả độ trễ Internet đó cũng nhỏ so với “độ trễ” khi chờ tải các tài nguyên trang như hình ảnh hay thư viện mã
Ngay từ đầu nên tránh tối đa các truy vấn cơ sở dữ liệu tuần tự; nếu có thể thì dùng join, còn nếu không thể thì cũng nên gửi các truy vấn đồng thời theo kiểu bất đồng bộ nhiều nhất có thể để chúng chạy song song
Để tránh vấn đề ghi song song, ngoài việc thiết lập một chế độ vận hành thô nhất định, có thể dùng mẹo trong ứng dụng là một luồng đơn chuyên ghi
Khi đó mã song song vốn đã phức tạp thường sẽ phức tạp thêm một chút. Nếu chỉ có một luồng ghi, SQLite hoạt động thật sự rất tuyệt
fsync()một tệp trên hệ thống tệp ext4 ở máy tính desktop, ngay cả với đĩa NVMe vẫn đo được độ trễ 1–2msTrên hệ thống mới hơn thì khoảng 800µs
Lượng thông tin hay đến mức tôi đọc mà hoàn toàn quên mất đây là quảng bá sản phẩm. Phần trực quan hóa và tương tác rất tuyệt
Nhìn hoạt ảnh I/O đĩa làm tôi nhớ đến Melvin Kaye
Ngay cả khi chiếc Flexowriter chậm cần độ trễ giữa các ký tự xuất ra, Mel cũng không dùng vòng lặp trì hoãn thời gian
Thay vào đó, ông điều chỉnh vị trí lệnh trên trống sao cho mỗi khi cần lệnh tiếp theo, đầu đọc vừa đi qua nó; thế là trống phải quay thêm một vòng để tìm lệnh tiếp theo
https://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/The...
Metal trông thật sự rất hấp dẫn, nhưng khi ở công ty trước tôi dùng instance local SSD của GCP thì gặp các vấn đề độ tin cậy nghiêm trọng, chẳng hạn block thiết bị bị mất dữ liệu
Tôi tò mò không biết hiện giờ tình hình đã thay đổi chưa, và họ dùng loại máy nào
Cách обход khi đó là đây: https://discord.com/blog/how-discord-supercharges-network-di...
Tuy vậy, chúng tôi vận hành một hệ thống dự phòng bằng sao chép bán đồng bộ MySQL, để mọi thao tác ghi được lưu bền vững trên hai máy ở hai vùng khả dụng khác nhau trước khi xác nhận với client
Kubernetes operator và tiến trình
vtorccủa Vitess phối hợp với nhau để chủ động phát hiện và thay thế cả những replica đã hỏng hoặc đáng ngờTrên GCP, chúng tôi thấy kết quả tốt nhất với máy n2d-highmem; trên AWS thì gần như dùng rộng rãi các loại thế hệ mới nhất có instance storage
Bài viết hay. Nhìn chung còn có vấn đề là lưu trữ đám mây đặc biệt chậm
Chuyện này đã được nói đến ở nơi khác, nhưng bài này tóm tắt vấn đề rất tốt: http://databasearchitects.blogspot.com/2024/02/ssds-have-bec...
Gần đây https://github.com/feldera/feldera đã bổ sung hỗ trợ lưu chỉ mục gia tăng trên S3/lưu trữ đối tượng, còn NVMe thì đã được hỗ trợ từ lâu hơn vì lợi thế hiệu năng rõ ràng như bài trước đã nói
Mong là có ai đó khuấy động mảng này bằng một cách cung cấp tốt hơn
Có một phần về lưu trữ phân tán trong bài này chưa được đánh giá đầy đủ
Thứ nhất, một số hệ thống không cung cấp sẵn replication. Cụm Cassandra hoặc MySQL có thể dùng replication master-slave, nhưng nhiều hệ thống thì không
Thứ hai, nếu dùng lưu trữ NVMe trên đám mây, bạn phải để ý các khoảng bảo trì và việc drain do nhà cung cấp đám mây khởi xướng, khiến vận hành khó hơn nhiều
Nếu không tích hợp với những hệ thống đó để chuyển dữ liệu sang node khác, dữ liệu sẽ biến mất
Khi tách lưu trữ và compute, nhà vận hành đám mây có thể làm trống và di chuyển phần compute khi cần; dữ liệu độc lập với compute, và nhà vận hành đám mây cũng quản lý hệ thống dữ liệu đó cùng quá trình drain, nên có thể điều chỉnh vị trí đặt workload mà không cần khách hàng can thiệp
Lưu trữ kết nối mạng có replication nhưng trông như API hệ thống tệp “cục bộ” là một cách mạnh mẽ để đem lại độ bền cho các hệ thống không có replication tích hợp như của chúng tôi
Thực sự rất tuyệt, và PlanetScale Metal trông cũng khá vững. Tôi đặc biệt thích thấy độ trễ giảm mạnh trong bản phát hành: https://planetscale.com/blog/upgrading-query-insights-to-met...
Suốt nhiều năm tôi không hiểu vì sao các cơ sở dữ liệu có replication cứ luôn bám lấy EBS và chấp nhận độ trễ đó. Đã có replication rồi thì sao không mạnh dạn dùng đĩa cục bộ?
Ở tổ chức trước, khi vận hành Elasticsearch làm kho lưu log/metric tạm thời, yêu cầu về độ tin cậy cũng không cao, nên tôi đã đề xuất làm vậy nhưng không thuyết phục được, và cuối cùng lại dùng AWS Elasticsearch tệ hơn
Tôi biết dung lượng đĩa cục bộ là hữu hạn, nhưng tỷ lệ core/bộ nhớ/đĩa có lẽ đủ cho hầu hết use case. Cũng có nhiều instance đĩa cục bộ với các tỷ lệ khác nhau, nên có thể tìm được điểm cân bằng phù hợp
Cũng có thể triển khai lưu trữ hot/cold bằng instance ổ cứng cục bộ trên 20TB
Rất muốn khen ngợi đội PlanetScale vì cuối cùng họ đang làm điều hợp lý. Ngay cả AWS cũng không chạy Elasticsearch trên đĩa cục bộ; cứ thử nghĩ đến việc chạy mọi thứ như ClickHouse hay Cassandra trên đĩa cục bộ là thấy
Vấn đề cốt lõi là sau sự kiện stop-start, đĩa sẽ bị xóa. Ngay cả khi phần còn lại của cluster vẫn ổn và còn replica khả dụng, SQL Server cũng không tự xử lý được việc này
Vì nó không tự động khôi phục node đã bị khởi tạo lại, nên việc viết script và kiểm thử để vòng qua vấn đề này là thứ khó có thể chịu được trong production, trừ những tổ chức táo bạo và đủ năng lực nhất
Chúng tôi vận hành hàng trăm cụm ClickHouse theo mô hình này. Việc đổi kích thước để giải quyết vấn đề hiệu năng phổ biến hơn nhiều so với vì sự cố
Ví dụ, nếu một tenant gặp vấn đề hiệu năng vào sáng Chủ nhật theo giờ Mỹ, cách đơn giản nhất là nâng lên VM lớn hơn trong cuối tuần và để nhóm nòng cốt xem nguyên nhân gốc vào sáng thứ Hai
Chi phí tăng thêm nhỏ, và có thể tránh được tình trạng burnout của nhân viên vốn đắt đỏ hơn nhiều
Bài viết thực sự xuất sắc, và phần trực quan hóa ghi ngẫu nhiên được làm rất tốt
Tôi có vài câu hỏi có thể hơi ngớ ngẩn về giới hạn IOPS của lưu trữ kết nối mạng
Thứ nhất, tôi thắc mắc liệu giới hạn “IOPS” có đúng là giới hạn tốc độ cho một loại lưu lượng mạng cụ thể, tức lưu lượng đi và đến volume EBS hay không. Nói cách khác, tôi muốn hỏi liệu “IOPS” có nghĩa là “lưu lượng mạng của volume EBS” không
Thứ hai, tôi cũng tò mò liệu cách này có tiết kiệm chi phí không. Nếu có, đó là do chênh lệch giá kỳ lạ của AWS, hay do hiệu quả tăng lên vì làm ít networking EBS hơn?
Việc đặt storage và compute trên cùng một máy rõ ràng có lợi thế cấu trúc về độ trễ vì bớt một hop, nhưng tôi muốn biết liệu nó có lợi cả về throughput trên mỗi đô la hay không
Tôi thường nhìn nó theo một mô hình khác. Volume EBS không phải là một phần bo mạch vật lý gắn vào bus PCIe, mà giống một phần trong hệ thống phân tán quy mô lớn gồm rất nhiều ổ đĩa vật lý, gần với SAN có dung lượng mạng chuyên dụng đi và đến compute
Có thể tiết kiệm chi phí, nhưng rốt cuộc đó là một tập hợp các đánh đổi