# Index Published articles for Index. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Introducing TIN: full-text search for Postgres DevFeed: [Introducing TIN: full-text search for Postgres]() Original publisher: [Read original article]() Author: Patrick Reynolds Published: 2026-09-16T00:00:00Z Content type: release Language: en Sources: [Blog -- PlanetScale]() Topics: [Databases](), [benchmarking]() Tags: [backups](), [benchmark](), [benchmarks](), [bm25](), [engineering](), [full-text-search](), [index](), [performance](), [postgres](), [reddit](), [replication](), [search](), [text](), [wikipedia]() ### AI overview PlanetScale announces TIN, a full-text search extension for Postgres and Neki databases. The article describes supported query and matching features, transaction and update behavior, and benchmark workloads and corpora used to assess performance. ### Source excerpt TIN is a fast, full-featured, full-text search index for Postgres ## A visual guide to troubleshooting search performance using Query Insights dashboards DevFeed: [A visual guide to troubleshooting search performance using Query Insights dashboards]() Original publisher: [Read original article]() Author: Chenyang Ji Published: 2026-09-04T20:11:52Z Content type: tutorial Language: en Sources: [OpenSearch]() Topics: [Amazon OpenSearch Service](), [dashboards](), [Monitoring](), [Latency](), [cpu]() Tags: [blog](), [configuration](), [cpu](), [dashboards](), [distribution](), [how-to](), [index](), [latency](), [memory](), [monitoring](), [navigation](), [opensearch](), [performance](), [real-time](), [technical](), [troubleshooting](), [view](), [visualization]() ### AI overview A visual guide to using OpenSearch Query Insights dashboards to investigate slow searches and unexpected resource usage. It covers the Live Queries and Top N Queries views, interactive visualizations, configuration, and metrics such as latency, CPU, and memory. ### Source excerpt OpenSearch Query Insights dashboards provide interactive visualizations for monitoring live queries, analyzing top N query performance, and viewing individual query details. This post explores each visualization and shows how to use visualizations to troubleshoot search performance issues. The post A visual guide to troubleshooting search performance using Query Insights dashboards appeared first on OpenSearch. ## Benchmarking vector indexes DevFeed: [Benchmarking vector indexes]() Original publisher: [Read original article]() Author: Evgeniy Patlan Published: 2026-08-27T13:35:32Z Content type: article Language: en Sources: [Blog - Percona]() Topics: [benchmarking](), [Ground truth / benchmark quality](), [Databases](), [ann](), [datasets](), [Sorting]() Tags: [ai-vector](), [ann](), [benchmark](), [benchmarking](), [benchmarks](), [blog](), [blog-post](), [data](), [database-performance](), [database-trends](), [databases](), [datasets](), [embeddings](), [index](), [measurements](), [model](), [open-source](), [percona](), [points](), [report](), [run](), [search](), [sorting](), [vector-search](), [vectorsearch]() ### AI overview This article explains how Percona's vector-bench measures vector indexes by building database engines from pinned versions, running them in identical containers with the same data and hardware, and comparing consistent measurements. It describes embeddings, exact search, approximate nearest neighbour search, and ground truth as the brute-force reference needed to evaluate index accuracy. ### Source excerpt Nearly every database has vector search now, and every one of them has a blog post with a big number in it. Almost none of those numbers can be checked, because the thing that makes them meaningful is usually missing. We built a vector-bench to stop guessing. You name the engines you want, build them ... Continued The post Benchmarking vector indexes appeared first on Percona. ## 【etcd】treeIndex 与 Apply 管道：propose -\> commit -\> apply DevFeed: [【etcd】treeIndex 与 Apply 管道：propose -\> commit -\> apply]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [Back end]() Tags: [applied-index](), [apply](), [backend](), [bbolt](), [commit](), [compaction](), [distributed](), [etcd](), [index](), [kubernetes](), [mvcc](), [raft](), [range](), [recovery](), [revision](), [store](), [treeindex](), [txn](), [v3-5](), [wal](), [watch]() ### AI overview This tutorial explains the etcd v3.5.33 apply pipeline from Raft commit to MVCC application. It covers the separation between propose, commit, and apply; the roles of treeIndex and bbolt; consistent-index updates; watch notification timing; and troubleshooting committed-versus-applied lag. ### Source excerpt 走读 etcd v3.5.33 从 Raft commit 到 MVCC apply 的串行管道：treeIndex 与 bbolt 分工、consistent index、watchableStore 通知触发点，以及 committed/applied 分列排障。 ## Postgres 19: How Our Advice Has Changed Since We Wrote It DevFeed: [Postgres 19: How Our Advice Has Changed Since We Wrote It]() Original publisher: [Read original article]() Author: Christopher Winslett Published: 2026-08-18T19:00:00Z Content type: article Language: en Sources: [CrunchyData Blog]() Topics: [data](), [JIT](), [Latency](), [Temporal data](), [Linux]() Tags: [advice](), [async](), [benchmarks](), [index](), [jit](), [latency](), [linux](), [maintenance](), [parallel](), [partitioning](), [postgres](), [postgres-19](), [production-postgres](), [release](), [storage](), [upgrade]() ### AI overview This article revisits earlier Crunchy Data guidance on loading, storage, indexes, and partitioning for the upcoming Postgres 19 release. It explains which changes in Postgres 18 and 19 affect that advice, including asynchronous I/O, parallel maintenance, BRIN and skip-scan behavior, partition operations, and JIT being disabled by default. The details are based on current betas and may change before general availability. ### Source excerpt Revisiting Crunchy posts on COPY, TOAST, BRIN, covering indexes, and partitioning: what we said then, which Postgres versions changed the story, and what we recommend on Postgres 19. ## Detecting Full Table Scans With SQLite DevFeed: [Detecting Full Table Scans With SQLite]() Original publisher: [Read original article]() Published: 2026-07-15T15:26:22Z Content type: tutorial Language: en Sources: [Aaron Patterson]() Topics: [SQLite](), [Databases](), [Development](), [Rails]() Tags: [database](), [index](), [query](), [rails](), [sqlite](), [test]() ### AI overview This tutorial shows how to detect full table scans in SQLite by inspecting prepared-statement statistics after executing a query. It demonstrates checking full-scan steps, then adding an index to eliminate the scan, and discusses possible Rails integration for test or development warnings. ### Source excerpt I'm at RubyConf this week, and it's great! I recently read that lobste.rs is now running on SQLite. One part from the post caught my attention: I wish we could say in a test, "Fail if you encounter any full table scans". Which would have caught the perf issues we experienced during the first deploy. SQLite collects information about prepared statements and exposes those statistics though an API. The upshot of this is that we can tell whether a statement did a full table scan after executing the statement without using an EXPLAIN. Here's an example program that demonstrates detecting a query did a full table scan: db = SQLite3::Database.new(":memory:") db.execute("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, age INTEGER)") # Insert a bunch of records 1_000.times do |i| db.execute("INSERT INTO users (name, age) VALUES (?, ?)", ["user#{i}", i % 100]) end def query(db) # Prepare a statement and query it stmt = db.prepare("SELECT * FROM users WHERE age = ?") stmt.bind_param(1, 42) stmt.to_a # Check the number of full scan steps to detect full table scan fullscan_steps = stmt.stat(:fullscan_steps) puts "fullscan_steps: #{fullscan_steps}" if fullscan_steps > 0 puts " => query performed a full table scan" else puts " => no full table scan" end end # No index, so we'll see a full table scan query(db) # Create an index db.execute("CREATE INDEX idx_users_age ON users(age)") # Added an index, so no full table scan query(db) Feels like we could integrate this in to Rails and warn or raise in test / development. I'm not sure if we'd want to check this all the time in production, but maybe it would be fine? ## How to Achieve Pruning When Querying by Non-Partitioned Columns in PostgreSQL DevFeed: [How to Achieve Pruning When Querying by Non-Partitioned Columns in PostgreSQL]() Original publisher: [Read original article]() Author: Haki Benita Published: 2026-07-08T21:00:00Z Content type: tutorial Language: en Sources: [Haki Benita]() Topics: [PostgreSQL](), [Databases]() Tags: [articles](), [how-to](), [index](), [partition](), [patterns](), [performance](), [postgresql](), [query]() ### AI overview This tutorial explains PostgreSQL partition pruning and shows how certain data patterns can enable pruning when queries filter on columns other than the partition key. It uses event data partitioned by year and examines queries by date range and session. ### Source excerpt Under conventional wisdom, pruning can only be achieved when querying by the partition key. However, if your data follows certain patterns, using some clever tricks you can achieve pruning even when filtering by non-partition key columns. ## Kubernetes 网络深度系列 DevFeed: [Kubernetes 网络深度系列]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-04-03T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [Kubernetes](), [Linux](), [eBPF](), [VXLAN](), [gateway](), [nginx](), [traefik](), [Grafana]() Tags: [ebpf](), [gateway](), [grafana](), [index](), [k8s](), [kubernetes](), [linux](), [net-11](), [networking](), [nginx](), [return](), [series](), [service-mesh](), [traefik](), [vxlan]() ### AI overview A Chinese tutorial series explains Kubernetes networking from the Linux network stack through virtual devices, routing, tunnels, eBPF, CNI plugins, Services, security policies, service discovery, traffic management, performance tuning, and troubleshooting. It includes packet captures, code, and kernel-source references, with comparisons of major CNI and ingress approaches. ### Source excerpt 从 Linux 网络栈的第一个字节到多集群联邦网络的最后一跳----用代码、抓包和内核源码把 Kubernetes 网络讲透 ## Cursor Pagination vs Offset Pagination: Which One Should You Use? DevFeed: [Cursor Pagination vs Offset Pagination: Which One Should You Use?]() Original publisher: [Read original article]() Published: 2026-03-11T00:00:00Z Content type: tutorial Language: en Sources: [Gaurav Sarma's Blog]() Topics: [API](), [Databases](), [SQL](), [Query (disambiguation)]() Tags: [api](), [apis](), [b-tree](), [database](), [index](), [indexes](), [query-planner](), [rest-apis]() ### AI overview This tutorial compares offset, cursor, and keyset pagination for REST APIs. It explains that offset pagination becomes slower at deep pages because the database scans and discards preceding rows, while concurrent inserts can cause duplicates or skipped results. Cursor pagination uses an indexed position for more consistent performance but does not support random page access; keyset pagination generalizes the approach to arbitrary sort orders. ### Source excerpt . [Cursor vs Offset Pagination](cursor-pagination-vs-offset-pagination-cover... ## SQLite Query Optimisation - How the Planner Thinks and Where It Goes Wrong DevFeed: [SQLite Query Optimisation - How the Planner Thinks and Where It Goes Wrong]() Original publisher: [Read original article]() Published: 2026-03-08T00:00:00Z Content type: tutorial Language: en Sources: [Gaurav Sarma's Blog]() Topics: [SQLite](), [SQL](), [Databases]() Tags: [b-tree](), [index](), [optimisation](), [planner](), [query](), [query-planner](), [sql](), [sqlite]() ### AI overview A tutorial on how SQLite's query planner chooses between index searches and full table scans. It explains planner behavior, the effects of query patterns and data distribution, and how to avoid conditions that make indexes inaccessible or scans appear cheaper. ### Source excerpt . [SQLite Query Optimisation](sqlite-query-optimisation-cover... ## What is index overhead on writes? DevFeed: [What is index overhead on writes?]() Original publisher: [Read original article]() Author: depesz Published: 2026-01-06T11:57:10Z Content type: article Language: en Sources: [select \* from depesz;]() Topics: [data]() Tags: [benchmark](), [btree](), [delete](), [gin](), [index](), [insert](), [operations](), [overhead](), [performance](), [postgresql](), [speed](), [tutorial](), [uncategorized](), [update]() ### AI overview The article measures how indexes affect write performance using PostgreSQL 18 and a one-million-row test table. It reports that loading performance decreases as indexes are added, and that a roughly 3.6-fold increase in storage corresponded to an eightfold slowdown in the tested case. A single wide index performed better than ten separate indexes, though the author notes that the configurations solve different computational problems. ### Source excerpt One of things people learn is that adding indexes isn't free. All write operations (insert, update, delete) will be slower - well, they have to update index. But realistically - how much slower? Full tests should involve lots of operations, on realistic data, but I just wanted to see some basic info. So I figured ... Continue reading "What is index overhead on writes?" ## Do you really need tsvector column? DevFeed: [Do you really need tsvector column?]() Original publisher: [Read original article]() Author: depesz Published: 2025-11-03T12:34:33Z Content type: article Language: en Sources: [select \* from depesz;]() Topics: [data](), [Query (disambiguation)](), [Algorithm]() Tags: [algorithm](), [benchmark](), [comparison](), [data](), [function](), [gin](), [gist](), [index](), [postgresql](), [query](), [tsearch](), [tsvector](), [uncategorized]() ### AI overview This article tests whether a materialized tsvector column is necessary for full-text search. Using a large Wikipedia-derived dataset, it compares a tsvector column with an expression-based function index and reports that the tested query took about 4.5 minutes with the materialized column versus almost an hour with the function-based index. ### Source excerpt When using tsearch one usually, often, creates a tsvector column to put data in, and then create index on it. But, do you really need the index? I wrote once already that you don't have to, but then a person talked with me on IRC, and pointed this section of docs: One advantage of the ... Continue reading "Do you really need tsvector column?" ## How Cursor Indexes Codebases Fast DevFeed: [How Cursor Indexes Codebases Fast]() Original publisher: [Read original article]() Author: Engineer's Codex Published: 2025-05-10T16:28:09Z Content type: article Language: en Sources: [Engineer's Codex]() Topics: [cursor](), [Software Engineering](), [Code](), [hash](), [Embeddings](), [structure](), [file](), [implementation]() Tags: [code](), [cursor](), [embeddings](), [hash](), [index](), [indexing](), [software-engineering]() ### AI overview This article explains how Cursor indexes codebases using Merkle trees. It describes local code chunking, hash-tree construction and synchronization with Cursor's server, followed by embedding generation through OpenAI's embedding API or a custom embedding model. ### Source excerpt Merkle Trees in the real world ## How and when to use btree\_gist DevFeed: [How and when to use btree\_gist]() Original publisher: [Read original article]() Author: George MacKerron Published: 2024-07-08T13:29:31Z Content type: tutorial Language: en Sources: [Blog -- Neon Docs]() Topics: [SQL](), [Databases](), [CSV](), [data](), [DateTime]() Tags: [data](), [extension](), [files](), [format](), [index](), [monitor](), [numbers](), [postgres](), [schema](), [sql](), [time]() ### AI overview This tutorial explains how to use PostgreSQL indexes for queries combining one-dimensional and multidimensional data. It focuses on the btree_gist extension and demonstrates its use with UK crime data containing locations and reporting dates, including loading selected CSV data into PostgreSQL. ### Source excerpt The right indexes make big SQL queries fast. If you've been using Postgres for more than 5 minutes, you're almost certainly familiar with the everyday B-Tree index. This can deal with data that has a one-dimensional ordering: numbers, timestamps, text, and so on. And if you've ha... ## pgvector: Fewer dimensions are better DevFeed: [pgvector: Fewer dimensions are better]() Original publisher: [Read original article]() Author: Greg Richardson; Oliver Rice; Egor Romanov Published: 2023-08-03T07:00:00Z Content type: article Language: en Sources: [Supabase Blog]() Topics: [Embeddings](), [Supabase](), [AI search](), [hugging face]() Tags: [compute](), [embedding](), [hardware](), [index](), [information-retrieval](), [openai](), [performance](), [pgvector](), [provisioning](), [vectors]() ### AI overview This article explains why using embedding vectors with fewer dimensions can improve pgvector performance. It covers vector storage in Postgres, similarity indexes, memory and compute requirements, and the scaling challenges of high-dimensional embeddings. ### Source excerpt Increase performance in pgvector by using embedding vectors with fewer dimensions ## Chainguard contributes Rekor Search project to Sigstore DevFeed: [Chainguard contributes Rekor Search project to Sigstore]() Original publisher: [Read original article]() Published: 2023-03-24T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard](), [browser](), [Code](), [Git]() Tags: [browser](), [chainguard](), [git](), [gitsign](), [hash](), [index](), [open-source-software](), [rekor](), [search](), [sigstore](), [transparency-log](), [ui]() ### AI overview Chainguard is donating its open-source Rekor Search UI project to Sigstore. The browser-based search engine lets users search and sort entries in the public Rekor transparency log by email, hash, entry UUID, or log index, with support for Gitsign signatures and Git commit associations. ### Source excerpt Chainguard announces its donating the Rekor Search UI project to Sigstore, allowing users to conveniently search entries in the public Rekor transparency log. ## Visualizing information propagation in markets DevFeed: [Visualizing information propagation in markets]() Original publisher: [Read original article]() Author: Ricson Cheng Published: 2022-11-23T00:00:00Z Content type: article Language: en Sources: [Jane Street]() Topics: [Transactions](), [data]() Tags: [data](), [forecasting](), [future](), [hedge](), [index](), [information](), [transactions](), [uk](), [visualization]() ### AI overview The article uses the historical Dojima rice market and the story of Forecasting Yomiji to introduce how price information propagated through markets. It then presents a visualization of information transmission through fiber-optic cables using data from futures exchanges around the world, with equity index futures as an example. ### Source excerpt The Dojima rice market, established around 1716, is widely considered to be the world's first organized futures exchange. Instead of directly exchanging money for rice on the spot, merchants would agree on a price and future date at which rice and money would be exchanged. This allowed farmers and consumers to hedge their risk. As a result, information about the abundance or lack of rice would travel across the country as fast as rice merchants carried it. ## Postgres Auditing in 150 lines of SQL DevFeed: [Postgres Auditing in 150 lines of SQL]() Original publisher: [Read original article]() Author: Oliver Rice Published: 2022-03-08T07:00:00Z Content type: article Language: en Sources: [Supabase Blog]() Topics: [PostgreSQL](), [SQL](), [Databases]() Tags: [audit](), [index](), [postgres](), [postgresql](), [schema](), [sql]() ### AI overview This article presents a generic PostgreSQL auditing solution implemented in 150 lines of SQL. It explains how to track table changes over time, store audit records across multiple tables, preserve schema flexibility, maintain compatibility across PostgreSQL versions, and support efficient time-range queries with indexing. ### Source excerpt PostgreSQL has a robust set of features which we can leverage to create a generic auditing solution in 150 lines of SQL. ## Cracking PostgreSQL Interview Questions DevFeed: [Cracking PostgreSQL Interview Questions]() Original publisher: [Read original article]() Author: Ant Wilson Published: 2021-02-27T07:00:00Z Content type: article Language: en Sources: [Supabase Blog]() Topics: [PostgreSQL](), [SQL](), [Databases](), [Structured-data](), [Supabase]() Tags: [data](), [database](), [how-to](), [index](), [interview](), [modelling](), [performance](), [postgresql](), [schema](), [software-engineer](), [sql](), [technical]() ### AI overview A guide to preparing for PostgreSQL technical interviews, focusing on transactional SQL rather than analytical SQL. It covers relationship modeling, normalization, foreign keys, PostgreSQL data types such as JSONB, schemas, indexes, and query-plan analysis with EXPLAIN ANALYZE. ### Source excerpt Understand the top PostgreSQL Interview Questions ## Re-Introducing Hash Indexes in PostgreSQL DevFeed: [Re-Introducing Hash Indexes in PostgreSQL]() Original publisher: [Read original article]() Author: Haki Benita Published: 2021-01-10T22:00:00Z Content type: tutorial Language: en Sources: [Haki Benita]() Topics: [PostgreSQL](), [hash](), [Data structures](), [Databases]() Tags: [articles](), [data-structure](), [database](), [hash](), [index](), [indexes](), [performance](), [postgresql](), [sql]() ### AI overview This tutorial explains how PostgreSQL hash indexes work, including hash functions, buckets, tuple pointers, and collisions. It presents hash indexes as an option that can outperform B-Tree indexes under some circumstances. ### Source excerpt There is a type of index you are probably not using, and may have never even heard of. It is wildly unpopular, and until a few PostgreSQL versions ago it was highly discouraged and borderline unusable, but under some circumstances it can out-perform even a B-Tree index. ## Be Careful With CTE in PostgreSQL DevFeed: [Be Careful With CTE in PostgreSQL]() Original publisher: [Read original article]() Author: Haki Benita Published: 2018-09-16T21:00:00Z Content type: tutorial Language: en Sources: [Haki Benita]() Topics: [PostgreSQL](), [Database]() Tags: [articles](), [cache](), [cte](), [index](), [performance](), [postgresql](), [query](), [sql]() ### AI overview This tutorial explains how Common Table Expressions (CTEs) can hurt query performance in PostgreSQL versions 11 and earlier. It compares a direct query with a CTE, showing that CTE materialization can prevent predicate pushdown and index use, and discusses subqueries as an alternative. PostgreSQL 12 changed its treatment of CTEs to address these issues. ### Source excerpt Common table expressions, also known as the WITH clause, are a very useful feature. They help break down big queries into smaller pieces which makes it easier to read and understand. But, when used incorrectly they can cause a significant performance hit. ## Visualizing a column's space overhead using pg\_hexedit DevFeed: [Visualizing a column's space overhead using pg\_hexedit]() Original publisher: [Read original article]() Author: Peter Geoghegan (noreply@blogger.com) Published: 2018-05-18T23:11:00Z Content type: tutorial Language: en Sources: [Peter Geoghegan's blog]() Topics: [PostgreSQL](), [Optimization](), [Command-line interface](), [structure]() Tags: [command-line](), [index](), [indexes](), [internals](), [nbtree](), [optimization](), [overhead](), [pageinspect](), [pg-hexedit](), [postgresql](), [schema](), [storage]() ### AI overview The article describes a new pg_hexedit capability for annotating the space used by individual columns within PostgreSQL tuples in tables and B-Tree indexes. It explains how tuple metadata enables the feature and discusses how column ordering and types can reduce on-disk storage, particularly for large fact tables and machine-generated event data. ### Source excerpt pg_hexedit recently gained the ability to annotate the space taken up by each individual column/attribute within each individual tuple. This works with tables, and with B-Tree indexes. I had to come up with a way of passing the pg_hexedit frontend utility the relevant pg_attribute metadata to make this work. This metadata describes the "shape" of individual tuples in a relation (backend code uses a closely related structure called a "tuple descriptor"). My approach works seamlessly in simple cases, but can still be used when manually running the pg_hexedit command line tool. pg_attribute system catalog table with column annotations/tags This new capability could be applied to optimizing the data layout of a table that is expected to eventually have a massive number of rows. Carefully choosing the order and type of each column can reduce the total on-disk footprint of a table by an appreciable amount, especially when the final table ends up with several 1 byte columns that get packed together. I am aware of several PostgreSQL users that found it worthwhile to have a highly optimized tuple layout, going so far as to use their own custom dataypes. Alignment-aware micro-optimization of a Postgres client application's schema won't help much in most cases, but it can help noticeably with things like fact tables, or tables that contain machine-generated event data. Developing a sense of proportion around storage overhead should now be easier, and more intuitive. ## Kafka 的设计与实践思考 DevFeed: [Kafka 的设计与实践思考]() Original publisher: [Read original article]() Author: Joway Published: 2018-04-16T00:00:00Z Content type: tutorial Language: zh Sources: [Random Thoughts]() Topics: [Kafka](), [Replication](), [data]() Tags: [api](), [broker](), [data](), [file](), [index](), [kafka](), [leader](), [partition](), [replication](), [sync](), [tech](), [zookeeper]() ### AI overview A Chinese-language technical article presents a personal summary of Kafka's architecture, internal components, storage design, and APIs. It explains the roles of ZooKeeper, brokers, partitions, replication, leaders, ISR, offsets, segments, sparse indexes, and message access. ### Source excerpt 前几天看了 librdkafka 的官方文档，这篇文档不仅仅讲解了如何使用 Kafka ，某种程度也讲解了分布式系统实现的难点和使用细节，故而让我对 Kafka 的实现原理产生了浓厚的兴趣。 这篇文章从 Kafka 的设计到使用做了一些个人总结，围绕真正实践场景，探寻其设计上的智慧与妥协。 设计 架构设计 Zookeeper Zookeeper 存储了 Kafka 集群状态信息 。 Zookeeper 还负责从 Broker 中选举出一个机器作为 Controller, 并确保其唯一性。 同时, 当 Controller 宕机时, 再选举一个新的 。 ## Beacon Network at Index San Francisco 2018 DevFeed: [Beacon Network at Index San Francisco 2018]() Original publisher: [Read original article]() Published: 2018-02-28T11:19:42Z Content type: article Language: en Sources: [Miro Cupak]() Topics: [Bioinformatics](), [data](), [Protocol (disambiguation)](), [Network](), [Statistics](), [ibm]() Tags: [architecture](), [beacon](), [beacon-network](), [case-study](), [conference](), [data](), [developer](), [ibm](), [index](), [protocol](), [speaking](), [statistics](), [talk](), [talks](), [video]() ### AI overview A conference follow-up shares slides and a recording from a case-study talk about how DNAstack developed the Beacon Network, a global search engine for human genetic data, under the Global Alliance for Genomics & Health. ### Source excerpt In the previous post, we talked about one of the talks I gave at the Index Developer Conference last week. In this post, we share the materials from the other one, titled How we built a global search engine for genetic data. The session was scheduled in the Real-life production deployments track. Unlike the talks I usually... [Next page]()