Comments for GenieDB News http://blog.geniedb.com Next generation distributed database technology Wed, 06 Oct 2010 17:37:23 +0000 hourly 1 http://wordpress.org/?v=3.1.2 Comment on Generic indices in GenieDB by Luke Marsden http://blog.geniedb.com/2010/09/27/generic-indices-in-geniedb/comment-page-1/#comment-595 Luke Marsden Wed, 06 Oct 2010 17:37:23 +0000 http://blog.geniedb.com/?p=132#comment-595 Seriously cool. Good work! Seriously cool. Good work!

]]> Comment on In-memory databases by Alaric Snell-Pym http://blog.geniedb.com/2010/05/27/in-memory-databases/comment-page-1/#comment-594 Alaric Snell-Pym Wed, 06 Oct 2010 13:25:53 +0000 http://blog.geniedb.com/?p=119#comment-594 Sure, in that not having to commit writes to disk means you don't need to be limited by disk bandwidth and the time taken to sync. But my point is that it's silly to make an <em>entire database</em> be "in-memory" or not. The real issue is whether some of your data (eg, a table) needs to be persistent. Turn off persistence, and writes can go faster. Turn on persistence, and writes are limited by disks, but are persistent. Databases like Redis also let you fine-tune that a little, choosing degrees of persistence. And it shouldn't affect read performance at all, once the cache has warmed up. Why can't we have a single database, with some tables (or even just some <strong>records</strong>?) being persistent-but-slow-to-write, and some being fast-to-write-but-lossy, as a tweaking option? Why do we need an entire separate database? Sure, in that not having to commit writes to disk means you don’t need to be limited by disk bandwidth and the time taken to sync.

But my point is that it’s silly to make an entire database be “in-memory” or not. The real issue is whether some of your data (eg, a table) needs to be persistent. Turn off persistence, and writes can go faster. Turn on persistence, and writes are limited by disks, but are persistent. Databases like Redis also let you fine-tune that a little, choosing degrees of persistence. And it shouldn’t affect read performance at all, once the cache has warmed up.

Why can’t we have a single database, with some tables (or even just some records?) being persistent-but-slow-to-write, and some being fast-to-write-but-lossy, as a tweaking option? Why do we need an entire separate database?

]]> Comment on In-memory databases by Seun Osewa http://blog.geniedb.com/2010/05/27/in-memory-databases/comment-page-1/#comment-567 Seun Osewa Thu, 12 Aug 2010 09:07:06 +0000 http://blog.geniedb.com/?p=119#comment-567 In-memory databases are much faster in most cases, though. In-memory databases are much faster in most cases, though.

]]> Comment on Replication by H2O Development Blog » Replication in GenieDB http://blog.geniedb.com/2010/04/02/replication/comment-page-1/#comment-464 H2O Development Blog » Replication in GenieDB Fri, 02 Apr 2010 08:50:04 +0000 http://blog.geniedb.com/?p=88#comment-464 [...] just read an interesting blog post on replication from the people at GenieDB. They are dealing with a problem that we face in developing H2O – [...] [...] just read an interesting blog post on replication from the people at GenieDB. They are dealing with a problem that we face in developing H2O – [...]

]]> Comment on Concurrency bugs are all the rage! by RJ http://blog.geniedb.com/2009/10/27/concurrency-bugs-are-all-the-rage/comment-page-1/#comment-63 RJ Wed, 28 Oct 2009 09:37:29 +0000 http://blog.geniedb.com/?p=26#comment-63 Not sure about solaris but on Linux you could run the daemon with the nohup command so it ignores The HUP when your ssh session drops. Not sure about solaris but on Linux you could run the daemon with the nohup command so it ignores The HUP when your ssh session drops.

]]>