Does anyone have a great idea for what to name a new datastore? | Hacker News Reader

Does anyone have a great idea for what to name a new datastore?

daemonology.net

19 pointscperciva33 comments

Why am I writing a data store? Because my online backup service needs to store 200,000 key-value pairs for every $/month of revenue, and existing data stores aren't optimized very well for very large numbers of very small records.

Really? Every one of the dozens of open-source key/value stores is so far off from your requirements that they just don't work for you?

Yes. The most common problem is being designed for large values. My situation of having a large number of very small values is unusual, so it's not surprising that existing code isn't optimized for this case.

Did you know that only two, maybe three of those datastores are any good? And did you know that of those three, they're not designed for every workload?

I wrote a KV store for work (nothing special, not planning to release it) and call it Koko.

It's the Finnish word for "size" or "bulk" and does not have many Google hits (always an advantage).

Feel free to use it :)

Perhaps something related to it's design goals, like "grains", url getgrains.com (ie. lots of tiny grains of sand on the beach)?

silo?

Win.

> Naming after a random household object: FridgeDB?

Actually, I am pretty sure the name CouchDB was inspired by REST :)

Aha! I had no idea, but that makes perfect sense.

Five minute brainstorm: (so most are awful)

The datatorium

Ferret (no reason, it just sounds right)

Niblets (because it stores small chunks)

Petadata / petapairs (because it works with many k/v pairs)

Basology ((data)base + ology)

Keyology (the -ology of keys)

Tupology (because a k/v pair is a tuple)

If it is not too much to ask, what are your real constraints and requirements and what existing systems did you investigate?

Based on the tidbits you've supplied I would guess what you're really doing writing is a file system capable of handling small files well (i.e. something along the lines of ReiserFS).

Tarsnap data is stored in S3; my problem is handling the metadata which allows the Tarsnap service to find user data on request. The two large tables have (key, value) lengths respectively of (41, 12) and (8, 16).

I need immediate durability; fast restart; high throughput bulk writes; reasonable throughput random reads; range requests; and (for financial reasons) I'd like to have a high disk:RAM ratio.

How about Newd? For "New Datastore," of course. And all your clients can say "I'm going newd" when they adopt it.

I have to admit, this one made me laugh. But it doesn't feel quite appropriate as a name for a highly stable and durable data store.

Small chunks? Call it "WeeDB"

+1 for the already mentioned in the article:

Sauron

Kobold

"Shunya" - sanskrit word for zero/null/nothingness it also signifies existence(infinity/everything) is contained in nothingness. should work as a gud koan too :P

How about calling it a "transaction-value-logging-data-store" and naming it TRVLDS? That ought to be good for something. :-)

    Kevlar (KV)
    Rithm  (Log)
    OhBaby (TarSnap ;)
    Cubby  (Hole)
    Pigeon (Hole)

SandStorm

SandCastle

SandStore

Sandy

SnipStore

TinyOcean

YAYSP (Yet Another Yak Shaving Project)

burnaby cabinet

sounds better than "vancouver cabinet" and is technically more accurate

smallKeys

even tho you're referring to small values, "smallKeys" sounds better than "smallValues" (tho misleading)

No. But here's some mediocre ones:

Gidget

Kahuna

Hailstorm

Ark

Web Scale

I considered calling it "devnul", but I can't do sharding (I need range requests) so the joke wouldn't have worked anyway.

Attic

Iron Molehill

Shelf

Mandelbrot

Hooks (like key hooks)

Tar Pit

"The highly stable and durable data store."

And a cluster of Tar Pits = La Brea (which is actually a cluster of tar pits)

KeyMate

DonKey

YADS.

Reply on news.ycombinator.com