Tìm kiếm
26 kết quả cho “Drop table”. Tìm không phân biệt dấu.
- How we rolled out one of the largest Python 3 migrations ever Bài tóm tắt · Dropbox · 2018
…18 · 4. Điều chỉnh · Độ khó: Trung bình — [bài gốc](https://dropbox.tech/application/how-we-rolled-out-one-of-the-largest-python-3-migrations-ever) Bài đầu của một series về app de…
- Incrementally migrating over one million lines of code from Python 2 to Python 3 Bài tóm tắt · Dropbox · 2019
…19 · 4. Điều chỉnh · Độ khó: Trung bình — [bài gốc](https://dropbox.tech/application/incrementally-migrating-over-one-million-lines-of-code-from-python-2-to-python-3) Bài thứ hai c…
- Centrifuge: a reliable system for delivering billions of events per day Bài tóm tắt · Segment · 2018
…t tiến trình nhỏ chuyển các job đang retry sang DB khác rồi drop table thay cho hàng loạt DELETE ngẫu nhiên. Kết quả (theo Segment, 2018) - 5 kỹ sư, 9 tháng, 50.000 dòng Go; 400.00…
- Jepsen: PostgreSQL 12.3 Bài tóm tắt · Jepsen · 2020
Trước 9.1, chế độ "serializable" của PostgreSQL thực ra là snapshot isolation (SI); từ 9.1 (2011) có serializable snapshot isolation (SSI): SI cộng kiểm lúc chạy các "cấu trúc nguy hiểm" (hai cạnh phụ thuộc đọc-ghi kề…
- 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…
- 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.
- 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…
- Giao dịch phân tán và nhất quán xuyên service Chủ đề Thành viên
Với một DB quan hệ, BEGIN … COMMIT lo hết. Khi dữ liệu bị chia (shard, tách service, thêm Redis bên cạnh Postgres), một thao tác nghiệp vụ chạm nhiều nơi, và câu hỏi khó nhất trở thành "timeout rồi, việc đó đã xảy ra…
- 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:
- Đổ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.
- 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…
- 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.
- 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".
- Độ 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.
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- 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ả…
- Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) Chủ đề Thành viên
Lỗi trong hệ phân tán là chắc chắn (máy chết, zone mất, dependency chậm, cấu hình sai), nhưng phần lớn lỗi nằm ở những tổ hợp hiếm mà test chức năng không chạm tới. Bài toán là chủ động gây lỗi để biết hệ thống phản ứng…
- 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…
- 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:
- 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:
- 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.
- A Self-Baked Async FFI Framework for Rust <-> C# Interop Bài tóm tắt · ScyllaDB · 2026
…stack (rẻ), gọi bất đồng bộ dùng GCHandle bọc trong kiểu có Drop để tự giải phóng. Vì sao - Theo ScyllaDB: logic khó (định tuyến theo shard/tablet, pool kết nối, thực thi query) ch…
- How we used delayed replication for disaster recovery with PostgreSQL Bài tóm tắt · GitLab · 2019
…request. - Replication không phải backup: một lệnh DELETE / DROP TABLE được replicate gần như ngay tới mọi replica. Thay đổi chính - PITR (point-in-time recovery): base backup định…
- Inside branch-based restores in Lakebase Postgres Bài tóm tắt · Neon · 2026
…ca giúp khi máy chết, nhưng không giúp khi lệnh ghi sai hay DROP TABLE đã sang cả standby: lúc đó vẫn phải restore. - PITR truyền thống tới thời điểm T có ba bước: 1. Dựng instance…
- Knowing When Your Composite Index Earns Its Write Cost Bài tóm tắt · Tiger Data · 2026
…(tag id) đứng cạnh (tag id, ts DESC) gần như thừa. Xoá bằng DROP INDEX CONCURRENTLY . Bài học cho SWE - Câu hỏi không phải "index có làm chậm ghi không" mà là "index có rải ghi ra…
- Uber Công ty Thành viên
Một vòng đủ: monolith → microservices → tổ chức lại microservices. Năm 2012–2013 Uber có hai monolith; khi lên hàng trăm kỹ sư thì tách. Lý do chủ yếu là tổ chức. Năm 2015 họ có 500+ service và phải chuẩn hoá contract…