Skip to end of metadata
Go to start of metadata

一、关键特性


  1. 列式存储和执行
  2. 实时加载和查询
  3. 高级数据库分析工具
  4. 数据库设计和管理工具
  5. 高级压缩 压缩率最高可达90%
  6. 结构化和半结构化数据
  7. 大规模并行处理
  8. 方便部署
  9. 数据湖连接 支持使用JDBC/ODBC/ADO.NET来连接其他系统
  10. 管理和监控 GUI
  11. 动态扩展集群

二、Vertica体系结构基础

  1. 列存储

  2. 数据编码与压缩

    编码
        将数据转换成标准格式。
        根据列数据类型、表基数和排序顺序按照不同的编码策略进行转换。
        
    压缩
        压缩将数据转换为紧凑格式。
        vertica基于被压缩的数据，自动选择最优的一种压缩方式。
    提高查询性能、降低存储空间

  3. 集群

    支持扩展和冗余。
    列数据分布在集群中的节点上（不一定是全部节点）。
    当一个节点新加入结群或重新回到集群时，自动从其他节点查询来更新本节点数据。

  4. 投影projection

    projection包含了具有相同排序顺序的列的集合，
    由要排序的列来定义，或者由要排序的列的序列来定义。
    与传统数据库的索引或物化视图类似。
    projection可以加速查询，它可以包含表的部分或全部列。
    projection是分布式的，它分布在集群内所有节点上。

  5. 逻辑和物理schema

    vertica以逻辑schema和物理schema的形式存储数据库信息。
    逻辑schema，存储表、约束、视图等这些对象。
    物理schema，包含被称为projection的表列的集合。

  6. 持续性能

    并发加载和查询可提供实时视图，并且不需要夜间加载窗口。
    动态模式更改允许添加列和投影而无需关闭数据库；
    Vertica在保持数据库可用的同时管理更新。

  7. 专业术语

    instance 实例：
        运行的vertica进程  +  磁盘存储文件 
        一个主机上同时只能运行一个vertica实例
    hot data：
        存储在vertica数据库里的数据
    cold data：
        存储在外部的数据，例如hadoop文件系统


三、数据库模式


  1. Enterprise

    • Enterprise模式是vertica数据库的原始默认模式，在9.1版本之前，该模式是唯一模式。
      Enterprise模式下，数据分布在集群中所有节点的ROS容器中。
      查询时，一般只操作本地的存储数据。
      这种情况最适于固定的工作负载。
      Enterprise模式比Eon模式的可扩展性要低，这种模式下添加或移除节点更困难。
      当添加或移除节点时，vertica必须将本地存储的数据在所有节点间重新分配。
      这种模式下，数据存储在两种容器中 

    • Tuple Mover使用如下进程将WOS的数据移动到ROS
          Moveout ：
              WOS → Tuple Mover →  ROS ， 这个过程中，数据将被排序、编码和压缩
          Mergeout ：
              将多个小容量ROS容器合并为一个大容量容器。

      WOS（Write Optimized Store）

      在内存中存储数据，没有压缩或索引。
      使用INSERT/UPDATE/COPY语句可以将数据加载到WOS中
      WOS的存在是为了防止一些小数据加载时，vertica创建过多的小的ROS容器。
      大量的小容量ROS要比少量的大容量ROS性能差。

      ROS（read Optimized Store）

      数据存储在硬盘上。数据会被分段、排序和压缩。
      可以使用COPY语句将数据直接加载到ROS。

  2. Eon

    • Eon模式是从9.1版本之后引进的，它优化了数据库的可扩展性。
      这种模式下，可以根据工作负载动态的调整集群节点数量。
      这种灵活性来自于计算资源和存储资源的分离（共享存储？）
      Eon模式下数据库的数据存储在中央公共仓库中，节点本并不存储数据。
      添加或删除节点并不会打断当前的查询，甚至可以暂停整个数据，稍后再继续运行暂停的查询。
      当前Eon模式只在Amazon Web Services可用。

 

  • 数据库模式对Vertica架构的影响

    数据库模式不能直接切换。
    当创建数据库时必须选择一种模式进行安装。
    如果需要切换模式，需要备份数据，创建新模式数据库然后进行加载数据。



四、Enterprise模式概念


  1. K-Safety

    K-safety 设置Vertica数据库集群的容错能力。
    K的值，是集群中数据被复制的份数（副本数量）。
    这些副本允许其他节点接管发生故障节点的查询处理。
    在Vertica中，K的值可以是：

    k值

    情况简介

    0


    1

    这种情况下，当丢失一个节点，数据库会继续正常运行。 
    只要集群中至少有一个节点包含其他故障节点的副本，及时接下来继续丢失节点，数据库也会正常运行。

    2

    这种情况下，任何两个节点故障均不影响Vertica正常运行。当故障节点恢复正常，可以再次参与数据库的相关操作。

     
    如果故障节点数达到了K值，一些数据可能不可用。这种情况下，数据库被认为是不安全的，会自动关闭。但是，如果每个数据段至少在一个集群功能节点上是可用的，那么Vertica将继续安全的运行。
    如果一半或以上的集群节点故障，数据库会自动关闭，及时数据库中所有数据的副本都是可用的。这种行为防止网络partitioning。
    物理schema涉及必须满足一些必须的要求，建议使用数据库设计工具进行设计。
    Buddy Projections
        为了确定K-safety的值，Vertica创建buddy projections。 buddy projecctions是分布在数据库节点上的、segmented projections。
        Vertica将包含相同数据的segments分布在不同节点上。这保证了如果节点故障，所有的数据都可以在存活的节点上可用。
    K-safety监控
        NODE_COUNT：集群的节点数
        NODE_DOWN_COUNT：当前故障的节点
        CURRENT_FAULT_TOLERANCE：K-safety level

    查询K-safety值

    变更K-safety level   



  2. Projections的高可用性


    复制（for Unsegemnted Projections）

    • 创建Projections时，数据库设计器对他们进行复制、创建、并将这些projection的副本存储在数据库的所有节点上
      • 实现如下功能：
        • 分布式查询执行贯穿多个节点
        • 高可用和恢复。在K-safe数据库中，复制的projections保存为buddy projections，这表示可以用复制的projections来进行恢复。
      • 建议使用数据库设计工具创建physical schema。如果不使用设计工具而选择手动创建，一定要确定将所有大表segment化，分布在所有数据库节点上，对于小的、unsegmented 表的projection，复制到所有数据库节点上。

    创建buddy projections（for large , segmented projections ）

    • Vertica创建buddy projections，这是segmented projections的副本，分布在数据库节点上。Vertica将包含相同数据的segments分布在不同的节点上。这样来确保如果节点故障，所有的数据仍在存活的节点上可用。
    • Vertica使用offsets来对segments进行分布。


    结果集如何存储

    • Vertica将表列复制在数据库集群所有节点上，来确保高可用性和恢复。因此，如果在一个K-safe环境下，某个节点故障了，数据库会使用存活节点上的副本来保持正常运行。发生故障的节点恢复正常运行后，它将通过查询其他节点自动恢复丢失的对象和数据。
    • Vertica对数据进行压缩和编码，来极大的减少存储空间需求。同时，vertica尽可能的对编码数据直接进行操作，来避免解码的成本。编码和压缩的组合极大的优化了空间，提升了查询性能。
    • Vertica以projections的形式来存储表的列。存储数据的两种方式：
      • 对于大表，建议使用Projection segmentation
      • 其他表建议使用Replication



  3. Fault Groups的高可用性


    使用故障组来降低物理环境中固有的硬件风险，断电、网络故障、存储故障等等。

    通过定义fault Group，Vertica降低了这种风险。（异地？）

    Fault groups不能解决单点故障（如single network switch ）

     

     

    Fault Groups让Vertica可以认识集群拓扑结构

    • 当使用Terrace Routing时，让Vertica认识到集群拓扑是必要的。
    • Terrace Routing是一个降低buffer需求的功能。当集群包含很多节点，且需要运行大查询时，是Terrace Routing的应用场景。这种情况下如果不使用Terrace Routing，将会消耗大量的缓冲区。

    自动故障组

    • 当配置120个以上节点的集群时，Vertica自动创建故障组和Control nodes。Control nodes是集群节点的子集，他们控制control messageing的传播。

    用户定义的故障组

    • 如下情景需要定义自己的故障组
      • 群集布局可能会导致相关故障。
      • You want to influence which cluster hosts manage control messaging.

     

    在定义故障组之前，必须全面了解物理群集的布局。故障组需要仔细计划。



五、Eon模式概念


当前Eon模式只在Amazon Web Services可用。
暂不考虑。

六、通用Vertica概念


  • No labels