Does anyone have a great idea for what to name a new datastore?(daemonology.net)
daemonology.net
Does anyone have a great idea for what to name a new datastore?
http://www.daemonology.net/blog/2010-10-22-naming-a-datastore.html
24 comments
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.
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.
+1 for the already mentioned in the article:
Sauron
Kobold
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
Mandelbrot
Perhaps something related to it's design goals, like "grains", url getgrains.com (ie. lots of tiny grains of sand on the beach)?
Shelf
Hooks (like key hooks)
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?
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?
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)
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)
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.
SandStorm
SandCastle
SandStore
Sandy
SnipStore
TinyOcean
YAYSP (Yet Another Yak Shaving Project)
SandCastle
SandStore
Sandy
SnipStore
TinyOcean
YAYSP (Yet Another Yak Shaving Project)
Kevlar (KV)
Rithm (Log)
OhBaby (TarSnap ;)
Cubby (Hole)
Pigeon (Hole)Attic
Iron Molehill
Iron Molehill
YADS.
DonKey
No. But here's some mediocre ones:
Gidget
Kahuna
Hailstorm
Ark
Gidget
Kahuna
Hailstorm
Ark
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 :)
It's the Finnish word for "size" or "bulk" and does not have many Google hits (always an advantage).
Feel free to use it :)
Small chunks? Call it "WeeDB"
KeyMate
How about calling it a "transaction-value-logging-data-store" and naming it TRVLDS? That ought to be good for something. :-)
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)
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)
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).