Alternatives to KairosDB logo

Alternatives to KairosDB

InfluxDB, Cassandra, Graphite, OpenTSDB, and Prometheus are the most popular alternatives and competitors to KairosDB.
16
43
+ 1
5

What is KairosDB and what are its top alternatives?

KairosDB is a fast distributed scalable time series database written on top of Cassandra.
KairosDB is a tool in the Databases category of a tech stack.
KairosDB is an open source tool with 1.7K GitHub stars and 347 GitHub forks. Here’s a link to KairosDB's open source repository on GitHub

Top Alternatives to KairosDB

  • InfluxDB
    InfluxDB

    InfluxDB is a scalable datastore for metrics, events, and real-time analytics. It has a built-in HTTP API so you don't have to write any server side code to get up and running. InfluxDB is designed to be scalable, simple to install and manage, and fast to get data in and out. ...

  • Cassandra
    Cassandra

    Partitioning means that Cassandra can distribute your data across multiple machines in an application-transparent matter. Cassandra will automatically repartition as machines are added and removed from the cluster. Row store means that like relational databases, Cassandra organizes data by rows and columns. The Cassandra Query Language (CQL) is a close relative of SQL. ...

  • Graphite
    Graphite

    Graphite does two things: 1) Store numeric time-series data and 2) Render graphs of this data on demand ...

  • OpenTSDB
    OpenTSDB

    It is a distributed, scalable time series database to store, index & serve metrics collected from computer systems at a large scale. It can store and serve massive amounts of time series data without losing granularity. ...

  • Prometheus
    Prometheus

    Prometheus is a systems and service monitoring system. It collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if some condition is observed to be true. ...

  • Druid
    Druid

    Druid is a distributed, column-oriented, real-time analytics data store that is commonly used to power exploratory dashboards in multi-tenant environments. Druid excels as a data warehousing solution for fast aggregate queries on petabyte sized data sets. Druid supports a variety of flexible filters, exact calculations, approximate algorithms, and other useful calculations. ...

  • TimescaleDB
    TimescaleDB

    TimescaleDB: An open-source database built for analyzing time-series data with the power and convenience of SQL — on premise, at the edge, or in the cloud. ...

  • MySQL
    MySQL

    The MySQL software delivers a very fast, multi-threaded, multi-user, and robust SQL (Structured Query Language) database server. MySQL Server is intended for mission-critical, heavy-load production systems as well as for embedding into mass-deployed software. ...

KairosDB alternatives & related posts

InfluxDB logo

InfluxDB

961
1.1K
169
An open-source distributed time series database with no external dependencies
961
1.1K
+ 1
169
PROS OF INFLUXDB
  • 54
    Time-series data analysis
  • 30
    Easy setup, no dependencies
  • 24
    Fast, scalable & open source
  • 21
    Open source
  • 19
    Real-time analytics
  • 6
    Continuous Query support
  • 5
    Easy Query Language
  • 4
    HTTP API
  • 4
    Out-of-the-box, automatic Retention Policy
  • 1
    Offers Enterprise version
  • 1
    Free Open Source version
CONS OF INFLUXDB
  • 4
    Instability
  • 1
    HA or Clustering is only in paid version

related InfluxDB posts

Hi everyone. I'm trying to create my personal syslog monitoring.

  1. To get the logs, I have uncertainty to choose the way: 1.1 Use Logstash like a TCP server. 1.2 Implement a Go TCP server.

  2. To store and plot data. 2.1 Use Elasticsearch tools. 2.2 Use InfluxDB and Grafana.

I would like to know... Which is a cheaper and scalable solution?

Or even if there is a better way to do it.

See more
Cassandra logo

Cassandra

3.3K
3.3K
495
A partitioned row store. Rows are organized into tables with a required primary key.
3.3K
3.3K
+ 1
495
PROS OF CASSANDRA
  • 115
    Distributed
  • 96
    High performance
  • 80
    High availability
  • 74
    Easy scalability
  • 52
    Replication
  • 26
    Reliable
  • 26
    Multi datacenter deployments
  • 9
    OLTP
  • 7
    Open source
  • 7
    Schema optional
  • 2
    Workload separation (via MDC)
  • 1
    Fast
CONS OF CASSANDRA
  • 3
    Reliability of replication
  • 1
    Size
  • 1
    Updates

related Cassandra posts

Thierry Schellenbach
Shared insights
on
RedisRedisCassandraCassandraRocksDBRocksDB
at

1.0 of Stream leveraged Cassandra for storing the feed. Cassandra is a common choice for building feeds. Instagram, for instance started, out with Redis but eventually switched to Cassandra to handle their rapid usage growth. Cassandra can handle write heavy workloads very efficiently.

Cassandra is a great tool that allows you to scale write capacity simply by adding more nodes, though it is also very complex. This complexity made it hard to diagnose performance fluctuations. Even though we had years of experience with running Cassandra, it still felt like a bit of a black box. When building Stream 2.0 we decided to go for a different approach and build Keevo. Keevo is our in-house key-value store built upon RocksDB, gRPC and Raft.

RocksDB is a highly performant embeddable database library developed and maintained by Facebook’s data engineering team. RocksDB started as a fork of Google’s LevelDB that introduced several performance improvements for SSD. Nowadays RocksDB is a project on its own and is under active development. It is written in C++ and it’s fast. Have a look at how this benchmark handles 7 million QPS. In terms of technology it’s much more simple than Cassandra.

This translates into reduced maintenance overhead, improved performance and, most importantly, more consistent performance. It’s interesting to note that LinkedIn also uses RocksDB for their feed.

#InMemoryDatabases #DataStores #Databases

See more
Umair Iftikhar
Technical Architect at ERP Studio · | 3 upvotes · 269.2K views

Developing a solution that collects Telemetry Data from different devices, nearly 1000 devices minimum and maximum 12000. Each device is sending 2 packets in 1 second. This is time-series data, and this data definition and different reports are saved on PostgreSQL. Like Building information, maintenance records, etc. I want to know about the best solution. This data is required for Math and ML to run different algorithms. Also, data is raw without definitions and information stored in PostgreSQL. Initially, I went with TimescaleDB due to PostgreSQL support, but to increase in sites, I started facing many issues with timescale DB in terms of flexibility of storing data.

My major requirement is also the replication of the database for reporting and different purposes. You may also suggest other options other than Druid and Cassandra. But an open source solution is appreciated.

See more
Graphite logo

Graphite

380
405
42
A highly scalable real-time graphing system
380
405
+ 1
42
PROS OF GRAPHITE
  • 16
    Render any graph
  • 9
    Great functions to apply on timeseries
  • 8
    Well supported integrations
  • 6
    Includes event tracking
  • 3
    Rolling aggregation makes storage managable
CONS OF GRAPHITE
    Be the first to leave a con

    related Graphite posts

    Conor Myhrvold
    Tech Brand Mgr, Office of CTO at Uber · | 15 upvotes · 3.2M views

    Why we spent several years building an open source, large-scale metrics alerting system, M3, built for Prometheus:

    By late 2014, all services, infrastructure, and servers at Uber emitted metrics to a Graphite stack that stored them using the Whisper file format in a sharded Carbon cluster. We used Grafana for dashboarding and Nagios for alerting, issuing Graphite threshold checks via source-controlled scripts. While this worked for a while, expanding the Carbon cluster required a manual resharding process and, due to lack of replication, any single node’s disk failure caused permanent loss of its associated metrics. In short, this solution was not able to meet our needs as the company continued to grow.

    To ensure the scalability of Uber’s metrics backend, we decided to build out a system that provided fault tolerant metrics ingestion, storage, and querying as a managed platform...

    https://eng.uber.com/m3/

    (GitHub : https://github.com/m3db/m3)

    See more

    A huge part of our continuous deployment practices is to have granular alerting and monitoring across the platform. To do this, we run Sentry on-premise, inside our VPCs, for our event alerting, and we run an awesome observability and monitoring system consisting of StatsD, Graphite and Grafana. We have dashboards using this system to monitor our core subsystems so that we can know the health of any given subsystem at any moment. This system ties into our PagerDuty rotation, as well as alerts from some of our Amazon CloudWatch alarms (we’re looking to migrate all of these to our internal monitoring system soon).

    See more
    OpenTSDB logo

    OpenTSDB

    30
    61
    0
    A scalable time series database
    30
    61
    + 1
    0
    PROS OF OPENTSDB
      Be the first to leave a pro
      CONS OF OPENTSDB
        Be the first to leave a con

        related OpenTSDB posts

        Prometheus logo

        Prometheus

        3.2K
        3.4K
        239
        An open-source service monitoring system and time series database, developed by SoundCloud
        3.2K
        3.4K
        + 1
        239
        PROS OF PROMETHEUS
        • 47
          Powerful easy to use monitoring
        • 38
          Flexible query language
        • 32
          Dimensional data model
        • 27
          Alerts
        • 23
          Active and responsive community
        • 22
          Extensive integrations
        • 19
          Easy to setup
        • 12
          Beautiful Model and Query language
        • 7
          Easy to extend
        • 6
          Nice
        • 3
          Written in Go
        • 2
          Good for experimentation
        • 1
          Easy for monitoring
        CONS OF PROMETHEUS
        • 12
          Just for metrics
        • 6
          Bad UI
        • 6
          Needs monitoring to access metrics endpoints
        • 4
          Not easy to configure and use
        • 3
          Supports only active agents
        • 2
          Written in Go
        • 2
          TLS is quite difficult to understand
        • 2
          Requires multiple applications and tools
        • 1
          Single point of failure

        related Prometheus posts

        Conor Myhrvold
        Tech Brand Mgr, Office of CTO at Uber · | 15 upvotes · 3.2M views

        Why we spent several years building an open source, large-scale metrics alerting system, M3, built for Prometheus:

        By late 2014, all services, infrastructure, and servers at Uber emitted metrics to a Graphite stack that stored them using the Whisper file format in a sharded Carbon cluster. We used Grafana for dashboarding and Nagios for alerting, issuing Graphite threshold checks via source-controlled scripts. While this worked for a while, expanding the Carbon cluster required a manual resharding process and, due to lack of replication, any single node’s disk failure caused permanent loss of its associated metrics. In short, this solution was not able to meet our needs as the company continued to grow.

        To ensure the scalability of Uber’s metrics backend, we decided to build out a system that provided fault tolerant metrics ingestion, storage, and querying as a managed platform...

        https://eng.uber.com/m3/

        (GitHub : https://github.com/m3db/m3)

        See more
        Matt Menzenski
        Senior Software Engineering Manager at PayIt · | 15 upvotes · 286.9K views

        Grafana and Prometheus together, running on Kubernetes , is a powerful combination. These tools are cloud-native and offer a large community and easy integrations. At PayIt we're using exporting Java application metrics using a Dropwizard metrics exporter, and our Node.js services now use the prom-client npm library to serve metrics.

        See more
        Druid logo

        Druid

        349
        782
        30
        Fast column-oriented distributed data store
        349
        782
        + 1
        30
        PROS OF DRUID
        • 14
          Real Time Aggregations
        • 6
          Batch and Real-Time Ingestion
        • 4
          OLAP
        • 3
          OLAP + OLTP
        • 2
          Combining stream and historical analytics
        • 1
          OLTP
        CONS OF DRUID
        • 3
          Limited sql support
        • 2
          Joins are not supported well
        • 1
          Complexity

        related Druid posts

        Umair Iftikhar
        Technical Architect at ERP Studio · | 3 upvotes · 269.2K views

        Developing a solution that collects Telemetry Data from different devices, nearly 1000 devices minimum and maximum 12000. Each device is sending 2 packets in 1 second. This is time-series data, and this data definition and different reports are saved on PostgreSQL. Like Building information, maintenance records, etc. I want to know about the best solution. This data is required for Math and ML to run different algorithms. Also, data is raw without definitions and information stored in PostgreSQL. Initially, I went with TimescaleDB due to PostgreSQL support, but to increase in sites, I started facing many issues with timescale DB in terms of flexibility of storing data.

        My major requirement is also the replication of the database for reporting and different purposes. You may also suggest other options other than Druid and Cassandra. But an open source solution is appreciated.

        See more
        TimescaleDB logo

        TimescaleDB

        182
        316
        41
        Scalable and reliable time-series SQL database optimized for fast ingest and complex queries. Built on PostgreSQL.
        182
        316
        + 1
        41
        PROS OF TIMESCALEDB
        • 8
          Open source
        • 7
          Easy Query Language
        • 6
          Time-series data analysis
        • 5
          Established postgresql API and support
        • 4
          Reliable
        • 2
          Chunk-based compression
        • 2
          Postgres integration
        • 2
          Paid support for automatic Retention Policy
        • 2
          Fast and scalable
        • 2
          High-performance
        • 1
          Case studies
        CONS OF TIMESCALEDB
        • 5
          Licensing issues when running on managed databases

        related TimescaleDB posts

        John Kodumal

        As we've evolved or added additional infrastructure to our stack, we've biased towards managed services. Most new backing stores are Amazon RDS instances now. We do use self-managed PostgreSQL with TimescaleDB for time-series data—this is made HA with the use of Patroni and Consul.

        We also use managed Amazon ElastiCache instances instead of spinning up Amazon EC2 instances to run Redis workloads, as well as shifting to Amazon Kinesis instead of Kafka.

        See more

        Hi, I need advice on which Database tool to use in the following scenario:

        I work with Cesium, and I need to save and load CZML snapshot and update objects for a recording program that saves files containing several entities (along with the time of the snapshot or update). I need to be able to easily load the files according to the corresponding timeline point (for example, if the update was recorded at 13:15, I should be able to easily load the update file when I click on the 13:15 point on the timeline). I should also be able to make geo-queries relatively easily.

        I am currently thinking about Elasticsearch or PostgreSQL, but I am open to suggestions. I tried looking into Time Series Databases like TimescaleDB but found that it is unnecessarily powerful than my needs since the update time is a simple variable.

        Thanks for your advice in advance!

        See more
        MySQL logo

        MySQL

        103.1K
        85.4K
        3.7K
        The world's most popular open source database
        103.1K
        85.4K
        + 1
        3.7K
        PROS OF MYSQL
        • 796
          Sql
        • 675
          Free
        • 557
          Easy
        • 527
          Widely used
        • 487
          Open source
        • 180
          High availability
        • 160
          Cross-platform support
        • 104
          Great community
        • 78
          Secure
        • 75
          Full-text indexing and searching
        • 25
          Fast, open, available
        • 15
          SSL support
        • 14
          Reliable
        • 13
          Robust
        • 8
          Enterprise Version
        • 7
          Easy to set up on all platforms
        • 2
          NoSQL access to JSON data type
        • 1
          Relational database
        • 1
          Easy, light, scalable
        • 1
          Sequel Pro (best SQL GUI)
        • 1
          Replica Support
        CONS OF MYSQL
        • 15
          Owned by a company with their own agenda
        • 2
          Can't roll back schema changes

        related MySQL posts

        Tim Abbott

        We've been using PostgreSQL since the very early days of Zulip, but we actually didn't use it from the beginning. Zulip started out as a MySQL project back in 2012, because we'd heard it was a good choice for a startup with a wide community. However, we found that even though we were using the Django ORM for most of our database access, we spent a lot of time fighting with MySQL. Issues ranged from bad collation defaults, to bad query plans which required a lot of manual query tweaks.

        We ended up getting so frustrated that we tried out PostgresQL, and the results were fantastic. We didn't have to do any real customization (just some tuning settings for how big a server we had), and all of our most important queries were faster out of the box. As a result, we were able to delete a bunch of custom queries escaping the ORM that we'd written to make the MySQL query planner happy (because postgres just did the right thing automatically).

        And then after that, we've just gotten a ton of value out of postgres. We use its excellent built-in full-text search, which has helped us avoid needing to bring in a tool like Elasticsearch, and we've really enjoyed features like its partial indexes, which saved us a lot of work adding unnecessary extra tables to get good performance for things like our "unread messages" and "starred messages" indexes.

        I can't recommend it highly enough.

        See more
        Conor Myhrvold
        Tech Brand Mgr, Office of CTO at Uber · | 22 upvotes · 1.3M views

        Our most popular (& controversial!) article to date on the Uber Engineering blog in 3+ yrs. Why we moved from PostgreSQL to MySQL. In essence, it was due to a variety of limitations of Postgres at the time. Fun fact -- earlier in Uber's history we'd actually moved from MySQL to Postgres before switching back for good, & though we published the article in Summer 2016 we haven't looked back since:

        The early architecture of Uber consisted of a monolithic backend application written in Python that used Postgres for data persistence. Since that time, the architecture of Uber has changed significantly, to a model of microservices and new data platforms. Specifically, in many of the cases where we previously used Postgres, we now use Schemaless, a novel database sharding layer built on top of MySQL (https://eng.uber.com/schemaless-part-one/). In this article, we’ll explore some of the drawbacks we found with Postgres and explain the decision to build Schemaless and other backend services on top of MySQL:

        https://eng.uber.com/mysql-migration/

        See more