Commit f57b0331 authored by Kirill Smelkov's avatar Kirill Smelkov

.

parent 53ffcb26
...@@ -22,7 +22,8 @@ ...@@ -22,7 +22,8 @@
# cython: language_level=2 # cython: language_level=2
# distutils: language=c++ # distutils: language=c++
"""XXX""" """Modules _file_zodb.pyx complements file_zodb.py with things that cannot be
implemented in Python."""
from __future__ import print_function, absolute_import from __future__ import print_function, absolute_import
......
...@@ -97,7 +97,7 @@ To represent BigFile as ZODB objects, each file block is represented separately ...@@ -97,7 +97,7 @@ To represent BigFile as ZODB objects, each file block is represented separately
either as either as
1) one ZODB object, or (ZBlk0) 1) one ZODB object, or (ZBlk0)
2) group of ZODB objects (ZBlk1) XXX wcfs loads in parallel 2) group of ZODB objects (ZBlk1)
with top-level BTree directory #blk -> objects representing block. with top-level BTree directory #blk -> objects representing block.
...@@ -112,7 +112,7 @@ For "2" we have ...@@ -112,7 +112,7 @@ For "2" we have
- low-overhead in terms of ZODB size (only part of a block is overwritten - low-overhead in terms of ZODB size (only part of a block is overwritten
in DB on single change), but in DB on single change), but
- high-overhead in terms of access time - high-overhead in terms of access time
(several objects need to be loaded for 1 block) (several objects need to be loaded for 1 block(*))
In general it is not possible to have low-overhead for both i) access-time, and In general it is not possible to have low-overhead for both i) access-time, and
ii) DB size, with approach where we do block objects representation / ii) DB size, with approach where we do block objects representation /
...@@ -122,6 +122,10 @@ On the other hand, if object management is moved to DB *server* side, it is ...@@ -122,6 +122,10 @@ On the other hand, if object management is moved to DB *server* side, it is
possible to deduplicate them there and this way have low-overhead for both possible to deduplicate them there and this way have low-overhead for both
access-time and DB size with just client storing 1 object per file block. This access-time and DB size with just client storing 1 object per file block. This
will be our future approach after we teach NEO about object deduplication. will be our future approach after we teach NEO about object deduplication.
(*) wcfs loads ZBlk1 subobjects in parallel, but today ZODB storage servers do
not scale well on such highly-concurrent access.
""" """
# ZBigFile organization # ZBigFile organization
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment