rocksdb

配置参数： 参数含义 附加说明 [DBOptions] new_table_reader_for_compaction_inputs=false recycle_log_file_num=0 avoid_flush_during_shutdown=false skip_stats_update_on_db_open=false use_direct_io_for_flush_and_compaction=false access_hint_on_compaction_start=NORMAL allow_fallocate=true fail_if_options_file_error=false create_if_missing=false max_manifest_file_size=18446744073709551615 write_thread_slow_yield_usec=3 delayed_write_rate=16777216 create_missing_column_families=false error_if_exists=false allow_concurrent_memtable_write=true db_log_dir= paranoid_checks=true skip_log_error_on_recovery=false

表现：通过JNI打开RocksDB报错：snappy压缩库没有被链接： org . rocksdb . RocksDBException : Compression type Snappy is not linked with the binary . at org . rocksdb . RocksDB . open ( Native Method ) ~ [ rocksdbjni - 6.6 .0 - fix - osx . jar : ? ] at org . rocksdb . RocksDB . open ( RocksDB . java : 290 ) ~ [ rocksdbjni - 6.6 .0 - fix - osx . jar : ? ] at com . baidu . hugegraph . backend . store . rocksdb . RocksDBStdSessions . < init > ( RocksDBStdSessions . java : 130 ) ~ [ classes / : ? ] at com . baidu . hugegraph . backend . store . rocksdb . RocksDBStore . openSessionPool ( RocksDBStore . java : 299 ) ~ [

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 在Flink中管理大量的状态--增量式的检查点的介绍 本文由 Flink 博客 翻译而来，为了叙述的可读性和流畅性，笔者做了少量的修改。 Apache Flink是为了“有状态”的处理流式数据建立的。那么，在流式计算程序中，状态的含义是什么？ 我在前面的 博客 中做了“状态”以及 “有状态的流式处理”的定义。这里回顾一下，状态指的是，在程序中，Operator将过去处理过的event信息保存在内存中， 这样可以在之后的处理中使用。 “状态”是一个基础的功能，使得在流式计算中复杂的用户使用场景成为可能。在 Flink 文档 中列举 了一些例子。 程序需要查找某些固定的模式的事件，“状态”保存了至今接收到的事件流。 程序需要每分钟做聚合操作，“状态”缓存等待聚合的数据 程序需要基于流式的数据进行模型训练，“状态”保存当前版本的模型参数。 但是，只有“状态”拥有容错能力，这样才能在生产环境使用。“容错性”意味着，即使有软件或者机器的故障，最终的计算结果也是精确的，没有数据丢失也没有重复处理。 Flink的容错特性非常强大，它不仅对软件和机器的负载很小，并且也提供了“端到端仅一次”的消息传递保证。 Flink程序容错机制的核心是检查点。Flink的检查点是一个全局的、异步的程序快照，它周期性的生成并送到持久化存储

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 简介 Flink本身为了保证其高可用的特性，以及保证作用的Exactly Once的快速恢复，进而提供了一套强大的Checkpoint机制。 Checkpoint机制是Flink可靠性的基石，可以保证Flink集群在某个算子因为某些原因(如异常退出)出现故障时，能够将整个应用流图的状态恢复到故障之前的某一状态，保 证应用流图状态的一致性。Flink的Checkpoint机制原理来自“Chandy-Lamport algorithm”算法 (分布式快照算法)。 Checkpoint的执行流程 每个需要checkpoint的应用在启动时，Flink的JobManager为其创建一个 CheckpointCoordinator，CheckpointCoordinator全权负责本应用的快照制作。 CheckpointCoordinator周期性的向该流应用的所有source算子发送barrier； 当某个source算子收到一个barrier时，便暂停数据处理过程，然后将自己的当前状 态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告 自己快照制作情况，同时向自身所有下游算子广播该barrier，恢复数据处理； 下游算子收到barrier之后，会暂停自己的数据处理过程

互联网业务持续增长需要存储架构设计也能够弹性扩容。让我们来看看： RocksDB RocksDB是facebook开源的NOSQL存储系统，其设计是基于Google开源的LevelDB，优化了LevelDB中存在的一些问题，其性能要比LevelDB强，设计与LevelDB极其类似。RocksDB 具有高度灵活的配置设置，可以调整为在各种生产环境（包括纯内存，闪存，硬盘或 HDFS）上运行。它支持各种压缩算法，并且有生产和调试环境的各种便利工具。RocksDB 借用了来自开源 LevelDB 项目的核心代码，以及来自 Apache HBase 的重要思想。RocksDB 的主要设计点是，它应该是快速存储和服务器工作负载的性能而设计。它应充分利用 Flash 或 RAM 提供的高速读/写速率的全部潜力。它应该支持高效的点查找以及范围扫描。它应该可配置为支持高随机读取工作负载，高更新工作负载或两者的组合。其架构应支持轻松调整参数，支持读取放大，写入放大和空间放大场景。 RocksDB适用场景 1.对写性能要求很高，同时有较大内存来缓存SST块以提供快速读的场景； 2.SSD等对写放大比较敏感以及磁盘等对随机写比较敏感的场景 3.需要变长kv存储的场景； 4.小规模元数据的存取； 不适合场景 1.大value的场景，需要做kv分离；2.大规模数据的存取 系统架构 基于Redis的弹性扩容

0.导读 本文讲诉滴滴在分布式Nosql存储Fusion之上构建NewSQL的实践之路。详细描述Fusion-NewSQL的特性，应用场景，设计方案。 1.背景 Fusion-NewSQL是由滴滴自研的在分布式KV存储基础上构建的NewSQL存储系统。Fusion-NewSQ兼容了MySQL协议，支持二级索引功能，提供超大规模数据持久化存储和高性能读写。 ▍我们的问题 滴滴的业务快速持续发展，数据量和请求量急剧增长，对存储系统等压力与日俱增。虽然分库分表在一定程度上可以解决数据量和请求增加的需求，但是由于滴滴多条业务线（快车，专车，两轮车等）的业务快速变化，数据库加字段加索引的需求非常频繁，分库分表方案对于频繁的Schema变更操作并不友好，会导致DBA任务繁重，变更周期长，并且对巨大的表操作还会对线上有一定影响。同时，分库分表方案对二级索引支持不友好或者根本不支持。鉴于上述情况，NewSQL数据库方案就成为我们解决业务问题的一个方向。 ▍开源产品调研 最开始，我们调研了开源的分布式NewSQL方案：TIDB。虽然TIDB是非常优秀的NewSQL产品，但是对于我们的业务场景来说，TIDB并不是非常适合，原因如下： 我们需要一款高吞吐，低延迟的数据库解决方案，但是TIDB由于要满足事务，2pc方案天然无法满足低延迟（100ms以内的99rt，甚至50ms内的99rt） 我们的多数业务