
FoundationDB high contention allocator - wooola
https://www.activesphere.com/blog/2018/08/05/high-contention-allocator
======
wimbledon
FoundationDB 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.

~~~
bsaul
Care to provide more details ? (i don't understand why you got downvoted btw)

~~~
wimbledon
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.

~~~
bsaul
I was thinking about the « burning the bridge on initial users » part. But
maybe you meant selling to Apple.

------
ryanworl
This 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.

------
caniszczyk
FYI the FoundationDB community is doing its first community event in December:
[https://www.foundationdb.org/blog/announcing-foundationdb-
su...](https://www.foundationdb.org/blog/announcing-foundationdb-summit/)

------
tveita
It 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.

