Tìm kiếm
28 kết quả cho “Espresso”. Tìm không phân biệt dấu.
- Introducing Espresso - LinkedIn's hot new distributed document store Bài tóm tắt · LinkedIn · 2015
…· Độ khó: Khó — [bài gốc](https://engineering.linkedin.com/espresso/introducing-espresso-linkedins-hot-new-distributed-document-store) Bối cảnh - Trước Espresso, LinkedIn dùng Ora…
- Upscaling LinkedIn's Profile Datastore While Reducing Costs Bài tóm tắt · LinkedIn · 2023
…khi mở rộng, thay node, cache lạnh). Chuyển từ Oracle sang Espresso năm 2014 thì bỏ cache; Espresso profile được mở rộng tới hơn 1,4 triệu QPS bằng cách thêm node, rồi chạm trần c…
- Open sourcing Brooklin: Near real-time data streaming at scale Bài tóm tắt · LinkedIn · 2019
…n nhiều dữ liệu, mà là số loại hệ nguồn và đích tăng nhanh (Espresso, Oracle, MySQL, Kafka, Azure Event Hubs, Kinesis). - Mirror Kafka giữa các cụm và data center dùng Kafka Mirror…
- A Brief History of Scaling LinkedIn Bài tóm tắt · LinkedIn · 2015
…ack từ nhiều nguồn và ghim người dùng vào data center gần . Espresso hỗ trợ master/master. Năm 2015: ba data center chính và các PoP. - Còn lại: Samza, Espresso, Voldemort, Pinot;…
- Managing Software Dependency at Scale Bài tóm tắt · LinkedIn · 2018
…ild, test, runtime; API Rest.li. - Bỏ graph DB, chuyển sang Espresso: đồ thị của một product ở một version, khi đã tạo, là bất biến , nên không cần duyệt cạnh realtime; Neo4j không…
- Maximizing Our Publishing Platform Reach with Network Distribution Bài tóm tắt · LinkedIn · 2014
…i một activity "member published" vào Activities Index trên Espresso . Khi có request, Feed-Mixer lấy activity từ Unified Social Content Platform (USCP) và update từ các first pass…
- Solving manageability challenges at scale with Nuage Bài tóm tắt · LinkedIn · 2019
…es-with-nuage) Bối cảnh - Mỗi tính năng dùng nhiều hạ tầng: Espresso, Galene, Kafka, Bulkhead (quota), Helix, Fuse (chống lạm dụng), Couchbase, Ambry (blob), Pinot, Samza, Pro-ML,…
- Authorization at LinkedIn's Scale Bài tóm tắt · LinkedIn · 2019
…đổi có hiệu lực nhanh nhưng tải tăng. - Lưu trữ: ACL trong Espresso, 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 đồ…
- DataHub: A generalized metadata search & discovery tool Bài tóm tắt · LinkedIn · 2019
…all API. Hàng triệu MCE mỗi ngày. - Phục vụ bằng nhiều kho: Espresso (document), Galene (full-text), graph DB (quan hệ, join), sau các DAO chung để thay được kho (và mở mã nguồn vớ…
- 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".
- 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:
- Độ 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:
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏ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.
- 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…
- 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ả…
- 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…
- 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…
- 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…
- Building Venice with Apache Helix Bài tóm tắt · LinkedIn · 2017
…ết mỗi kho từ đầu mà dùng thư viện chung; Helix (ra đời cho Espresso) lo quản lý cụm và được dùng cho storage, stream processing, search, analytics. - Voldemort Read-Only là nơi ph…
- Project Voldemort: Scaling Simple Storage at LinkedIn Bài tóm tắt · LinkedIn · 2009
LinkedIn bắt đầu bằng một DB lớn và cụm front-end (cộng một đồ thị xã hội trong RAM trên máy riêng). DB được tách thành các service riêng cho profile, search, nhóm, network update, công ty; có read replica nhưng chưa có…
- 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
…n chuyên biệt: search, social graph, Voldemort (key-value), Espresso (document), recommendation, OLAP, Hadoop, Teradata, inGraphs. - Hạ tầng log sớm nhất là Databus : lớp cache log…
- Couchbase Ecosystem at LinkedIn Bài tóm tắt · LinkedIn · 2017
…base ở mid-tier rồi bị gỡ bớt) · (Couchbase làm cache trước Espresso) · - ·…
- An inside look at LinkedIn's data pipeline monitoring system Bài tóm tắt · LinkedIn · 2019
…Dữ liệu vào Hadoop chủ yếu qua Apache Gobblin (nguồn Kafka, Espresso, Oracle), job batch chạy hàng giờ trên hàng trăm dataset. Giám sát lúc đó chỉ là trạng thái pass/fail của job t…
- DataHub: Popular metadata architectures explained Bài tóm tắt · LinkedIn · 2020
…óc nhìn của LinkedIn. Đọc kèm . Bối cảnh - Tác giả từng xây Espresso, Databus, Kafka; khi sang team hạ tầng analytics (Hadoop) thấy người ta hỏi nhau "dataset nào đúng" suốt: lưu t…