FoundationDB high contention allocator
activesphere.com
FoundationDB high contention allocator
1–10 of 10 posts
Re: FoundationDB high contention allocator
#2This post is a great illustration of the FoundationDB model. If you can design an algorithm that scales from a theoretical perspective, and map it onto the FoundationDB key-value model, writing the application code is as straightforward as your algorithm. You don't have to think about the details of storage, networking, and transactions very much.
Re: FoundationDB high contention allocator
#3FoundationDB could really have been a big big thing had they not burnt bridges with their initial user set (i was one of them). It was a really cool database.
Re: FoundationDB high contention allocator
#4FoundationDB could really have been a big big thing had they not burnt bridges with their initial user set (i was one of them). It was a really cool database.
Care to provide more details ? (i don't understand why you got downvoted btw)
Re: FoundationDB high contention allocator
#5FoundationDB could really have been a big big thing had they not burnt bridges with their initial user set (i was one of them). It was a really cool database.
Care to provide more details ? (i don't understand why you got downvoted btw)
I think because when they sold to Apple they pulled their support and binaries.
Re: FoundationDB high contention allocator
#6Re: FoundationDB high contention allocator
#7FYI the FoundationDB community is doing its first community event in December: https://www.foundationdb.org/blog/announcing-foundationdb-su...
Re: FoundationDB high contention allocator
#8It took me a while reading the source code to convince myself that FoundationDB really doesn't use any prefix compression.
Seems like even with the directory encoding you'd be able to save a lot of storage space for keys by omitting the common prefixes.
Re: FoundationDB high contention allocator
#9FoundationDB could really have been a big big thing had they not burnt bridges with their initial user set (i was one of them). It was a really cool database.
Care to provide more details ? (i don't understand why you got downvoted btw)
FoundationDB had everything (launched or work in progress). SQL that was fast like NoSQL, No single point of failure, Scaling, Search, etc, etc... all built into one database. It was designed to remove the pain of managing many different components. For example, handling 'search' separately (via solr/lucene/cloudsearch) is a pain.
I'm not sure about the downvotes. I guess HN has lots of karma-police.
Re: FoundationDB high contention allocator
#10Earlier quoted context omitted.
Care to provide more details ? (i don't understand why you got downvoted btw)
FoundationDB had everything (launched or work in progress). SQL that was fast like NoSQL, No single point of failure, Scaling, Search, etc, etc... all built into one database. It was designed to remove the pain of managing many different components. For example, handling 'search' separately (via solr/lucene/cloudsearch) is a pain. I'm not sure about the downvotes. I guess HN has lots of karma-police.
I was thinking about the « burning the bridge on initial users » part. But maybe you meant selling to Apple.