saiku 分布式实践

saiku比较吃内存,一旦人多了,那么内存可能不够,所以会考虑主从结构,分担压力。为了保证数据的稳定性,也会有类似的考虑,那么问题来了,如何实现saiku的分布式搭建哪?

我阅读了一些国内的文章,没有发现类似的经验,自己摸索了一个方案,简单粗暴,可是能用,大家参考!

首先saiku使用的jackrabbit保存的元数据结构,而他使用repository文件夹保存数据,所以分布式必然要共享文件夹里面的文件,加上saiku升级也是保留这个文件夹,所以我确信如此。

大体思路如下图:

由于公司不支持mount的策略,我这里使用的是定时同步文件的方案。

经验注意:

1、同步文件的时候需要同步隐藏的文件,否则可能读取不到最新的数据内容

2、同步文件之后,刷新页面发现数据依然没有更新,这是正常情况,重启之后成效

3、重启时候发现报错,这个暂时我也解释不了,不过不用担心,因为不会影响正常使用

时间: 2024-08-25 01:00:36

saiku 分布式实践的相关文章

一站式学习Redis 从入门到高可用分布式实践(慕课)第五章 Redis持久化的取舍和选择

Redis持久化的取舍和选择 持久化的作用 RDB AOF RDB和AOF的决择 原文地址:https://www.cnblogs.com/jiang910/p/10025879.html

从分布式一致性谈到CAP理论、BASE理论

问题的提出 在计算机科学领域,分布式一致性是一个相当重要且被广泛探索与论证问题,首先来看三种业务场景. 1.火车站售票 假如说我们的终端用户是一位经常坐火车的旅行家,通常他是去车站的售票处购买车票,然后拿着车票去检票口,再坐上火车,开始一段美好的旅行----一切似乎都是那么和谐.想象一下,如果他选择的目的地是杭州,而某一趟开往杭州的火车只剩下最后一张车票,可能在同一时刻,不同售票窗口的另一位乘客也购买了同一张车票.假如说售票系统没有进行一致性的保障,两人都购票成功了.而在检票口检票的时候,其中一

(二)从分布式一致性谈到CAP理论、BASE理论

问题的提出 在计算机科学领域,分布式一致性是一个相当重要且被广泛探索与论证问题,首先来看三种业务场景. 1.火车站售票 假如说我们的终端用户是一位经常坐火车的旅行家,通常他是去车站的售票处购买车票,然后拿着车票去检票口,再坐上火车,开始一段美好的旅行----一切似乎都是那么和谐.想象一下,如果他选择的目的地是杭州,而某一趟开往杭州的火车只剩下最后一张车票,可能在同一时刻,不同售票窗口的另一位乘客也购买了同一张车票.假如说售票系统没有进行一致性的保障,两人都购票成功了.而在检票口检票的时候,其中一

Java企业级电商项目架构演进之路 Tomcat集群与Redis分布式百度云实战分享

muke慕课实战课程分享QQ313675301 新增课程: Java企业级电商项目架构演进之路 Tomcat集群与Redis分布式百度云实战分享 后端开发: 1.高级java软件架构师实战培训视频教程2.大型SpringMVC,Mybatis,Redis,Solr,Nginx,SSM分布式电商项目视频教程3.Spark Streaming实时流处理项目实战4.Java校招面试 Google面试官亲授5.Java开发企业级权限管理系统6.Java大牛 带你从0到上线开发企业级电商项目7.Java

漫谈spring cloud分布式服务架构

详情请交流  QQ  709639943 01.漫谈spring cloud 与 spring boot 基础架构 02.漫谈spring cloud分布式服务架构 03.Node.js入门到企业Web开发中的应用 04.精通高级RxJava 2响应式编程思想 05.Java秒杀系统方案优化 高性能高并发实战 06.Java深入微服务原理改造房产销售平台 07.快速上手Linux 玩转典型应用 08.快速上手Ionic3 多平台开发企业级问答社区 09.Java Spring Security开

分布式、微服务、集群概念梳理

分布式.微服务.集群概念梳理 分布式 从本质上讲分布式表明的是一种解决方案,即由传统的单体应用,扩展成多体结构. 它的实施基础就是将可以独立出来的功能模块放在不同的服务器上,然后通过REST,RPC,消息中间件等方式来实现不同服务器之间的通信,这些不同服务器上的不同模块实现通信后,最后组成多体应用. 说的分布式,就不得不提到SOA架构,SOA是软件开发重要的思想,即面向服务的体系结构,是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来.接口是采用中

蚂蚁金服十年自研分布式中间件,成就世界级新金融科技平台

中间件,是与操作系统和数据库并列的传统基础软件三驾马车之一,也是难度极高的软件工程.传统中间件的概念,诞生于上一个"分布式"计算的年代,也就是小规模局域网中的服务器/客户端计算模式,在操作系统之上.应用软件之下的"中间层"软件.早期中间件的出现,是为了解决日益复杂的PC服务器.网络甚至不同地理位置机房之间等异构硬件环境中,支撑应用软件的挑战.与操作系统和数据库不同,中间件并没有一个明确的定义,通常来说包括消息.数据.远程过程调用.对象请求代理.事务.构件等几个部分.

从一笔金币充值去思考分布式事务

此次分享的缘由 支付重构 考虑支付重构的时候,自然想到原本属于一个本地事务中的处理,现在要跨应用了要怎么处理.拿充值订单举个栗子吧,假设:原本订单模块和账户模块是放在一起的,现在需要做服务拆分,拆分成订单服务,账户服务.原本收到充值回调后,可以将修改订单状态和增加金币放在一个mysql事务中完成的,但是呢,因为服务拆分了,就面临着需要协调2个服务才能完成这个事务 所以就带出来,我们今天要分享和讨论的话题是:怎么解决分布式场景下数据一致性问题,暂且用分布式事务 来定义吧. 同样的问题还存在于其他的

分布式事务的背景(一)

背景 LCN框架在2017年6月份发布第一个版本,从开始的1.0,已经发展到了5.0版本. LCN名称是由早期版本的LCN框架命名,在设计框架之初的1.0 ~ 2.0的版本时框架设计的步骤是如下,各取其首字母得来的LCN命名. 锁定事务单元(lock) 确认事务模块状态(confirm) 通知事务(notify) 5.0以后由于框架兼容了LCN.TCC.TXC三种事务模式,为了避免区分LCN模式,特此将LCN分布式事务改名为TX-LCN分布式事务框架. 框架定位 LCN并不生产事务,LCN只是本