分表,集群任务总结

分表,集群任务总结

1.分表对Mysql主从的影响
  场景:esfpicture数据库已建好,并且已分表,历史数据已插入到对应的分表,现在需要插入增量数据;
  在esfpicture数据库,分表esfpicture0-esfpicture99都会放在esfpicture数据库.这个数据库默认是没有做主从同步的,如果在执行如果下的sql,会导致主从数据同步出现中断,因为从数据库也会执行这样一条sql,但是从执行会出错;
INSERT INTO esfpicture0 SELECT * FROM public.`esfpicture` WHERE hid%100=0;  
2.在应用分表实体bean反射时,注意”serialVersionUID”

  实体bean的第一个字段都是serialVersionUID”,在应用反射获取到Field集合时,需要过滤掉第一个字段;并且第二个字段必须为主键;
3.应用的接口注入

  Spring版本需使用3.x版本,并且接口需添加cache参数,配置如下:

<beanid="esfpictureManager" class="org.springframework.jndi.JndiObjectFactoryBean">

<property name="jndiTemplate">

<ref bean="shardJndiTemplate" />

</property>

<property name="jndiName" value="esfpictureManager/remote" />

<property name="cache" value="false"></property>

</bean>

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

java.lang.RuntimeException: cluster invocation failed, last exception was: 
org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterChooserInterceptor.java:166)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)

4.部分接口的修改没有到位。有的查询可以走分表查询,有的需要修改调用的业务。

5.ejb 实体bean注解需要添加库名

@Table(name = "esfpicture.esfpicture")

转载于:https://www.cnblogs.com/jiwuyf/p/3844244.html

### 数据库或搜索引擎中的索引分表策略最佳实践 #### 一、数据库索引的作用与设计原则 在数据库中,索引是一个重要的组成部分,用于加速数据检索操作。合理的索引设计能够显著提高查询效率,减少I/O开销。然而,在大规模数据场景下,单一表格可能无法满足性能需求,此时需要采用分表策略来进一步优化。 根据已有研究[^1],索引的本质是对数据进行预处理和分类,以便快速定位目标记录。因此,在设计索引时应遵循以下原则: - **选择性高的列优先建立索引**:如果某一列的重复值较少,则该列适合作为索引键。 - **避免过度创建索引**:过多的索引会增加写入成本,并占用额外的空间资源。 - **结合实际查询模式调整索引结构**:例如,对于范围查询频繁的字段,B树类型的索引更为合适;而对于精确匹配查询,哈希索引可能是更好的选择。 ```sql -- 创建复合索引示例 CREATE INDEX idx_user ON users (last_name, first_name); ``` --- #### 二、分表策略概述及其应用场景 当单张表的数据量达到一定规模后(通常超过千万级别),即使存在有效的索引机制也可能面临性能瓶颈。这时可以通过分表的方式缓解压力。常见的分表方法有两种: ##### (1)水平分表 将同一逻辑表按照某些条件分割成多个物理子表,每个子表只包含部分原始数据行。这种方法适用于数据量巨大但各条目间无明显关联性的场合,比如日志记录或者交易明细等。 依据参考资料[^4]可知,水平分表的具体实现方式包括但不限于按时间维度切分(每日/每月一张新表)、基于主键取模分配到不同桶内等等。需要注意的是,实施过程中要充分考虑到后续跨表联合查询的成本问题。 ##### (2)垂直分表 把原表拆解为若干个小表,其中每一个小表仅保留特定几项属性信息而不是完整的整行内容。这种做法特别适合那些少数几个热点字段被高频访问的情况——通过分离冷热数据可以有效减轻读负载。 案例分享指出[^3],面对十亿级订单这样的海量数据集时,除了简单的分区外还需要深入探讨冷热数据划分标准以及同步方案等问题。 --- #### 三、具体实施方案建议 以下是几种典型的索引加分布组合的最佳实践经验总结: 1. **利用覆盖索引来减少回表次数** 当前主流的关系型数据库支持构建覆盖索引(Covering Index),即将所需的所有字段都纳入同一个索引节点之中,这样可以直接从索引树获取全部必要资料而无需再回到基底表查找详情。这对于OLAP类分析任务尤其重要。 2. **引入分布式文件系统配合Sharding Key规划** 对于超大型集群环境下的NoSQL解决方案而言,预先定义好合适的shard key至关重要。它决定了最终数据会被均匀散布在哪台机器上面。同时借助HDFS之类的底层设施完成持久化存储工作。 3. **定期执行统计信息更新维护计划** 随着业务发展变化,原有的索引布局可能会逐渐失效甚至成为新的拖累因素之一。所以应该周期性地重新评估现有配置状态,并及时作出相应修正动作。 --- #### 四、注意事项与其他考量要素 尽管采取以上措施能够在很大程度上改善整体表现效果,但仍需警惕可能出现的新风险点。例如并发控制冲突加剧可能导致死锁现象发生频率上升;另外由于增加了复杂度故而在日常运维环节也需要投入更多精力去监控健康状况指标变动趋势。 最后强调一点就是无论选用何种技术路线图都应该紧密围绕项目本身特点来进行定制化开发调试过程直至达成预期目标为止。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值