Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
solso
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
31.
▲
by
solso
7y ago
Yes, we are on some minor blocking lists because of our data collection, even though is anonymous (please check the articles about Human Web on https://0x65.dev/ ) sending data, no matter what data, is a sin that has to be p
32.
▲
by
solso
7y ago
Not sure I get your point. But contextual search only works for the search within Cliqz browser, on the address bar dropdown, on the client space. The same approach cannot be done on the (web-page SERP page, beta.cliqz.com), because from a
33.
▲
by
solso
7y ago
[Disclaimer: I work at Cliqz] I hate to answer this one, becasue it looks too much marketing-speech but this feature exists. Not on beta.cliqz.com but on the drop-down search on Cliqz browser. Based on the tabs you have opened, different qu
34.
▲
by
solso
7y ago
[Disclaimer I work at Cliqz] There is a lot of systems under the hood, depending if it's the main index or the freshness index. But if I have to pick one as database it should be Keyvi ( https://github.com/KeyviDev/
35.
▲
by
solso
7y ago
[Disclaimer, I work at Cliqz] I cannot answer for the "true" motivation of the investors, but their pitch and actions so far are well align with the fight against monopolies narrative. Do they want to get return on investment (eve
36.
▲
by
solso
7y ago
[Disclaimer, I work at Cliqz] Your point is spot on. Old pages tend to have more association to seen queries, which does not play in favor for new pages. That said, however, there are a couple of things to consider: 1) seen queries is not t
37.
▲
by
solso
7y ago
An excerpt from the 1st post of this series: "Why would a team be motivated to build another search engine? Why would Hubert Burda Media finance this over several years (they continued to back us especially in times when things got tou
38.
▲
by
solso
7y ago
Refusing to speak spanish is a myth. It's much more likely that you will not ever be able to learn catalan becasue poeple will always switch to spanish the moment they see you are a foreigner. Whether you want to learn spanish or catal
39.
▲
by
solso
7y ago
works well, it would have fooled me. The quotes are as bizarre as the real ones :-)
40.
▲
by
solso
7y ago
Forget about Apple for a second, they will sell whatever to anyone, for sure. But please focus on Google, which is the one putting the money! Why Google pays so much money if they already have the best product and what the users want? Are t
41.
▲
by
solso
7y ago
[Disclaimer: I work at Cliqz] Yes, we are not the only approach. Even when we started collecting data back in 2014 it wasn't the only one. But we did not find any suitable off-the-shelf solution back then. Homomorphic encryption was di
42.
▲
by
solso
7y ago
Of course client-side aggregation can still leak privacy, it needs to guarantee that there are no explicit or implicit elements that would allow record-linkage on the server-side. On the diff. privacy, note that you mention before you stor
43.
▲
by
solso
7y ago
[Disclaimer, work at Cliqz] Comparisons of quality are relative, Google was good from day one because it was better than the competitors at that moment of time. Problem is that if one starts using X, and that provides an edge, the other hav
44.
▲
by
solso
7y ago
Of course it's business, but it invalidates the premise that people chose "mostly" because of the quality. If that was the main driver, Google could just pay zero, 9 Billion for few hundred million users is quite an hefty sum
45.
▲
by
solso
7y ago
The claim: "Google's dominance is almost entirely due to the fact that its by far the best at search." is, and I'm sorry to say, a make-believe Google's quality is better than anyone else, that is a fact. Let&#x
46.
▲
by
solso
7y ago
[disclaimer I work at Cliqz] We are all ears on ideas on how to beat Google :-) But on a serious note; i do not think that the aim is to beat Google because of Google but because on the monopoly they have on the access to the information. A
47.
▲
by
solso
7y ago
[[Disclaimer I work at Cliqz]] Your question is spot on, many of us ask ourselves the same question. Whether Cliqz would become a bully like Google if successful or not, I believe it's impossible to answer. But at least, we know, that
48.
▲
by
solso
13y ago
Redis persistence is very reliable, reliable enough to be a proper datastore when using replication (master-slave). We have been using it in prod for 4 years, with many GB and not a single problem. From my experience, redis is perfect for s
49.
▲
A simple document datastore using Redis
(github.com)
7 points
by
solso
13y ago
|
2 comments
50.
▲
Extending REST APIs
(3scale.github.io)
7 points
by
solso
13y ago
|
1 comments
51.
▲
by
solso
14y ago
The replication stream is about 20-25 Mbps for the current throughput of 25K-30K req/s, our peak to valley ratio is low. It seems that we have found this unusual conditions you mention :-) Before compression our replication was often laggin
52.
▲
by
solso
14y ago
that's totally correct. In the case of a redis replication, the ssh tunnel failing would be quite costly, since the whole database will have to be send again since the slave would do a SYNC op. And that can be multiple GB in our case. But s
53.
▲
by
solso
14y ago
The glitches with the ssh tunnel were not for the redis replication setup. This has been running fine for 3 weeks already. However we also use ssh tunnels for our continuous integration (jenkins) and the irc bots that we use for development
54.
▲
by
solso
14y ago
Indeed it's a nice problem to have :-) we are not yet there, we double every 3 months so far, so we still have 9 months to go :-) however, getting out of cloud does not help. The problem is the high-availability. To maintain 99.9% we cannot
55.
▲
by
solso
14y ago
that's a good point... as mentioned in the post we use ssh tunnels and have experienced quite a few glitches, but in this case it has been running without a hiccup for 3 weeks (proof of nothing of course). I suspect (guess) that not having
56.
▲
by
solso
14y ago
woops! @antirez in person :-) amazing job you have done with Redis. Initially we didn't add compression to save bandwidth but to solve the network bandwidth issues between amazon and rackspace. However, it turns out that you can save on the
57.
▲
Having fun with Redis Replication between Amazon and Rackspace
(3scale.github.com)
79 points
by
solso
14y ago
|
38 comments