Minor modifications.
This commit is contained in:
parent
733e9605b4
commit
217b833572
2 changed files with 17 additions and 16 deletions
|
|
@ -400,11 +400,12 @@ Compilé pour la dernière fois le
|
|||
.de ABSTRACT2
|
||||
.AE
|
||||
..
|
||||
.ds CH Page %
|
||||
.ds LH Page %
|
||||
.ds CH
|
||||
.de TITLE
|
||||
.TL
|
||||
\\$*
|
||||
.ds LH \\$*
|
||||
.\".ds LH \\$*
|
||||
.de HD .XX
|
||||
.sp -2.3
|
||||
.nr LINEWIDTH (\n[LL]/1.0i)
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ DODB can provide a filesystem representation of those indexes to enable off-appl
|
|||
or even a file explorer.
|
||||
|
||||
This document briefly presents DODB and its main differences with other database engines.
|
||||
Limits of such approach are discussed.
|
||||
Limitations of such approach are discussed.
|
||||
An experiment is described and analyzed to understand the performance that can be expected.
|
||||
.ABSTRACT2
|
||||
.SINGLE_COLUMN
|
||||
|
|
@ -208,7 +208,7 @@ In its current form and on commodity hardware, DODB aims for projects with up to
|
|||
There are no real hard limits but the underlying filesystem, DODB can accept billions of entries.
|
||||
.br
|
||||
See the section
|
||||
.dq "Limits of DODB" .
|
||||
.dq "Limitations of DODB" .
|
||||
.FOOTNOTE2
|
||||
However, its simplicity (approach and code) enables quick adaptations for specific needs.
|
||||
DODB may be a great starting point to implement more sophisticated features for creative minds.
|
||||
|
|
@ -242,7 +242,7 @@ Section 3 introduces caches in both the database and triggers.
|
|||
Section 4 presents the Common database, a storage facility that should be relevant for most applications.
|
||||
Section 5 presents the RAM-only database, for short-lived (temporary) data.
|
||||
Section 6 is about memory-constrained environments.
|
||||
Section 7 presents a few experiments to provide an overview of the performance you can expect from this approach.
|
||||
Section 7 presents a few experiments to provide an overview of the performance you can expect from DODB and similar approaches.
|
||||
Section 8 describes the limitations of DODB and its current implementation.
|
||||
Section 9 presents the related work, alternative approaches and implementations.
|
||||
Section 10 gives an overview of the current state of affairs regarding security in DODB.
|
||||
|
|
@ -251,11 +251,11 @@ Section 12 presents a real-world usage of DODB.
|
|||
Finally, section 13 provides a conclusion.
|
||||
.
|
||||
.SECTION How DODB works and basic usage
|
||||
DODB can be briefly described as a lookup table using an auto-incremented number as key, and data is stored in plain files (the key being used as file name).
|
||||
DODB can be briefly described as a lookup table using an auto-incremented number as key, and storing data in plain files (the key being used as filename).
|
||||
This section explains how to use DODB for basic cases including the few added mechanisms to speed-up searches.
|
||||
Also, the filesystem representation of the data is presented since it enables easy off-application searches.
|
||||
|
||||
The presented code is in Crystal such as the DODB library.
|
||||
The presented code is written in Crystal, as in the DODB library.
|
||||
Keep in mind that this document is all about the method more than the current implementation.
|
||||
Anyone could implement the exact same library in almost every other language.
|
||||
.
|
||||
|
|
@ -278,7 +278,7 @@ Let's create a DODB database for our cars.
|
|||
# Database creation
|
||||
database = DODB::Storage::Uncached(Car).new "path/to/db-cars"
|
||||
|
||||
# Add an element to the db
|
||||
# Add an item to the db
|
||||
database << Car.new "Corvet", "red", ["elegant", "fast"]
|
||||
|
||||
# Access all objects in the database
|
||||
|
|
@ -286,7 +286,7 @@ database.each do |car|
|
|||
pp! car
|
||||
end
|
||||
.SOURCE
|
||||
Inserted entries are serialized\*[*] and written in a dedicated file.
|
||||
Inserted entries are serialized\*[*] and written to a dedicated file.
|
||||
.FOOTNOTE1
|
||||
Serialization is currently in JSON.
|
||||
.[
|
||||
|
|
@ -310,7 +310,7 @@ db-cars/
|
|||
.TREE2
|
||||
In this example, the directory
|
||||
.I db-cars/data
|
||||
contains the serialized value with a formated number as file name.
|
||||
contains the serialized value with a formated number as filename.
|
||||
The file "0000000000" contains the following:
|
||||
.QP
|
||||
.SOURCE JSON ps=9 vs=10
|
||||
|
|
@ -328,7 +328,7 @@ The car is serialized as expected in the file
|
|||
.QE
|
||||
.
|
||||
.
|
||||
The key of the entry (its number) is required to directly modify the database entries.
|
||||
The key of the entry (its number) is required to modify it.
|
||||
.
|
||||
.QP
|
||||
.SOURCE Ruby ps=9 vs=10
|
||||
|
|
@ -638,14 +638,14 @@ Requested, added or modified values are considered
|
|||
In case a new value is added to the cache and that the number of entries exceeds the cache size, the least recently used value is evicted, along with its related data from the cache.
|
||||
|
||||
.B "The Least Recently Used algorithm" .
|
||||
Each time a value is added in the database, its key is put as the first element of a
|
||||
Each time a value is added in the database, its key is put as the first item of a
|
||||
.I set
|
||||
structure (each value is unique).
|
||||
This set is ordered, the first element being the most recently used.
|
||||
This set is ordered, the first item being the most recently used.
|
||||
Adding a value that is already present in the set is considered as
|
||||
.I "using the value" ,
|
||||
thus it is moved at the start of the set.
|
||||
In case the number of entries exceeds what is allowed, the least recently used value is therefore the last element of the set.
|
||||
In case the number of entries exceeds what is allowed, the least recently used value is therefore the last item of the set.
|
||||
|
||||
.B "Implementation details" .
|
||||
The LRU strategy is both simple and can be easily implemented efficiently with a double-linked list and a lookup table.
|
||||
|
|
@ -1030,7 +1030,7 @@ With Postgres, the request duration of a single value varies from 0.1 to 2 ms on
|
|||
.
|
||||
.
|
||||
.
|
||||
.SECTION Limits of DODB
|
||||
.SECTION Limitations of DODB
|
||||
DODB provides basic database operations such as storing, retrieving, modifying and removing data but doesn't fully handle ACID properties nor a few other aspects generally associated with databases\*[*].
|
||||
.FOOTNOTE1
|
||||
Traditional SQL databases may have created some "expectations" towards databases from a general public standpoint, such as the ACID properties (atomicity, consistency, isolation and durability), transactions and replication.
|
||||
|
|
@ -1909,7 +1909,7 @@ When the cache size is not sufficient, the requests are hundred times slower, wh
|
|||
.QP
|
||||
This figure shows the request durations to retrieve data based on a tag containing up to 5k entries.
|
||||
.QE
|
||||
As for partitions, the response time depends on the number of entries to retrieve and the duration increases linearly with the number of elements.
|
||||
As for partitions, the response time depends on the number of entries to retrieve and the duration increases linearly with the database size.
|
||||
.
|
||||
.
|
||||
.APPENDIX Recap of the DODB API
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue