Tue Jun 16 14:11:17 +0200 2009Sun Jun 28 15:16:20 +0200 2009anrfnq1Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 200912Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 200913Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 200914Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 200915Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 200916Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 200917Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 200918Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 200919Tue Jun 16 14:11:17 +0200 2009Wed Jun 17 00:01:16 +0200 20092Wed Jun 17 00:01:16 +0200 2009Wed Jun 17 00:01:16 +0200 2009trueedit: Say you want to find out what's behind the buzz of all these new [#nosql][nosql] databases. There's a large number to choose from today. All options come in varying degrees of maturity and characteristics so it'd be nice to know what solves your problem best. A non inclusive list of these databases or storage systems include [Memcache][mc][[DB]][mcd], [BerkleyDB][bdb], [Tokyo Cabinet][tc] / [Tyrant][tt], [Project Voldemort][pv], [Scalaris][sc], [Dynamite][dy], [Redis][red], [Persevere][psvr], [MongoDB][mo], [Solr][solr] or my favourite [CouchDB][cdb]. And these are just some of the open source ones.]]>janTue Jun 16 16:53:06 +0200 2009Tue Jun 16 16:53:06 +0200 2009falseAndres10Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009111Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009112Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009113Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009114Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009115Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009116Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009117Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009118Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009119Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009120Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009121Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009122Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009123Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009124Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009125Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009126Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009127Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009128Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009129Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009130Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009131Tue Jun 16 14:11:17 +0200 2009Sun Jun 28 15:16:20 +0200 20092LalitSun Jun 28 15:16:20 +0200 2009Sun Jun 28 15:16:20 +0200 2009trueedit: From time to time you see some crazy numbers posted to the reddits reddit of the internets internet that claim fantastic performance. ]]>Lalit32Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 20091“The (imaginary) SuperfastDB can store 450,000 items per second!”.]]>33Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009134Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009135Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009136Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009137Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009138Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009139Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009140Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009141Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 20091Tue Jun 16 15:02:23 +0200 2009Tue Jun 16 15:02:23 +0200 2009falselangalex42Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 14:11:17 +0200 2009143Tue Jun 16 14:11:17 +0200 2009Tue Jun 16 18:12:39 +0200 20092Tue Jun 16 18:12:39 +0200 2009Tue Jun 16 18:12:39 +0200 2009trueedit: Context is as important as reproducibility. The last article [last article][last] here established that finding out that my system and your system come up with different numbers is not much of a help. Any sort of serious test must come with a set of scripts or programs and comprehensive instructions on how the tests were run.]]>janTue Jun 16 17:27:13 +0200 2009Tue Jun 16 17:27:13 +0200 2009falseCK44Tue Jun 16 18:12:38 +0200 2009Tue Jun 16 18:12:39 +0200 20091Tue Jun 16 18:12:39 +0200 2009Tue Jun 16 18:12:39 +0200 2009trueedit: added new line]]>jan45Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009146Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009147Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009148Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009149Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009150Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009151Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009152Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009153Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009154Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009155Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009156Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009157Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009158Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 18:13:22 +0200 20093Tue Jun 16 18:13:23 +0200 2009Tue Jun 16 18:13:23 +0200 2009trueedit: Hashing revolves around the idea of [`O(1)`][o] lookups. Allocate a number of buckets, create a function that gives you a number of a bucket for any data item you might want to store, make sure no two data items hit the same bucket (or work around that). Runtime characteristics include that you only need to ask your function where to look for or store your data and the allocation of your set of buckets: If you need to store more items than you have buckets, some more work is required which gives you some non-`O(1)` O(N)` operations that you can't ignore in practice.]]>janTue Jun 16 18:13:23 +0200 2009Tue Jun 16 18:13:23 +0200 2009trueedit: Hashing revolves around the idea of [`O(1)`][o] lookups. Allocate a number of buckets, create a function that gives you a number of a bucket for any data item you might want to store, make sure no two data items hit the same bucket (or work around that). Runtime characteristics include that you only need to ask your function where to look for or store your data and the allocation of your set of buckets: If you need to store more items than you have buckets, some more work is required which gives you some non-`O(1)` O(N)` operations that you can't ignore in practice.]]>janTue Jun 16 18:13:22 +0200 2009Tue Jun 16 18:13:22 +0200 2009trueedit: Hashing revolves around the idea of [`O(1)`][o] lookups. Allocate a number of buckets, create a function that gives you a number of a bucket for any data item you might want to store, make sure no two data items hit the same bucket (or work around that). Runtime characteristics include that you only need to ask your function where to look for or store your data and the allocation of your set of buckets: If you need to store more items than you have buckets, some more work is required which gives you some non-`O(1)` O(N)` operations that you can't ignore in practice.]]>janTue Jun 16 18:13:22 +0200 2009Tue Jun 16 18:13:22 +0200 2009trueedit: Hashing revolves around the idea of [`O(1)`][o] lookups. Allocate a number of buckets, create a function that gives you a number of a bucket for any data item you might want to store, make sure no two data items hit the same bucket (or work around that). Runtime characteristics include that you only need to ask your function where to look for or store your data and the allocation of your set of buckets: If you need to store more items than you have buckets, some more work is required which gives you some non-`O(1)` O(N)` operations that you can't ignore in practice.]]>janTue Jun 16 17:31:13 +0200 2009Tue Jun 16 17:31:13 +0200 2009falseCKTue Jun 16 16:57:26 +0200 2009Tue Jun 16 16:57:26 +0200 2009falseAndresTue Jun 16 16:55:31 +0200 2009Tue Jun 16 16:55:31 +0200 2009falseAndresTue Jun 16 16:55:22 +0200 2009Tue Jun 16 16:55:22 +0200 2009trueedit: Hashing revolves around the idea of [`O(1)`][o] lookups. Allocate a number of buckets, create a function that gives you a number of a bucket for any data item you might want to store, make sure no two data items hit the same bucket (or work around that). Runtime characteristics include that you only need to ask your function where to look for or store your data and the allocation of your set of buckets: If you need to store more items than you have buckets, some more work is required which gives you some non-`O(1)` operations that you can't ignore in practice.]]>Andres59Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091]]>60Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 17:31:34 +0200 20092CKTue Jun 16 17:31:34 +0200 2009Tue Jun 16 17:31:34 +0200 2009trueedit:

]]>CKTue Jun 16 17:31:34 +0200 2009Tue Jun 16 17:31:34 +0200 2009trueedit:

]]>CKTue Jun 16 17:31:34 +0200 2009Tue Jun 16 17:31:34 +0200 2009trueedit:

]]>CKTue Jun 16 17:31:34 +0200 2009Tue Jun 16 17:31:34 +0200 2009trueedit:

]]>CK61Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009162Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009163Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009164Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 15:07:17 +0200 20093Tue Jun 16 16:56:55 +0200 2009Tue Jun 16 16:56:55 +0200 2009falseAndresTue Jun 16 16:49:34 +0200 2009Tue Jun 16 16:49:34 +0200 2009falsechrisTue Jun 16 15:07:17 +0200 2009Tue Jun 16 15:07:17 +0200 2009trueedit: The other elephant in the room are [b-trees][btr]. The fundamental idea here is to get to your data in a minimal number of steps traversing a tree because making a step is expensive, but reading your data is very fast comparatively. Steps are expensive because they translate to a head seek (that is the time your spinning hard drive needs to position the reading arm that hovers over the plate finds to find the spot to read your data from), but reading from a harddrive once the reading head is in place is fast.]]>langalexTue Jun 16 15:07:17 +0200 2009Tue Jun 16 15:07:17 +0200 2009trueedit: The other elephant in the room are [b-trees][btr]. The fundamental idea here is to get to your data in a minimal number of steps traversing a tree because making a step is expensive, but reading your data is very fast comparatively. Steps are expensive because they translate to a head seek (that is the time your spinning hard drive needs to position the reading arm that hovers over the plate finds to find the spot to read your data from), but reading from a harddrive once the reading head is in place is fast.]]>langalexTue Jun 16 15:04:54 +0200 2009Tue Jun 16 15:04:54 +0200 2009trueedit: The other elephant in the room are [b-trees][btr]. The fundamental idea here is to get to your data in a minimal number of steps traversing a tree because making a step is expensive, but reading your data is very fast comparatively. Steps are expensive because the they translate to a head seek (that is the time your spinning hard drive needs to position the reading arm that hovers over the plate finds the spot to read your data from), but reading from a harddrive once the reading head is in place is fast.]]>langalex65Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091]]>66Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 17:32:46 +0200 20092CKTue Jun 16 17:32:46 +0200 2009Tue Jun 16 17:32:46 +0200 2009trueedit:

]]>CKTue Jun 16 17:32:46 +0200 2009Tue Jun 16 17:32:46 +0200 2009trueedit:

]]>CKTue Jun 16 17:32:46 +0200 2009Tue Jun 16 17:32:46 +0200 2009trueedit:

]]>CKTue Jun 16 17:32:46 +0200 2009Tue Jun 16 17:32:46 +0200 2009trueedit:

]]>CK67Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009168Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009169Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009170Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009171Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009172Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009173Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009174Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009175Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009176Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009177Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 17:34:12 +0200 20092CKTue Jun 16 17:34:13 +0200 2009Tue Jun 16 17:34:13 +0200 2009trueedit: Creating storage systems that assume only one access occurs at a time is relatively easy. If resource resources are shared concurrently, things become tricky. The two larger schools of thought (and practice) are locking and no-locking (heh).]]>CKTue Jun 16 17:34:13 +0200 2009Tue Jun 16 17:34:13 +0200 2009trueedit: Creating storage systems that assume only one access occurs at a time is relatively easy. If resource resources are shared concurrently, things become tricky. The two larger schools of thought (and practice) are locking and no-locking (heh).]]>CKTue Jun 16 17:34:13 +0200 2009Tue Jun 16 17:34:13 +0200 2009trueedit: Creating storage systems that assume only one access occurs at a time is relatively easy. If resource resources are shared concurrently, things become tricky. The two larger schools of thought (and practice) are locking and no-locking (heh).]]>CKTue Jun 16 17:34:12 +0200 2009Tue Jun 16 17:34:12 +0200 2009trueedit: Creating storage systems that assume only one access occurs at a time is relatively easy. If resource resources are shared concurrently, things become tricky. The two larger schools of thought (and practice) are locking and no-locking (heh).]]>CK78Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009179Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091Tue Jun 16 17:37:49 +0200 2009Tue Jun 16 17:37:49 +0200 2009falseCK80Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009181Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009182Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009183Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009184Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009185Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009186Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009187Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009188Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 18:14:18 +0200 20092Tue Jun 16 18:14:18 +0200 2009Tue Jun 16 18:14:18 +0200 2009trueedit: Hybrid approaches are possible too: While MVCC is used internally, the database's clients can rely on database-side locking (e.g. [PostgreSQL][post] or [InnoDB][inno]).]]>janTue Jun 16 16:58:36 +0200 2009Tue Jun 16 16:58:36 +0200 2009falseAndres89Tue Jun 16 18:14:18 +0200 2009Tue Jun 16 18:14:18 +0200 20091Tue Jun 16 18:14:18 +0200 2009Tue Jun 16 18:14:18 +0200 2009trueedit: added new line]]>jan90Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009191Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009192Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009193Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009194Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009195Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009196Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009197Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009198Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 2009199Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091100Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091101Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091102Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091103Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091104Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091105Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091106Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091107Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091108Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091109Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091110Tue Jun 16 14:11:18 +0200 2009Tue Jun 16 14:11:18 +0200 20091111Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091Tue Jun 16 17:43:10 +0200 2009Tue Jun 16 17:43:10 +0200 2009falseCKTue Jun 16 17:00:32 +0200 2009Tue Jun 16 17:00:32 +0200 2009falseAndres112Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091113Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091Tue Jun 16 17:08:07 +0200 2009Tue Jun 16 17:08:07 +0200 2009falseCK114Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091115Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091116Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091117Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091118Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091119Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091Tue Jun 16 17:11:21 +0200 2009Tue Jun 16 17:11:21 +0200 2009falseAndresTue Jun 16 17:02:46 +0200 2009Tue Jun 16 17:02:46 +0200 2009falseAndres120Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091121Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091122Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091123Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091124Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091125Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091126Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091127Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091128Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091129Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091130Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091131Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 18:16:23 +0200 20092Tue Jun 16 18:16:23 +0200 2009Tue Jun 16 18:16:23 +0200 2009trueedit: Back to failure scenarios: Again, the reasons can be manifold, but what happens when we've (over-)written the first 4 digits of the old with the new number and then the server dies, power goes away or the database server crashes? The next time you want to read the phone number you get a mix of the old and the new one (if you are lucky) and you don't exactly know that this is the case and which parts are missing. Your database file is *inconsistent* and you need to run a *integrity check* to find missing bits and correct half-written bytes. In the worst case that means scanning your entire database file a few times before you resolved all inconstancies. If you have a lot of data, that takes a while.can take *days*.]]>janTue Jun 16 18:16:23 +0200 2009Tue Jun 16 18:16:23 +0200 2009trueedit: Back to failure scenarios: Again, the reasons can be manifold, but what happens when we've (over-)written the first 4 digits of the old with the new number and then the server dies, power goes away or the database server crashes? The next time you want to read the phone number you get a mix of the old and the new one (if you are lucky) and you don't exactly know that this is the case and which parts are missing. Your database file is *inconsistent* and you need to run a *integrity check* to find missing bits and correct half-written bytes. In the worst case that means scanning your entire database file a few times before you resolved all inconstancies. If you have a lot of data, that takes a while.can take *days*.]]>janTue Jun 16 16:53:00 +0200 2009Tue Jun 16 16:53:00 +0200 2009falsechris132Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091133Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 18:16:05 +0200 20093Tue Jun 16 18:16:05 +0200 2009Tue Jun 16 18:16:05 +0200 2009trueedit: To solve this, you always write the new phone number to a new place in the database file and only when it has been `fsync()`ed to disk, you update the location of the phone number (and then flush that update to disk as well). You will never end up in a scenario where your database file can end up an inconsistent state and after a crash you are back online without an integrity check that could take days.check.]]>janTue Jun 16 18:16:05 +0200 2009Tue Jun 16 18:16:05 +0200 2009trueedit: To solve this, you always write the new phone number to a new place in the database file and only when it has been `fsync()`ed to disk, you update the location of the phone number (and then flush that update to disk as well). You will never end up in a scenario where your database file can end up an inconsistent state and after a crash you are back online without an integrity check that could take days.check.]]>janTue Jun 16 18:15:55 +0200 2009Tue Jun 16 18:15:55 +0200 2009trueedit: To solve this, you always write the new phone number to a new place in the database file and only when it has been `fsync()`ed to disk, you update the location of the phone number (and then flush that update to disk as well). You will never end up in a scenario where your database file can end up an inconsistent state and after a crash you are back online without an integrity check.check that could take days.]]>janTue Jun 16 18:15:55 +0200 2009Tue Jun 16 18:15:55 +0200 2009trueedit: To solve this, you always write the new phone number to a new place in the database file and only when it has been `fsync()`ed to disk, you update the location of the phone number (and then flush that update to disk as well). You will never end up in a scenario where your database file can end up an inconsistent state and after a crash you are back online without an integrity check.check that could take days.]]>janTue Jun 16 17:04:23 +0200 2009Tue Jun 16 17:04:23 +0200 2009falseAndres134Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091135Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091136Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091137Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091138Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091139Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091140Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091141Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091142Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091143Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091144Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091145Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091146Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091147Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091148Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091149Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091150Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091151Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091152Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091153Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091154Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091155Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091156Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091157Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091158Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091159Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091160Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 18:23:23 +0200 20092Tue Jun 16 18:23:23 +0200 2009Tue Jun 16 18:23:23 +0200 2009trueedit: Distributing writes and data works by designating two machines with 50% of the operations. A clever intermediate, a proxy server for example, decides which request goes where and all is well, we can store twice as much and we can store at twice the speed. When we need to grow bigger yet, we add another server and tell the proxy server to distribute the load equally among them.them. Adding a proxy for distribution introduces a single point of failure and you don't want these; there's added complexity with this approach.]]>janTue Jun 16 18:23:23 +0200 2009Tue Jun 16 18:23:23 +0200 2009trueedit: Distributing writes and data works by designating two machines with 50% of the operations. A clever intermediate, a proxy server for example, decides which request goes where and all is well, we can store twice as much and we can store at twice the speed. When we need to grow bigger yet, we add another server and tell the proxy server to distribute the load equally among them.them. Adding a proxy for distribution introduces a single point of failure and you don't want these; there's added complexity with this approach.]]>janTue Jun 16 17:06:49 +0200 2009Tue Jun 16 17:06:49 +0200 2009falseAndres161Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091]]>162Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 17:20:55 +0200 20092CKTue Jun 16 17:20:55 +0200 2009Tue Jun 16 17:20:55 +0200 2009trueedit:

]]>CK163Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091164Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091165Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091166Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091167Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091168Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091169Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091Tue Jun 16 17:13:09 +0200 2009Tue Jun 16 17:13:09 +0200 2009falseAndres170Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091171Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091172Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091173Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091]]>174Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 17:22:20 +0200 20092CKTue Jun 16 17:22:20 +0200 2009Tue Jun 16 17:22:20 +0200 2009trueedit:

]]>CK175Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091176Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091177Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091178Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091179Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091180Tue Jun 16 14:11:19 +0200 2009Tue Jun 16 14:11:19 +0200 20091181Tue Jun 16 14:11:20 +0200 2009Tue Jun 16 14:11:20 +0200 20091182Tue Jun 16 14:11:20 +0200 2009Tue Jun 16 14:11:20 +0200 20091183Tue Jun 16 14:11:20 +0200 2009Tue Jun 16 14:11:20 +0200 20091184Tue Jun 16 14:11:20 +0200 2009Tue Jun 16 14:11:20 +0200 20091185Tue Jun 16 14:11:20 +0200 2009Tue Jun 16 14:11:20 +0200 20091186Tue Jun 16 14:11:20 +0200 2009Tue Jun 16 14:11:20 +0200 20091Tue Jun 16 22:57:29 +0200 2009Tue Jun 16 22:57:29 +0200 2009falselangalexTue Jun 16 22:57:17 +0200 2009Tue Jun 16 22:57:17 +0200 2009falselangalex