Tìm kiếm
40 kết quả cho “Vite”. Tìm không phân biệt dấu.
- Vitess (PlanetScale/CNCF) Công ty Thành viên
Dự án mã nguồn mở, sinh ra ở YouTube khoảng 2010 khi tầng định tuyến shard được tách khỏi ứng dụng . Bài 2022 giải thích bước cut-over của online schema change: đệm query bằng ACL có hạn, đổi tên bảng để ghi trở nên bất…
- Cloud Native MySQL Sharding with Vitess and Kubernetes Bài tóm tắt · Vitess · 2015
…15 · 3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://vitess.io/blog/2015-10-06-cloud-native-mysql-sharding-with-vitess-and-kubernetes/) Bài của engineer YouTube giới thiệu V…
- Scaling Etsy Payments with Vitess: Part 3 – Reducing Cutover Risk Bài tóm tắt · Etsy · 2023
…https://www.etsy.com/codeascraft/scaling-etsy-payments-with-vitess-part-3--reducing-cutover-risk) Bối cảnh - Tác giả ở đội Data Access Platform (giữ ORM nội bộ của Etsy; đã upstrea…
- VTOrc: Vitess-native Orchestrator Bài tóm tắt · Vitess (PlanetScale/CNCF) · 2022
…22 · 3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://vitess.io/blog/2022-09-21-vtorc-vitess-native-orchestrator/) Bài của dự án mã nguồn mở Vitess; mọi nhận định là theo các…
- Scaling Etsy Payments with Vitess: Part 1 – The Data Model Bài tóm tắt · Etsy · 2023
…https://www.etsy.com/codeascraft/scaling-etsy-payments-with-vitess-part-1--the-data-model) Bối cảnh - Cuối 2020, hai database thanh toán đã ở cấu hình máy cao nhất của Google Cloud…
- Migrating Etsy's database sharding to Vitess Bài tóm tắt · Etsy · 2026
….etsy.com/codeascraft/migrating-etsyas-database-sharding-to-vitess) Bối cảnh - Etsy shard MySQL từ khoảng 2010 : ~1.000 bảng trên ~1.000 shard, hơn 425 TB, ~1,7 triệu request/giây…
- Cut-over logic in vitess schema migrations Bài tóm tắt · Vitess (PlanetScale/CNCF) · 2022
…2022 · 3. Quy mô lớn · Độ khó: Nâng cao — [bài gốc](https://vitess.io/blog/2022-04-06-online-ddl-vitess-cut-over/) Bài kỹ thuật của dự án mã nguồn mở Vitess, không phải câu chuyện…
- Scaling Datastores at Slack with Vitess Bài tóm tắt · Slack · 2020
…(https://slack.engineering/scaling-datastores-at-slack-with-vitess/) Bối cảnh - Slack bắt đầu bằng LAMP. Mọi dữ liệu trên MySQL, gồm ba loại cluster: - Shards chứa dữ liệu khách hà…
- Scaling Etsy Payments with Vitess: Part 2 – The "Seamless" Migration Bài tóm tắt · Etsy · 2023
…https://www.etsy.com/codeascraft/scaling-etsy-payments-with-vitess-part-2--the-seamless-migration) Bối cảnh - Dữ liệu thanh toán phải chia lại vào 40 shard mới, kiểm đủ, rồi chuyển…
- How we scaled reads on the Twitter Users Database Bài tóm tắt · Twitter · 2023
…ệu query/giây"). Thay đổi chính - Chuyển sang MySQL thuần + Vitess . MySQL được chọn vì đã dùng rộng rãi ở Twitter, đơn giản, hiệu năng tốt; server MySQL phần lớn on-prem, phần cứn…
- A new Protocol Buffers generator for Go Bài tóm tắt · Vitess · 2021
…2021 · 4. Điều chỉnh · Độ khó: Nâng cao — [bài gốc](https://vitess.io/blog/2021-06-03-a-new-protobuf-generator-for-go/) Bối cảnh - Mọi giao tiếp giữa các thành phần của Vitess đi q…
- How we rebuilt Next.js with AI in one week Bài tóm tắt · Cloudflare · 2026
…dev. Thay đổi chính - Viết lại bề mặt API của Next.js trên Vite (vinext), không bọc output của Next.js: routing, SSR, React Server Components, server actions, cache, middleware, d…
- Sharding Cash Bài tóm tắt · Square · 2018
…r-blog/sharding-cash-10280fa3ef3b) Bài mở đầu một series về Vitess ở Cash App; các phần sau không có trong wiki. Bối cảnh - Cash App bắt đầu là thử nghiệm Hack Week trên một MySQL;…
- Hardening EmergencyReparentShard in v25 Bài tóm tắt · Vitess (PlanetScale/CNCF) · 2026
…2026 · 4. Điều chỉnh · Độ khó: Nâng cao — [bài gốc](https://vitess.io/blog/2026-09-23-hardening-emergency-reparent-shard/) Bài của dự án mã nguồn mở; mọi nhận định là theo các main…
- The history of Postgres sharding Bài tóm tắt · PlanetScale · 2026
…ng MySQL nên công cụ shard và online schema change (gh-ost, Vitess) phát triển sớm hơn. - Facebook 2008: hơn 100 triệu user trên khoảng 1.800 node MySQL, shard ở tầng ứng dụng theo…
- Slack's Incident on 2-22-22 Bài tóm tắt · Slack · 2022
…nhất) mới dùng được; boot lỗi là trang lỗi. - Dữ liệu trên Vitess chia nhiều keyspace (). Cache là Memcached, Mcrouter định tuyến bằng consistent hashing. Mcrib là control plane m…
- Slack's Migration to a Cellular Architecture Bài tóm tắt · Slack · 2023
…frontend phải ghi nhận lỗi rồi mới loại được backend hỏng; Vitess nhất quán mạnh nên mỗi shard chỉ có một primary nhận ghi. Đây là gray failure : mỗi thành phần thấy tính sẵn sàng…
- Reducing local dev time by 83%: Why we migrated off Next.js Bài tóm tắt · Inngest · 2026
…load trang lúc dev chậm. Bối cảnh - Inngest từng chuyển từ Vite sang Next.js "trong chưa tới một ngày", dùng App Router từ bản beta và React Server Components (RSC) với lời hứa bỏ…
- Building a region‑aware, SEO‑friendly global web app Bài tóm tắt · Mercari · 2025
…ới wrapper cho component async lồng nhau, chạy trên CI bằng Vitest. Theo real user metrics, dù chưa tối ưu hay cache gì, hiệu năng đã tốt hơn rõ so với web Nhật. - Subdomain theo v…
- Moving Railway's Frontend Off Next.js Bài tóm tắt · Railway · 2026
…r thì đẩy hẳn về server-first. Thay đổi chính - Chuyển sang Vite + TanStack Start/Router : route có kiểu, layout là primitive thật, HMR tức thì, SSR chỉ cho trang marketing/changel…
- Executing Cron Scripts Reliably At Scale Bài tóm tắt · Slack · 2023
…queue riêng nên chạy nhanh; gánh hết CPU và bộ nhớ. - Bảng Vitess thay flock : mỗi lần chạy là một dòng với trạng thái (enqueued, in progress, done); trước khi chạy kiểm 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.
- 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.
- 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:
- 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…
- 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".
- 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:
- 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ự…
- 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.
- Đổ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.
- 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…
- 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,…
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- 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ó…
- 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ả…
- Query planner và hiệu năng truy vấn Chủ đề Thành viên
Database quan hệ không chạy SQL theo đúng cách nó được viết. Query planner chọn một plan (dùng index nào, join kiểu gì: nested loop, merge, hash; dừng sớm khi có LIMIT hay không) dựa trên thống kê về dữ liệu: số dòng,…
- Etsy Công ty Thành viên
Etsy shard MySQL từ khoảng 2010 bằng ORM tự viết: gán shard ngẫu nhiên, lưu ánh xạ trong một index DB, thành điểm hỏng chung. Từ 2018 họ chuyển sang Vitess mà không dời dữ liệu (vindex lai: SQLite cho ID cũ, hash cho ID…
- Slack Công ty Thành viên
Slack bắt đầu bằng LAMP và giữ PHP vì môi trường của nó (mỗi request trạng thái sạch, vòng lặp sửa–tải lại). Họ cải tiến dần bằng HHVM và Hack thay vì viết lại . Tầng dữ liệu đi từ MySQL active-active shard theo…
- Re-architecting Slack's Workspace Preferences: Moving to an EAV Model Bài tóm tắt · Slack · 2018
…ỳ chọn một cột (đổi schema đắt mỗi lần thêm). Bảng tạo trên Vitess (). - Migration: - không dùng được công cụ chép bảng có sẵn vì một hàng cũ tách thành nhiều hàng mới; - viết hàm…
- Cloudflare Công ty Thành viên
Cloudflare bắt đầu bằng một cluster Postgres cfdb cho hầu hết control plane; từ 2017 các service dời dữ liệu ra dần. Đến 2022–2024 dữ liệu DNS (hàng tỷ record) được tách sang cluster riêng, sau khi mọi service đã đi qua…