10225101440
/
leveldb_ttl
forkattu lähteestä building_data_management_systems.Xuanzhou.2024Fall.DaSE/leveldb_base
1
0
Fork 0
Koodi Ongelmat 0 Pull-pyynnöt 0 Julkaisut 0 Wiki Toiminta
作者： 韩晨旭 10225101440 李畅 10225102463
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
42 Commitit
3 Branchit
9.6 MiB
Puu: 3cc27381f7
Branchit Tagit
${ item.name }
Create branch ${ searchTerm }
from '3cc27381f7'
${ noResults }
leveldb_ttl/TODO

13 rivejä
494 B
Raaka Normaali näkymä Historia

Initial checkin. git-svn-id: https://leveldb.googlecode.com/svn/trunk@2 62dab493-f737-651d-591e-8d6aee1b9529
13 vuotta sitten
​
​
​
​
​
​
​
​
​
A number of smaller fixes and performance improvements: - Implemented Get() directly instead of building on top of a full merging iterator stack. This speeds up the "readrandom" benchmark by up to 15-30%. - Fixed an opensource compilation problem. Added --db=<name> flag to control where the database is placed. - Automatically compact a file when we have done enough overlapping seeks to that file. - Fixed a performance bug where we would read from at least one file in a level even if none of the files overlapped the key being read. - Makefile fix for Mac OSX installations that have XCode 4 without XCode 3. - Unified the two occurrences of binary search in a file-list into one routine. - Found and fixed a bug where we would unnecessarily search the last file when looking for a key larger than all data in the level. - A fix to avoid the need for trivial move compactions and therefore gets rid of two out of five syncs in "fillseq". - Removed the MANIFEST file write when switching to a new memtable/log-file for a 10-20% improvement on fill speed on ext4. - Adding a SNAPPY setting in the Makefile for folks who have Snappy installed. Snappy compresses values and speeds up writes. git-svn-id: https://leveldb.googlecode.com/svn/trunk@32 62dab493-f737-651d-591e-8d6aee1b9529
13 vuotta sitten
​
​
 
  1. ss
  2. - Stats
  3. 

  4. db
  5. - Maybe implement DB::BulkDeleteForRange(start_key, end_key)
  6.   that would blow away files whose ranges are entirely contained
  7.   within [start_key..end_key]?  For Chrome, deletion of obsolete
  8.   object stores, etc. can be done in the background anyway, so
  9.   probably not that important.
  10. 

  11. After a range is completely deleted, what gets rid of the
  12. corresponding files if we do no future changes to that range.  Make
  13. the conditions for triggering compactions fire in more situations?