MySql Redis ElasticSearch MongoDb ClickHouse Neo4J 其他（Hadoop、HugeGraph、Hbase）
    已使用场景 用户，菜单等数据存储 多线程图片转计数器；提高接口ID吞吐量，用于mysql摄像头详情数据缓存 微服务调用日志存储（主ELK），商品详情检索，服务人员详情检索（积分机制） 图片Base64存储 摄像头图片结构化数据存储（S3存储图片，Kafka批量） 摄像头布控人员以及之间关系
    现使用场景 用户等常规数据存储 接口方法+接口参数取MD5的接口缓存；频繁使用数据缓存；定时器开关 QB，人员等全文检索（因为实体信息需求变化大） 事件分析相关数据，文件流存储 无 无
    已使用高可用方案 主从复制（一主两从，对外有主节点写入binlog，从节点读取reley log;现在单机模式） 哨兵模式（日志存储；对外有主节点写入并采用aof日志增量备份，从节点读取并采用rdb日志全量备份） 多节点集群（链接任意一个节点发送请求都可以，但是内部同样有选举出来的主节点，去中心化的；多份副本集来备份） 单机 集群（依赖zookeep,可直接存储某一从节点，也可存储到集群，通过集群分散到各个节点；读取数据可读某一节点，也可读取集群；副本集来备份） 单机
    高可用方案 ①主从复制（异步复制、半同步复制）
    ②MHA
    ③MYSQL Cluster集群    		 Redis3.0支持集群，实现去中心化，现在版本是4.0以上了 集群 ①Master-Slave模式，主从同步，mongo3.6版本后不推荐；
    ②ReplicaSet副本集，主节点通过选举产生，主节点是通过选举产生，用于写操作，从节点用于读操作，并且有仲裁节点用于选举，注意选举节点需要是奇数；
    ③Sharding模式，代理层mongos，配置中心副本集群mongod，数据层Shard集群，通过配置中心得到查询的数据层数据块节点；    		 集群 ①基于neo4j主从同步
    ②集群
    并发量 100以上，1000以下（oracle） Redis官方数据
    读是110000次/s,
    写是81000次/s    		 高 2000-3000 官方建议100最大连接数 高
    数据量级 千万级别以下，千万级别以上依赖索引建立 1万-10万，内存小，缓存数据量不能太多 亿级别 千万级别 十亿级别 亿级
    扩展性 中等 集群模式扩展性强 分布式，扩展性强 Sharding模式扩展性强 高（添加节点，走配置文件） 中等
    特点 ①事务性强，保证数据一致性；
    ②成本低，占用资源少，开源；
    ③支持多种操作系统；    		 ①丰富结构化；
    ②Redis提供事务性（watch悲观锁乐观锁）
    ③数据支持持久化，且启动后数据会 加载到内存，读写快；    		 ①近乎实时系统；
    ②适合全文检索和复制的聚合数据分析    		 ①适合需求变更，数据模型无法确认，表灵活；
    ②写入频繁，读写频繁；
    ③数据量大，千万级别；
    ④支持索引，快速查询    		 ①查询效率极高且读多行少列场景
    ②数据批量插入导入性能高且快
    ③支持数据稀疏索引和DDL管理    		 ①采用原生吐存储和处理数据，查询效率比关系型数据块
    ②兼容ACID保证数据一致性
    ③社区活跃
    劣势 ①复杂查询依赖索引的建立，且查询数据会随着数据量级而增加；
    ②没有存储过程；
    ③不支持热备份    		 ①数据存储在内存，数据量大时，太占内存，需要定期清理内存缓存数据；
    ②主从复制的持久化机制，恢复数据太久，需要刷aof写的操作日志，恢复慢    		 ①相对mysql与mongoDB不是实时的；
    ②字段类型无法修改，需要reindex；
    ③写入性能相对来说不高；    		 ①事务性不支持
    ②占用空间比较大
    ③不适合做大量多表连接查询    		 ①集群模式，需要手动配置节点地址，节点无法主动被发现；
    ②数据存储非实时，存在一定时间的延迟；
    ③并发上限依赖机器性能，官方建议连接数为100；
    ④无事务的支持    		 未知
    支持使用场景 大部分量级低的开发场景 ①实时排行榜
    ②分布式缓存
    ③打卡签到场景    		 ①日志场景
    ②数据分析场景
    ③复制的查询和聚合场景    		 ①社交场景，附近的人；
    ②应用APP日志，游戏用户行为分析，支持内嵌对象；
    ③物流场景；    		 ①OLAP分析场景
    ②用户行为分析场景
    ③数据存储量大，数据价值挖掘    		 ①社交网络关系
    ②推荐系统
    ③疫情传播链
    学习难度 低 低 中 中 低 高 高
    生态圈和社区 高 高 高 中 低 高

    问题：
    1、方案有问题，ck并发量太低，不适合做并发太高的实时数据存储，如何利用好clikchouse?
    2、主从复制不适合在数据要求高度一致性的场景，比如银行系统，主从复制基本是（mysql,redis,mongo）额外线程进行日志写操作写入或者复制数据，存在节点宕机问题；如何解决？
    3、数据库高可用演化，从主从复制，到选举主节点的集群，再到去中心化的集群，以后会是什么呢？
    4、解决性能和瓶颈 问题，优化有横向扩容或者纵向扩容，一个纵向扩容是增加集群的内存，cpu，磁盘等，一个横向扩容是增加集群节点来提供能力，此外有没有其他方法来解决数据库的性能和瓶颈问题？