Share your experience using YugabyteDB

I have experience in ClickHouse, and we also use Apache Druid, which has corporate support from Druid, along with data products in Hadoop. We are currently exploring many platforms such as GMI, TKI, and Vertex.

I use ClickHouse as a merchant side portal, especially when we started exploring how to use the data, which was coming from multiple sources such as logs, mainframe, Teradata, and many file systems that come to the data lake. The real-time challenge was joining the data and providing more analytical queries for our merchants, who work throughout the year to improve GMB, sales, and ensure the right quantity of items is ordered at the right time. That's the challenge for the merchants, and we aim for fast analytical queries on larger databases, which is why we selected ClickHouse as our columnar OLAP database supporting real-time analytics with its own SQL interface.

We have installed both local Docker versions, which are quite scalable, and usually connect with BI tools such as Grafana, Superset, and Tableau while utilizing materialized views, DDLs partitions, and many other connectors with Python, such as ClickHouse connectors and drivers. It's exciting to see how ClickHouse has evolved, and we are evaluating ClickHouse Cloud while also having the on-premises version.

We are already a customer of ClickHouse, with Sam's Club utilizing it on the merchant side while also exploring ClickHouse for consumers, primarily for user analytics, metrics, and streaming data analysis in ad tech. Additionally, we use custom analysis and metrics for fraud detection in payments and ad campaign metrics, with various teams utilizing it for ad campaign management and user behavior analytics, particularly on e-commerce sites focusing on customer behavior. It's extensively used due to its low latency, fast aggregations, and excellent OLAP columnar storage, featuring quick joins and real-time data visibility, making ClickHouse very appealing to us.

ClickHouse is very easy to use; one of the good features is that it has joins, which were not present in Druid, and Druid was quite expensive, especially with our applications at Sam's Club utilizing ClickHouse very quickly.

ClickHouse deserves a rating of 9 when compared to competitors, particularly Druid, which is stable but comes with higher costs and subpar support. ClickHouse proves to be more lightweight, offering low latency and high throughput, along with joins, making it especially good for log and metrics handling.

The basic challenge for ClickHouse is the documentation, which isn't ideal, but it's mature and stable with more columnar storage, compression, and parallel processing, making it the best for OLAP. In terms of improvements, it's not designed for very frequent small writes, making it less scalable in write-intensive workloads, and it's not flourishing in transactional use cases or when ingesting streaming data, such as batching or buffering, which is something ClickHouse will improve.

ClickHouse is quite stable, and it deserves a rating of 9.

ClickHouse deserves a scalability rating of 8 since it's quite scalable but has some room for improvement regarding scaling challenges.

The support team has its own community support on platforms such as Slack Overflow and ClickHouse Slack. Commercially, the company provides enterprise support, especially for Sam's Club through ClickHouse Cloud. We utilize AVN ClickHouse, which is effectively managed by AVN, providing bug fixes and developing new functionalities along with architecture reviews. I appreciate their 24/7 support which is beneficial, although those using open source might face some challenges. Overall, the enterprise support is quite good.

Positive

The initial setup for ClickHouse is relatively easier compared to Flink; however, for newcomers, it is quite challenging. I find it easier in terms of API with single-node setups through Yum or apt taking only a couple of minutes to install. Planning cluster setups is a bit complex, primarily an admin task, and while a single-node setup is easy, managing ClickHouse Cloud is extremely easy. Creating clusters can vary from moderate to difficult based on the scale, typically from 5 to 10 nodes, depending on the use case.

I would recommend this solution. Overall rating: 9 out of 10.

On-premises

Other

We are developing a trading agent that uses multiple machine learning models to adapt to the crypto market in real time. InfluxDB is used to collect data on crypto coin prices from exchanges like Binance and Bybit. Our use case requires low latency and the ability to query data effectively. We use InfluxDB on a DigitalOcean infrastructure in a containerized environment with Docker.

The most important feature for us is low latency, which is crucial in building a high-performance engine for day trading. InfluxDB can handle around ten thousand messages per second, which is essential for our requirements. The solution's ability to store time series data is also significant in our crypto trading use case where time series data about prices is critical.

One area for improvement is the querying language. InfluxDB deprecated FluxQL, which was intuitive since developers are already familiar with standard querying. Though we can adapt to the Flux language, I would like to see more development in this area and am unsure why FluxQL was deprecated.

We have been using InfluxDB for the last eight months.

We did not encounter any issues with the deployment. Using Kubernetes allowed us to easily set up InfluxDB in a containerized environment. Although DigitalOcean does not offer a managed database service, deploying our own container was straightforward and aligned with our continuous integration processes.

We have not experienced any stability issues with InfluxDB so far, and it has been acceptable for our needs.

Scalability has not been an issue because we have only used one instance of InfluxDB. It is primarily used for real-time data acquisition rather than for extensive scaling.

We have not needed to contact technical support. All resources required were available through documentation, enabling us to resolve any issues on our own.

Neutral

Previously, we used CassandraDB and ScyllaDB, a fork of CassandraDB. While these were performant, they did not store data in the time series format essential for our needs. Once we discovered that there were databases like InfluxDB designed for time series data, we decided to try it.

The initial setup was straightforward, as we used Kubernetes to deploy InfluxDB. Although DigitalOcean does not offer a managed database service for InfluxDB, setting up our own container was an easy process.

One person was responsible for the entire deployment of InfluxDB in our organization.

I have experience with CassandraDB and ScyllaDB as alternatives.

My advice for new users would be to ensure you are choosing the right engine for your domain. For InfluxDB, it performs well for low latency inputs and high-performance real-time data. While I would rate InfluxDB a ten on a scale of one to ten, users should be thoughtful about matching the engine to their specific needs.

Public Cloud

Other