-
Notifications
You must be signed in to change notification settings - Fork 81
docs: update the readme to note Google provided integrations #173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -83,3 +83,25 @@ print(chat_history.messages) | |||||
### Vectorstore | ||||||
|
||||||
See example for the [PGVector vectorstore here](https://github.com/langchain-ai/langchain-postgres/blob/main/examples/vectorstore.ipynb) | ||||||
|
||||||
## Google Cloud Integrations | ||||||
|
||||||
[Google Cloud](https://python.langchain.com/docs/integrations/providers/google/) provides Vector Store, Chat Message History, and Data Loader integrations for [AlloyDB](https://cloud.google.com/alloydb) and [Cloud SQL](https://cloud.google.com/sql) for PostgreSQL databases via the following PyPi packages: | ||||||
|
||||||
* [`langchain-google-alloydb-pg`](https://github.com/googleapis/langchain-google-alloydb-pg-python) | ||||||
|
||||||
* [`langchain-google-cloud-sql-pg`](https://github.com/googleapis/langchain-google-cloud-sql-pg-python) | ||||||
|
||||||
Using the Google Cloud provided integrations provides the following benefits: | ||||||
|
||||||
- **Enhanced security**: Easily and securely connect to Google Cloud databases utilizing IAM for authorization and database authentication without needing to manage SSL certificates, configure firewall rules, or enable authorized networks. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Consider dropping marketing language from technical docs. (words like "easily" aren't great for technical docs)
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, I've revised it |
||||||
- **Simplified and Secure Connections:** Connect to Google Cloud databases effortlessly using the instance name instead of complex connection strings. The integrations creates a secure connection pool that can be easily shared across your application using the `engine` object. | ||||||
|
||||||
Learn how to [migrate a `PGVector` vector store to `AlloyDBVectorStore`](https://github.com/googleapis/langchain-google-alloydb-pg-python/blob/main/samples/migrations/migrate_pgvector_to_alloydb.md) to gain the following benefits: | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The marketing language is very strong here. I think it's fair to have a summary of which features are supported by each implementation. Right now, this is just reading as a recommendation to migrate off PGVector to alloydbvectorstore, which I don't think is appropriate. Perhaps a table listing in column the features, packages on the row, and information about whether the feature is supported or not? Is database agnostic filtering implemented? If not, could you specify that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've revised it into a tabular form, and yes db agnostic filtering has been implemented now (and mentioned in the table). |
||||||
|
||||||
- **Simplified management**: a single table contains data corresponding to a single collection, making it easier to query, update, and maintain. | ||||||
- **Schema flexibility**: allow users to add tables into any database schema. | ||||||
- **Improved performance**: using a single-table schema can lead to faster query execution, especially for large collections. | ||||||
- **Improved metadata handling**: store metadata in columns instead of JSON, resulting in significant performance improvements. | ||||||
- **Clear separation**: clearly separate table and extension creation, allowing for distinct permissions and streamlined workflows. | ||||||
- **Better integration with AlloyDB**: take advantage of AlloyDB's advanced indexing and scalability capabilities. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed