巨杉数据库学习笔记

在整个流程的学习中可以分为SCDP的知识学习和SCDD的代码学习，还有对巨杉文档的探索三个部分：

将学习笔记分为错题集，现代数据库知识补充和文件系统创建思路整理三个部分。

---

• 在建立分区集合时，默认会在_id字段与分区字段创建索引
• 命令行部署中，创建临时协调节点，会默认链接11790端口
• 创建Catalog组，一个使用createCataRG
• 获得整个集群的快照信息：db.snapshot(SDB_SNAP_SYSTEM)
• SequoiaDB架构可以对源系统增删查改的数据进行T+n秒的准实施同步
• 使用source，myloader等命令或工具可以吧SQL数据导入SequoiaSQL-MySQL数据库
• SequoiaDB 5.0.1对Mysql/mariadb/postgreSql/mongoDB/spark读写同一数据源，跨引擎事务一致。
• 巨杉数据库可以采用sdbtop、SAC管控中心、snapshot/list等监控方式

---

在学习了巨杉SCDP的课程后参加了对应的考试，发现在考试中还遇到了很多属于现代数据库知识的问题，所以做一个错题整理和探索

1. 分布式交易型数据库的特点是混合事物和分析场景，对象储存技术不属于分布式交易型数据库的技术点
2. 消息总线产品为了实现数据的先进先出：
   Spring Cloud Bus能管理和传播分布式系统间的消息，就像一个分布式执行器，可用于广播状态更改、事件推送等，也可以当作微服务间的通信通道。
3. myloader可以用多线程的方式向Mysql导入数据
4. 数据中台需要为业务需求构建数据生命体系、统一标准化查询服务和全新的数据服务框架
   
5. 流处理引擎的技术特点是实时计算
   
6. 微服务的开发中需要主义对外隐藏实现的细节
    

   微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。

   微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。

   通过整体式架构，所有进程紧密耦合，并可作为单项服务运行。这意味着，如果应用程序的一个进程遇到需求峰值，则必须扩展整个架构。随着代码库的增长，添加或改进整体式应用程序的功能变得更加复杂。这种复杂性限制了试验的可行性，并使实施新概念变得困难。整体式架构增加了应用程序可用性的风险，因为许多依赖且紧密耦合的进程会扩大单个进程故障的影响。

   使用微服务架构，将应用程序构建为独立的组件，并将每个应用程序进程作为一项服务运行。这些服务使用轻量级 API 通过明确定义的接口进行通信。这些服务是围绕业务功能构建的，每项服务执行一项功能。由于它们是独立运行的，因此可以针对各项服务进行更新、部署和扩展，以满足对应用程序特定功能的需求。

7. SparkSQL实例只要用来执行OPAP
   OLAP(Online Analytical Processing)数据库也称分析型数据库，是指一类支持对大规模数据进行较为复杂的联机分析处理的数据库，更关注复杂查询和聚集分析。OLAP系统通常并发不高，每个查询会运行较长时间，操作的数据量巨大。分析中的查询，大多只需读取数据，不会对历史数据轻易修改。分析中的关系代数操作，会包含非常复杂的交运算，中间结果可能种类繁多数量庞大，但 最终返回给用户的结果可能较小较容易理解。分析查询面向某一主题的数据，尝试从集成数据中发掘新知识，所以可能执行分析查询前，用户自身对结果的情况也是未知的。
8. SMP架构的特点是对称多处理器每个CPU访问储存效率均等，同时执行并行计算
   所谓SMP，即Symmetric Multi-processor，对称多处理器结构，x86服务器及其他双路服务器就属于这种结构，PC机、手机和笔记本电脑也属于这种架构。顾名思义，这种服务器架构的特点就是服务器是一个对称结构。服务器的多个CPU之间没有主从关系，他们协同工作，共享内存及总线。
    
9. 文档型、K/V型、图计算属于NoSQL
   文档型数据库：文档数据库(也称为面向文档的数据库或文档存储)是在文档中存储信息的数据库，是非关系型数据库的一种。一个文档就是文档型数据库中的一条记录。文档通常存储关于一个对象及其任何相关元数据的信息。文档是以字段-值成对的形式存储数据。值的类型和结构可以有多种，包括字符串、数字、日期、数组等。文档存储的格式可以是JSON,BSON（二进制形式的JSON）和XML。
   
   K/V型数据库：

   kv数据库是指Key-value数据库，是一种以键值对存储数据的一种数据库，类似java中的map。可以将整个数据库理解为一个大的map，每个键都会对应一个唯一的值。

   key-value分布式存储系统查询速度快、存放数据量大、支持高并发，非常适合通过主键进行查询，但不能进行复杂的条件查询。

   如果辅以实时搜索引擎进行复杂条件检索、全文检索，就可以替代并发性能较低的MySQL等关系型数据库，达到高并发、高性能，节省几十倍服务器数 量的目的。以MemcacheDB、Tokyo Tyrant为代表的key-value分布式存储，在上万并发连接下，轻松地完成高速查询。
   
   图计算：图处理框架（graph processing frameworks）、图计算引擎（graph computing engines），它的主要工作是对已有的数据进行计算和分析。
   图数据库的框架主要功能可以分为三大部分：存储、计算与面向应用的服务（例如数据分析、决策方案提供、预测等）。其中计算部分，包含图计算，但是图数据库通常可以处理AP与TP类操作，也就是说可以兼顾OLAP与OLTP（Online Transactional Processing，在线事务处理），两者的结合也衍生出了新的HTAP类型的图数据库

   ---

还有一个部分是关于在使用巨杉数据库制作的流程：

下是制作一个文件管理系统的基本要求：

拿到任务后首先去巨杉文档中查找非结构化数据的存储方式，发现了巨杉支持Lob类型的存储，这就使得巨杉数据库可以一力承载整个系统所有类型数据的存储工作，抛弃繁琐的 MySQL+NAS 的存储模式。
我和另外一位同学首先探索了使用Mysql实例＋lob的存储方式，使用Mysql存取lob的oid，因为比较熟知mysql的相关语句。但是在对文档的更深入探索过程中，发现了一个更为优秀（贴合目标的数据库实例），那就是S3的实例。S3实例直接支持非结构化数据的存储，可以直接调用sdbS3的代码进行文件数据的上传，同时还支持对应元数据的上传，十分符合非结构化存储的特点。
（这里还有个很有意思的探索过程，我们在确定了使用S3实例之后，就开始用java写实现代码，在写到文件上传函数时，突然发现既然S3只是巨杉数据库的实例，那S3上传的文件数据应该就是以Lob的形式储存在数据库中，而不是像S3一样上传到服务器。因为之前一直没有看到过相关例子，所以返回文档中继续查找，终于在S3的配置说明下面的sdbs3.sequoiadb.data.lobPageSize参数中确定了我们的猜想）

下面是软件说明书中的部分内容,算是对于文件系统说明书的开发说明：

 桶是存储对象的容器，我们将桶作为学科的分类器， 每个桶代表一个学科，每个用户最多创建 100 个桶（最多有一百个科目）；文件数据就 是 一个个 对 象 

在元数据的集合空间S3_SYS_Meta中，由于学习资料多以pdf等文档为主，估计大小为10mb左右，故选择LobPageSize为最大参数524288。

在集合的分区选择上，使用range分区，以元数据中subject为分区键，更符合学习资料以科目为分类的目的。