Yugabyte-db: Tell us if you're using YugabyteDB
Hello folks, please comment here if you or your org is using YugabyteDB.
Would love to hear about:
- What are you using YugabyteDB for?
- Why do you like it?
- Which company/project are you a part of?
rkarthik007
All 5 comments
What are you using YugaByte DB for?
A lot of our clients have been looking for high-performance distributed SQL solutions, as transactions handling at the application layer is messy and error-prone. YugaByte DB is a permanent in our recommendations and solution architectures.Why do you like it?
High feature velocity, community support, zero-fuss support resources (docs, engineering blog, etc.) to make informed decisions and get started with YugaByte DB. And of course, the battle-tested design choices from Spanner lineage, while being open source.Which company/project are you a part of?
Solutions Consultant @ Open Factory
khatribharat
on 21 Jun 2019
- What are you using YugaByte DB for?
We are using yugabyte with the YEDIS interface to store many small keys for a week at a time.
We expect around 500 Million small key/value pairs to be stored at any given time.
The workload is very write intensive. Reads are comparatively uncommon.
We have no need to store the keys for more than around 7 days. We had a simple use-case and wanted a solution that would just work well. I was surprised when I found yugabyte because it does so much but is actually incredibly easy to use.
- Why do you like it?
Yugabyte makes it easy to set a TTL on each key. I don't have to worry about coming back and cleaning up after myself. And the TTLs are handled efficiently. I don't see any big jump in CPU usage for them.
The concept of having only two processes, a master and 'tablet server' makes it really easy to set up. And it makes it play well with docker too, since docker only has one process to watch per container. Its exactly as docker was intended to be used. And startup time is short enough that kubernetis could move the proceses around without much issue. I come from a background working with Hadoop, where you have HDFS masters, hdfs data node processes, journal nodes, and zookeeper just to get the storage layer up. Then you have a bunch more complexity to get anything useful running on top of it. As far a data storage goes, its great having something that is so easy to set up but just as scalable. I'd love to play around with using yugabyte as storage for spark.
Yugabyte proved to be extremely fast for our workload. Testing showed we could expect write speeds for our workload at a little over 20,000 writes per second on a simple 8-core GCP VM with a 1.2TB standard disk and just 8GB of ram. This was not even an SSD and was tested before any tuning such as dedicated or multiple disks for yugabyte. This solution is so incredibly cost effective and easy to implement.
The auto sharding and rebalancing is also great. I know there won't be any issue scaling up if we ever need to. The YEDIS Interface even implements the redis cluster commands, allowing keys to go directly to the server where they belong when you use a client that supports redis cluster.
JackDavidson
on 25 Jun 2019
- What are you using YugaByte DB for?
We have several use cases for YugaByte, both very read and write intensive. We store complete copies of several blockchains (detailed information for all transactions) in YCQL schemas that are designed for very fast access. Write loads are on the order of hundreds of millions to billions per day. Additionally we store the analytics results for blockchain and other sourced data in YCQL. The write loads are anywhere from tens of millions to hundreds of millions per day.
Read loads for all of these tables can be very high, easily in the many hundreds of millions per day. Throughput remains high and even under heavy load query latency is low.
- Why do you like it?
Performance is awesome - much better than Cassandra (even with a smaller cluster). Always consistent access is a requirement for us so getting this while still maintaining excellent performance is, of course, fantastic. Additionally we find stability to be much better than Cassandra. Partition sizing is much less of a problem, new nodes can be brought in much faster and we no longer have issues with nodes randomly going down.
Add to that the excellent support (for both cluster maintenance and schema design) from the YugaByte team and what's not to love!
totalslacker
on 28 Jun 2019
What are you using YugaByte DB for?
Our product needs a workload with relational and non-relational data. The product is basically a document processor that generates a lot of information during data processing, classification, identification and extraction, and for that we use ScyllaDB. After this step we need consistent data and still have transaction, so we used PostgreSQL and recently CockRoachDB.
Yugabyte offers both of the models we need, with the advantage of "coming for free" with nonrelational transactions.
Why do you like it?
The big advantage will be CDC (Change Data Capture), we will keep in sync with ElasticSearch and Vespa (through Kafka) without efforts. (We even get out of sync a few times because of some maintenance that we forgot to sync with elastic - when we use spark for fix data per example).
Which company/project are you a part of?
Wisecapture from Klink (www.klink.ai)
fabiocmazzo
on 29 Aug 2019
What are you using YugaByte DB for?
Admiral is a visitor relationship management platform that helps publishers build better relationships through subscriptions, adblocking, membership, and more, to the right user, at the right time, with the right message, individualized for each unique user. Publishers can use Admiral to store personalized data, entitlements, and more, all of which are stored using YugaByte across multiple continents.
Why do you like it?
We ended up choosing YugaByte because it was the best option for achieving the global scalability and low latency requirements of our product. Additionally, we were already familiar with CQL and so transitioning to YugaByte was a much simpler process than learning a new query language from scratch.
Which company/project are you a part of?
I'm a Co-Founder at Admiral
jameshartig
on 12 Sep 2019
Related issues
lhotari
路
5Comments
hudclark
路
4Comments
ajcaldera1
路
4Comments
nocaway
路
3Comments
rahuldesirazu
路
3Comments
Most helpful comment
We are using yugabyte with the YEDIS interface to store many small keys for a week at a time.
We expect around 500 Million small key/value pairs to be stored at any given time.
The workload is very write intensive. Reads are comparatively uncommon.
We have no need to store the keys for more than around 7 days. We had a simple use-case and wanted a solution that would just work well. I was surprised when I found yugabyte because it does so much but is actually incredibly easy to use.
Yugabyte makes it easy to set a TTL on each key. I don't have to worry about coming back and cleaning up after myself. And the TTLs are handled efficiently. I don't see any big jump in CPU usage for them.
The concept of having only two processes, a master and 'tablet server' makes it really easy to set up. And it makes it play well with docker too, since docker only has one process to watch per container. Its exactly as docker was intended to be used. And startup time is short enough that kubernetis could move the proceses around without much issue. I come from a background working with Hadoop, where you have HDFS masters, hdfs data node processes, journal nodes, and zookeeper just to get the storage layer up. Then you have a bunch more complexity to get anything useful running on top of it. As far a data storage goes, its great having something that is so easy to set up but just as scalable. I'd love to play around with using yugabyte as storage for spark.
Yugabyte proved to be extremely fast for our workload. Testing showed we could expect write speeds for our workload at a little over 20,000 writes per second on a simple 8-core GCP VM with a 1.2TB standard disk and just 8GB of ram. This was not even an SSD and was tested before any tuning such as dedicated or multiple disks for yugabyte. This solution is so incredibly cost effective and easy to implement.
The auto sharding and rebalancing is also great. I know there won't be any issue scaling up if we ever need to. The YEDIS Interface even implements the redis cluster commands, allowing keys to go directly to the server where they belong when you use a client that supports redis cluster.