Tìm kiếm
40 kết quả cho “Tối ưu”. Tìm không phân biệt dấu.
- Hạ tầng nghiên cứu định lượng (dữ liệu thị trường, feature, backtest) Chủ đề Thành viên
Một quỹ định lượng hay công ty market making sống bằng vòng nghiên cứu: đặt giả thuyết → lấy dữ liệu → tạo feature → train model hay dựng tín hiệu → backtest/mô phỏng → đưa vào giao dịch thật → lặp lại. Theo Optiver, độ…
- A Brief History of the UUID (KSUID) Bài tóm tắt · Segment · 2017
…m một thư viện UUID PHP va chạm nhiều. Với 122 bit, phải có tới ~2^46 UUID thì xác suất va chạm mới ở mức 1/50 tỷ. - ID có thời gian: - Cassandra TimeUUID: lộ host, có vấn đề khi l…
- Goodbye to sequential integers, hello UUIDv7 Bài tóm tắt · Buildkite · 2023
…giữ UUID "v4 có thời gian" tự chế. Chọn v7 vì là chuẩn sắp tới, ít tự chế. Chưa cần nhét số shard vào ID; nếu cần sau này có thể dùng UUIDv8. Vì sao - Theo Buildkite: ID có tiền t…
- How we stopped xmin horizon blocking Postgres vacuuming Bài tóm tắt · Trigger.dev · 2024
…ai bên. Bài học cho SWE - Dùng Postgres làm queue được, cho tới khi vacuum không theo kịp: bảng có tỷ lệ xoá cao biến dead tuple thành nút cổ chai. Cùng họ vấn đề vacuum với Notion…
- How we optimized infrastructure spend at GitLab Bài tóm tắt · GitLab · 2020
…sau đó ra chuẩn hạ tầng về tạo project và đặt tên label. 3. Tối ưu theo câu hỏi cụ thể (cùng chuyên gia từng mảng): - CI runner: báo cáo chi phí theo repo, pipeline, job để tối ưu…
- Handling Growth with Postgres: 5 Tips From Instagram Bài tóm tắt · Instagram · 2013
…p scale tiếp mà không phải đổi công nghệ. Bài học cho SWE - Tối ưu trong DB đang dùng trước khi đổi DB. Hơn 100 lần tải với cùng Postgres. - Index nhỏ hơn thì working set vừa RAM h…
- Apache Spark Resource Optimization: Lessons From Eight Million Jobs a Day Bài tóm tắt · Salesforce · 2026
…chạy khoảng 8 triệu lần Spark mỗi ngày (2026), từ job ngắn tới job xử lý TB trong nhiều giờ. Hoá đơn compute tăng trong khi job vẫn thành công. Theo bài: thành công chỉ chứng minh…
- Working with PostgreSQL Bài tóm tắt · Zerodha · 2021
…cặp master-replica (32 core, 64 GB RAM) chứa hàng tỷ dòng, tới khi dữ liệu tăng vọt; chuyển sang nhiều shard đầu năm 2020. Thay đổi chính - Schema: denormalize hầu hết dữ liệu và…
- 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…
- 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…
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- Edge Authentication and Token-Agnostic Identity Propagation Bài tóm tắt · Netflix · 2021
…hiết bị là ai. - Luồng đăng nhập cũ: Zuul chuyển credential tới API /login ; API gọi backend xác thực rồi tạo cookie sâu trong stack và đẩy ngược lên. Hệ quả: token hợp lệ từ bên n…
- Rethinking Netflix's Edge Load Balancing Bài tóm tắt · Netflix · 2018
…ững lại vì cập nhật property/dữ liệu hoặc GC lớn, phần cứng tồi hoặc hàng xóm ồn. Thay đổi chính - Nguyên tắc: làm trong khung load balancer có sẵn để đội khác dùng lại (tuỳ biến c…
- Beyond synthetic testing: Capturing and replaying real database workloads at Airbnb Bài tóm tắt · Airbnb · 2026
…sk (mỗi task một file), đẩy vào message queue; worker scale tới hàng nghìn instance. Mọi task trong batch có cùng "expected start time" để worker bắt đầu đồng loạt, giữ được độ đồn…
- Anatomy of a (Postgres) search engine Bài tóm tắt · PlanetScale · 2026
…ích thước index khoảng 20% corpus nếu không có vị trí/điểm, tới khoảng 300% cho index tìm code. - Tokenizer, stemming, stop word: stop word làm index nhỏ hơn nhưng mất độ chính xác…
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một mặt…
- PostgreSQL Stories: A simple query with a big problem Bài tóm tắt · Render · 2024
…dần vì phải quét dòng cũ. - Chặn vacuum quá lâu có thể dẫn tới transaction ID wraparound : Postgres tự tắt để tránh mất dữ liệu, phải can thiệp tay. Bài học cho SWE - Tuổi transac…
- Active-Active for Multi-Regional Resiliency Bài tóm tắt · Netflix · 2013
…region), chế độ "failover" cho một region, và trần traffic tối đa : vượt trần thì trả lỗi ngay, để bảo vệ tầng dưới khi service đang scale lên hoặc cache region còn nguội (thunder…
- 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".
- Đổi ngôn ngữ và runtime Chủ đề Thành viên
Ngôn ngữ ban đầu được chọn để làm nhanh. Khi lớn lên, nó có thể thành nút thắt về hiệu năng, latency, hoặc tổ chức code. Có ba hướng: tối ưu runtime đang dùng, cải tiến dần, hoặc viết lại có phạm vi.
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), gọi đồng bộ từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- Realtime và fan-out Chủ đề Thành viên
Một sự kiện (tin nhắn, ảnh, tweet, vote) phải tới rất nhiều người, rất nhanh, qua rất nhiều kết nối mở cùng lúc.
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- Xử lý sự cố và on-call Chủ đề Thành viên
Khi hệ còn nhỏ, vài người biết hết mọi thứ; có lỗi thì người thấy đầu tiên sửa luôn. Khi có hàng trăm service và hàng trăm engineer, câu hỏi đổi khác:
- 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…
- Sự cố và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một sự cố: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này gom…
- CI và build ở quy mô lớn Chủ đề Thành viên
Lúc nhỏ, CI là "mỗi commit chạy hết build và test". Khi codebase và số commit tăng, chạy hết trở thành bất khả (Stripe 2026: chạy tuần tự mất bốn tháng), và thời gian chờ của một thay đổi không còn chỉ là thời gian…
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- Kiến trúc frontend Chủ đề Thành viên
Frontend bắt đầu là vài trang render ở server; lớn lên thành ứng dụng có trạng thái, nhiều team cùng sửa, và mỗi tính năng thêm vào là thêm byte phải tải. Ba trục lặp lại trong các nguồn: render ở đâu (server, client,…
- Độ 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.
- Mã hoá đầu cuối và hệ thống mà server không được đọc Chủ đề Thành viên
Một hệ thống bình thường giả định server thấy hết dữ liệu: server fan-out tin nhắn, lưu bản sao lưu, đồng bộ thiết bị, thu log để vận hành, chạy model, chống lạm dụng. Khi sản phẩm hứa chính nhà vận hành cũng không đọc…
- Sharding và tách database Chủ đề Thành viên
Một database quan hệ duy nhất là điểm khởi đầu của hầu hết sản phẩm. Đến một lúc nó không chịu nổi lượng ghi, dữ liệu không còn vừa một máy, hoặc một sự cố ở DB đó làm sập mọi tính năng.
- Coding agent trong engineering (migrate, viết lại, chạy song song, quyền hạn) Chủ đề Thành viên
Từ 2026 các công ty bắt đầu giao cho coding agent những việc trước đây là dự án nhiều tuần: migrate hàng trăm module hay dataset, dọn feature flag, viết lại cả framework hay app. Agent viết nhanh, nhưng ba thứ không tự…
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Batching và khấu hao round-trip Chủ đề Thành viên
Nhiều nút thắt không nằm ở việc mỗi thao tác tốn bao nhiêu công, mà ở chi phí cố định trả cho mỗi thao tác: một round-trip mạng, một lần fsync, một PUT lên object storage, một syscall, một transaction. Khi chi phí cố…
- Hạ tầng tìm kiếm Chủ đề Thành viên
Lúc đầu, tìm kiếm là LIKE trên database hoặc một thư viện (Lucene) nhúng trong app. Khi dữ liệu và tính năng tăng, search thành một hệ có trạng thái riêng, khác database ở mấy điểm:
- Monolith và microservices — đi và quay lại Chủ đề Thành viên
Lúc nào nên tách hệ thống thành nhiều service, và cái giá của việc đó là gì? Các nguồn hiện có cho thấy đây không phải đường một chiều.
- Nền tảng ML (feature, training, serving, giám sát model) Chủ đề Thành viên
Model ML đầu tiên của một công ty thường được nhúng thẳng vào một service có sẵn, với feature tính trong vài script và train bằng một job riêng. Khi số model và số người làm model tăng, bốn chỗ cùng hỏng:
- Quản lý fleet và migrate code hàng loạt Chủ đề Thành viên
Khi số component (repo, service, pipeline, thư viện) tăng nhanh hơn số kỹ sư, chi phí của mỗi thay đổi xuyên suốt (nâng thư viện, vá bảo mật, đổi API nội bộ, khai tử dataset) tỉ lệ với số component chứ không với độ khó…
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn sự cố bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.