• zombodb不错

  • 一招秒杀 N+1 agg 问题 at 2018年12月13日

    select的时候COALESCE一下或自己判断都可以

  • 算BaaS了吧

  • MySQL是web 2.0时代的产物啊,LAMP标配,不过新项目的话,pg还是最佳选择。

  • 图解 Unicorn 工作原理 at 2018年12月07日

    你说的是mongrel的作者吧

  • 最近在写,一个大概的提纲:

  • 买过,看你想入门还是已经有经验了,有经验了的话不建议买。

  • protip: 存decimal,app端比较用to_d

  • aws还有一个aurora看起来很厉害:https://aws.amazon.com/cn/rds/aurora/

  • Managed DB问题就是预装extension有限,这方面做的好的是阿里云RDS,预装extension非常全,可能和他们自己也在使用有关吧

  • 牛油果对标的应该是芒果吧,对自己发明一套查询语法的DB没好感,要学的太多,记不住...

  • 😂

  • great 👏

  • 不一定是sql写模型,可以plpython plr结合的,你可以参考下madlib的源码,但使用的时候少了导入导出和ETL部分,过滤的话sql本身就替代了pandas

  • 用了快两年了吧,主要自己看看文档和相关领域专家的blog吧

  • 那就2019咯

  • 最近在用,灰常棒,已经回不去REST了

  • mysql 为什么不走索引? at 2018年11月16日

    建议用 https://www.db-fiddle.com 把信息帖全

  • each_with_index

  • 一招秒杀 N+1 agg 问题 at 2018年11月11日

    因为你的条件有deleted at ,要加符合索引,我试过没问题的,你看我上一个回帖后面的结果。

  • 一招秒杀 N+1 agg 问题 at 2018年11月10日

    可以试试 把left join改成LEFT JOIN LATERAL,加个条件 OrderItem.where("orders.id = order_items.order_id").group

    SELECT orders.*, aggs.* FROM "orders" LEFT JOIN LATERAL (SELECT order_id, COUNT(*) AS items_count FROM "order_items" WHERE "order_items"."deleted_at" IS NULL AND (orders.id = order_items.order_id) GROUP BY "order_items"."order_id") AS aggs ON aggs.order_id = orders.id ORDER BY id desc;
    
    Sort  (cost=31853.46..31862.86 rows=3759 width=344) (actual time=26.134..26.694 rows=3759 loops=1)
      Sort Key: orders.id DESC
      Sort Method: quicksort  Memory: 2035kB
      ->  Nested Loop Left Join  (cost=0.28..31630.25 rows=3759 width=344) (actual time=0.041..21.992 rows=3759 loops=1)
            ->  Seq Scan on orders  (cost=0.00..289.59 rows=3759 width=328) (actual time=0.014..0.904 rows=3759 loops=1)
            ->  Subquery Scan on aggs  (cost=0.28..8.33 rows=1 width=16) (actual time=0.004..0.005 rows=1 loops=3759)
                  Filter: (aggs.order_id = orders.id)
                  ->  GroupAggregate  (cost=0.28..8.31 rows=1 width=16) (actual time=0.004..0.004 rows=1 loops=3759)
                        Group Key: order_items.order_id
                        ->  Index Scan using index_order_items_on_order_id on order_items  (cost=0.28..8.30 rows=1 width=8) (actual time=0.002..0.003 rows=1 loops=3759)
                              Index Cond: (orders.id = order_id)
                              Filter: (deleted_at IS NULL)
                              Rows Removed by Filter: 0
    Planning time: 0.411 ms
    Execution time: 26.936 ms
    

    不用lateral的话,你要加索引[order_id, deleted_at],我本地是没问题的,带order by id desc:

    Limit  (cost=495.12..498.33 rows=10 width=344) (actual time=16.001..16.218 rows=10 loops=1)
      ->  Merge Left Join  (cost=495.12..1702.50 rows=3759 width=344) (actual time=16.001..16.217 rows=10 loops=1)
            Merge Cond: (orders.id = order_items.order_id)
            ->  Index Scan Backward using orders_pkey on orders  (cost=0.28..1144.43 rows=3759 width=328) (actual time=0.105..0.283 rows=10 loops=1)
            ->  Sort  (cost=494.84..503.81 rows=3589 width=16) (actual time=15.886..15.889 rows=10 loops=1)
                  Sort Key: order_items.order_id DESC
                  Sort Method: quicksort  Memory: 249kB
                  ->  GroupAggregate  (cost=0.28..247.03 rows=3589 width=16) (actual time=1.900..14.025 rows=3257 loops=1)
                        Group Key: order_items.order_id
                        ->  Index Only Scan using tindex on order_items  (cost=0.28..187.50 rows=4727 width=8) (actual time=1.887..11.415 rows=4727 loops=1)
                              Index Cond: (deleted_at IS NULL)
                              Heap Fetches: 32
    Planning time: 0.716 ms
    Execution time: 16.316 ms
    
  • uuid更浪费,主键不止要存在一张表里,还要在其他表作为外键,还要加索引,所以内存和磁盘空间都带来没有必要的增长,云服务商应该是最希望看到uuid主键了。

    1. flock or redis lock
    2. k8s job可以配置
  • 为何要mix oltp olap呢?聚合查询在slave做或etl到一个analytics db这是很容易的。oltp olap混用可能500万一张表会出问题,但这是架构问题…

  • 冷热分两种db?真是no zuo no die…要么老老实实做sharding要么换个可以auto sharding的库,要么搞proxy…

    你上面的流程能work的前提是你的系统只存在简单的select查询…

    你们是啥系统,都达到这种规模,但还搞出这种过家家一样的方案,交易所吗