Tìm kiếm
14 kết quả cho “Brooklin”. Tìm không phân biệt dấu.
- Open sourcing Brooklin: Near real-time data streaming at scale Bài tóm tắt · LinkedIn · 2019
…bình — [bài gốc](https://engineering.linkedin.com/blog/2019/brooklin-open-source) Bối cảnh - Bài toán không chỉ là chuyển nhiều dữ liệu, mà là số loại hệ nguồn và đích tăng nhanh (…
- Solving manageability challenges at scale with Nuage Bài tóm tắt · LinkedIn · 2019
…g lạm dụng), Couchbase, Ambry (blob), Pinot, Samza, Pro-ML, Brooklin, Venice. Mục tiêu "hạ tầng vô hình": team sản phẩm tự tạo và quản lý tài nguyên mà không phải hiểu từng hệ. - N…
- Upscaling LinkedIn's Profile Datastore While Reducing Costs Bài tóm tắt · LinkedIn · 2023
…trapper là job Samza đọc stream CDC và stream bootstrap của Brooklin . Nhất quán cuối cùng. - Hợp đồng cache theo request: header "staleness bound" để ứng dụng bật/tắt cache và chọ…
- Authorization at LinkedIn's Scale Bài tóm tắt · LinkedIn · 2019
…o, Couchbase làm cache phía server; khi ACL bị sửa, CDC qua Brooklin báo để xoá cache. - Log mọi lần check bất đồng bộ qua Kafka để debug, phân tích traffic và phục vụ audit; số li…
- 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ả…
- 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:
- 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…
- 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:
- Xác thực và phân quyền (authn/authz) Chủ đề Thành viên
Ở monolith, mỗi dữ liệu thường chỉ có một đường vào, nên kiểm tra quyền nằm ngay đó: một hàm hasaccess?, một API mỗi resource. Khi hệ thống tách thành nhiều service, nhiều client, nhiều loại token, cả hai nửa đều vỡ:
- LinkedIn Công ty Thành viên
Bài khung là bài nhìn lại năm 2015 . LinkedIn bắt đầu năm 2003 là một monolith tên Leo. Service đầu tiên tách ra là member graph, vì đồ thị kết nối có profile tải khác hẳn; DB profile được đỡ bằng scale dọc rồi replica…
- Open sourcing Databus: LinkedIn's low latency change data capture system Bài tóm tắt · LinkedIn · 2013
LinkedIn có nhiều hệ lưu trữ chuyên biệt: DB OLTP nhận ghi; search index, cache, read replica phục vụ đọc. Các hệ dẫn xuất này phải theo kịp DB chính một cách đáng tin cậy và giữ thứ tự transaction.
- The Log: What every software engineer should know about real-time data's unifying abstraction Bài tóm tắt · LinkedIn · 2013
Khoảng 2007 LinkedIn bắt đầu chạm giới hạn của một database tập trung, chuyển sang một danh mục hệ phân tán chuyên biệt: search, social graph, Voldemort (key-value), Espresso (document), recommendation, OLAP, Hadoop,…
- Introducing Espresso - LinkedIn's hot new distributed document store Bài tóm tắt · LinkedIn · 2015
Trước Espresso, LinkedIn dùng Oracle (dữ liệu chính, nhất quán mạnh) và Voldemort (key-value). Phần lớn dữ liệu chính không cần đủ tính năng RDBMS nhưng lại cần đọc-sau-ghi và một change capture stream có thứ tự theo…
- Running Kafka At Scale Bài tóm tắt · LinkedIn · 2015
Năm 2015 Kafka chạm gần như mọi server LinkedIn: hơn 800 tỷ message/ngày (175 TB vào, 650 TB đọc ra), đỉnh 13 triệu message/giây (2,75 GB/s), hơn 1.100 broker trong hơn 60 cụm.