Comments (9)
Thanks for the answers :)
A use-case I had in mind was to have a scalable, multi-tenant database for web frontends.
Having separate storage from compute would allow scalability of stateless compute nodes (cozo), and let storage backends like foundationDB or tiKV handle the ACID concurrency stuff.
The advantage is bottomless scalability, and not being bottlenecked by single node I/O limits, at the cost of network latency.
from cozo.
The storage layer API rewrite is now complete. It works very well with other embedded engines such as SQLite, which opens up way to have Cozo running on mobile (compiling rocksdb for mobile is too much trouble, and the mobile version of rocksdb lacks critical features).
However, I'm not very positive about the performance when the backend is a distributed store. It works, sure, but our smoke tests complete in around 130 seconds under TiKV backend. After we did some obvious optimizations it went down to around 40 seconds, but going beyond that could take lots of work and may only yield meager returns. For comparison, with purely in-memory storage it completes about 0.6 seconds, with RocksDB backend about 0.8 seconds, and with SQLite backend about 1.2 seconds.
@docteurklein is 1 to 2 orders of magnitude decrease in performance acceptable for your use case? It certainly isn't for us, as we can pretty much forget about running most of the graph algorithms. Currently under distributed storage the only queries that can still run efficiently are simple point queries that yield small number of rows.
To regain performance under the distributed setting really requires a distributed and replicated KV store. Unfortunately there seems to be no suitable open source projects that we can just use, and writing one is significantly more work than this project, and is certainly outside the scope of this project.
from cozo.
@docteurklein It will be available with the next release, but it will be highly experimental (and untested).
from cozo.
Thank you for your interest!
In principle, yes, any KV store can be used as the storage layer. The only requirement is the ability
to store binary key-value pairs and to scan keys by bytes order (some of the ACID properties may have to be relaxed if the store does not have the required operations). We are currently refactoring in order to make an internal storage API available. When that is done, swapping should be trivial. We may even provide a ready-to-run distribution!
Would you mind describing your use case for a distributed store a little bit? And do you have any consistency/latency/throughput requirements? What is the maximum amount of data that a single query could touch for your use case?
from cozo.
Close this, as nothing more can be done at the moment.
from cozo.
Thanks for the feedback! Looks like shared-nothing architectures always win when it comes to perf.
I'd love to give tikv a spin anyway, did you publish the pluggable tikv backend?
from cozo.
It has been already several releases since @zh217 tried tikv as backend. @docteurklein did you find some time to try it yourself?
from cozo.
not yet because I would have to recompile cozo with the correct features.
from cozo.
@zh217 to do this properly (without the drop in performance), it would need some more abstract distribution right? Like replication & rebalancing based on usage? Seems unlikely it can be fast, ever, based on low level kv like that.
from cozo.
Related Issues (20)
- Feature request: be able to build queries directly in rust, bypassing the script parser HOT 2
- What is the params argument for in the C library? HOT 1
- RFC: `cozo-migrate`, a simple migrations library for cozo HOT 1
- FTS: Field `k` is required for HNSW search
- Vector search error HOT 1
- Cannot include `#` character in a "raw string" HOT 7
- numerically equal float and int display as the same in REPL HOT 1
- Cozodb as a vector store for llama index or langchain
- CRDT based CozoDB cross device sync
- Aggregation returns 0 rows HOT 3
- Record types HOT 4
- List methods don't work on Validity HOT 1
- Nested binding/matching
- cannot build cozo_c without -F graph-algo
- CRDT with Cozo HOT 1
- JSON object key order is lost
- Wrong fields being used on index HOT 1
- Binary embeddings support HOT 1
- Seems * can not be used in FTS ? HOT 1
- Update sqlite version to 3.45 +
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cozo.