这话题有点大!回答起来有些难度,主要是怎么回答都有不足的地方。尽量多写一点:1 服务器的选择:cpu 尽量找高的主频,这个很重要!!!内存差不多就行64 32 甚至16GB都也能凑合。 磁盘最好用ssd当然是最好的,尽量做个raid1
他应该不是个迁移工具。不太适合是个各个平台抽取数据的时候使用。很少在迁移库的时候去用到。
大体就是高并发查询场合! 举个例子! 比如一个产品信息,同时有6000人在看。这个时候要从redis去读。
这个好像不行,可以看不到表的数据。表名好像能看到!!!!哈哈。不知道之后有没有改进
咋说呢!网的比较我就不说了。之前是做oracl dba 和 dev 方面的很久之前。从12年接触了8.4 9.0 版本。开始感觉有点不好!但是越学越感觉,oracle 的钱确实白花了。哈 ,特别在开发速度上,绝对pg很顺手,但你要
pg 膨胀就是个灾难问题。哈,个人认为,咋处理都有点那个!!!!硬伤!我这处理的经验基本有几个点,基本都是为了避免膨胀后者避免碰撞带来的效率问题(io)!1场景 比如临时表的使用,在自己的session 里面把需要做的 u d 都做
1 看主要业务,要是这个业务确实没有任何的瓜葛,那么就要分库。比如你们的自己人力系统和你们给客户开发的产品系统。2 但凡有点瓜葛关系,尽量 schema 模式,这个是最保全的方式,因为他可以之后再分离成数据库3 主
你好,这个问题真的没这么弄过。迁移是个很常见而且很闹心的问题,一般迁移我是这么做的,也许对你没有作用!1 生产mysql 库表结构,然后各种的替换类型啊,语法啊,等等 形成pg的语法。2 自增的问题交易3 找个合适的迁移
1 这个问题在个别场合里会有碰到。基本用的都是分开区域的处理方法。比如:你可以 把select setval('blue_item_id_seq',100000000,false);设置很大1亿开始的。自动插入的都是1以后的数据,自增的都是都是自己的值(这个
1 首先说这个是数据库基础理论问题2 我个人认为myslq 也不会成功 (如果id 是数字类型的主键)可以再聊聊你的正式需求和场景
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30