[HN Gopher] The PlanetScale vectors public beta
___________________________________________________________________
The PlanetScale vectors public beta
Author : ksec
Score : 72 points
Date : 2024-10-22 16:06 UTC (6 hours ago)
(HTM) web link (planetscale.com)
(TXT) w3m dump (planetscale.com)
| alberth wrote:
| Given that PlanetScale only operates in a handful of AWS and
| Google regions, isn't the latency brutal for any customer not
| hosting in 1 of the ~12 datacenter PlanetScale is in.
| andkenneth wrote:
| At the enterprise level my understanding is that PlanetScale
| can operate within your environment directly instead of as a
| pure service.
| samlambert wrote:
| this is correct
| sgammon wrote:
| Awesome! Excited to play with this one.
| tanoku wrote:
| Hi! I'm one of the authors of this feature. It's something quite
| novel, because it's not just a HNSW plug-in for MySQL (like e.g.
| pgvector is for Postgres). It's a fully transactional index,
| integrated into InnoDB.
|
| We based the implementation on two very new papers from Microsoft
| Research, SPANN and SPFresh. SPANN is a hybrid graph/tree
| algorithm that does a fantastic job of scaling larger-than-RAM
| indexes (https://arxiv.org/abs/2111.08566) and SPFresh expands
| upon it by defining a set of background operations that can be
| performed to maintain the index's performance and recall while
| it's continuously updated in-place
| (https://arxiv.org/html/2410.14452v1). The novel thing here is
| designing all the SPANN _and_ SPFresh operations to be
| transactional, and integrating them in MySQL's default storage
| engine.
|
| This tight integration fundamentally means that inserting,
| updating and deleting vector data from MySQL is always reflected
| immediately in the index as part of committing your transaction.
| But it also means that the indexes are fully covered by the MySQL
| binlog; they recover from hard crashes just fine. They're also
| managed by MySQL's buffer pool, so they scale to terabytes of
| data, just like any other table. And also crucially, they're
| fully integrated with the query planner, so they can be used in
| any query, including JOINs and WHERE clauses (something that many
| other vector indexes really struggle with).
|
| We plan to release a whitepaper on our transactionality
| extensions to SPFresh, which I think will be super interesting,
| but meanwhile please feel free to test the beta and ask me any
| questions (here, or by emailing PlanetScale support). Thanks!
| sujayakar wrote:
| very cool stuff! I just read the SPFresh paper a few days ago
| and was wondering if it's been implemented in industry (e.g.
| Turbopuffer's implementation of SPANN).
|
| I'd be curious how y'all represent the posting lists for each
| partition in InnoDB:
|
| - what IDs are you storing in the posting lists?
|
| - how are the posting lists represented on disk? are they using
| compression and/or some form of skip indexing? the paper seemed
| to use a pretty simple block-based representation, but I'm
| curious what works well in practice.
|
| - how do the posting list data structures themselves handle
| incremental updates and MVCC?
| tanoku wrote:
| These are very relevant questions! Thank you!
|
| We're storing IDs from a ghost column that is created in the
| table where you're inserting vector data. This works very
| well in practice and allows updating the value of the vectors
| in the table, because they're translated into a delete +
| insert in the vector index by updating the ghost ID.
|
| We have abstracted away the quantization system from the
| index; for the initial release, vector data is stored in raw
| blocks, like in the paper. Query performance is good, but
| disk usage is high. We're actively testing different
| quantization algorithms to see which ones we end up offering
| on GA. We're hoping our beta users will help us guide this
| choice!
|
| Incremental updates and MVCC are _extremely tricky_, for both
| correctness and performance. As you've surely noticed, the
| hard thing here is that the original paper is very focused on
| LSM trees, because it exploits the fact that LSM trees get
| compacted lazily to perform incremental updates to the
| posting lists ('merges'). MySQL (and Postgres, and all
| relational databases, really) are B-tree based, and in-place
| updates for B-trees are expensive! I think we came up with
| very interesting workarounds for the problem, but it's a
| quite a bit to drill down in a HN comment. Please stay tuned
| for our whitepaper. :)
| sujayakar wrote:
| looking forward to it!
|
| I'd be curious if y'all end up supporting adding filter
| attributes to the inverted index that can then be pushed
| down into the posting list traversal.
|
| for example, a restaurant search app may have (1) an
| embedding for each restaurant but also (2) a cuisine. then,
| if a restaurant has `cuisine = Italian`, we'd also store
| its ghost ID in a `cuisine:Italian` posting list.
|
| at query time, the query planner could take a query like
| `SELECT * FROM t1 WHERE cuisine = 'Italian' ORDER BY
| DISTANCE(..)` and emit a plan that efficiently intersects
| the `cuisine:Italian` posting list with the union of the
| partitions' posting lists.
|
| this feels to me like a potential strength of the inverted
| indexing approach compared to graph-based approaches, which
| struggle with general filtering (e.g. the Filtered-DiskANN
| paper).
| trollied wrote:
| Since you're here - why decide to write something from scratch
| for mysql instead of using/improving postgres? Seems like a
| very strange decision. MySQL is a poor RDBMS in comparison.
| estebarb wrote:
| PlanetScale is built on Vitess. Vitess was created in 2010 to
| help scaling MySQL at Youtube.
| vvladymyrov wrote:
| Awesome. Does planetscale vector support multi node indices (like
| Milvus) and even further blob store index storage which can be
| separate from compute, allowing to pay for compute on demand when
| queries are run?
| tanoku wrote:
| Definitely yes to the first: the index implementation is fully
| integrated with PlanetScale's sharding layer, so you can scale
| horizontally as much as you need. This works very well in
| practice: the sharding layer, Vitess, is extremely well battle
| tested with petabyte-sized clusters in production, and our
| vector indexes are like any other table on the cluster, so it
| really scales horizontally with very predictable performance.
|
| As for separating storage and compute: we don't do that. One of
| our key sells here is that this is vector data fully integrated
| into your relational database with ACID semantics. Very hard to
| do separate storage and compute and keep this behavior!
| cholmon wrote:
| I'm very interested to see this alongside MySQL 9
| (https://dev.mysql.com/doc/refman/9.0/en/vector-
| functions.htm...), and MariaDB (https://mariadb.com/kb/en/vector-
| overview/).
|
| Will these converge on a common syntax for vector fields,
| indexes, and comparison functions in the near future? Or will
| vector implementations just add momentum to the increasing
| incompatibility in the MySQL-ish ecosystem?
| tanoku wrote:
| Our vector implementation is fully compatible with the syntax
| for vector fields and comparison functions in MySQL 9 -- we
| have carefully backported all the changes to our version of
| MySQL 8 to ensure full backwards and forwards compatibility.
| The index syntax is specific to PlanetScale because the open-
| source MySQL 9 preview does not yet have support for ANN
| indexes on vector columns, but we're committed to being as
| compatible as possible in the future and to minimize
| fragmentation. I do agree that fragmenting the ecosystem is not
| great!
| Temporary_31337 wrote:
| I work for another db vendor and we also have added vectors
| support. What's crazy is that customers were not really asking
| for- just surfing the hype wave like everyone else. Why would
| someone store vectors in an SQL db rather than a dedicated vector
| db with support for native graph / vector semantics?
| herval wrote:
| Are you asking why you did it?
___________________________________________________________________
(page generated 2024-10-22 23:00 UTC)