Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding a library to support for reading from/writing to memory addresses #183

Open
robinlee09201 opened this issue Dec 15, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@robinlee09201
Copy link

Request

Currently, CLP/CLG only supports writing to/reading from files under a specific directory structure in a POSIX file system. However, some FSless applications may wish to store/read data to/from a memory address. A fuse layer may achieve this, but it may cause huge overhead. It would be great to use CLP/CLG as a library providing memory interfaces.

Possible implementation

Providing a C++ class which includes pointers to memory buffers that would otherwise be stored in the archive directory in the current implementation. This class also allows users to call compress, decompress, and search directly instead of going through the command line.

@robinlee09201 robinlee09201 added the enhancement New feature or request label Dec 15, 2023
@kirkrodrigues
Copy link
Member

The motivation makes sense. The current archive format has several files with different write patterns:

  • logtype.dict, var.dict, logtype.segindex, var.segindex
    • Write pattern: Mostly sequential but has a header that requires seeking
    • Read pattern: Sequential if the archive has been closed for writing, mostly sequential otherwise
  • s/<id>
    • Write pattern: Sequential, chunk by chunk, where each chunk is a column (timestamps, logtype IDs, or variables)
    • Read pattern: Sequential, chunk by chunk
  • metadata
    • Write pattern: Random
    • Read pattern: Sequential
  • metadata.db
    • Write pattern: Random (sqlite-implementation dependent)
    • Read pattern: Random (sqlite-implementation dependent)

Some questions:

Compression

  1. How would the proposed class handle the write workloads given that the buffers need to grow over time? I imagine we want to avoid static allocations, but dynamic allocations are non-trivial if we need to grow + copy.
  2. To support writing (and reading) metadata.db in-memory, we'd need to implement a SQLITE VFS interface, right?

Search

  1. Could you describe the interface changes you'd need to make? I can imagine you need to change the reader::Archive interface to take the new class as another input type. How about the internals of reader::Archive and reader::File?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants