Tìm kiếm
40 kết quả cho “graph database”. Tìm không phân biệt dấu.
- How PayPal Uses Real-time Graph Database and Graph Analysis to Fight Fraud Bài tóm tắt · PayPal · 2021
…c](https://medium.com/paypal-tech/how-paypal-uses-real-time-graph-database-and-graph-analysis-to-fight-fraud-96a2b918619a) Bài nói mô hình dữ liệu đồ thị trong ví dụ không phải mô…
- LIquid: The soul of a new graph database, Part 1 Bài tóm tắt · LinkedIn · 2020
…engineering.linkedin.com/blog/2020/liquid-the-soul-of-a-new-graph-database-part-1) Bối cảnh - Theo LinkedIn, giá trị của đồ thị nằm chủ yếu ở mạng cấp 2 : bạn của bạn, thường ít nh…
- LIquid: The soul of a new graph database, Part 2 Bài tóm tắt · LinkedIn · 2020
…ngineering.linkedin.com/blog/2020/liquid--the-soul-of-a-new-graph-database--part-2) Bối cảnh - Đồ thị biểu diễn bằng một bảng cạnh (adjacency list) là đúng mô hình quan hệ: không N…
- How Stripe uses graph search and state machines to auto-remediate a global database fleet Bài tóm tắt · Stripe · 2026
…âng cao — [bài gốc](https://stripe.dev/blog/how-stripe-uses-graph-search-and-state-machines-to-auto-remediate-a-global-database-fleet) Bối cảnh - Document Database của Stripe: khoả…
- 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".
- From Events to Insights: Memgraph Production Telemetry Stack with AWS, ClickHouse, and Grafana Bài tóm tắt · Memgraph · 2026
…· 2026 · 2. Tăng trưởng · Độ khó: Dễ — [bài gốc](https://memgraph.com/blog/memgraph-production-telemetry-stack-aws-clickhouse-grafana) Telemetry ở đây là dữ liệu sử dụng sản phẩm (…
- Memgraph Công ty Thành viên
Memgraph là công ty graph database. Năm 2026 họ bỏ colocation tự giữ máy cho CI và benchmark sang thuê Hetzner, chi phí giảm khoảng một nửa; CI chạy trên vCPU dùng chung, benchmark trên bare metal để giảm nhiễu . Cùng…
- Why Memgraph Infrastructure Was Moved to Hetzner Bài tóm tắt · Memgraph · 2026
· 2026 · 4. Điều chỉnh · Độ khó: Dễ — [bài gốc](https://memgraph.com/blog/memgraph-infrastructure-move-to-hetzner) Bài ngắn của một công ty database (Memgraph); hạ tầng được nói t…
- Retail Graph — Walmart's Product Knowledge Graph Bài tóm tắt · Walmart · 2020
…rung bình — [bài gốc](https://medium.com/walmartlabs/retail-graph-walmarts-product-knowledge-graph-6ef7357963bc) Bối cảnh - Catalog thương mại điện tử lấy dữ liệu từ seller và nhà…
- Under the Hood: Building out the infrastructure for Graph Search Bài tóm tắt · Meta · 2013
…re-infra/under-the-hood-building-out-the-infrastructure-for-graph-search/) Bối cảnh - Facebook có nhiều hệ search cũ chồng nhau: PPS (theo từ khoá, cá nhân hoá, lọc theo loại entit…
- Managing Software Dependency at Scale Bài tóm tắt · LinkedIn · 2018
…ai còn dùng thư viện có bug nghiêm trọng. - Hệ cũ dựng trên graph database thương mại , ghi phụ thuộc ở mức product, không phản ánh việc Gradle giải xung đột version ở mức module,…
- Integrating Neo4j Into Your Stack Bài tóm tắt · Doximity · 2022
…- Cùng công ty: (nền tảng Kafka cho Ruby) · - Cùng bài toán graph DB:…
- Single-Store Vector Index: Architecture and Memory Efficiency Bài tóm tắt · Memgraph · 2026
…2. Tăng trưởng · Độ khó: Trung bình — [bài gốc](https://memgraph.com/blog/single-store-vector-index) Bài nhà cung cấp; benchmark tự chạy trên một kịch bản (1 triệu node, 1024 chiề…
- The Log: What every software engineer should know about real-time data's unifying abstraction Bài tóm tắt · LinkedIn · 2013
…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, Teradata, inGraphs. - Hạ tầng log sớm n…
- A Brief History of Scaling LinkedIn Bài tóm tắt · LinkedIn · 2015
…logic, kết nối vài database). - Service đầu tiên là member graph ("Cloud"): đồ thị kết nối cần duyệt trong bộ nhớ, có profile tải khác hẳn Leo nên tách ra scale riêng, gọi qua Jav…
- How we rolled out our own permissions DSL at Figma Bài tóm tắt · Figma · 2024
…n sự thật: logic phải viết hai lần, ở Sinatra (HTTP) và LiveGraph (API realtime), và hay lệch nhau. Thay đổi chính - Build thay vì buy: đã xét Open Policy Agent, Zanzibar, Oso nhưn…
- DataHub: Popular metadata architectures explained Bài tóm tắt · LinkedIn · 2020
…QL/Postgres), một search index (Elasticsearch), có thể thêm graph (Neo4j); crawler chạy mỗi ngày kéo metadata từ nguồn. Dựng nhanh, một team làm được. Yếu điểm: crawler giòn (firew…
- How LIquid Connects Everything So Our Members Can Do Anything Bài tóm tắt · LinkedIn · 2023
…-members-can-do-anything) Bối cảnh - LIquid () giữ Economic Graph: kết nối giữa member, trường, kỹ năng, công ty, vị trí, việc làm, sự kiện, nhóm. Năm 2023: 270 tỷ cạnh , 2 triệu q…
- Netflix Conductor: A microservices orchestrator Bài tóm tắt · Netflix · 2016
…hì không còn nhìn thấy quy trình. Thay đổi chính - Bỏ choreography ngang hàng, dùng orchestrator trung tâm. Theo Netflix, pub/sub chỉ ổn cho luồng đơn giản: luồng nghiệp vụ nằm rải…
- Cross Shard Transactions at 10 Million Requests Per Second Bài tóm tắt · Dropbox · 2018
Edgestore là lớp trừu tượng trên hàng nghìn node MySQL, giữ hàng petabyte metadata, hơn 10 triệu request/giây. Developer gom dữ liệu hay đi cùng nhau vào một colo (cùng shard vật lý): trong colo có transaction mạnh,…
- 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.
- 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.
- 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:
- 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…
- Tách compute khỏi storage Chủ đề Thành viên
Hệ có trạng thái kiểu cổ điển (database, broker Kafka, fileserver Git) đặt dữ liệu bền trên đĩa của chính máy xử lý. Máy đó vừa là compute vừa là storage, nên:
- 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…
- Vector search và index ANN Chủ đề Thành viên
Search ngữ nghĩa, gợi ý và RAG quy về tìm các vector (embedding vài trăm tới vài nghìn chiều) gần một vector query. Vector không có thứ tự tự nhiên, nên B-tree hay inverted index không dùng được; ở quy mô lớn phải dùng…
- 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ố…
- 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ả…
- 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:
- 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:
- 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…
- 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,…
- 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ỡ:
- 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…
- Load test và kiểm chứng capacity Chủ đề Thành viên
Trước một mốc tải chưa từng gặp (ra mắt game, tính năng mới gửi push toàn quốc, mùa giải, tăng trưởng nhanh), cần biết hệ chịu được bao nhiêu, cái gì gãy trước, và cần bao nhiêu máy. Test từng service riêng không đủ vì…
- 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:
- 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.
- 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…