Yeah, more database solutions that's what we need. https://xkcd.com/927/
It actually is needed. It's a great enterprise-level timeseries-centric database.
Druid: fast column-oriented distributed data store
41–50 of 50 posts
Re: Druid: fast column-oriented distributed data store
#42Druid is quickly becoming the leading open source solution for building highly scalable analytics. We evaluated it for getstream.io. Unfortunately the setup and maintenance is still very labour intensive. For startups that's a concern. Many larger companies we spoke to were extremely happy about running Druid in production though.
No it isn't Elasticsearch and Redshift are.
That doesn't make any sense at all.
Re: Druid: fast column-oriented distributed data store
#43Earlier quoted context omitted.
Druid isn't even close to being the leading solution. The overwhelming majority of places doing big data analytics will be Hadoop/Spark using core HDFS. Then most places will augment this with a range of database solutions depending on how structured/clean the data is and the various workloads. Cassandra, HBase, MongoDB, Teradata, Oracle, ElasticSearch, Greenplum are all pretty common place in most enterprises. And o…
Druid's main value add to the data infrastructure space is around power user-facing data applications at scale. The queries it is best at are OLAP/business intelligence style queries. It isn't really designed to be a general processing tool such as Hadoop or Spark. The open source data space is very complex, and there are many different solutions targeted towards many different use cases. Druid is better than other s…
Your Wikipedia link to "stream processors" is for the wrong kind of stream processors. For a decades, the digital signal processing and graphics worlds have used the streaming abstraction to design programs and hardware. Their applications are typically expressed in pipelines, and do have to continually process data.
"Big data" stream processing is obviously related as its a dataflow programming model, but it's still very different in practice. The streaming abstraction is generally more free-form, and not realized directly in hardware. I contrast the two kinds of streaming in Section 2 of a paper from a few years ago: http://www.scott-a-s.com/files/pact2012.pdf
Re: Druid: fast column-oriented distributed data store
#44What's the advantage of a "column-oriented" data store/database?
Wikipedia is a good start: https://en.wikipedia.org/wiki/Column-oriented_DBMS The references section has good primary sources.
Re: Druid: fast column-oriented distributed data store
#45Our 2-man team set up Druid........ i took 5+ months and was excruciating to configure and get running smoothly (things were slightly more complicated because we decided to use docker). It also took ~30 servers to make a truly fault-tolerant setup. With that said, it works very well, but it definitely came at the cost of a good dose of sanity.
FWIW, Imply repackaged Druid in such a way that should make it much much easier to set up and evaluate. We've been porting our docs over to Druid for 0.9.0: http://imply.io/docs/latest/quickstart
There's also a production-ready docker distribution: https://hub.docker.com/r/imply/imply/
Re: Druid: fast column-oriented distributed data store
#46Has anyone done a meaningful private benchmark comparison with http://www.scylladb.com/ ? I didn't find one online.
It is a 100% different type of database. Druid is olap while scylladb is oltp. They have nothing in common (except for the "columnar" name)
Yes, but that doesn't mean you can't benchmark them anyway. And I think you could probably find some meaningful comparison. Certainly it would be more useful than the Druid whitepaper's benchmarks against MySQL. (I used to work on a DB project, we too had a benchmark against MySQL even though our DB was OLAP-focused.)
Re: Druid: fast column-oriented distributed data store
#47Earlier quoted context omitted.
Druid has a SparkSQL connector: https://github.com/SparklineData/spark-druid-olap
Cool! Yeah I poked around the druid site and didn't find anything originally, but this looks pretty promising. It's hard to tell how full-featured it is without getting hands-on, but I see something like this making Druid much more usable in a lot of analytics environments.
We have couple of companies running Tableau on top of this. The deployment is Tableau - Spark ThriftServer(with our extension) - Druid.
We push down Slice and Dice and Star Join Queries as Druid Queries; all of Spark SQL is supported with some portions of a Query Plan being executed in Spark. We are working on supporting more Spark UDFs being pushed to Druid, performance improvements, and more coverage for Tableau. Further down we will support Star Schemas where some or all dimensions are not indexed.
Happy to discuss specific SQL support or deployment questions. Please reach out to us.
- Harish.
Re: Druid: fast column-oriented distributed data store
#48Earlier quoted context omitted.
If one of these databases included a really good SparkSQL connector (including great predicate push-down), I could see that being hugely beneficial to growth. Part of why people are using these systems is because you can connect in many different types of data. Make your database part of that ecosystem and you can gradually take in more of the analytics workload without the users losing the ability to also throw in s…
Cassandra, MongoDB and ElasticSearch all have SparkSQL DataSource drivers with predicate pushdown support. Most of the limitations in that support is from the database itself and not from the driver. The biggest problems with SparkSQL is simply in its limited support for ANSI SQL. It's getting better with every release but not nearly quick enough.
I don't know the specific state of the DataSources you mention, but yes just providing a DataSource only is not enough; you can only push Filters and Projections to the underlying engine. You need to develop Query Rewrite Rules to rewrite Joins, Group Bys, Having, Limit etc to the underlying engine. For example our Rewrite engine for Druid is here: https://github.com/SparklineData/spark-druid-olap/blob/maste...
Can you be specific about ANSI SQL compliance requirements. Spark SQL is closing the gap on Hive SQL; both have decent support for analytical queries: Cubes/Rollups/Windowing etc. The only major gap between Spark and Hive SQL I know off is SubQuery predicates(exists/not exists).
Re: Druid: fast column-oriented distributed data store
#49Earlier quoted context omitted.
Second that experience: When I was at Optimizely, my team chose Druid for a large-scale analytics application, after a pretty extensive benchmarking. It was very impressive, though not trivial to set up. Blog post with a bit more detail: https://medium.com/engineers-optimizely/slicing-and-dicing-d...
I'm a bit surprised about forking the druid chef cookbook. From the blog post: > we were delighted to find an existing community cookbook, chef-druid, that can configure and deploy a druid cluster. However, that community cookbook hasn’t been updated for nearly a year and does not support the latest version of druid. We have therefore forked off our own version, optimizely/chef-druid, which supports the latest versio…
I wasn't involved in that specific implementation decision, so can't say.
Speculating personally, it was probably just something that happened for speed/ease - as opposed to trying to get an apparently abandoned repo rolling again.
We did make optimizely/chef-druid open and public though, and while I'm not with Optimizely any more, I'm sure the good folk there would be more than happy to merge back into the original repo if anyone was still maintaining it and wanted that to happen.
Re: Druid: fast column-oriented distributed data store
#50Earlier quoted context omitted.
It is a 100% different type of database. Druid is olap while scylladb is oltp. They have nothing in common (except for the "columnar" name)
Yes, but that doesn't mean you can't benchmark them anyway. And I think you could probably find some meaningful comparison. Certainly it would be more useful than the Druid whitepaper's benchmarks against MySQL . (I used to work on a DB project, we too had a benchmark against MySQL even though our DB was OLAP-focused.)
No they can't because scylladb can't do the stuff druid can (and vice-versa). While mysql can (even though it's a completely different way).