3 ms·

One simply has to mention Tokyo/Kyoto Cabinet/Tyrant. http://fallabs.com/ http://fallabs.com/ With all the NoSQL Hype Redis and MongoDB get I think these are

by tete 15y ago

One simply has to mention Tokyo/Kyoto Cabinet/Tyrant. http://fallabs.com/ http://fallabs.com/ With all the NoSQL Hype Redis and MongoDB get I think these are too often overseen. What's really nice is that you can use them in embedded (cabinet) or server (tyrant) "mode". What's also great about them is that they provide a lot of flexibility, since they are not just one database. Also great that they have official bindings that work. They have tons of features and sometimes an embedded database is really interesting when you don't want (need) to care about the protocol you send it over.

premchai21 15y ago
Do Tokyo Cabinet and Kyoto Cabinet still use totally unprotected mmap? Last I checked, truncating the DB file in the middle of an operation would take down the entire process with SIGBUS, and I assume a disk error would do something similar. This seems like it'd be bad for fault tolerance. Or are storage devices just that reliable nowadays, or does enough else break along with them that they're considered a critical component anyway?
pak 15y ago
I just found these two little jewels and have been using them to provide fast access to a haystack of images (GB to TB size, each image about ~1KB). I am curious to hear what others think about moving from Tokyo to Kyoto--the website says Kyoto is recommended, but there is a real dearth of information about Kyoto (at least in English) out on the web, compared with the scattered breadcrumbs that you can sort of piece together for information on Tokyo. Most of those breadcrumbs are unfortunately silly benchmark articles instead of real experiences. Also, I already did have one Tokyo Cabinet Hashtable go corrupt on me--which caused certain operations to lock up the CPU indefinitely. Hmm, that didn't ease my conscience. However, it was completely recoverable with "tchmgr optimize". It'd be nice to google for more war stories, but like I said... breadcrumbs so far.
hcles 15y ago
My experience with their B+ Tree database is that when your database size hits a Gb or more, closing the database can take up to 10mins or more (depending on writes queued), and opening a database that was not closed correctly rebuilds the entire database. I've not found any such limitations with LevelDB

by tete 15y ago

premchai21 15y ago

Do Tokyo Cabinet and Kyoto Cabinet still use totally unprotected mmap? Last I checked, truncating the DB file in the middle of an operation would take down the entire process with SIGBUS, and I assume a disk error would do something similar. This seems like it'd be bad for fault tolerance. Or are storage devices just that reliable nowadays, or does enough else break along with them that they're considered a critical component anyway?

pak 15y ago

I just found these two little jewels and have been using them to provide fast access to a haystack of images (GB to TB size, each image about ~1KB). I am curious to hear what others think about moving from Tokyo to Kyoto--the website says Kyoto is recommended, but there is a real dearth of information about Kyoto (at least in English) out on the web, compared with the scattered breadcrumbs that you can sort of piece together for information on Tokyo. Most of those breadcrumbs are unfortunately silly benchmark articles instead of real experiences. Also, I already did have one Tokyo Cabinet Hashtable go corrupt on me--which caused certain operations to lock up the CPU indefinitely. Hmm, that didn't ease my conscience. However, it was completely recoverable with "tchmgr optimize". It'd be nice to google for more war stories, but like I said... breadcrumbs so far.

hcles 15y ago

My experience with their B+ Tree database is that when your database size hits a Gb or more, closing the database can take up to 10mins or more (depending on writes queued), and opening a database that was not closed correctly rebuilds the entire database. I've not found any such limitations with LevelDB