HackerTrans
TopNewTrendsCommentsPastAskShowJobs

mgachka

no profile record

comments

mgachka
·3 years ago·discuss
"A license that doesn’t allow reselling the service is good enough For example, I saw this with Tailwind UI" FYI, we discussed it in this thread https://github.com/ClickHouse/ClickHouse/issues/44767. For the moment, the only way to get the new features is to use the cloud version (which is likely to be a no-go for most companies managing their own clickhouse infrastructure).
mgachka
·3 years ago·discuss
As a user of clickhouse since 2018 I'm fully aligned with the content of this article. This technology is one of the best I've been using in my career.

The choice of clickhouse for a new project in my company has always been a no-brainer, but the recent move from clickhouse.inc to a closed source version has made this choice less straightforward.
mgachka
·4 years ago·discuss
Hi,

It's a good read. I have a few questions/comments:

- given the description of the Rumor-mongering approach vs the Anti-entropy approach, it looks like the Anti-entropy approach:

-- has an important overhead in terms of network/messages sent (since nodes are always chatting even when there are no changes in the cluster).

-- is slower to propagate a change of cluster state to all the nodes. Does it mean that in case of a node failures/shutdown, the cluster will be instable for longer (since dead nodes will receive queries)?

- the article mention a "seed node" but doesn't define what this is.

- on a dynamic quickwit setup (that often downscales/upscales depending on the load), it seems that the size of the metadata in each node will keep increasing since the state of the dead nodes will be kept, unless the same node_unique_id can be reused after a downscale/upscale (but I don't know enough how kube works to see if it's the case).
mgachka
·11 years ago·discuss
When I started this side project in 2012, I looked for publicly reliable information (especially thesis or research papers) and the only useful information I found was Shazam confounder’s paper.

Since this paper was written in 2003, I wouldn't be surprised if they have changed their algorithms since this time.

But from my understanding, the 2003 paper describes a highly scalable architecture and a noise tolerant and "time efficient" algorithm (that can be modified using thresholds) so it could still work in 2015 with a few optimizations. Still, I'm not working at Shazam and I'm not a researcher so I could be wrong.
mgachka
·11 years ago·discuss
I, I’m the author of the article and I already know that. The big difference between Roy van Rijn and I is that I only put algorithms whereas he put “ready to use” java code. On paper I should be bulletproof to any lawsuit since this article is nothing more than a very detailed version of the confounder Shazam paper (+some unexplained algorithms).
mgachka
·11 years ago·discuss
I, I’m the author of the article. In fact I also did the same when I did my prototype of Shazam. When I wrote the article, I hesitated to add a sub chapter in the Shazam chapter when I would have put a well-known music and its fingerprinted version so that everyone can hear what it sounds like but I didn’t do it because I feared copyright lawsuit.