3 ms·
the reason why not using sql is that the thing I am doing is more about using a "library" (like what tokyo cabinet c api provides). SQLite may be good for this
by liuliu 17y ago
the reason why not using sql is that the thing I am doing is more about using a "library" (like what tokyo cabinet c api provides). SQLite may be good for this purpose but still, I guess there will be a simpler implementation specially for attacking this kind of problem. MySQL/PgSQL is not suitable because of the authorization mechanism.
- silentbicycle 17y agoSQLite is a C library, and is called in-process. It's probably the best fitting relational database for your problem, as I understand it. You've painted a pretty incomplete picture, though. The constraints on the problem (how much simultaneous r/w access, size of the data set, etc.) will have the most impact on what to choose, but it doesn't seem like you've fleshed that out anywhere else in the thread.
- liuliu 17y agoin my scenario, it is a read-heavy database with occasionally writes. As average about 3 tags for 500,000 images, it should supports 1.5 million in-memory records on one computer. for performance, I expect ~100ms to retrieve 100,000 records.