Check out:
http://jaksprats.wordpress.com/2010/09/28/introducing-redisql-the-lightning-fast-polyglot/
On Nov 3, 2010, at 10:51 AM, Jay A. Kreibich wrote:
> On Wed, Nov 03, 2010 at 05:10:22PM +0300, Alexey Pechnikov scratched
> on the wall:
>> 2010/11/3 Jay A. Kreibich <j...@kreibi.ch>
>>>
>>> Why not just use an off-the-self hash cache, like memcached, or an
>>> off-the-self hash database, like Redis? Redis even supports an
>>> Append-Only write mode (e.g. WAL-ish journal mode).
>>
>> How about power fail or OS crash? As I know, Redis does not
>> garantees the
>> data safety.
>
> This is getting a bit off topic, but quickly...
>
> No, by default Redis does not provide the level of protection a
> default file-backed SQLite database provides. Redis's append-only
> mode does a pretty good job, however. Redis will update journal
> with each command, and a sync is performed every second. In theory,
> in the case of a power or OS crash, maximum data loss is right around
> one second worth of transactions. Application crash will not result
> in data loss, since the OS still has valid file buffers that will
> eventually be flushed. You can also configure things so that the
> journal syncs after each command, providing similar protection to
> SQLite. That is, as you might expect, somewhat slow, however.
>
>> And I think SQLite in-memory database is faster.
>
> Without testing, I'd guess Redis is faster for basic read/write
> operations. Redis is also a proper server and allows multiple client
> connections, even for a fully memory based data set.
>
> By default Redis will hold all data in RAM, and is highly optimized
> for one-- and only one-- basic operation, while SQLite is supporting
> a much richer and more expressive data processing environment.
>
> Each tool has its place, and they're not really trying to solve
> the same problem.
>
> The whole reason I'm looking to merge the two has to do with SQLite's
> expressive environment. In designing a very high-performance app,
> the highly-optimized common-case queries can talk to Redis directly.
> This is fast, but requires jumping through a lot of hoops in the
> application code. Conversely, the less frequent queries (including
> many of the management tasks) can talk to SQLite, which can then talk
> to Redis. Use of the SQL language makes development MUCH faster for
> those operations that are not as performance-critical.
>
> -j
>
> --
> Jay A. Kreibich < J A Y @ K R E I B I.C H >
>
> "Intelligence is like underwear: it is important that you have it,
> but showing it to the wrong people has the tendency to make them
> feel uncomfortable." -- Angela Johnson
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
