> > Okay, this is just an idea ... Why not support a real database then to > > store > > the data (read the first * below before you react)? > > You could use JDBC and a database if you wanted to. I personally hate it > when software uses a database when it's not necessary. You need to set up > a database (which often requires root access) and that's a pain. For high > traffic nodes it might be a good idea. Relational databases are generally > optimized for do fast lookups on relationships. What we want to do really > is just find the file based on a simple hash table and then transfer it as > fast as possible. I think an in-memory hashtable pointing to files on the > filesystem (possibly buffered in memory if there is a lot of RAM) works > fine for this for many, many files.
Yes, but an in-memory hashtable would fail to scale. He's right on at least that count... if you have a 20gb node, keeping the index in memory just won't hack it. This is the sort of thing an rdbms is meant to handle. The concurrency control and query optimization would be tremendous boons. > > All of this superoptimization for high-traffic, high-end nodes is not > really relevant to the reference implementation, which needs to be > optimized more towards featurefulness and standards compliance. Speed > junkies are going to want a C node instead anyway so they can squeeze out > some CPU cycles. So I would say that while there might be an audience for > this sort of thing, it's probably pretty small and not appropriate for > inclusion in the reference implementation. Indeed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000803/2f1dac68/attachment.pgp>
