Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a very fast cache service with millions of entries in Go

allegro.tech

Post reply on HN
Print view View original

51–60 of 92 posts

Re: Writing a very fast cache service with millions of entries in Go

#51

Post by Maascamp »

endymi0n wrote: post #38

I still don’t get why people try writing their own data store, especially in a language that's simply not very well suited to that task (and we're an almost 100% Golang shop here). Seems to be a rite of passage. The requirements are literally Public service announcement: Don't write your own data store. Repeat after me: Don't write your own data store, except if you want to experimentally find out how to build data s…

Not sure if this applies to their use case since they mention FIFO in the context of it being a simple eviction policy, but if you _require_ FIFO semantics then both Redis and memcached are out of the question since they use nondeterministic LRU policies (memcached's LRU is particularly egregious in its nondeterminism due to the way slab allocation works).

Re: Writing a very fast cache service with millions of entries in Go

#52

Post by tmaly »

endymi0n wrote: post #38

I still don’t get why people try writing their own data store, especially in a language that's simply not very well suited to that task (and we're an almost 100% Golang shop here). Seems to be a rite of passage. The requirements are literally Public service announcement: Don't write your own data store. Repeat after me: Don't write your own data store, except if you want to experimentally find out how to build data s…

I used Redis with Go and I was very happy with the results. I did have one case where I used boltdb.

I run things on a lean vps, and I had a large amount of data I tried to stuff in a trie. Well it worked fine on my macbook with plenty of memory, but it ran out of memory on my vps. Using bolt helped in this case with the memory mapped file.

Re: Writing a very fast cache service with millions of entries in Go

#54

Post by leetrout »

st0p wrote: post #24

Why not use Varnish? POST messages of 500 bytes could easily be rewritten / proxy'd to GET requests. That might not be 100% restfull but seems like a lot less work. On our production environment Varnish always responds in less then 2 ms. Even on my development VM I never see response times > 5 ms. It has all the other requirements they state. Perhaps I'm prejudiced because Varnish has proven to be such an awesome cac…

Varnish is actually difficult to use for POST requests unless you know C and can tweak the existing vmods. I just came off the same basic requirements and ended up going with Nginx (OpenResty) with Lua & Redis.

Re: Writing a very fast cache service with millions of entries in Go

#55

Post by im_down_w_otp »

endymi0n wrote: post #38

I still don’t get why people try writing their own data store, especially in a language that's simply not very well suited to that task (and we're an almost 100% Golang shop here). Seems to be a rite of passage. The requirements are literally Public service announcement: Don't write your own data store. Repeat after me: Don't write your own data store, except if you want to experimentally find out how to build data s…

There are two datastores I would really like that don't exist.

1) An efficient, high-performance distributed persistence store for arbitrarily large CRDT's.

2) A Kafka-like highly-available distributed binary log w/ cheap topics, that doesn't require external coordination, and doesn't lose acknowledged writes (which I'll happily give up any shape of linearization guarantee for).

Re: Writing a very fast cache service with millions of entries in Go

#56

Post by markbnj »

endymi0n wrote: post #38

I still don’t get why people try writing their own data store, especially in a language that's simply not very well suited to that task (and we're an almost 100% Golang shop here). Seems to be a rite of passage. The requirements are literally Public service announcement: Don't write your own data store. Repeat after me: Don't write your own data store, except if you want to experimentally find out how to build data s…

Sort of came here to say this. Interesting article, especially some of the design choices (such as http for the interface), but I am most curious as to why redis, or memcached, or some other k/v store was not good enough?

Re: Writing a very fast cache service with millions of entries in Go

#57

Post by endymi0n »

im_down_w_otp wrote: post #55
endymi0n wrote: post #38

I still don’t get why people try writing their own data store, especially in a language that's simply not very well suited to that task (and we're an almost 100% Golang shop here). Seems to be a rite of passage. The requirements are literally Public service announcement: Don't write your own data store. Repeat after me: Don't write your own data store, except if you want to experimentally find out how to build data s…

There are two datastores I would really like that don't exist. 1) An efficient, high-performance distributed persistence store for arbitrarily large CRDT's. 2) A Kafka-like highly-available distributed binary log w/ cheap topics, that doesn't require external coordination, and doesn't lose acknowledged writes (which I'll happily give up any shape of linearization guarantee for).

can't help with 1), but as for 2), maybe Kudu is an option for you? http://blog.rodeo.io/2016/01/24/kudu-as-a-more-flexible-kafk...

Re: Writing a very fast cache service with millions of entries in Go

#58

Post by iAmCyclic »

pcwalton wrote: post #3

From the article: > [Go] also has managed memory, so it looks safer and easier to use than C/C++. But most of the post describes a sophisticated way to work around the garbage collector, totally reliant on a specific implementation detail of the current Go GC (skipping of pointer-free data types), documented in a GitHub issue. It seems easier to not have, or to not use, the GC in the first place for this specific pro…

I think the problem with using offheap for something like this is that it requires you to specify the exact size of the data you want to put in each "cell" of the hash table. Take a look at the NewHashFileBacked function in https://github.com/glycerine/offheap/blob/master/offheap.go. If you wanted to cache a variety of json data this could lead to a lot of unused space if most of the items are smaller than the cell size. So, their large byte array plus offsets solution seems preferable.

I do agree with you that perhaps Golang was not the right choice for this project since they spent much of the time working around features of the language.

Re: Writing a very fast cache service with millions of entries in Go

#59

Post by chris_va »

im_down_w_otp wrote: post #55
endymi0n wrote: post #38

I still don’t get why people try writing their own data store, especially in a language that's simply not very well suited to that task (and we're an almost 100% Golang shop here). Seems to be a rite of passage. The requirements are literally Public service announcement: Don't write your own data store. Repeat after me: Don't write your own data store, except if you want to experimentally find out how to build data s…

There are two datastores I would really like that don't exist. 1) An efficient, high-performance distributed persistence store for arbitrarily large CRDT's. 2) A Kafka-like highly-available distributed binary log w/ cheap topics, that doesn't require external coordination, and doesn't lose acknowledged writes (which I'll happily give up any shape of linearization guarantee for).

(1) Spanner does exist, though not really available outside of Google

Re: Writing a very fast cache service with millions of entries in Go

#60

Post by LeonidBugaev »

NicoJuicy wrote: post #29

I found the mention of ffjson interesting, a faster serializer then the standard buildin json serializer ( 2x - 3x as fast) ==> https://github.com/pquerna/ffjson

You should check https://github.com/buger/jsonparser and https://github.com/mailru/easyjson as well. They are even more faster.
Post reply on HN