相关疑难解决方法(0)

我们的系统写入了大量数据（一种大数据系统）。写入性能足以满足我们的需求，但读取性能真的太慢了​​。

我们所有表的主键（约束）结构都相似：

timestamp(Timestamp) ; index(smallint) ; key(integer).

一个表可以有数百万行，甚至数十亿行，而一个读请求通常是针对特定时间段（时间戳/索引）和标记的。查询返回大约 20 万行是很常见的。目前，我们每秒可以读取大约 15k 行，但我们需要快 10 倍。这是可能的，如果是，如何？

注意： PostgreSQL 是和我们的软件一起打包的，所以不同客户端的硬件是不一样的。

它是一个用于测试的虚拟机。VM 的主机是具有 24.0 GB RAM 的 Windows Server 2008 R2 x64。

服务器规范（虚拟机 VMWare）

Server 2008 R2 x64
2.00 GB of memory
Intel Xeon W3520 @ 2.67GHz (2 cores)

postgresql.conf 优化

shared_buffers = 512MB (default: 32MB)
effective_cache_size = 1024MB (default: 128MB)
checkpoint_segment = 32 (default: 3)
checkpoint_completion_target = 0.9 (default: 0.5)
default_statistics_target = 1000 (default: 100)
work_mem = 100MB (default: 1MB)
maintainance_work_mem = 256MB …

在位串列上创建索引的最佳方法是什么？假设我有一个 type 列，bit(4)我想搜索所有设置了特定位的条目。所以如果我有条目：

bitfield | ...
--------------
1001
1010
0110
0010
0000 

如果我试图搜索所有0010设置的条目，我可以轻松地做到这一点。但是我可以使用索引来优化搜索吗？

我决定使用可为空字段或 jsonb 来存储用户配置文件。最初，这将用于联系人：email和phone。我预计稍后可能会添加其他列，例如mobile和website。此外，可能还有其他不相关的字段，例如设置/首选项、保存的搜索等。

我已经决定我不想为此使用任何形式的键值存储（或任何涉及多对多关系的模式），除非有非常好的理由。

jsonb 的优点：

• 如有必要，可以为每个“列”存储多个值
• 添加新字段只需要 JS 编码和文档

jsonb 的缺点：

• 将“列”名称存储为每个“行”的字符串的开销
• Wonky 执行比较查询（我认为我的使用场景不适用）
• 不得不期待意外

还有什么要添加到这个优点/缺点列表中的吗？尽管我只想使用可为空的列，但我认为忽略 jsonb 是一种疏忽 - 这似乎是一个令人信服的选择。