3 ms·
Great read :-) Hooray for another Perl fan as well as for the simplicity and power of BerkeleyDB/other similar dbs. Have you look at Tokyo Cabinet / Tokyo Tyran
by strlen 18y ago
Great read :-) Hooray for another Perl fan as well as for the simplicity and power of BerkeleyDB/other similar dbs. Have you look at Tokyo Cabinet / Tokyo Tyrant ( http://tokyocabinet.sourceforge.net/index.html http://tokyocabinet.sourceforge.net/index.html )
Also, what is the URL of the project/site/start-up you're scaling. I am interested very much in seeing the seeds of this effort.
- streety 18y agoThe first slide says that the presentation is by Mark Maunder with an email address at http://feedjit.com http://feedjit.com so I'm guessing that's the site being optimized. The content in the presentation does make sense for what feedjit does.
- gcv 18y agoTokyo Cabinet looks intriguing. One major limitation of Berkeley DB is that it cannot reliably store its files on a network filesystem (NFS or CIFS or what have you) because of unreliable POSIX semantics. It's a tough problem, but any idea if Tokyo Cabinet tackles it?
- strlen 18y agoUsing NFS doesn't seem like a good idea for this situation - from the operations perspective, NFS in production is going to be hell anyway. A better way would be (since Tokyo Cabinet is thread safe) having a separate thread/process which receives messages (using a message queuing system) that update the database files (ala MySQL replications). (Or you can separate out the db layer as a separate network service and partition the writes/reads to go to a specific several servers based on the key. Tokyo Cabinet even includes a memcached API compatible network layer for this - the Tokyo Tyrant).