A few minor modifications to the paper.
This commit is contained in:
parent
6beccbb96b
commit
d275dc10bd
@ -290,13 +290,23 @@ attribute can be used to speed-up searches.
|
||||
cars_by_name = cars.new_index "name", do |car|
|
||||
car.name
|
||||
end
|
||||
|
||||
# Two other ways to say the same thing, thanks to the Crystal syntax:
|
||||
cars_by_name = cars.new_index "name", { |car| car.name }
|
||||
cars_by_name = cars.new_index "name", &.name
|
||||
.SOURCE
|
||||
Once the index has been created, every added or modified entry in the database will be indexed.
|
||||
Adding an index (basic index, partition or tag) provides an object used to manipulate the database based on this index.
|
||||
Adding an index (basic index, partition or tag) provides an
|
||||
.I object
|
||||
used to manipulate the database based on this index.
|
||||
Let's call it an
|
||||
.I "index object" .
|
||||
In the code above, the
|
||||
.I "index object"
|
||||
is named
|
||||
.I "cars_by_name" .
|
||||
.QE
|
||||
.
|
||||
|
||||
The
|
||||
.I "index object"
|
||||
has several useful functions.
|
||||
@ -311,7 +321,6 @@ cars_by_name.update "Corvet", new_car
|
||||
|
||||
# In case the index hasn't changed (the name attribute in this example),
|
||||
# the update can be even simpler.
|
||||
new_car = Car.new "Corvet", "green", ["eco-friendly"]
|
||||
cars_by_name.update new_car
|
||||
|
||||
# Delete the car named "Corvet".
|
||||
@ -354,6 +363,9 @@ attribute of our cars.
|
||||
cars_by_color = database.new_partition "color", do |car|
|
||||
car.color
|
||||
end
|
||||
|
||||
# Shortcut:
|
||||
cars_by_color = database.new_partition "color", &.color
|
||||
.SOURCE
|
||||
.QE
|
||||
As with basic indexes, once the partition is asked to the database, every new or modified entry will be indexed.
|
||||
@ -396,6 +408,9 @@ Tags are basically partitions but the indexed attribute can have multiple values
|
||||
cars_by_keywords = database.new_tags "keywords", do |car|
|
||||
car.keywords
|
||||
end
|
||||
|
||||
# Shortcut:
|
||||
cars_by_keywords = database.new_tags "keywords", &.keywords
|
||||
.SOURCE
|
||||
As with other indexes, once the tag is requested to the database, every new or modified entry will be indexed.
|
||||
.QE
|
||||
@ -464,9 +479,9 @@ A cached database has the same API as the other DODB databases.
|
||||
database = DODB::Storage::Cached(Car).new "path/to/db-cars"
|
||||
.SOURCE
|
||||
All operations of the
|
||||
.CLASS DODB::Storage::Basic
|
||||
.CLASS Storage::Basic
|
||||
class are available for
|
||||
.CLASS DODB::Storage::Cached .
|
||||
.CLASS Storage::Cached .
|
||||
.QE
|
||||
.
|
||||
.SS Cached indexes
|
||||
@ -844,7 +859,9 @@ In our example, each \f[CW]car\f[] has an unique \fIname\f[] which is used as an
|
||||
The following graph represents the result of 100 queries of a car based on its name.
|
||||
The experiment starts with a database containing 1,000 cars and goes up to 250,000 cars.
|
||||
|
||||
.ps -2
|
||||
.so graph_query_index.grap
|
||||
.ps \n[PS]
|
||||
|
||||
Since there is only one value to retrieve, the request is quick and time is almost constant.
|
||||
When the value and the index are kept in memory (see \f[CW]RAM only\f[] and \f[CW]Cached db\f[]), the retrieval is almost instantaneous (about 50 to 120 ns).
|
||||
@ -879,11 +896,15 @@ Caching the value enables a massive performance gain, data can be retrieved seve
|
||||
.SS Partitions (1 to n relations)
|
||||
.LP
|
||||
|
||||
.ps -2
|
||||
.so graph_query_partition.grap
|
||||
.ps \n[PS]
|
||||
|
||||
.SS Tags (n to n relations)
|
||||
.LP
|
||||
.ps -2
|
||||
.so graph_query_tag.grap
|
||||
.ps \n[PS]
|
||||
.
|
||||
.
|
||||
.
|
||||
|
Loading…
Reference in New Issue
Block a user