0%

发表于

下面这个类可以静态枚举字段：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
struct A : Base {
    ADD_FIELD(int, a, 110);
    ADD_FIELD(double, b, 1.2);
    ADD_FIELD(std::string, c, "OK");
    ADD_FIELD(uint32_t, d, 27);
    std::string others;
};

int main() {
    A a;
    Helper::visit([](std::string_view name, auto &&value) {
        std::print("name: {} value: {}\n", name, value);
    }, a);

    Helper::apply([](int a, double b, std::string_view c, uint32_t d) {
        std::print("a: {} b: {} c: {} d: {}\n", a, b, c, d);
    }, a);
}

感谢某同事手把手教会我写这个 demo

阅读全文 »

发表于 更新于

原文：Better bitmap performance with Roaring bitmaps

TL;DR

本文提出了一种 bitmap 压缩格式 Roaring，它使用自适应的两级索引结构，分别用 bitmap 保存 dense 数据、用数组保存 sparse 数据，由此在空间占用与常见操作性能之间取得了很好的平衡。

相比 trivial 的 bitset 实现，Roaring 在内存占用，以及超稀疏场景下的操作性能上都有着明显的优势。相比基于 RLE 的 WAH 和 Concise 两种格式，它在空间占用与操作性能上都有着明显的优势。

Roaring 属于是一看就觉得 make sense，早该如此的 idea。

阅读全文 »

发表于 更新于

原文：Order-Preserving Key Compression for In-Memory Search Trees

TL;DR

本文提出了一种针对字符串的分段编码框架 HOPE（High-speed Order-Preserving Encoder），在构建初始字典之后，可以流式编码任意字符串。且，重点来了，编码之间仍然保持原有字符串的顺序。这样 HOPE 的适用范围就不仅仅是静态的压缩已有数据了，它还能直接与各种树结构结合，直接用编码后的值作为 key。这样的好处有：

  1. 对于 B-tree 等，更短的 key 意味着更大的 fanout。
  2. 对于 Trie 等，更短的 key 意味着更低的高度。
  3. 节省空间有助于在内存中维护更多数据（如 cache 等）。
  4. 节省空间有助于提升 cache 性能。

令我大开眼界。直觉这篇 paper 比较实用。

阅读全文 »

发表于 更新于

原文：InfiniFS: An Efficient Metadata Service for Large-Scale Distributed Filesystems

TL;DR

InfiniFS 针对的是如何实现超大规模的单一分布式文件系统，目标上有些类似于 Facebook 的 Tectonic。但 InfiniFS 仍然是比较正统的、遵守 POSIX 语义的 fs，而 Tectonic 则是 HDFS 的升级版，目的是解决 Facebook 自身业务遇到的实际问题。

InfiniFS 看上去是 LocoFS 的后继，延续了 LocoFS 将 metadata 分成两部分的设计（但针对所有 inode 而不只是 f-inode）。另外 InfiniFS 还从 HopsFS 借鉴了并发 load inode。除此之外 InfiniFS 还有如下独特设计：

  1. client 端可以通过 hash 预测 inode id。结合并发 load inode，可以有效降低 network trip。
  2. client 与 metadata server 共同维护的一致性 cache。
  3. 单独的 rename coordinator。

整体看下来感觉 InfiniFS 的完成度还是比较高的，很实用，可能和有阿里云的前同事参与有比较大的关系。

阅读全文 »