标签: rocksdb

我读过Redis和RocksDB,我没有得到Redis优于RocksDB的优势.

我知道Redis全部在内存中,而RocksDB在内存中并使用闪存存储.如果所有数据都适合内存,我应该选择哪一个？他们有相同的表现吗？Redis与CPU的数量呈线性关系？我想还有其他一些我没有得到的差异.

我有一个适合内存的数据集,我打算选择Redis,但似乎RocksDB提供了相同的功能,如果有一天数据集增长太多,我就不必担心内存了.

在Apache Kafka 0.9和0.10的新功能调查期间,我们使用了KStreams和KTables.有一个有趣的事实是,Kafka在内部使用RocksDB.请参阅Kafka Streams简介:流处理变得简单.RocksDB不是用JVN兼容语言编写的,因此需要仔细处理部署,因为它需要额外的共享库(取决于操作系统).

这里有一些简单的问题:

• 为什么Apache Kafka Streams使用RocksDB？
• 怎么可能改变它？

我试图搜索答案,但我只看到隐含的原因,RocksDB在每秒大约数百万次操作范围内的操作非常快.

另一方面,我看到一些用Java编码的数据库,也许端到端他们可以做到这一点,而且他们不会通过JNI.

我试图找出我的kafka-streams应用程序内存不足的原因。我已经发现RocksDB消耗了大量本机内存，我尝试使用以下配置对其进行限制：

# put index and filter blocks in blockCache to avoid letting them grow unbounded (https://github.com/facebook/rocksdb/wiki/Block-Cache#caching-index-and-filter-blocks)
cache_index_and_filter_blocks = true;

# avoid evicting L0 cache of filter and index blocks to reduce performance impact of putting them in the blockCache (https://github.com/facebook/rocksdb/wiki/Block-Cache#caching-index-and-filter-blocks)
pinL0FilterAndIndexBlocksInCache=true

# blockCacheSize should be 1/3 of total memory available (https://github.com/facebook/rocksdb/wiki/Setup-Options-and-Basic-Tuning#block-cache-size)
blockCacheSize=1350 * 1024 * 1024

# use larger blockSize to reduce index block size (https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide#difference-of-spinning-disk)
blockSize=256 * 1024

但内存使用量似乎仍然无限增长，我的容器最终被 OOMKilled。

我使用 jemalloc 来分析内存使用情况（如此处所述），结果清楚地表明 …

描述：

RocksDB 是一个键值存储，因此我们可以简单地序列化对象列表并存储与键对应的值。如果列表中的数据足够小，这将是可以的。

但是如果列表很大并且大小不断增加，那么我们需要对数据进行分页。因此，在这种情况下，存储与单个键对应的整个序列化列表数据不是一个好主意；因为会存在性能问题，因为每次将新数据插入列表时，这个非常大的值也需要在读取期间读取和更新，当向用户显示列表时，将检索整个值，而只有一部分是用户需要。

例如：假设我们想将用户下的订单存储在 RocksDB 中。然后我们可以在 RockDB “u:1:li:o” 中以下列方式存储这个订单数据：Serialised([O1{}, O2{},....On{}])。但是如果用户下的订单数以千计，我们想以页面的形式检索订单（一次 10 或 20 条记录）。因此，在同一个键中存储数千个订单并从该键中检索整个数据然后提供所需的 10-20 条记录并不是一个好主意。此外，用户向同一键添加新订单将影响上述性能。

所以我正在努力设计模式以在 RocksDB 中有效地存储和检索如此大的列表。

如果您能就架构设计提出您的建议，那将会很棒且非常有帮助。

我无法理解Spark如何与存储交互.

我想创建一个Spark集群,从RocksDB数据库(或任何其他键值存储)中获取数据.但是,此时,我能做的最好的事情是将整个数据集从数据库中提取到每个集群节点的内存中(例如,到地图中)并从该对象构建RDD.

我只需要获取必要的数据(如Spark与HDFS一样)？我已经阅读了有关Hadoop输入格式和记录阅读器的内容,但我并没有完全理解我应该实现的内容.

我知道这是一个广泛的问题,但我真的很感激帮助我开始.先感谢您.

我想以安全的方式将正在运行的rocksdb实例备份到同一磁盘上的某个位置，并且在备份期间不会中断处理。

我读过了：

• Rocksdb备份说明
• 检查点文档
• Rocksdb/utilities/{checkpoint.h,backupable_db.{h,cc}} 中的文档

我的问题是调用是否CreateNewBackupWithMetadata被标记为非线程安全来表示对此函数的两个并发调用将具有不安全的行为，或者表明对数据库的任何并发调用都将是不安全的。我已经检查了实现，它似乎正在创建一个检查点 - 第二篇文章声称该检查点用于 MyRocks 的在线备份 - 但我仍然不确定调用的哪一部分不是线程安全的。

我目前将此解释为，它是不安全的，因为CreateBackup...调用DisableFileDeletions和稍后EnableFileDeletions，当然，如果进行两个重叠的调用，可能会引起麻烦。由于 SST 文件是不可变的，我并不担心它们，但不确定通过插入修改 WAL 是否会损坏备份。我认为触发备份刷新应该可以防止这种情况，但我想确定一下。

任何指示或帮助表示赞赏。

WAL（Write-Ahead Log）技术已经在很多系统中使用。

WAL 的机制是，当客户端写入数据时，系统会做两件事：

1. 将日志写入磁盘并返回给客户端
2. 将数据异步写入磁盘、缓存或内存

有两个好处：

1. 如果出现异常（即断电），我们可以从日志中恢复数据。
2. 性能好，因为我们异步写入数据，可以批量操作

为什么不直接将数据写入磁盘？您将每次写入都直接写入磁盘。成功时，您告诉客户端成功，如果写入失败，则返回失败的响应或超时。

这样，您仍然拥有这两个好处。

1. 在断电的情况下，您不需要恢复任何东西。因为返回给客户端的每个成功响应都意味着数据确实在磁盘上。
2. 性能应该是一样的。虽然我们经常接触磁盘，但是 WAL 也是一样的（WAL 每次写入成功都意味着它在磁盘上成功）

那么使用 WAL 有什么好处呢？

I am using openjdk:8-alpine for deploying Kafka Streams application. I am using Windowing and it crashes with below error:

Exception in thread "app-4a382bdc55ae-StreamThread-1" java.lang.UnsatisfiedLinkError: /tmp/librocksdbjni94709417646402513.so: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /tmp/librocksdbjni94709417646402513.so)
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
    at java.lang.Runtime.load0(Runtime.java:809)
    at java.lang.System.load(System.java:1086)
    at org.rocksdb.NativeLibraryLoader.loadLibraryFromJar(NativeLibraryLoader.java:78)
    at org.rocksdb.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:56)
    at org.rocksdb.RocksDB.loadLibrary(RocksDB.java:64)
    at org.rocksdb.RocksDB.<clinit>(RocksDB.java:35)
    at org.rocksdb.Options.<clinit>(Options.java:22)
    at org.apache.kafka.streams.state.internals.RocksDBStore.openDB(RocksDBStore.java:116)
    at org.apache.kafka.streams.state.internals.Segment.openDB(Segment.java:43)
    at org.apache.kafka.streams.state.internals.Segments.getOrCreateSegment(Segments.java:91)
    at org.apache.kafka.streams.state.internals.RocksDBSegmentedBytesStore.put(RocksDBSegmentedBytesStore.java:100)
    at org.apache.kafka.streams.state.internals.RocksDBSessionStore.put(RocksDBSessionStore.java:122)
    at org.apache.kafka.streams.state.internals.ChangeLoggingSessionBytesStore.put(ChangeLoggingSessionBytesStore.java:78)
    at org.apache.kafka.streams.state.internals.ChangeLoggingSessionBytesStore.put(ChangeLoggingSessionBytesStore.java:33)
    at org.apache.kafka.streams.state.internals.CachingSessionStore.putAndMaybeForward(CachingSessionStore.java:177)
    at org.apache.kafka.streams.state.internals.CachingSessionStore.access$000(CachingSessionStore.java:38)
    at org.apache.kafka.streams.state.internals.CachingSessionStore$1.apply(CachingSessionStore.java:88)
    at …

我是商店的新手key-value。我的目标是使用嵌入式键值存储来保持持久数据模型。如果使用传统的 RDBMS 设计，数据模型将包含很少的相关表。我正在查看一篇关于为键值存储建模表的中等文章。尽管本文使用 Level DB 和 Java，但我计划在我的工作中使用 Level DBRocksDB或FASTERC++。

它使用一种方案，其中每行的每个属性都使用一个键，如下例所示。

$table_name:$primary_key_value:$attribute_name = $value

当用户代码确切地知道要获取哪个键时，上面的内容对于点查找来说是很好的。但也有一些场景，比如搜索具有相同电子邮件地址的用户，或者搜索超过一定年龄的用户，或者搜索某一特定性别的用户。在搜索场景中，文章对所有键执行线性扫描。在每次迭代中，它都会检查键的模式，并在找到具有匹配模式的键后应用业务逻辑（检查匹配的值）。

看来，这种类型的搜索效率很低，在最坏的情况下需要遍历整个商店。为了解决这个问题，需要一个反向查找表。我的问题是

如何建模反向查找表？这是某种轮子的重新发明吗？有什么替代方法吗？

很容易想到的一个解决方案是separate ?为每个可索引属性建立一个存储，如下所示。

$table_name:$attribute_name:$value_1 = $primary_key_value 

采用这种方法，迫在眉睫的问题是

如何处理这个反向查找表中的冲突？因为多个$primary_keys 可能与同一个值相关联。

作为直接的解决方案，可以不存储单个值，而是array存储多个主键，如下所示。

$table_name:$attribute_name:$value_1 = [$primary_key_value_1, ... , $primary_key_value_N]

但是这种类型的建模需要用户代码从字符串解析数组，并在多次操作后再次将其序列化为字符串（假设底层键值存储不知道数组值）。

将多个键存储为数组值是否有效？或者存在一些供应商提供的有效方法？

假设类似字符串化的数组设计有效，每个可索引属性都必须有这样的索引。因此，这提供了对索引什么和不索引什么的细粒度控制。想到的下一个设计决策是这些索引将存储在哪里？

索引应该存储在单独的存储/文件中吗？或者在实际数据所属的同一存储/文件中？每个房产是否应该有不同的商店？

对于这个问题，我没有任何线索，因为这两种方法都需要或多或少相同数量的 I/O。然而，如果数据文件较大，则磁盘上的内容较多，内存上的内容较少（因此 I/O 较多），而对于多个文件，内存上的内容较多，因此页面错误较少。根据特定键值存储的架构，这种假设可能是完全错误的。同时，文件太多会成为管理复杂文件结构的问题。此外，维护索引需要插入、更新和删除操作的事务。拥有多个文件会导致多个树中的单个更新，而拥有单个文件会导致单个树中的多个更新。

交易是否更具体地支持涉及多个存储/文件的交易？

不仅是索引，还有表的一些元信息也需要与表数据一起保存。要生成新的主键（自动递增），需要先了解最后生成的行号或最后一个主键，因为类似 a 的东西COUNT(*)不起作用。另外，由于未对所有键建立索引，因此该meta信息可包括对哪些属性建立索引以及对哪些属性未建立索引。

如何存储每个表的元信息？

同样的一组问题也出现在元表中。例如元应该是一个单独的存储/文件吗？此外，我们注意到并非所有属性都被索引，我们甚至可能决定将每一行作为 JSON 编码值存储在数据存储中，并将其与索引存储一起保存。底层键值存储供应商会将该 JSON 视为字符串值，如下所示。

$table_name:data:$primary_key_value = {$attr_1_name: $attr_1_value, ..., $attr_N_name: $attr_N_value}
...
$table_name:index:$attribute_name = [$primary1, ..., $primaryN] …

我正在开发Windows机器上编写Kafka Streams应用程序.如果我尝试使用leftJoin和branch卡夫卡流的特点,我得到执行的jar应用程序时的错误如下:

Exception in thread "StreamThread-1" java.lang.UnsatisfiedLinkError: C:\Users\user\AppData\Local\Temp\librocksdbjni325337723194862275.dll: Can't find dependent libraries
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
    at java.lang.Runtime.load0(Runtime.java:809)
    at java.lang.System.load(System.java:1086)
    at org.rocksdb.NativeLibraryLoader.loadLibraryFromJar(NativeLibraryLoader.java:78)
    at org.rocksdb.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:56)
    at org.rocksdb.RocksDB.loadLibrary(RocksDB.java:64)
    at org.rocksdb.RocksDB.<clinit>(RocksDB.java:35)
    at org.rocksdb.Options.<clinit>(Options.java:22)
    at org.apache.kafka.streams.state.internals.RocksDBStore.openDB(RocksDBStore.java:115)
    at org.apache.kafka.streams.state.internals.Segment.openDB(Segment.java:38)
    at org.apache.kafka.streams.state.internals.Segments.getOrCreateSegment(Segments.java:75)
    at org.apache.kafka.streams.state.internals.RocksDBSegmentedBytesStore.put(RocksDBSegmentedBytesStore.java:72)
    at org.apache.kafka.streams.state.internals.ChangeLoggingSegmentedBytesStore.put(ChangeLoggingSegmentedBytesStore.java:54)
    at org.apache.kafka.streams.state.internals.MeteredSegmentedBytesStore.put(MeteredSegmentedBytesStore.java:101)
    at org.apache.kafka.streams.state.internals.RocksDBWindowStore.put(RocksDBWindowStore.java:109)
    at org.apache.kafka.streams.state.internals.RocksDBWindowStore.put(RocksDBWindowStore.java:101)
    at org.apache.kafka.streams.kstream.internals.KStreamJoinWindow$KStreamJoinWindowProcessor.process(KStreamJoinWindow.java:65)
    at org.apache.kafka.streams.processor.internals.ProcessorNode$1.run(ProcessorNode.java:48)
    at org.apache.kafka.streams.processor.internals.StreamsMetricsImpl.measureLatencyNs(StreamsMetricsImpl.java:188)
    at org.apache.kafka.streams.processor.internals.ProcessorNode.process(ProcessorNode.java:134)
    at org.apache.kafka.streams.processor.internals.ProcessorContextImpl.forward(ProcessorContextImpl.java:83)
    at org.apache.kafka.streams.kstream.internals.KStreamFlatMapValues$KStreamFlatMapValuesProcessor.process(KStreamFlatMapValues.java:43)
    at org.apache.kafka.streams.processor.internals.ProcessorNode$1.run(ProcessorNode.java:48)
    at org.apache.kafka.streams.processor.internals.StreamsMetricsImpl.measureLatencyNs(StreamsMetricsImpl.java:188)
    at org.apache.kafka.streams.processor.internals.ProcessorNode.process(ProcessorNode.java:134)
    at org.apache.kafka.streams.processor.internals.ProcessorContextImpl.forward(ProcessorContextImpl.java:83)
    at org.apache.kafka.streams.kstream.internals.KStreamFilter$KStreamFilterProcessor.process(KStreamFilter.java:44)
    at org.apache.kafka.streams.processor.internals.ProcessorNode$1.run(ProcessorNode.java:48)
    at org.apache.kafka.streams.processor.internals.StreamsMetricsImpl.measureLatencyNs(StreamsMetricsImpl.java:188)
    at …