工业领域的智能制造具有巨大的未来应用潜力。
计时数据应用程序方案是在时间表中的每次倒入多个数据源的数据。根据连续时间的多个纬度以及由第二甚至毫秒计算得出的真实时间存储，生成大量数据。
传统RDBMS数据库的支持是根据该行处理的，并建立了B树结构的索引。它不是为分批批量编写的高速写作而设计的，尤其是像多纬度的时正式数据一样。发动机不可避免地会导致负载和吞吐量的极其不舒服的适应。
因此，当前顺序数据的存储设计通常不考虑传统的RDBM，并将重点介绍LSM-Tree和柱状数据结构存储的方向。
LSM数据模型被按下从内存到磁盘文件的批处理数据层。有些人会安排数据KV订单，以形成存储文件簇，例如HBase，Cassandra；根据列字段的多个文件存储以形成列以形成列，形成列的列表，这可以大大提高压缩率，例如druid.io。
查看定时数据结构：数据源+指示器项目（metric）+timestamp =数据点，每个数据点是时间轴上的指示测量点。
如果它由两个维图表示，如下图所示，水平轴代表时间，垂直轴表示测量值，而图中的每个点都是由指示器测量的数据点（点）。
上图可以表示为：数据源1（动态环检测高科技区计算机室数据区域） - 辅助器（湿度），数据源2（动态环检测-XIXIAN-xixian新区域计算机室计算区） -指示器（湿度）在时间戳上连续的时间表图。
其中，动态环检测代表数据源的业务领域。计算机室和区域表示数据源的标签（标签）。动态环检测+计算机室+区域确定唯一的时间序列数据源。
除了流入DB，定时数据库还具有另一个知名的计时库-opentsDB。OPENTSDB基于HBase平台的定时数据库。在我以前的答案中，HBase的内部机制具有Google Bigtable用途列群的数据模型，作为数据组织和存储的整体单位。
我们可以理解，列群是一张Excel宽表。表中的每个单元格由k/v组成，密钥由键+群集名称+列名+时间组成。k/v自然形成了行键的顺序，群集名称，列名和时间。抓住一组列的列非常方便。
从定时数据的特征中，我们可以看到数据源+指示器+时间戳可以确定到数据点，因此在OpentSDB的设计中，此组合是行键。导致每个K/V线键，这将生成大量单列数据。
因此，OPENTDB进行了优化，并且根据小时表将行键中的时间戳分为3600列。通过这种方式，列的线代表一个时序数据的一个小时，每个列代表该第二个的值。
从机制设计的角度来看，OpentSDB是根据HBase的特征进行了优化的，并且做得很好。但是，HBase的本质是K/V作为一个原子单元，该单元形成一个由多个K/V形成一个块，然后是块。HFILE文件由块形成。
缺点是：
（1）每个k/v都会带来很多冗余，因为钥匙的构造，并且无法根据标签标签有效地实现条件索引，因为标签被摩擦到键中，这需要完整的扫描顺序。
（2）不能有效地将键压缩到一般压缩算法上。最后，它肯定会承担更多的存储成本。必不可少的问题是，时间戳不能独立分开。
InfluxDB不打算充分参与新的数据存储理论系统。相反，请参阅HBASE的LSM-TREE数据模型，并构建一组适合定时数据的存储架构，称为TSM。
让我们重复HBASE的数据模型机制，添加WAL，然后在内存中建立批处理的数据缓冲区备忘录。定期或完整写作时，备忘录将（齐平）洗净到磁盘库。Merge排序和完整记录。
基于LSM-树结构的数据模型可以大大提高写作性能。许多NOSQL系统都是这种操作方式。
流入也不例外。继续此LSM-树结构例程。写入定时数据后，添加了WAL，然后编写缓存，然后将磁盘TSM文件刮到磁盘TSM文件中。
我们看到它与HBase不同，主要是在数据结构的设计中。HBASE的备忘录将书面数据直接封装到K/V中，并形成更大的块块。
该结构的最大特征是，HBase按顺序以一般的方式将原子单元（K/V）安排在较大的块块中。数据之间的数据非常松散。结构优化，但依赖于索引扫描，属于油类型的类型，可用于任何上限应用，例如：扫描查询，聚合分析或设计基于TSDB关于时间轴分析。
但是InfluxDB重新优化了缓存中的结构：**地图收集<数据源,Map集合<指标,List列表<时间戳:数据值>>>，**我们可以看到它是地图集映射和列表的结构。地图的第一层是序列（系列）集合。系列是由InfluxDB定义的数据源（Formurement + Multi -Tag标签集）。对于指示器，InfluxDB定义索引是字段，第三层是某个数据源的某个指标的时间表记录列表。
因此，我们可以看到InfruxDB首先根据计时数据的特征执行了数据结构化数据，以满足此计时特征的需求，然后有一个基于数据源作为索引的定位指标，将索引作为索引，作为索引索引是定位定位时间单元数据列表的索引时间。
在InfluxDB内存中，缓存将齐平到TSM文件。TSM文件还将建立数据块布置和根据上述结构安排的索引块。每个数据块可以由时间戳列表和值列表组成。
然后，您可以单独压缩TimessTamps列表（delta-delta），并且值列表具有相同的类型，可以根据类型进行压缩。索引块创建数据块和系列之间的关系，并快速定位。数据块位移要通过双点搜索方法的时间范围进行检查。
InfluxDB分为两个索引，一个是在TSM文件中构建的串联索引，另一个是倒置索引。
系列索引：InfluxDB构建的索引中的系列 +字段是主要键，定位了某个指标的索引块，该索引块由n个索引实体组成。每个索引实体提供最短和最大的时间，这段时间与TSM文件系列数据块的偏移相对应，TSM文件具有多个系列数据块，每个系列数据块包含时间列表（TimessTamps）。可以通过钥匙进行排序，并通过时间范围进行双面搜索。
查询指数：除了TSM结构外，InfluxDB还具有TSI结构。TSI主要是定时数据的倒置索引，例如：通过控制戒指检测高科技区域计算机室检查高科技区机房的各个区域的指标。或您还可以检查所有数据区域电脑室穿过动态环检测数据区域的状况。
TSI的数据结构是：地图收集<标签名,Map集合<标签值,List列表>>一楼是标签昵称的集合，二楼是标签名称下的所有标签集。例如：标签名称是该区域，其中包括数据区域和计算区域的标签值。三楼是特定的标签。相应的数据源，例如，包含数据区域标签的数据源包括动态环检测高 - 网络区域数据中心，动态环检测 - Xixian new District-Data中心等。
通过此索引方法，可以通过此索引方法来实现所有包含此标签的数据源。通过数据源的服务器，查看TSM文件中的其他条件。
TSI数据模型使用与TSM相同的例程。它本质上是基于LSM数据结构。通过数据编写，倒置索引首先写下WAL。在编写内存中内存索引后，齐平倒入内存时间表后将TSI文件倒入。TSI文件是基于磁盘的基于磁盘的索引倒置索引文件，其中包含串联块和标签块。您可以通过标签块中的标签值在系列块中找到所有相应的系列。
定时库将在该数据源标签（TAA）分类的分析和查询中非常有效，这也是InfluxDB完全满足定时数据业务需求的需求。
InfuluxDB关闭了集群的来源，这确实是一个可惜的地方。但是，任何技术创业公司都必须寻求生存和发展是可以理解的。商业输血是必要的。我希望有一天InfuxDB的母公司可以被巨人收购，然后再次是完全开源的。
我过去谈到了HBase和Cassandra的比较。感兴趣的朋友可以看到：HBase和Cassandra Architecture的比较分析的经验经验
infuxdb更倾向于分散分布式，其中包含我对两者的分布的比较，而流入室更接近cassandra。卡桑德拉（Cassandra）是一个分散的分布式体系结构。infuxdb包含元节点和数据节点，但元节点似乎是主节点，但角色非常薄弱。它主要存储一些公共信息和连续查询计划。数据读取和写作问题主要集中在数据节点上。
InfluxDB是CAP定理中的一个AP分布式系统，非常专注于高可用性，而不是一致性。第二，InfluxDB主要是两个级别的碎片，第一级是ShardGroup，第二级是Shard。
ShardGroup是一个合乎逻辑的概念，代表一段时间内的多个碎片，在创建InfluxDB数据库和预订策略之后，确定了ShardGroup的延续期。这等同于第一个顺序数据。时间段的分区，例如一小时作为碎片组。
但是，这些小时内的数据并未存储在数据节点上，该数据与HBase区域大不相同。区域将首先将其写入数据节点。区域迁移分布。
InfuxdB应指的是Cassandra的集合。它使用基于系列的哈希分布作为钥匙，并在集群中的不同数据节点上分配了多个schlen。
下面代码中的键是系列，这是唯一指定的数据源（表测量 +标签收集标签集）。
上面代码中的shardgroup。莎士德是碎片的碎片数。数字为n/x，n是群集中的数据节点的数量，而x是复制因子。
例如：群集有4个节点，2个副本和4/2个小时的碎片范围数据分为2个schks，并且每个副本2副本。它分布在四个数据节点中。哈希分布方法，均匀分布的时序数据，还充分利用了集群的每个数据节点的读写优势。
infuxdb是最终的一致性。在写作一致性方面，各种监管策略与Cassandra相同，一个，法定人数，全部和卡桑德拉都相同，并加强了协调节点中提示的交接的临时队列。
即使真实复制节点有故障，它也会在协作节点的提示交接队列中保存很长时间。在节点的副本未能恢复后，从提示的交接队列中复制和恢复。它是为了达到最终的一致性。
此外，InfluxDB和Cassandra3.x是相同的版本，并且是背景片段维修的先前版本（抗输入），但有趣的部分是Cassandra不再保留背景阅读和修复的功能，并且不建议以前的版本启用，因为有了主动阅读和维修的能力，背景阅读和修复效果不佳，也会影响性能。
当然，无论涌入与Cassandra是否相同，在阅读过程中阅读和维修需要主动，因为它是一个封闭的源系统。我目前不知道这一点。
InfluxDB在删除问题上的表现非常弱。它仅允许删除该系列下的范围集或尺寸集。这也是由于该正时结构的设计。单点的删除将非常麻烦，成本也很高。
删除方法还应指Cassandra的墓碑机制：权力下放的问题是，在每个人都担心每个人都会删除副本之后，错误中的副本节点再次恢复。它不知道发生了什么，但是在维修过程中会认为删除的副本丢失了，让所有人恢复。
随着墓碑标记的长期存在，复制数据的故障节点是根据恢复后的其他副本节点标记的，并且众所周知，删除发生在故障期间，并立即删除其相应的副本数据。
首先，InfluxDB的出现大大减少了定时数据的存储量，这非常有利于物联网时代的数据存储问题。关键是合理的存储结构设计。一方面，它可以减少数据冗余量。在其他手提压缩算法上，例如：TSM文件中时间戳集合的高压缩算法的delta-delta压缩算法；
其次，面对时间的存储作为主线，很难在以前找到合适的解决方案。例如，我们使用Elasticsearch建立一个日期索引来保存日志，但是我们始终在创建的条件下以及何时纠结纠结的情况下创建。解决了这种问题；
最后，根据数据捕获，聚合和分析纬度的数据，按时间捕获，按需可以可以在一段时间内实现时间 - 序列模型的索引，尤其是倒置的索引TSI。大大提高了整体计算资源的应用效率。
作者：Xi'an Guardian Stone信息技术CTO CTO OLD FANG