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

Badger – A fast key-value store written natively in Go

open.dgraph.io

Post reply on HN
Print view View original

51–60 of 101 posts

Re: Badger – A fast key-value store written natively in Go

#51

Post by anarazel »

wolco wrote: post #47
jkarneges wrote: post #42

Earlier quoted context omitted.

> The AGPL for database products isn't unheard of. See also Neo4J. And Mongo. Also RethinkDB until the parent company folded. > This licencing model wouldn't be appropriate for a community-centric database, such as PostgreSQL. I don't disagree. It's interesting, though, how counterintuitive this is. I would think that GPL wouldn't be a problem for individual contributors (the types of participants I imagine when I th…

I think the problem is they never will contribute back any modifications upstream. Pick the right license for the project. Apache is for marketshare, gpl is perfect framework for community involvement, agpl is best for control

> agpl is best for control

In my personal opinion, AGPL is largely chosen to avoid various cloud providers from profiting significantly from $product, without ever giving back. That's control, but a very specific form of it. I don't personally like AGPLs legalese, it's very very imprecise.

Re: Badger – A fast key-value store written natively in Go

#52

Post by dkarapetyan »

ckaygusu wrote: post #48
dkarapetyan wrote: post #40

Earlier quoted context omitted.

Was with you until you said you don't need SQL.

For really simplistic applications, omitting SQL is a fine choice, especially in golang you don't have the comfort of a well established ORM. There exists libraries that do provide an ORM, but since the declarative side of golang is limited compared to languages, say Python, I find them unwieldy. Also, the current trend shuns the usage of an ORM in golang and encourages directly or indirectly writing SQL queries and…

For really simple application omitting a k/v store is even better. Why isn't a simple map good enough?

Re: Badger – A fast key-value store written natively in Go

#53

Post by lumost »

mirekrusin wrote: post #39

Silly question - if SSDs or even motherboard had persistent storage of (couple of) 4 KB blocks where you'd be able to fsync It seems that databases often want to persist/flush data in unfinished (4KB or 8KB) pages when they're being built, once they are full, they don't change much - once full they could be normally persisted. Another kind of pages are those that change very frequently - ie. single "root" page which…

There used to be a lot more innovation and variety in hardware following similar approaches. However, commodity gear was an easier deployment target for software and economics ensured commodity gear provided better performance per dollar than proprietary solutions.

Re: Badger – A fast key-value store written natively in Go

#54

Post by defanor »

slimsag wrote: post #7
dkarapetyan wrote: post #6

There's that word again, natively. Should just say written in Go. The native part is redundant.

I believe the author is using the term 'natively' here to describe the project being written purely in Go, rather than using CGO (i.e. being a wrapper to some database written in C). I agree 'written purely in Go' would have been a better choice of words, though.

But if it was a wrapper, it would be wrong to say "a key-value store written in Go" (even without "purely").

Re: Badger – A fast key-value store written natively in Go

#55

Post by ckaygusu »

dkarapetyan wrote: post #52
ckaygusu wrote: post #48

Earlier quoted context omitted.

For really simplistic applications, omitting SQL is a fine choice, especially in golang you don't have the comfort of a well established ORM. There exists libraries that do provide an ORM, but since the declarative side of golang is limited compared to languages, say Python, I find them unwieldy. Also, the current trend shuns the usage of an ORM in golang and encourages directly or indirectly writing SQL queries and…

For really simple application omitting a k/v store is even better. Why isn't a simple map good enough?

Depends on the requirements (persistency, concurrency etc.) No offense, but it's bit pointless to discuss it further without deeper context.

Re: Badger – A fast key-value store written natively in Go

#56

Post by ashwin95r »

fortytw2 wrote: post #11

off topic: flipping through the dgraph code, I noticed their licensing switch from Apache 2 to AGPLv3, anyone involved around to comment? Adding a draconic open source license is an unwise decision for an early stage database product imo ( https://open.dgraph.io/licensing is a dead link)

https://open.dgraph.io/post/licensing/

Re: Badger – A fast key-value store written natively in Go

#57

Post by ovao »

dkarapetyan wrote: post #52
ckaygusu wrote: post #48

Earlier quoted context omitted.

For really simplistic applications, omitting SQL is a fine choice, especially in golang you don't have the comfort of a well established ORM. There exists libraries that do provide an ORM, but since the declarative side of golang is limited compared to languages, say Python, I find them unwieldy. Also, the current trend shuns the usage of an ORM in golang and encourages directly or indirectly writing SQL queries and…

For really simple application omitting a k/v store is even better. Why isn't a simple map good enough?

Lack of persistence is one such reason. Because Go's built-in maps are not completely safe to use concurrently, too, their usefulness as a key/value store is somewhat limited in many applications.

Naturally, it's possible to build a solution to persist Go maps and to make them safe to access across goroutines, but by that point you've built a persistent key/value store.

Re: Badger – A fast key-value store written natively in Go

#59

Post by mrjn »

skyde wrote: post #15

Range iteration latency is very important and might be limited by concurrency. I think you can only get 100K IOPS on Amazon’s i3.large when the disk Request queue is full. fio [1] can easily do this because it spawn a number of threads While working with Rocksdb we also found that Range iteration latency was very bad compared to a B+-tree and that RocksDB get good read performance mostly from random read because it's…

(Badger author) We have tried huge prefetch size, using one Goroutine for each key; hence 100K concurrent goroutines doing value prefetching. But, in practice, throughput stabilizes after a very small number of goroutines (like 10). I suspect it's the SSD read latency that's causing range iteration to be slow; unless we're dealing with some slowness inherent to Go. A good way to test it out would be to write fio in Go, simulate async behavior using Goroutines, and see if you can achieve the same throughput.

If one would like to contribute to Badger, happy to help someone dig deeper in this direction.

Post reply on HN