[HN Gopher] ClickHouse, Inc.
___________________________________________________________________
ClickHouse, Inc.
Author : zX41ZdbW
Score : 318 points
Date : 2021-09-20 16:13 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| whitepoplar wrote:
| Haven't used any of these yet, but how does ClickHouse compare to
| Postgres extensions like TimescaleDB and Citus (which recently
| launched a columnar feature)? I remember reading in the
| ClickHouse docs some time ago that it does not have DELETE
| functionality. Does this pose any problems with GDPR and data
| deletion requests?
| zX41ZdbW wrote:
| There are many independent comparisons of ClickHouse vs
| TimescaleDB:
|
| By Splitbee:
| https://github.com/ClickHouse/ClickHouse/issues/22398#issuec...
| By GitLab:
| https://github.com/ClickHouse/ClickHouse/issues/22398#issuec...
| And others:
| https://github.com/ClickHouse/ClickHouse/issues/22398#issuec...
| https://github.com/ClickHouse/ClickHouse/issues/22398#issuec...
|
| If you'll find more, please post it there.
|
| TimescaleDB can work pretty fine in time series scenario but
| does not shine on analytical queries. For most of time series
| queries, it is below ClickHouse in terms of performance but for
| small (point) queries it can be better.
|
| The main advantage of TimescaleDB is that it better integrates
| with Postgres (for obvious reasons).
|
| There are also many comparisons of ClickHouse vs Citus. The
| most notable is here: https://blog.cloudflare.com/http-
| analytics-for-6m-requests-p...
|
| ClickHouse can do batch DELETE operations for data cleanup.
| https://clickhouse.com/docs/en/sql-reference/statements/alte...
| It is not for frequent single-record deletions, but it can
| fulfill the needs for data cleanup, retention, GDPR
| requirements.
|
| Also you can tune TTL rules in ClickHouse, per table or per
| columns (say, replace all IP addresses to zero after three
| months).
| ryanbooz wrote:
| [Timescale DevRel here]
|
| @zX41ZdbW@ - Thanks for pointing out the various benchmarks
| that have been run by other companies between Clickhouse and
| TimescaleDB using TSBS[1]. As we mentioned, we'll dig deeper
| into a similar benchmark with much more detail than any of
| those examples in an upcoming blog post.
|
| One notable omission on all of the benchmarks that we've seen
| is that none of them enable TimescaleDB compression (which
| also transforms row-oriented data into a columnar-type
| format). In our detailed benchmarking, queries on compressed
| columnar data in Timescale outperformed Clickhouse in most
| queries, particularly as cardinality increases, often by 5x
| or more. And with compression of 90% or more, storage is
| often comparable. (Again, blog post coming soon - we are just
| making sure our results are accurate before rushing to
| publish.)
|
| The beauty of TimescaleDB columnar compression model is that
| it allows the user to decide when their workload can benefit
| from deep/narrow queries of data that doesn't change often
| (although it can still be modified just like regular row
| data), verses shallow/wide queries for things like inserting
| data and near-time queries.
|
| It's a hybrid model that provides a lot of flexibility for
| users AND significantly improves the performance of
| historical queries. So yes, we do agree that columnar storage
| is a huge performance win for many types of queries.
|
| And of course, with TimescaleDB, one also gets all of the
| benefits of PostgreSQL and its vibrant ecosystem.
|
| Can't wait to share the details in the coming weeks!
|
| [1]: https://github.com/timescale/tsbs
| xdanger wrote:
| _(although it can still be modified just like regular row
| data)_
|
| But it can't be updated or deleted, so what do you mean by
| this?
| stavros wrote:
| I have a related question, in case anyone knows: We want to
| store typical analytics data _somewhere_ (currently in
| BigQuery) to analyze with Looker. Things like "CI run
| started", "CI run finished" and then calculate analytics
| over average CI runtimes.
|
| Which database would be a good fit for this? There isn't
| too much data, maybe tens of thousands of rows eventually.
| Would Timescale be a good fit? I'd prefer that, due to
| existing familiarity with Postgres, but if ClickHouse is
| better, that's good too.
| zX41ZdbW wrote:
| Thank you! Looking forward for a blog post. We need more
| references for comparison to optimize ClickHouse
| performance.
| lima wrote:
| > I remember reading in the ClickHouse docs some time ago that
| it does not have DELETE functionality. Does this pose any
| problems with GDPR and data deletion requests?
|
| Clickhouse has ALTER ... DELETE and ALTER ... UPDATE
| functionality now! (and TTLs)
| didip wrote:
| ClickHouse competes with OLAP storages like Druid or Pinot.
|
| I don't know about ClickHouse but the other 2 uses bitmap
| indexes to make storing petabytes of data affordable.
|
| Row oriented databases would struggle to compete against
| ClickHouse. They are easily an order of magnitude slower.
| hodgesrm wrote:
| ClickHouse uses skip indexes. They basically answer the
| question "is the value I'm seeking not in the block."
|
| For example, there are a couple varieties of Bloom filters,
| which allow you to test for presence of string sequences in
| blocks. This allows ClickHouse to skip reading and
| uncompressing blocks (actually called granules)
| unnecessarily.
| ericb wrote:
| ClickHouse wins on licensing--Apache.
|
| The TimeScale licensing approach, the way it is written,
| perhaps accidentally, has lots of hidden landmines. The
| TimeScale license slants toward cloud giant defense to the
| extent that normal use is perilous.
|
| For example, timescale can be used for normal data (postgres)
| as well, so any rules seem to apply to all your data in the
| database. The free license only usable available if:
|
| the customer is prohibited, either contractually or
| technically, from defining, redefining, or modifying the
| database schema or other structural aspects of database
| objects, such as through use of the Timescale Data Definition
| Interfaces, in a Timescale Database utilized by such Value
| Added Products or Services.
|
| My read is that if you let a customer do anything that adds a
| custom field, or table, or database, or trigger, or anything
| that is "structural" (even in the regular relational stuff)
| anywhere in your database (metrics or not), you are in
| violation. There doesn't seem to be a distinction about whether
| this is "direct" control or not, or whether a setting
| indirectly adds a trigger. I don't want to be in a courtroom
| debating whether a new metric is a "structural change!"
|
| Now, none of that might be the _intent_ of the license, but you
| have to go by what it says, not intentions.
|
| The sad part of that is, I, and I'm sure many folks, have no
| interest in starting a database company, but we can't rally
| timescale because of legal risk. Looks awesome otherwise,
| though.
| akulkarni wrote:
| [Timescale co-founder here]
|
| Hi Eric, thanks for taking a close look at our license.
|
| I'd like to dispel some misconceptions:
|
| The core of TimescaleDB is Apache2. Advanced features are
| under the Timescale License.
|
| Regarding this: the customer is prohibited,
| either contractually or technically, from defining,
| redefining, or modifying the database schema or other
| structural aspects of database objects, such as through use
| of the Timescale Data Definition Interfaces, in a Timescale
| Database utilized by such Value Added Products or Services.
| My read is that if you let a customer do anything that adds a
| custom field, or table, or database, or trigger, or anything
| that is "structural" (even in the regular relational stuff)
| anywhere in your database (metrics or not), you are in
| violation. There doesn't seem to be a distinction about
| whether this is "direct" control or not, or whether a setting
| indirectly adds a trigger. I don't want to be in a courtroom
| debating whether a new metric is a "structural change!"
|
| That's not correct, and we took pains to clarify that in the
| license: 3.5 "Timescale Data Definition
| Interfaces" means SQL commands and other interfaces of the
| Timescale Software that can be used to define or modify the
| database schema and other structural aspects of database
| objects in a Timescale Database, including Data Definition
| Language (DDL) commands such as CREATE, DROP, ALTER,
| TRUNCATE, COMMENT, and RENAME. [0]
|
| Strictly speaking, if you provide Data Definition Interfaces
| (DDL) to customers via a SaaS service (ie you are running a
| TimescaleDBaaS - which applies to < 0.000001% of all possible
| users) you are in violation of the license. But otherwise you
| are fine.
|
| If you are looking for more votes of confidence, today there
| are literally millions of active TimescaleDB instances,
| including by large companies like Walmart, Comcast, IBM,
| Cisco, Electronic Arts, Bosch, Samsung, and many many smaller
| ones. [2]
|
| If you have any other questions, I'm happy to answer them
| here, or offline (ajay at timescale dot com).
|
| [1] https://www.timescale.com/legal/licenses#section-3-5-time
| sca...
|
| [2] https://www.timescale.com/
| ericb wrote:
| Are you sure?
|
| The phrasing "such as" in " _such as_ through use of the
| Timescale Data Definition Interfaces " looks to me like it
| can be interpreted as saying "Including but not limited to"
| akulkarni wrote:
| Yes :-)
|
| It was a little cumbersome to list every DDL SQL command,
| which why it uses that language. But that is the intent.
|
| If you have a specific question, happy to answer it here
| (or offline)
|
| Also, we used this language deliberately to provide more
| clarity. DDL vs DML is a pretty clear line to most
| developers who use TimescaleDB (vs some other companies
| who use language like, "you can't compete with us" etc).
| ericb wrote:
| Right, I'm onboard with your stated intent, and the
| lovely database, and even sympathetic on the cloud
| provider threat.
|
| My interpretation doesn't hinge on the DDL/DML question.
| If what you said is your intent, the legal language used
| is wrong and you should fix it. Consider this a bug
| report. Here's a source!
|
| https://www.law.cornell.edu/definitions/uscode.php?width=
| 840...
|
| In order for the license to be usable, you need to be
| _limitative_ here.
| akulkarni wrote:
| Thanks for the feedback, will pass along :-)
| mst wrote:
| The issue isn't the DDL vs. DML.
|
| The issue is the 'such as', which reads to me as
| indicating that providing an API endpoint that can add
| fields would also be a way of letting the customer modify
| the database schema and therefore covered.
|
| Which means that building a SaaS app backed by timescale
| that has any level of customisation exposed to the user
| appears to be prohibited.
|
| This seems a rather stronger level of prohibition than
| stopping people directly competing with you, and would
| suggest that if it's intended it would help to make it
| more explicit, and if it isn't then an explicit statement
| of that would be worth adding.
| akulkarni wrote:
| Practically speaking, there are already 1000s+ SaaS apps
| built on TimescaleDB (and using the Timescale License
| features)
|
| But I appreciate the feedback on how we could make our
| language clearer. Will share with the team!
| shadowwolf007 wrote:
| So this is a very relevant question and I have been trying
| to figure out if I need to migrate off timescaledb asap
| coincidentally over the last 2 weeks (We're pre-production
| anyway, so it's the time to do so!). Doing so has been
| super low priority, but since you're here .... :)
|
| If I have a table that records timeseries data and then
| another table that has a customer-provided extensible set
| of metadata where a customer can define columns and other
| related tabular data, would that violate the license? The
| customer doesn't have a direct, like, psql level of access
| but the API intentionally provides a very similar level of
| interaction.
|
| Does this qualify as providing Data Definition Interfaces?
| If none of those additional columns and such appear on
| tables set up as timescale tables does that make any
| difference?
| mfreed wrote:
| One clarification to the above discussion -- about
| whether these restrictions also get applied to "even the
| regular relational stuff" -- which I think is relevant to
| you (and parent):
|
| The Timescale License only covers the TimescaleDB code.
| Postgres code continues to be covered by the OSS
| PostgreSQL License [0].
|
| So putting aside the question about API vs. psql level
| (again, the Timescale License was drafted to enabled this
| for "Value Added Services", e.g., where "such value-added
| products or services are not primarily database storage
| or operations products or services"), this license
| wouldn't apply for non-Timescale code.
|
| [Timescale co-founder here]
|
| [0] https://github.com/timescale/timescaledb/blob/master/
| NOTICE
| shadowwolf007 wrote:
| Ok thank you!
|
| I appreciate from your POV this probably is silly but for
| us it's very helpful to have explicit clarity since
| investors are questioning and demand certainty. I once
| had to rewrite https handshakes because a lawyer thought
| export compliance laws would be violated, so hopefully
| you understand my trepidation :-)
| ericb wrote:
| Not the parent, but great to hear that clarification! By
| the way, doubt I would complain if Prometheus didn't look
| impressive. :-)
|
| One other bug report on the license language front, this
| language could be construed to prohibit uses like
| Prometheus--unless there's a definition of operations
| products I missed (possible).
|
| > are not primarily database storage or _operations
| products_
|
| Suggested edit:
|
| > are not primarily database storage or * _database
| operations products*_
| goodpoint wrote:
| > ClickHouse wins on licensing--Apache
|
| How so? An end user should prefer a database under a license
| that protect the developer and users from
| cloudification/proprietization/SaaS
| goodpoint wrote:
| On top of that, Yandex requires a very aggressive CLA to be
| signed by contributors:
| https://yandex.ru/legal/cla/?lang=en
|
| This worries me and makes me wonder if they are going for
| the open-source-only-by-name model.
|
| [Please reply instead of giving silent dowvotes.]
| zX41ZdbW wrote:
| We don't require Yandex CLA:
|
| > As an alternative, you can provide DCO instead of CLA.
| You can find the text of DCO here:
| https://developercertificate.org/ It is enough to read
| and copy it verbatim to your pull request.
|
| > If you don't agree with the CLA and don't want to
| provide DCO, you still can open a pull request to provide
| your contributions.
|
| https://github.com/ClickHouse/ClickHouse/blob/master/CONT
| RIB...
|
| Anyway, Yandex CLA will be removed in the upcoming days
| (it should be already removed).
| ryanbooz wrote:
| (Timescale DevRel here)
|
| We've recently been working through a detailed benchmark of
| TimescaleDB and Clickhouse. The DELETE/UPDATE question has been
| an intriguing story to follow - and I honestly hadn't
| considered the GDPR angle.
|
| ATM, Clickhouse is still OLAP focused and their MergeTree
| implementation does not allow direct DELETE (or UPDATE) of any
| data. All DELETE/UPDATE requests are applied asynchronously by
| (essentially) re-writing/merging the table data (it's referred
| to as a "mutation") without whatever data was referenced in the
| DELETE/UPDATE. [1]
|
| [1]: https://clickhouse.com/docs/en/sql-
| reference/statements/alte...
| kwillets wrote:
| This question is becoming critical right now, as
| nonrecoverable deletes are required within 30 days for both
| GDPR and CCPA.
|
| Most products do the asynchronous rewrite, especially if
| they're based on immutable storage. That's fine, but it
| should be tested to verify that it's not triggering on every
| delete, for example, and that it's resource-efficient.
| nezirus wrote:
| You are correct, the proper way to do deletions in ClickHouse
| is to use partitions, and drop partitions. That is probably
| good enough for most analytical use cases, but YMMV.
| hkolk wrote:
| We are using Clickhouse combined with GDPR's Data Deletion
| Requests. We store the user-ids in a separate system, and run
| the ALTER/DELETE statements once per week. Works pretty
| smooth, though I would prefer some more automation within
| Clickhouse for them.
|
| Data for in-active users gets deleted because our clickhouse
| retention policy is lower than the in-active-user timeout
| [deleted]
| stingraycharles wrote:
| In a nutshell, my extremely subjective and biased take on it:
|
| * Citus has a great clustering story, and a small data
| warehousing story, afaik no timeseries story;
|
| * TimescaleDB has a great timeseries story, and an average data
| warehousing story;
|
| * Clickhouse has a great data warehousing story, an average
| timeseries story, and a bit meh clustering story (YMMV).
|
| (Disclaimer: I work for a competitor)
| akulkarni wrote:
| [Timescale co-founder]
|
| This is a really great comparison. I might borrow it in the
| future :-)
|
| But yes, if you have classic OLAP-style queries (e.g.,
| queries that need to touch every database row), Clickhouse is
| likely the better option.
|
| For anything time-series related, and/or if you like/love
| Postgres, that is where TimescaleDB shines. (But please make
| sure you turn on compression!)
|
| TimescaleDB also has a good clustering story, which is also
| improving over time. [0][1]
|
| [0] https://news.ycombinator.com/item?id=23272992
|
| [1] https://news.ycombinator.com/item?id=24931994
| mromanuk wrote:
| I like how you always chime in with time series stuff. Just
| by watching you interact here, boost my confidence on your
| product
| zX41ZdbW wrote:
| > Disclaimer: I work for a competitor
|
| What competitor btw? I tried to open a link from your profile
| but it does not work.
| arthurcolle wrote:
| It appears the competitor is QuasarDB
| stingraycharles wrote:
| Excellent comment archeology, this is correct. :)
| arthurcolle wrote:
| actually grabbed it from Keybase -> Googled name ->
| LinkedIn :)
| fiddlerwoaroof wrote:
| I benchmarked ClickHouse vs. Timescale, Citus, Greenplum and
| Elasticsearch for a real-time analytics application. With a
| couple hours learning for each (although I've used Postgres
| extensively and so Postgres-backed databases had a bit of an
| advantage), ClickHouse's performance was easily an order of
| magnitude or two better than anything except ES. ES had its own
| downsides with respect to the queries we could run (which is
| why we were leaving ES in the first place).
| someguy101010 wrote:
| What did you end up going with?
| fiddlerwoaroof wrote:
| ClickHouse deployed to EKS with Clickhouse operator
| data_ders wrote:
| I'm betting we'll see a "Clickhouse Cloud" product announcement
| in the next 12 months. I'm curious to see if they can provide
| enough add-on value to their open source product to be
| profitable. But I'm certainly rooting for them!
| ignoramous wrote:
| There's definitely market for a managed clickhouse 1p product.
| It remains to be seen if the product is substantial enough to
| challenge the incumbents. The engineering pedigree is ample. So
| that's already 50% of the way there. With money in the bank, it
| is all about how they suit it up with their sales and
| marketing. Interesting times ahead for them.
| yigitkonur35 wrote:
| Aiven will offer a managed Clickhouse service too:
| https://landing.aiven.io/2020-upcoming-aiven-services-
| webina...
|
| And also Altinity is a trustable partner with a great know-
| how about Clickhouse internals. They have started to offer
| managed instances in AWS: https://altinity.com/altinity-
| cloud-test-drive/
|
| At last, Alibaba Cloud has an option to use:
| https://www.alibabacloud.com/product/clickhouse
|
| Are there any other ones?
| polskibus wrote:
| Yandex offers managed clickhouse :
| https://cloud.yandex.com/en/services/managed-clickhouse
| ignoramous wrote:
| To be clear, I meant _1p_ as in Confluent - > Kafka; not
| AWS -> Managed Kafka.
|
| Despite Yandex (who originally built Clickhouse) offering a
| managed solution, a substantial investment outlay from the
| VCs does come off as a huge vote of confidence in the
| founders.
| nemo44x wrote:
| I'm guessing that's the entire purpose here. Build Snowflake
| with Clickhouse branding.
| encoderer wrote:
| The only value they need to add is that you no longer need to
| run database clusters yourself. I would hope they don't try to
| add any special paid features.
| petr_tik wrote:
| worth keeping in mind that Yandex and russian technology
| companies in general are used to running lean and profitable
| operations so unfathomed in the land of 0% interest rates and
| VC money on tap. If they continue as they are now (15 people)
| and convert customers like Cloudflare into paying engagements,
| there is nothing stopping them from being profitable.
| pm90 wrote:
| How exactly do they get to operate that lean? It seems the
| most straightforward way is by paying employees less.
| hunterb123 wrote:
| Get out of the valley. One engineer can do a lot. Even in
| Texas we run slimmer. I'm the sole frontend dev. I created
| and maintain our iOS, Android, and Web app for a largish
| tech company.
|
| When you don't have VC money and you HAVE to profit, you
| really learn optimize the workflow.
| ctvo wrote:
| > _One engineer can do a lot. Even in Texas we run
| slimmer. I 'm the sole frontend dev. I created and
| maintain our iOS, Android, and Web app for a largish tech
| company._
|
| What do you mean by "do a lot". Can you deliver as
| quickly as a team? If so, do you work more hours or are
| you just better? If you're just better, why do you decide
| to stay with your largish tech company when we're
| acknowledging SV pays more? A remote role would increase
| your salary, no?
|
| Breaking this down:
|
| Russia has a great mathematics and engineering education
| system. Many graduates, unable to leave, take jobs with
| Russian tech companies. Russian tech companies pay less
| than US tech companies.
|
| That's why the situation may be as is with ClickHouse.
| You're not in Russia.
|
| Texas isn't particularly known for running lean. Every
| Big Tech has a presence in Austin. Dallas is filled with
| legacy financial companies burning money on IT.
| hunterb123 wrote:
| Yeah, I use RN to do all the platforms. I spit out
| features pretty fast. They apply to all platforms since
| the codebase is 95% shared. I work normal 40 hours, never
| overtime. I could make more in SV possibly, but I like
| working where I'm at and I have a big influence (I decide
| the tech, style guide, some features etc.) Plus I don't
| like working with a team or too many meetings etc. I
| already work remote and I make a good salary. Cost of
| living would be much higher in SV and most companies
| would cut pay for remote work over there so it would be
| similar.
| ctvo wrote:
| > _Cost of living would be much higher in SV and most
| companies would cut pay for remote work over there so it
| would be similar._
|
| I would validate this by getting an offer. Even adjusting
| for location, my guess is it's still significantly higher
| than what you're making locally. The adjustment isn't,
| say, you live in SF so you make 400k, you live in Houston
| you make 150k. It's ~15-20% for most places, at most.
|
| > _Yeah, I use RN to do all the platforms._
|
| I want to point out those bloated teams that aren't lean
| from SV? They made ReactNative. They made Flutter too if
| you were thinking of swapping.
| hunterb123 wrote:
| 400k is for FAANG, I doubt I'd get that nor do I really
| want to compete for it. Seems like a lot. I'm really
| happy where I am, even if I'm not making top dollar.
| Money isn't everything, I want to be comfortable, happy,
| and stress-free. I also just don't like California, I
| prefer small towns in Texas.
|
| I know Google and FB made Flutter and RN respectively,
| and I thank them for that. That doesn't mean other SV
| companies aren't bloated, FAANG has a lot of money from
| their spigots (Google & FB have their ad money streams)
| and live on another level, not VC funding.
|
| Cross platform has come a long way and enables small
| companies to do a lot more with less. Flutter is nice but
| has flaws, RN is the sweet spot. I could talk for days
| about the pros and cons of both.
|
| A previous comment of mine regarding of Flutter vs RN:
| https://news.ycombinator.com/item?id=28394396
| spyspy wrote:
| No scrum masters, no in-house chef, few or no dedicated
| product managers, no middle manager(s) between eng and
| C-Suite.
| vxNsr wrote:
| So theoretically really just more work per dev and less
| compensation. I guess that makes sense.
| DevKoala wrote:
| Eastern Europe talent probably. They are fantastic and
| their salaries are cheap thanks to conversion rates.
| wayneftw wrote:
| Why would my ad blocker (uBlock Origin) be blocking the domain of
| a "open-source column-oriented database management system"?
|
| I guess this is used heavily in advertising?
| fiddlerwoaroof wrote:
| https://news.ycombinator.com/item?id=28595996
| mempko wrote:
| It's great to see this spin off. ClickHouse is fast but certain
| use cases are not ideal and having it spin off the team can focus
| more on the community and what they need instead of just the use
| cases Yandex had. Cheers to the team and good luck!
| anglinb wrote:
| We're using Clickhouse to power our in-product analytics. It's
| awesome but would love a managed service b/c it definitely
| requires a bit of management overhead. Super excited about this
| announcement!
| hodgesrm wrote:
| Check out Altinity.Cloud. It's managed and works today.
|
| Disclaimer: I work for Altinity, which operates the
| Altinity.Cloud service.
| pachico wrote:
| I wish the best to them. They forged a game changer software.
| Hopefully, they will also offer a competitive SaaS model
| (hopefully also at bare-metal based price).
| didibus wrote:
| > Most other database management systems don't even permit
| benchmarks (through the infamous "DeWitt clause"). But we don't
| fear benchmarks; we collect them.
|
| I love the confidence here.
| hkolk wrote:
| I wonder how this will play out with https://altinity.com who
| have been doing enterprise support for quite some time..
| hodgesrm wrote:
| I run Altinity. We think it's great. This is going to help grow
| adoption which benefits everyone. Watch our blog for a post in
| a couple hours.
|
| BTW congrats to Alexey on the new company.
| [deleted]
| acidbaseextract wrote:
| As a sidenote, I saw your talk on Clickhouse to the CMU
| database group [1] back when and was extremely impressed with
| your deep technical knowledge yet down-to-earth presentation.
| Still haven't had an opportunity to use Clickhouse for
| production work, but would welcome it.
|
| [1] https://www.youtube.com/watch?v=fGG9dApIhDU
| hodgesrm wrote:
| Thank you!! That was the most fun I've ever had on a tech
| talk. Any Pavlo is a one man army when it comes to fun
| questions and there were more like him in the audience. The
| whole series of quarantine talks was great.
| zX41ZdbW wrote:
| Thank you! This is an important milestone for ClickHouse and
| will benefit the entire ecosystem.
| tnolet wrote:
| We are using Altinity too. Great support up to now. We are
| about to go live with it. For us (see my bio for company
| link) having a company manage the cluster was paramount. We
| just want to use the data and API, not manage the
| machines/VM's and k8s clustering stuff.
| hodgesrm wrote:
| Cool! Thank you so much for posting. We get a huge kick
| when projects go live. (Being a manager has not beaten it
| out of me.)
| jordanthoms wrote:
| We recently setup Clickhouse on GKE using the Altinity
| operator (and signed up for Altinity support).
|
| There's been so many queries where I've thought 'that's going
| to need a join and aggregation across tens of billions of
| rows, no way!' - and then Clickhouse spits back a query
| result in 10 seconds...
| mobileexpert wrote:
| I think similar to other situations e.g Starburst with
| Presto/Trino. There really are a limited number of devs pushing
| a long the core projects and a lot of people needing support.
| Each start up in the space can likely grow the pie for support
| and adoption and a few big enterprises will still hire in house
| devs.
| mobileexpert wrote:
| Awesome! Really excited for CH.
| PeterZaitsev wrote:
| Interesting news indeed! I very much wonder what it means long
| term in terms of Licenses. I would imagine much better future if
| Clickhouse would become Foundation driven process which gives
| good protection from license change (through I'm biased here) -
| Currently Clickhouse fully under Apache 2.0 license may look too
| good to be true compared to where many successful VC funded
| projects took licenses of their projects (think Elastc, MongoDB,
| Redis)
|
| In any case though I expect a lot of growth in Clickhouse
| community now and investment both engineering and most
| importantly Marketing - I think Clickhouse technology has a lot
| more adoption potential than it currently has
| puppet-master wrote:
| I'd much rather they relicensed early if they can, to set
| expectations and to ensure talented people actually get to
| sustain its development, rather than parasitic jobsworth FAANG
| types who will inevitably drive development at Amazon. Free
| software in this context is very dead, let's not pretend
| network and channel effects of AWS were ever envisaged in the
| 1980s when most "contemporary" free software licensed were
| designed.
| legg0myegg0 wrote:
| Does anyone happen to know which country the new company is
| incorporated in? I'm still looking for a chance to use ClickHouse
| because it sounds so excellent!
| monstrado wrote:
| I'm excited for the future of ClickHouse! I'm hopeful that this
| move will help smooth out the rough-edges of ClickHouse, mainly
| around clustering.
| ricardobeat wrote:
| Totally unrelated, but this part of the readme says
| Yandex N.V. is the largest internet company in Europe
| and employs over 14,000 people
|
| I'm quite sure there are larger "internet companies" in the EU
| such as Booking, Zalando, etc.
| discobot2 wrote:
| Booking is 5K employees.
| einpoklum wrote:
| For those who don't know it:
|
| ClickHouse is a columnar, analytic, close-to-a-DBMS, but not a
| full-fledged one. The "100x-1000x faster" is compared to row
| stores. Last time I checked it was mostly single-table-oriented.
| ucarion wrote:
| Might make more sense to link to the blog post, instead of its
| underlying markdown in GitHub?
|
| https://clickhouse.com/blog/en/2021/clickhouse-inc/
| vxNsr wrote:
| Most of the audience here blocks ads with either uBlock or
| something else and they all include that domain in the
| blacklist.
| truthwhisperer wrote:
| one questions is did you implement special algorithms to bias in
| plus or minus against your president? This is a rumour. Just want
| to know if it is true or false
| chrismorgan wrote:
| Canonical link: https://clickhouse.com/blog/en/2021/clickhouse-
| inc/
|
| But I presume the GitHub link
| (https://github.com/ClickHouse/ClickHouse/blob/master/website...)
| has been submitted because clickhouse.com is going to be blocked
| for a large fraction of HN users ( _Peter Lowe's Ad and tracking
| server list_ , which I think uBlock Origin has enabled by
| default, includes ||clickhouse.com^). I'm actually a bit curious
| why clickhouse.com (or more likely a subdomain?) would be being
| used this way; I'd have thought that they'd separate any such
| uses to a different domain so as not to hinder their main domain
| which is about the software and nothing to do with ads or
| tracking at all (even if that's probably the main end use of such
| an OLAP DBMS).
| pgl wrote:
| Someone just reported this to me and I've removed the entry
| from my blocklist.
|
| This was a very old entry - it was added on Fri, 06 Jun 2003
| 19:53:00. Back then it was a marketing company that served ads.
|
| I pride myself on knowing the entries in my list very well, but
| I have to admit I forgot about this one, which is ironic
| because I use Clickhouse at my job these days.
| chrismorgan wrote:
| Great! That makes much more sense.
|
| Thank you for maintaining such lists. You and a few others
| like you save me much time and aggravation.
| Maxburn wrote:
| Thank you for this service!
| wayneftw wrote:
| Thanks! This worked instantly just now as I purged cache and
| updated all lists in uBlock Origin.
|
| I don't look forward to when Chrome enforces Manifest v3 when
| I'll probably have to wait for a whole extension to be
| updated instead of just a list file.
| f0e4c2f7 wrote:
| I'm surprised and impressed that you would remember what's on
| the list.
|
| Thank you for your hard work. Every day it makes my
| experience of the internet 100x better.
| sikhnerd wrote:
| Thank you so much for the hard work you do! It makes the web
| sooo much more usable.
| newman314 wrote:
| FWIW, clickhouse.com is also blocked by "Malvertising filter
| list by Disconnect"
| nacs wrote:
| It's also blocked on my Pi-Hole install network-wide
| apparently.
| KitDuncan wrote:
| Just got started with clickhouse. Super cool software.
| jenny91 wrote:
| These some really great technology coming out of Russia in the
| information retrieval/database world: ClickHouse, a bunch of
| Postgres stuff that Yandex is working on, 2gis.ru (a super
| detailed vector map on a completely different stack to
| Google/MapBox), etc.
| nhoughto wrote:
| We just did months of testing on a bunch of dbs for a time-series
| workload, and whilst we really liked the story and devs behind
| clickhouse. The ops burden of not separating storage and compute
| ended up being a turn off. Good to see it is progressing and will
| hopefully get more investment, although I wonder what this means
| for companies like Altinity.
|
| We compared Timescale, Clickhouse, Snowflake and Firebolt. Ended
| up really liking Firebolt, some amazing tech with a few
| roughedges (its pretty new), basically Clickhouse speed meets
| Snowflake simplicity definitely one to watch.
|
| https://www.firebolt.io/
| qaq wrote:
| reads like marketing copy
___________________________________________________________________
(page generated 2021-09-20 23:00 UTC)